Certificates for SSL Applications

Configuring Certificates in the SSL Client and Server

SSL client and server applications might require four certificates:

A root CA is a CA certificate that is located as a root in a certificate signing hierarchy. A root CA is not signed by any other CA - it is signed by itself. In Figure 4-3 “ Client and Server Certificates Directly Signed by CAs” and Figure 4-4 “ Client and Server Certificates Indirectly Signed by CAs”, the CA certificates correspond to root CAs.

For successful certificate verification, the certificates must have the proper signing relationships, as shown in Figure 4-3 “ Client and Server Certificates Directly Signed by CAs” and Figure 4-4 “ Client and Server Certificates Indirectly Signed by CAs”. In Figure 4-3 “ Client and Server Certificates Directly Signed by CAs”, the client and server certificates are directly signed by their peers- CAs.

Figure 4-3  Client and Server Certificates Directly Signed by CAs

	NOTE: The client and server certificates are not necessarily directly signed by the CAs (see Figure 4-3 “ Client and Server Certificates Directly Signed by CAs”). In some cases, the certificate is signed by an RA (registration authority) or an intermediate CA whose certificate is signed by the CA that is trusted by the peer. (The client certificate in Figure 4-4 “ Client and Server Certificates Indirectly Signed by CAs” is an example of this situation.) In other cases, the certificate's signing chain may involve more RAs or intermediate CAs. (The server certificate in Figure 4-4 “ Client and Server Certificates Indirectly Signed by CAs” is an example of this situation.)

As long as the chain depth setting is appropriate (that is, the certificate chain depth for verification is longer than the depth from the CA to the certificate being verified), the certificate verification succeeds.

Figure 4-4  Client and Server Certificates Indirectly Signed by CAs

Figure 4-5 “ Certificates on SSL Client and Server (Case 1)” depicts the most common deployment of certificates. This deployment is often used when establishing SSL connections between web browsers and a web server. As part of its initialization, the SSL server loads a certificate (server certificate) signed by a CA. This CA is trusted by the SSL clients. When a client verifies the server, the server certificate is sent to the client and then is verified against the CA certificate. The fact that the server has a certificate signed by a trustworthy CA means that the server can be trusted by the client, because the client trusts the CA. This certificate setup prevents the SSL client from establishing an SSL connection with an untrustworthy SSL server.

Figure 4-5  Certificates on SSL Client and Server (Case 1)

In addition to server certificate verification on the SSL client, you can perform client certificate verification on the SSL server. This is shown in Figure 4-6 “ Certificates on SSL Client and Server (Case 2)”. Web sites that require higher security, such as banks and online brokers, deploy this model. The SSL client connecting to this type of SSL server is requested to send its certificate (client certificate) to the server. The SSL server then performs client authentication based on the client certificate verification.

This method is the same as the one used in Figure 4-5 “ Certificates on SSL Client and Server (Case 1)”, but in this case the server checks the client certificate against the server-s CA certificate to establish the level of trust. Using this implementation, the SSL server can achieve enhanced client authentication by combining with another authentication method, such as requiring a user name and password.

Figure 4-6  Certificates on SSL Client and Server (Case 2)

Obtaining and Creating Certificates

If the proper certificates are not in place, the SSL application user or developer must either create them or obtain them from a trustworthy organization such as a CA or RA. The SSL command line interface (described in Chapter 5) and Certificate Tool (described in Chapter 3) allow you to create X.509 certificates. Figure 4-7 “ Certificate Creation Process” shows the process for creating an X.509 certificate.

Figure 4-7  Certificate Creation Process

When you obtain or create a certificate, consider the following:

Algorithms: RSA certificate with RSA keys or DSA certificate with DH keys

Although RSA certificates are commonly used for SSL, DSA certificates can be loaded in the SSL structure as well. (Most SSL servers load only RSA certificates. SSL servers that use DSA certificates are rare.)

	NOTE: RSA and DSA certificates and keys are incompatible. An SSL client that has only an RSA certificate and key cannot establish a connection with an SSL server that has only a DSA certificate and key.

To avoid this problem, you can load both RSA and DSA certificates and key pairs in the SSL_CTX and SSL structure. (For more information, see the description of the SSL_CTX_use_certificate() and SSL_CTX_set_cipher_list() APIs in this manual.)

If you use a DSA certificate, you must load DH keys. Although the RSA algorithm is used for both key exchange and signing operations, DSA can be used only for signing. Therefore, DH is used as the key agreement algorithm with a DSA certificate in an SSL application.

	NOTE: DSA certificates and DH keys cannot be created with the OpenVMS SSL Certificate Tool (described in Chapter 3). Use the SSL command line interface, described in Chapter 5, instead.

Key size: 512-bit, 1024-bit, or others

You must specify the key size of the algorithms when you create a certificate. The key size affects security and performance of the SSL application. A longer key makes the application more secure, but it can slow performance. A shorter key makes encryption and decryption faster, but lowers security.

Usually RSA and DSA keys are 512-bit, 1024-bit or 2048-bit. (1024-bit keys are the most commonly used.) In some cases, you must decide the key size based on the application-s requirement or corporate or national security policy.

Certificate and key formats: PEM, DER or others

The OpenSSL command line interface supports the following three certificate formats:

The most common certificate format for SSL applications is PEM. The SSL Certificate Tool, described in Chapter 3, supports only the PEM format. If a DER certificate is necessary, use the SSL command line interface, described in Chapter 5.

Security policy of the application using the certificates

Check the application-s security policy or requirements when you issue certificates. Some applications require certain attributes or values in the X.509 certificates. For example, SSL applications for financial transactions might have a security policy to use 1024-bit or longer RSA keys, or certain extensions in an X.509 certificates might be mandatory.

Many countries have national policies regarding encryption. Using and exporting strong encryption algorithms and keys might be affected by these policies. Also, some organizations might have policies that disallow their employees using strong encryption.