Acquiring and using your Certificate

Once you've chosen a certificate authority, you must submit a standardized request to the CA in order obtain your certificate. This standardized request is known as a “certificate signing request” or CSR. The CSR phase starts out with generating a cryptographic public/private key pair. As their names imply, the private key is kept secret, while the public key is widely distributed.

Your public key is bundled with other identifying information such as your company name, company address, and web site URL. This bundle is then “signed” with your (secret) private key, and finally sent off to your certificate authority of choice. A typical CSR is shown below:

-----BEGIN CERTIFICATE REQUEST-----
MIIB7zCCAVgCAQAwga4xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcgWW9yazEP
MA0GA1UEBxMGSXRoYWNhMRowGAYDVQQKExFBY21lIEJ1cnJpdG9zIDEyMzEUMBIG
A1UECxMLSVQgRGl2aXNpb24xIDAeBgNVBAMTF3d3dy5hY21lYnVycml0b3MxMjMu
Y29tMScwJQYJKoZIhvcNAQkBFhhpbmZvQGFjbWVidXJyaXRvczEyMy5jb20wgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMVvXVb+boOxTUyEZaLx+5MMKLqy3NJN
RomD+Q3DV6mtMKXOdlJ2gnZzNLPrM3fNgiK+Vk4BbMSRX0azl/qx6FqppCmkAzKa
pMyPJetCsEi6llet8cgOWhFk+LrXNR36UIv795hSiGO2PGE/mgpyBE8JhTHDFH6T
kLDot1QtR9mHAgMBAAGgADANBgkqhkiG9w0BAQUFAAOBgQBYjfFVdJLyZO+5gE1U
HWv//FbUUG2Go/Wf7+/J0PkwvkAa2VZv5pNWXNJkp3rQgpdk9u4w337du4Q3B5mF
UPLb1+lmHYXJ0kLspTMX3oGU4gRdPfHGjeljCY93x4QpfgyIZOB++yl8uTYZvaSK
xFVAkcajkxi1TlxFAF2qzoplNw==
-----END CERTIFICATE REQUEST-----	 

Upon receiving your CSR, the certificate authority will then begin the verification phase of the process. During this phase, the CA will attempt to verify the legitimacy of your business through various methods. In some cases, verification may be as simple as replying to an automated email, or as complex as faxing numerous documents providing proof of organization. Ultimately, you must choose the right balance between security and convenience for your organization.

Once the certificate authority successfully verifies the legitimacy of your business, they will then issue you an actual X.509 certificate to be used for SSL/TLS communications on your server. The key point here is that the certificate has been signed with the CA's private key. As the computer systems used by your customers will have the corresponding CA's public key installed, they will deem your certificate as authenticate and will therefore trust that the the given CA legitimately signed your certificate. Once installed on your server, your digital certificate will be presented to visitors to prove the fact that the legitimacy of your business has been verified by a trust third party.

In addition to verifying the authenticity of your business, the certificate also provides a vehicle for the delivery of your public cryptographic key to the customer. Once the customer has your public key, he or she will use this key to commence secure (encrypted) SSL sessions. As mentioned earlier, asymmetric cryptography helps to solve the key distribution dilemma by securely distributing keys to potential customers. The unfortunate side-effect of public key cryptography is that it's quite slow. In order to provide balance between secure key distribution and performance, SSL starts out by building a secure channel using public key cryptography, but then switches to private key crypto once a secure channel has been established. For example, a typical SSL session may start out using 768-bit RSA, then switch to 128-bit RC4.

Customers commencing new secure sessions with your server will use your server's public key to encrypt all data. Your server will then use the highly secret “private key” to decrypt all data. Even though customers may encrypt data with your public key, only the private key holder is capable of decrypting the information. Therefore, securing your private key is of utmost importance. Keeping your private key on a secured file system in which only proper personnel have access to would be the first step in keeping your key safe. Additional steps may include storing the key on an encrypted file system, or securing the key file itself with a passphrase.

If your private key is ever lost, the corresponding public key becomes useless as you may no longer decrypt data from public key wielding customers. If your private key is compromised by an intruder, communications may no longer be deemed confidential as the intruder may use tools such as ssldump to decode previously recorded encrypted communications. In either scenario, the certificate must be immediately replaced using a new public/private key pair. You may optionally place the old certificate in a special list which conveys to customers that it must no longer be used. This list is known as a certificate revocation list, or “CRL” for short. Well-written SSL and TLS applications should examine relevant CRLs using protocols such as OCSP prior to using a server's public key.