Chapter 4 |
Certificates and Certificate Authorities |
SSL requires the use of a certificate authority (CA). The CA prevents "man-in-the-middle" attacks on your Web server. You need to be certain that no third party is intercepting communications and violating the integrity or privacy of your transmissions. Users who access your site also need to be certain the no such interception can compromise their security.
This document discusses
In order to encrypt transmissions to your server, the client requires the server's public key. The integrity (not the privacy) of the key is vital to the security of the subsequent SSL session. If a third party replaced it with his own public key, that "man-in-the-middle" could view all traffic, or even modify the data in transit. Neither the client nor the server would detect the intrusion.
To prevent this, the server sends the public key in a certificate signed by a certificate authority. The client checks that digital signature. If the signature is valid, the client knows that the CA has certified that this is this server's authentic certificate, not a certificate forged by a "man-in-the-middle."
The CA must be a trusted third party in order to provide meaningful authentication.
If you are using Stronghold for Internet-wide transactions, choose a CA trusted by as many people as possible. It is important that users feel safe connecting to a Web site that claims to be secure. It is important that they trust that the data they are transmitting and receiving has not been modified or viewed by unauthorized third parties.
Currently, there are only a few Internet-wide certificate authorities. The most popular of these is VeriSign. VeriSign realizes the importance of trust in the certification industry and has taken many steps to become the trusted name on the Internet. Being the first in the field, they have made mistakes and improved with experience, though the rapid innovation of network burglars makes future missteps unavoidable for any CA.
Prior to version 2.0, Netscape Navigator only trusted VeriSign. Other CAs were acknowledged, but VeriSign was the only one used. With the release of Navigator 2.0, clients were given the option of trusting certificate authorities other than VeriSign. With Navigator 3.0 (still in beta as of this writing, and subject to change), more CAs are built into the client as default-trusted CAs, and the ability to trust additional CAs remains.
If you install Stronghold for access by a limited number of people, such as within a corporate firewall, the issues become much more complex. Under no circumstances, however, should the server be installed with a "self-signed certificate." The self-signed certificate installed with Stronghold for testing purposes only. A server running with a self-signed certificate provides no protection against the man-in-the-middle attack.
Depending on your security needs, you can choose to use an external CA, such as VeriSign, or an internal CA controlled by your own organization. Each has benefits and drawbacks.
Using an external CA is the simplest option. The Stronghold installation script automatically generates a certificate signing request for you to fill out, sends it for you, and you receive a signed certificate in a few days. No expensive training or startup fee is required. Be aware, however, that different certificate authorities have different policies. Investigate CAs before you choose one that is appropriate for your needs.
The largest drawback of this approach is that is sacrifices local control and confidentiality in favor of usability. By involving an external agency in the installation of your SSL-secured Web server, you may be subjecting sensitive data to external eyes or inadequate security measures. In some cases, this violates a site's security policy. By keeping a private CA, there is little risk of such a violation. A private CA can also be more responsive to the needs of people requesting certificates within the organization. Furthermore, since the CA is local, the organization has absolute control over the security policy. The security surrounding the CA can be as strong or as weak as required.
The drawbacks of the local CA lie in the expense of setting one up. Setting up a high-security CA requires dedicated, RF-shielded hardware, for example. Highly trusted personnel must be trained to operate the CA. Unless the organization is very large, setting up an internal CA may cost more than using an external CA--even though it may appear cheaper at first.
Another option combines the local control of the internal CA with the outsourcing benefit of the external CA. VeriSign offers "private label services" which allow people to build internal CAs while gaining leverage from VeriSign's existing investment in hardware, people, and knowledge. Contact VeriSign for more information.
You should receive your signed certificate within a few days after you submit the CSR using genkey or genreq. Use getca to install it:
# getca hostname < /tmp/cert # rm /tmp/cert
The certificate includes your server's public key and other identifying information about the server. It is also signed with the CA's private key. Since the client can obtain the matching public key directly from the CA, successfully decrypting the certificate shows the client that the certificate is valid and authorized by a trusted third party--the CA. It can therefore trust that the information in your certificate is correct and the public key belongs to your server. In this way, certificates prevent malicious parties from intercepting data packets and substituting their own encryption keys, which would allow them to decrypt all of your transmissions.
You can create a private certificate authority for your Intranet to certify internal web servers. Since these servers are typically accessed only by internal clients, a private CA can provide a sufficient level of trust within certain security policies.
It is your responsibility to follow an adequate security policy. Choose your CA platform carefully, and maintain it under the strongest security:
Stronghold provides tools for setting up a basic certificate authority. To do this, you must
Keep in mind that you can also use XCert Sentry to set up a more complex CA, which includes an Apache module and LDAP support, among other things.
The makeca script sets up the CA by generating a key pair and self-signed certificate for the CA. Be sure ${SSLTOP} is set appropriately.
Once the CA is built using the makeca script, you should edit the ${SSLTOP}/lib/ssleay.conf file to fit the policy for the Certificate Authority that you've built. Pay special attention to the policy section. This is the section you need to edit in order to limit the fields for requests which your CA will sign. (In most cases, your CA will only sign keys within in the same organization as the CA. In this case you should set the policy to policy_match, which requires that the countryName, stateOrProvinceName, and organizationName of the certificate request match the respective information in the Certificate Authority's information.)
Now that the Certificate Authority has been built and the policy configured, you need to publicize within your organization the CA's certificate, so that you user's client software accepts server's certificates signed with your private CA. The file ${SSLTOP}/CA/cacert.pem is where the makeca script stored your CA's certificate. Netscape Navigator 2.0 uses a MIME type of application/x-x509-ca-cert to denote a Certificate Authority certificate. See the Netscape site for how Navigator deals with certificates.
Make sure your users install your new certificate in Netscape Navigator and their other client programs.
The CA certificate must be in DER format when downloaded to Navigator with the application/x-x509-ca-cert MIME type. In order to convert the PEM certificate format to DER format, you just use the x509 program:
# x509 -outform DER \ < /usr/local/ssl/CA/cacert.pem > /usr/local/apache/htdocs/myca.cacert
Now you need to setup a mechanism by which people will submit Certificate Signing Requests (CSRs) to your Certificate Authority. You perhaps should setup an email address to which people can mail their CSRs. You also need to define your organization's policy regarding the level of documentation before your CA will issue a signed certificate for a given CSR. You need to establish a policy such that you can be sure that the information in the certificate is the correct information for the person or group within your organization submitting the certificate request. When someone in your organization then installs an SSL application (such as Stronghold or Netscape Commerce), they can send the CSR to your private CA address.
When you receive a CSR, make sure you first verify` the origin of the CSR according to your policies as you've defined them above. Then, after you've determined that you desire to issue a signed certificate, pass the CSR through the ca program. This program will print out information regarding the CSR. Verify that the information is compliant with your organization's policy again, and then answer "y" to both questions to issue a certificate. Send the signed certificate back to the requestor.
The default SSLeay settings are recommended. However, in order to use the CA according to your organization's security policy, you may need to edit the ${SSLTOP}/lib/ssleay.conf file.
Once you have set up the private certificate authority and publicized it, establish a procedure for collecting and processing CSRs. Depending on the number of CSRs you need to accommodate, you can construct an automatic mechanism for signing certificates or sign them one by one through email or file transfer.
# ca -config ${SSLTOP}/lib/ssleay.conf -in /tmp/csr