An Overview of Private/Public Keys and Server Certificates
To understand how server certificates work, an understanding of Public Key/Private Key principles is helpful. Here's an overview.
Each party that wishes to participate in secure communications must create a key set for encrypting and decrypting messages. One key is private and the other is public. The public key is for exchanging with other parties with whom you who wish to participate in secure communication sessions. Each individual owner must keep the private portion of the key secure. The private key also has a secret pass phrase, in the event that it is ever 'misappropriated'.
Here's how it might work. Let's say Bob and Janice want to communicate securely; they each create a key set and exchange public keys. Bob uses Janice's public key to encrypt a message that only she will be able to read when she decrypts it with her private key and secret pass phrase. If Janice wishes to issue a secure reply, she uses Bob's public key to encrypt the message so that only Bob can decrypt.
This seems somewhat straightforward but let's introduce a complication. When Janice receives Bob's initial message, how does she really know that it was Bob who sent the message? The header said it was from Bob and perhaps Bob was the only person that Janice gave her public key to. But it is certainly possible that someone else could have 'found' Janice's public key and tried to impersonate Bob.
Public keys aren't secure - they are, by their nature, public. So, how can you be assured of the sender's identity? Simple - the sender must sign the message … electronically.
Public key/private key technology allows the sender to sign a message with their private key. When the recipient receives the message, they can validate the authenticity of the signature because they have the sender's public key.
Apache server certificates work in a similar way to Bob and Janice's exchange.
As a web server administrator, you will generate a public/private key pair for your server. You will pass out the public key to all visitors who are planning to send you confidential information. Using your public key, they will encrypt the confidential information so that only your server can decrypt it. But, much like Janice's dilemma, how will your user know that you are who you say you are before they send you this sensitive information? That's where the certificate comes in.
You must request a Certificate Signing Request from a Certificate Authority that your users can trust. During the installation of a NuSphere product, you can create a test certificate, but this is not sufficient for production purposes. VeriSign and Thawte are two of the many Certificate Authorities. You provide them with documentation to prove that you are who you say you are, along with your server's public key. They, in turn, will provide you with a server certificate, which consists of:
- Your server's public key
- Your Company Name
- Their name as the Certificate Authority
- Their digital signature as the Certificate Authority
Figure 1: Flow of Server Certificate on Secure Web Site
How it all comes together:
- Your user connects to your SSL-enabled secure site using an https:// url rather than an http:// url.
- Your server presents its certificate to the user's browser and it, in turn, examines the certificate's credentials and attempts to verify that the Certifying Authority is one that it recognizes and can trust to verify the digital signature.
- If all goes well, it will use the associated public key to encrypt the sensitive information so that only your server can decrypt it.
- If not, the browser will issue a warning, telling the user that it doesn't recognize the Certificate Authority.
To read more about how SSL and Digital Certificates work, visit
http://www.modssl.org/docs/2.6/ssl_faq.html or
http://www.openssl.org/support/faq.html
For more hints and answers to frequently asked questions, visit our Tech Library. | 
