We have previously written about the different types of SSL certificates, but in that article we focused on validation levels. A recent post on LinkedIn highlighted the fact that there is another dimension that we haven’t yet explored.

SSL certificates come in three basic packages: “single-domain” certificates that can only be used on one specific website, “multi-domain” certificates that can be used on more than one website, and “wildcard” certificates that can be used on any website within a specific domain name. Multi-domain certificates are often called “unified communications” or “UC” certificates. This is a reference to one common use of these certificates, which is to secure Microsoft messaging products such as Exchange and Lync. The table below shows examples of the number and types of websites that each of these packages can protect:

Type of Certificate

Example Websites Protected



Multi-domain (UCC)

https://www.firstwebsite.com https://www.secondwebsite.com

Wildcard (*)

(unlimited number of subdomains)

You may be wondering what the technical difference is between these packages. It all comes down to the Subject Alternative Name (SAN) field that is embedded in the certificate when it’s issued. When a certificate only has one SAN field and it contains a reference to a single website, then it’s a single-domain certificate. If that one SAN field contains an asterisk in the website name (e.g. ‘*.firstwebsite.com’) then it’s a wildcard certificate. If the certificate has many SAN fields, then it’s a multi-domain certificate. Multi-domain certificates sometimes have 100 or more SAN fields, and some or all of these fields may contain wildcards, creating a hybrid “multi-domain wildcard” certificate like the example shown below!


Price is often the main concern in choosing between these options. If you have the need to secure more than one website, a multi-domain or wildcard certificate is usually more cost effective. However, there are a few other considerations that you should be aware of.

Wildcard SSL certificates can be used to secure an unlimited number of websites that are subdomains of the domain name in the certificate. This is convenient, but it also creates a potential risk. What if someone gained unauthorized access to your certificate’s private key and used it to set up a rogue website that you didn’t know about? For example, if your website is at https://secure.company.com, someone – even an employee – with access to that certificate could set up a site at https://secure1.company.com. That website would be difficult to detect and would have a perfectly valid SSL certificate giving it undeserved legitimacy. For this reason, wildcards are not allowed in Extended Validation certificates. Of course, if you feel that you have sufficient control over your certificate and understand the risks, a wildcard certificate may still be a good choice to simplify certificate management.

Multi-domain SSL certificates are popular and they don’t expose the security risk of wildcard certificates that I described above, but they have some issues of their own. First, the more SAN fields you add to a certificate, the larger the certificate, and size impacts the performance of your website. Because the certificate has to be downloaded to the browser before any content is loaded, you should be especially sensitive to the size of the SSL certificate you use. A multi-domain certificate with 5 or 10 SANs may not make much difference, but one with 50 or 100 is likely to have a big impact on performance.

A second issue with multi-domain certificates occurs when they are used to secure websites belonging to different organizations. This is commonly done by Content Delivery Networks (CDNs) because it allows them to reduce their need for scarce IP addresses. However, if the certificate contains information identifying the organization, that information will be wrong because it can only identify one of the organizations – and often that one organization is the CDN operator rather than you.

Multi-domain certificates are often updated to add or remove websites. Each time a change is made, the certificate must be reissued and replaced on all the websites it protects. These changes can be risky and result in downtime for your websites.

A final risk that applies to both wildcard and multi-domain certificates is that you multiply the scope of any potential issues with the certificate. If the private key is stolen or the certificate expires, this problem now affects every site using the wildcard or multi-domain certificate rather than just one.

There are many cases where it makes sense or is even required to use a multi-domain or wildcard certificate. However, we encourage you to consider all of the tradeoffs when deciding which package to choose.

  • Alberto Gonzalez

    Are the multi-domains certificates supported by all the common technologies with PKI ? I mean, we usually set up websites with SSL certificates and then web develop some kind of application that connects to the website by https. Web mainly use java technology. Do you know if this technology supports multi-domains certificates ? I wouldn’t like to buy a multi-domain certificate and then the application wasn’t able to connect because of the type of the certificate.

  • Guilherme E. J.

    “First, the more SAN fields you add to a certificate, the larger the certificate, and size impacts the performance of your website.”… You mean the size of the SAN field? Because even if it has 100 domains it will cost ~ 3k

  • Max