How to Use X.509 Certificates and SSL For Secure Communications


Stephen McHenry


As security and privacy become more important for web-based communications, there is a natural migration toward using secure connections to ensure that the information being exchanged is not read by third parties. SSL (Secure Sockets Layer) is one such form of encryption that is commonly used in this scenario. This document provides a brief overview of how SSL/TLS should be used, and considerations that must be taken into account in order to effectively use SSL.


As more and more organizations see the value in, and deploy secure communications, we are seeing an increased frequency of implementations that do not properly account for one or more aspects of either certificate generation and usage, or protocol usage. This document is not intended to provide a complete treatment of how to use SSL and X.509 certificates, but it is intended to provide a short introduction to each of the aspects of using SSL, as well as recommendations and best practices, in order to successfully interact with Google services now and in the future. It also provides some relevant links for those seeking more information.

This document does not contain any proprietary information, and is intended to be given out to customers and/or partners to aid in their planning and implementation efforts.


At its core, SSL uses X.509 certificates to validate connection endpoints (e.g., the identity of the server to which the connection is made). To allow verification of the authenticity of these certificates, they are digitally signed by a certificate authority (CA). In a similar manner, that certificate authority’s certificate is signed by a higher level CA. This continues until the certificate is signed by a CA known as a “Root CA”. A Root CA is a CA whose certificate is considered trusted, and is distributed with the browser or operating system - thereby eliminating the need to download it from a potentially untrustworthy host. Presumably, these Root Certificate Authorities have had their trustworthiness independently evaluated, which is why browser vendors distribute their certificates.

This process of signing certificates, whereby the Root CA signs the next “lower” certificate, and that CA signs the next lower one, down to the server certificate, is known as certificate chaining.

If the certificate at the top level is not a recognized Root CA, then the browser will display a warning message to the user that they are accessing a potentially untrusted site, and ask for permission to continue.

Updating and Revocation

One thing that is important to remember when building applications that use SSL, is that Root certificates can (and do) change over time. Reasons for the change are:
  1. Expiration - All certificates (even Root certificates) expire at some point. All certificates chained off of that root will become invalid and will need to be chained off of a new root certificate when that happens. For example, the A-CERT ADVANCED root (and all certificates that chained off of it) expired October 23, 2011 at 7:14:14 AM.
  2. Deprecated - Standards bodies can mandate the deprecation of keys and algorithms that are deemed weak/insecure. NIST recently deprecated the use of 1024-bit keys, and mandated the move to 2048-bit keys (or longer).
  3. Revocation - Compromise of the private key for a root certificate will cause the issuer to revoke any certificates chained off of it, and reissue new ones under a different root certificate (Note: this might also involve creating and distributing a new root certificate).  Alternately, that compromised CA is likely to be removed from the Root Certificate Authorities that are distributed with browsers or operating systems.
  4. “Just changed” - the “leaf” server certificate could just be signed by a new (or different) root CA. This is most likely to happen just before the server certificate expires and is renewed, but it could happen at any time. Another time this can happen is when a Root CA changes the hashing algorithm, but leaves everything else the same.
As a result, browsers and OSs have mechanisms to periodically update their list of root certificates, so if you build your application using the communication API of the underlying OS, you shouldn’t need to do anything special. However, if you build your own communications layer, it is important that you provide for a way to update the trusted root certificates as they change over time. Failure to do so will result in a fragile application that will break the first time the application contacts a server whose root is not trusted, or contacts a server whose root has changed to one that is not present in the client. Additionally, a possibly even more severe consequence is that you can end up trusting a compromised root, thereby leaving your application vulnerable to dangerous attacks.

So, if you are planning to use SSL to secure your communications, make sure that you provide for a way to update your root certificates as they change.

Subject Alternate Names (SANs)

In the original SSL specification, there was an expectation of one server with one service, and therefore one certificate. Unfortunately, virtual hosting broke that assumption/expectation. If virtual hosting is used, a single server can host multiple host/domain names on a single IP address.

One of the solutions to this was the addition of the Subject Alternate Name extension. This allows a certificate to have additional hostnames for which it is valid. If a server responds to and, can be listed as an alternate name in the certificate, allowing a single certificate to be used for both hostnames.

The client software must check the hostname it is expecting against all SANs in the certificate before issuing any sort of failure or warning to the user.

Also note, the list of SANs can be quite large (numbering in the hundreds), so no assumptions should be made about size.

While SANs solve the fundamental issue of not being able to have multiple hostnames for a single server, they also have some limitations. First, if there are a lot of names, they can increase the size of the certificate, and this can increase latency for establishment of the connection.

Another problem is that the issuing certification authority must be willing to issue a certificate that has all of the names listed. If all of the names are in the same second level domain (e.g., example/com) as shown above, this is usually not a problem. However, if the certificate needed the following list:

many certificate authorities have policies that prohibit issuing such certificates.

Another disadvantage to SANs is that the certificate must be reissued every time a new hostname is added.

A certificate with multiple SANs can be used for multiple applications (e.g. email, www) or physicSCal servers (e.g. in the case where are separate hosts). however, because the certificate only lists one key and one key algorithm, all the services and all the hosts using the certificate need to be able to access and use the key using the single crypto method listed in the cert.

Wildcard Domains

In some cases, this list of hostnames can grow quite long. Consider:

One way to reduce the number of domains listed as SANs is to use wildcards to specify the list of acceptable hostnames. In this example, all of these hostnames could be represented with the single SAN entry *

Any client implementation that checks validity of certificates needs to be able to check the hostname against a wildcard specification.

As convenient as wildcards are, they also introduce a security hole in that any host in the domain whose DNS resolves to that IP address will be able to connect via SSL. This may not be desirable.

For example, if an attacker compromised a host (say, having a certificate containing *, that certificate could be deployed on another host which was labeled, and it would continue to work, lulling the user into a false sense of security.

Also note that RFC6125 needs to be stringently adhered to when issuing or parsing wildcard certificates, as there are many browsers that will fail otherwise.

Server Name Indication (SNI)

Another method of dealing with multiple hostnames for a single IP address is Server Name Indication (SNI). Details are specified in RFC4366.

With SNI, the client passes the server name as part of the initial ClientHello message. This allows a server to have multiple certificates, one for each hostname served, and know which one to select and return to the client, prior to establishment of the session.

SNI is a newer extension to the SSL protocol, and is not as widely supported in legacy systems. SANs have been around longer, and are widely supported. However, in any case, new clients (or servers) being developed should support both.

SNI will solve many of the problems mentioned earlier to which SANs are subject.
  • When SNI is used, the length of the certificates does not increase, as there is only one name per certificate.
  • Different domains are not a problem since the hostnames for different domains can have different certificates (and can even be signed by different CAs).
  • Different hostnames don’t have to use the same public key algorithm, since they can be listed in different certificates.

Certificate Revocation

In the event of a key compromise, all certificates using, or signed by, that key must be revoked. There are two methods for communicating the revocation of a certificate: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP).


Certificate Revocation Lists are exactly what their name implies - lists of revoked certificates. When a certificate is revoked, for the remainder of its lifetime, it will be listed on the CRL of the site that previously signed that certificate as being valid. Once the expiration date has passed, the certificate will be removed from the CRL, since it should no longer be trusted.

CRLs are generated periodically (often daily or weekly), and can be downloaded and cached by clients. If a client caches the CRL, then it must provide a method to flush the cache and force the CRL to be re-downloaded. The client should provide configuration options for setting a maximum validity period for a cached CRL. These cache controls are necessary because some CAs publish CRLs frequently (e.g. daily) but specify the CRL’s nextUpdate time far in the future (e.g. 1 year) to prevent an “expired” CRL.


In contrast to the CRL, which contains all of the invalid certificates, the Online Certificate Status Protocol (OCSP) provides a way for a client to check whether a certificate has been revoked in real-time, while establishing the connection.

To support OCSP, each certificate issuer must have a server responding to OCSP requests, that returns whether or not a certificate is valid.

As an optimization, the server providing the certificate can “staple” the OCSP response to the original certificate, thus eliminating the extra round trip (but at the expense of larger packets).

Unfortunately, many clients do not require either current CRLs or a reachable OCSP responder, since the lack of availability would create a denial-of-service.

Summary of Recommendations for Client Developers

1. Support a sufficiently rich set of root certificates that unexpected changes can be accommodated
2. Provide a mechanism for updating root certificates
3. Support Subject Alternate Names (SANs)
4. Handle wildcard certificates and wildcard SANs correctly
5. Use the Server Name Indication (SNI) feature of TLS
6. Check for certificate revocations via Certificate Revocation Lists (CRLs) and/or OCSP, and make CRL cache times configurable

SSL Communications

Overview of Connection Establishment

A client and server that use SSL (or TLS) must open a connection, exchange identity information (in the form of X.509 certificates), negotiate an encryption key to be used during the communication session, and then finally, exchange data. This is expanded in more detail below.
  1. ClientHello - Client sends to server, proposing SSL options
  2. ServerHello - Server sends to client, selecting the SSL options
  3. Certificate - Server sends to client with its public key information
  4. ServerHelloDone - Server sends to client, concluding its negotiation with client.
  5. ClientKeyExchange - Client sends to server, containing session key information (encrypted with server’s public key).
  6. ChangeCipherSpec - Client sends to server to activate the negotiated options for all future messages it will send.
  7. Finished - Client sends to server so the server check the newly activated options.
  8. ChangeCipherSpec - Server sends to client to activate the negotiated options for all future messages it will send.
  9. Finished - Server sends to client so the client can check newly activated options.
At this point, the session is established, and data can be exchanged.

Complete details can be found in RFC2246. A more readable treatise can be found in a number of books, including SSL and TLS Essentials by Stephen Thomas and SSL and TLS: Designing and Building Secure Systems by Eric Rescorla.

Options for Limiting Trust

In some situations where higher security is required, a client might not want to trust the entire set of certificates that are trusted by browser/OS vendors. In these cases, there is a tendency to hard-code the certificate of the server directly into the client application code. This can lead to very brittle applications, since server certificates change (usually) every one or two years. A much better approach is to place in the client only the root certificates that are trusted. But, if you do this, be sure that there is a way to update them if needed. 

Note that, in the event of a compromise of the root certificate, it may be necessary for server certificates to be signed by a different root very quickly. Though this situation is rare, it does happen. One example of this was the Diginotar compromise that happened in Sept 2011. When Diginotar roots were revoked, the Dutch government needed to get new server certificates signed by a different root. If applications had hard coded only the Diginotar root, there would have been the additional problem of updating the trusted root set. So, including a set of trusted root certificates broad enough to accomodate any unplanned events is a good contingency plan.

Options for Implementation

One excellent option for implementation is OpenSSL. A good, detailed book on how to use it can be found in Network Security with OpenSSL. A thorough read is recommended, as implementing an SSL client or server can be fraught with subtleties that can affect the quality of the resulting code.

Another option that people have used is libcurl. If you are using libcurl, here are some suggestions that should be followed for updating the trusted root certificates on the client.

Unfortunately, the HTTP libraries provided with some languages have poor support for server certificate checking. For example, Python urllib doesn’t do any server certificate validation at all. So, additional work must be done to ensure that an environment using these is able to connect securely. Typically, this includes adding certificate verification, and CRL or OCSP revocation checks.

Where To Go For More Help

Securing Communications with SSL/TLS: A High-Level Overview - Part 1

Overview of SSL & TLS Encryption, Microsoft.

SSL and TLS Essentials by Stephen Thomas

SSL and TLS: Designing and Building Secure Systems by Eric Rescorla.

Network Security with OpenSSL - John Viega, et. al.


RFC6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations - US NIST, June 2005.