For better and more recently often for worse, SSL certificates provide the security for the data in transit for many modern protocols, most commonly the web. Every time you see a URL that starts with https rather than http, you are using SSL. Typically, SSL certificates are designated for only a single host such as www.example.com or shoppingcart.example.com. However, most modern businesses may have many hosts that run services that they wish to security with SSL and these hosts and services may have different security requirements and different public visibility. Certificate authorities offer multiple types of SSL certificates to match different requirements, in particular there are several kinds of certificates that can support security multiple hosts with a single certificate. These include types known as multi-domain certificates, Subject Alternative Name (SAN) certificates, Unified Communications Certificates (UCC), and wildcard certificates. Since example.com is considered a separate host from www.example.com--this is one of the most common situations--most certificate authorities will provide you with a certificate that will work for both www.example.com and example.com for the price of a single certificate.
The second name on the SSL certificate, such as example.com, is an important technicality that unfortunately needs some additional explanation. It is accomplished with Subject Alternative Name or subjectAltName (SAN) extension that appeared in X.509 version 3 PKI specification that defines much of what we think of as SSL. For the purposes of this article, think of the SAN as a field on the SSL certificate. The alternative names may be other hosts other domains or a hostname wildcard. All modern browsers support SAN fields, however older Symbian OS 9.1 and earlier and Palm Treo devices do not. In practice, supporting multiple domains on a single certificate is difficult, although support for multiple domains offers a great advantage for web servers that run virtual hosts, so that a single server may support multiple secure domains using a single IP address. The Server Name Indication (SNI) extension is one solution to this problem, however support is not universal, as it will not work with older operating systems such as Windows XP.
Unified Communications Certificates (UCC) are SAN certificates that are typically intended for use on Microsoft Exchange Server 2007 or 2010 installations that need multiple hostnames such as mail.example.com, owa.example.com, smtp.example.com, and autodiscover.example.com. In addition, UCC certificates can include NetBIOS names for configurations with older clients. UCC certificates can also be used with Microsoft Lync installations.
Another type of multi-domain certificates is known as a wildcard certificate, which allows a single certificate to secure an arbitrary number of hosts in a single subdomain such as *.example.com that could include www.example.com, mail.example.com, calendar.example.com, portal.example.com, and so forth. In addition, some certificate authorities will provide the option to include hosts via Subject Alternative Names on the certificate that can also secure example.com as well as other hosts that may need to be used with older mobile devices such as those running Windows Mobile 5. Some certificate authorities may restrict the number of different servers that are allowable for use with a single wildcard certificate via a license agreement even if it is technically possible to use the certificate on an unlimited number of machines. If this aspect is a consideration, you will want to check your license agreement carefully.
Most certificate authorities offer a wildcard certificate products. Not all certificate types are available as wildcards. For example, one of the certificate authority industry associations, the CA/Browser Forum says that the domain name field "“must contain one or more host domain name(s) owned or controlled by the Subject and to be associated with Subject’s publicly accessible server. Such server may be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV SSL Certificates.”
Pros and Cons of Wildcard Certificates
I commonly read arguments against wildcard certificates that I think are a bit specious. For example, I regularly heard that wildcard certificates are more expensive. This is true in the sense that they cost more than a single certificate, but if you have many hosts you wish to secure, such as many development server machines, the cost can be quite competitive. I recently purchased, a RapidSSL wildcard certificate for $150, while the least expensive UCC certificate I found was about $300.
I also frequently hear the argument that wildcard certificates are less secure. The argument follows that if one machine has a compromised SSL private key then all machines with that certificate would also be compromised. This is true, but mostly a red herring. If a typical web server is compromised so badly that someone can extract the private keys from the SSL certificates, then you likely have far greater problems and should probably reissue your certificates in any case. The extra work is minimal compared to the overall remediation problem. Some vendors such as DigiCert will issue unique variants of a single wildcard SSL certificate to reduce the damage from any one key leaking. This said, wildcard certificates are frequently used in a manner that is insecure and any certificate that is used on more than one machine should be treated with additional caution.
Wildcard certificates are best used when it is desirable to secure a large number of independent services and the cost of purchasing certificates would be prohibitive otherwise. As I mentioned earlier, support for SNI is still not as widespread as one would hope, so you will likely need one IP address or port per server unless you are certain that your user base is modern enough to support SNI. One additional note of caution, wildcard certificates can be finicky with Microsoft Exchange, especially versions older than 2010 and it is not currently possible to use a wildcard certificate with Microsoft Lync.
I have written about SSL certificates a number of other times including: Purchasing SSL Certificates, No Frills SSL Certificates Are Inexpensive and Useful, Smartphone Anti-Phishing Protection Leaves Much to Be Desired, SSL Is Critical Infrastructure at Risk
