VeriSign certification of cryptographic keys


Introduction: Certificates

SSL enables a user agent (typically a web browser) to communicate securely with a web server; in the process of establishing this secure connection, the user agent can verify, from the responses it receives when it contacts a web site, that those responses are really coming from the web site in question - rather than from an impersonator. Both the security of communication and knowledge of the web server's identity are achieved using a certificate, which is `signed' by a `Certificate Authority', such as VeriSign, in response to a `certificate request'.

Your Keys

A web site's security ultimately depends on a pair of cryptographic keys: one public, the other private. A message may be encoded by either key; the result can only be decoded using the other. During the initiation of an SSL session, the user agent sends the web server a message encrypted with the web site's public key: the user agent knows what it encoded, but only the web server can decode it; consequently, after this message is sent, only the web server and the user agent know what was in the message; so the two are able to use it as (part of) a `shared secret' when establishing their secure connection.

It is very important that you keep your private key secret and do not lose it. (Your public key, in contrast, shall be published to all visitors to your web site; and if you lose it you can regenerate it from your private key.) Keeping your private key secret involves ensuring that the file which holds it can only be read by the web server: you may also need to ensure one other user, yourself, can read it; but no other users should be able to read it. When the Zeus Web Server generates a private key for you, it will ensure that only it can read the file. Keeping your private key secret also involves not placing it in a directory which your web server will show to visitors to your web site. For example, do not put your private key in a directory under your web server's document root directory.

If you generate a private key, you will need to specify the size of the private key. The larger your key is, the more time it will take for software to encode and decode messages using your key; but equally the longer it will take for a cryptanalyst to `break' it. By default the Zeus key manager generates a 1024-bit key for maximum security. 512-bit keys offer good enough security for many web sites and do allow for faster connections: if speed is very important to you, you may wish to use a 512-bit key.

Certificates and security

The Certificate Authority (CA) generates its certificate from your public key and some information about you and your web site. The latter information is described as a `distinguished name'. It comprises:

The certificate refers to you as the `subject' and the CA as the `issuer': for each, it provides a distinguished name. The certificate also includes a start date and an expiration date: the certificate is only valid between these dates. The names and dates, combined with your public key, form the body of the certificate.

Just as the web site has a pair of keys, so also does the CA. The CA computes a `digest' of the certificate body: this is like a `checksum' - it depends on the whole of the body, and on nothing else; it will change if the text of the body is changed; and it can be computed by a standard tool (which doesn't depend on anyone's cryptographic keys) - except that it is extremely hard, given the digest of a text, to invent another text with the same digest. Anyone reading the certificate can compute the body's digest and should arrive at the same answer as that obtained by the CA, provided the body has not been changed. The CA encodes the digest with its private key: the result is known as the CA's `signature' for the body. The certificate consists of the body and this signature.

The CA's public key is typically built into user agents. When a user agent is connecting to a secure web server, the server sends its certificate; the user agent computes the digest of the body and uses the CA's public key to decode the signature; if the decoded signature agrees with the digest, the certificate is valid so the user agent checks that the `common name' of the certificate matches the name of the web site the user agent set out to contact. If either part doesn't match, the user agent knows that it is being lied to: otherwise, it knows it's in touch with the web site it intended to contact, so proceeds with the exchange mentioned above, in which the server and user agent establish a `shared secret' and, thereby, a `stream cipher' with which to encode the rest of their communications.

Ordering a certificate on line

To enable SSL, you need a private key and a certificate for the corresponding public key. The Zeus Web Server can generate a private key for you, or you can provide a private key for it to use. It can, from your private key and your `distinguished name', generate a certificate request (and/or a `self-signed public certificate', discussed below). To obtain a certificate signed by a Certificate Authority, such as VeriSign, you need to send a certificate request to the CA. The Zeus Web Server can automatically send your certificate request to VeriSign in a process which is integrated with VeriSign's enrollment forms. This simplifies the ordering and installation (once delivered) of your certificate.

The process begins with a form on your administration server; this provides any preparatory notes appropriate before sending you to VeriSign's site. Here you will be asked questions about the certificate (and any ancillary services) you want to order; in particular, your `distinguished name' will be collected.

The last of these forms will confirm the information gathered: submitting it will POST the information gathered to a form on your administration server, which will then display your distinguished name and ask for your private key, or the name of a file in which to store a newly-generated private key. This form allows you to specify, at the same time, a certificate request file and/or a self-signed public certificate; these can be generated from (or, if they exist already, can be checked against) your private key and distinguished name. You don't need to store your certificate request in a file, but it is prudent to do so; you may want a copy for your records, or you may want to obtain a compatible certificate from another CA at a later date. Likewise, you don't need a self-signed certificate, but (as discussed below) it may assist in testing your site while you wait for VeriSign to process your application for a certificate.

Submitting this form will generate the requested files. It will generate a certificate request in any case; but will only save it to a file if asked to do so. This form contacts the VeriSign enrollment system directly to establish a `transaction identifier' of which you must keep a record in order to be able to renew (or revoke) your certificate at a later date (before it expires). On success, you are then offered a new form which, when submitted, will POST your certificate signing request (among other details) to VeriSign's server and take you to a page at VeriSign's site.

This last begins a chain of pages which will obtain contact and payment details from you; it will also establish a `challenge phrase' and a `reminder question' which, along with your transaction ID, you will need if you are subsequently to renew (or revoke) your certificate. This is explained in greater detail by VeriSign's web pages.

Once you have provided payment and contact details, VeriSign's last form will, once more, return you to your Zeus Administration Server, which can then record that you have completed the enrollment process.

It remains to collect your certificate once VeriSign has verified the details you have told it and obtained payment. Since this may take several days, collection is mediated by a separate form. This collects the name of a file in which to store your certificate; when submitted, it asks VeriSign's web server whether your certificate is ready; if so, it collects the certificate and stores it in the nominated file (if it has trouble storing to file, the form is re-presented and you are asked to suggest another name: it is important to fill in this form, not to go `back' to the previous one, as the new form contains your certificate). If your certificate request is still pending, you will be advised of the delay.

Self-signed public certificates

Between enrollment and collection, you will have a private key but no VeriSign certificate. You can, none the less, generate a certificate by acting as both `issuer' and `subject': such a certificate is described as `self-signed' because it is (issued and) signed by its subject. User agents can verify that the certificate is consistent (it contains the public key they need to decode the signature) but, naturally, cannot trust such a certificate's claim that the subject is a real-world entity or that this entity genuinely holds the private key matching the public key in the certificate.

Provided you can persuade your user agent to accept the insecurity involved in a self-signed certificate, you can test that your web site will work once it is secured: just ask the Zeus Administration Server to generate the certificate (see above, or the SSL configuration wizard) and enable security. You can then test your web site while you wait for your VeriSign certificate to be prepared; once the certificate is installed, user agents will be able to trust your web site without having to be persuaded to accept any insecurity; but they will see the functionality you tested while you were waiting.