Single Multi Domain Https Certificates Are the Same Thing

__Update April 2017__: *Google Chrome now [doesn't use the 'CN' field at all](https://bugs.chromium.org/p/chromium/issues/detail?id=308330) since Chrome 58.* HTTPS certificate vendors often discuss two types of certificates:

July 12, 2021
We're Expedited Security. We help SAAS applications prevent and recover from attack, overcome regulatory or integration security requirements or just stop "weird" traffic before it becomes a problem.

Update April 2017: Google Chrome now doesn’t use the ‘CN’ field at all since Chrome 58. HTTPS certificate vendors often discuss two types of certificates: - ‘single domain’ certificates - ‘multi domain’ - sometimes called ‘UCC’ or ‘SAN’ certificates. Which inevitably leads to questions for people who need an HTTPS cert. Here are some of those, and the answers: - Should I get a single domain, or multi domain / SAN / UCC cert? Even if you only have a single domain now, you may still want to add additional domains in the future. Or you might not. Or you might later and not know it right now, at which point changing your certificate type is a pain. - Is www a seperate domain from my actual site? Yes. It may be included for free, or not, depending on both the certificate vendor and the type of cetificate you’re purchasing. - So with my domain as well as www, isn’t that two domains total? So is my ‘single domain’ certificate actually a ‘SAN/UCC certificate’? Yes, your ‘single domain’ cert has multiple SANS. It just might not be a SAN product, so you can’t add any more domains. - If I only want a single domain now, can I switch to a multi domain cert later? This is actually surprisingly hard with a lot of existing cert vendors. - What should I put into the CN fields when creating a CSR? It doesn’t matter. The CN is always less important than the SANs. And it’s been this way for about a decade. Let’s go into more detail.

A single domain cert is just a multiple domain certificate with one domain

HTTPS implementations - ie, web browsers and servers - follow RFC 2818: HTTP Over TLS, a document published in 2001 which says: > Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the DNSName instead. To clarify: DNSName is the most common type of Subject Alt name entry. Ie, CN has been deprecated in favour of SAN since 2001. CAs create certificates the same way. The Baseline Requirements, the minimum rules used to issue all certificates, mentions: > 7.1.4.2.2. Subject Distinguished Name Fields > > Certificate Field: subject:commonName (OID 2.5.4.3) > > Required/Optional: Deprecated (Discouraged, but not prohibited) > > If present, this field MUST contain a single IP address or Fully‐Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension Again, the CN is either unused or just a copy of one of the DNS names in the Subject Alternative Names field.

Most single domain name certs probably have two domains anyway

www is just another domain name - it’s not any different from download.example.com or mail.example.com. Just like those names, www has to be included as a SAN inside the certificate. This means a ‘single domain’ certificate still has at least two SANs.

I still don’t believe you

RFC 6125: The Cosmonaut’s Last Message to the Woman He Once Loved in the Former Soviet Union (2011) - this may not actually be this RFCs name, but we ran out of electrons trying to show you the real one - states: > 2.3. Subject Naming in PKIX Certificates > > For our purposes, an application service can be identified by a name or names carried in the subject field (i.e., a CN-ID) and/or in one of the following identifier types within subjectAltName entries: > > - DNS-ID > - SRV-ID > - URI-ID Later in Checking of Common Names the RFC reiterates: > As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client. > Therefore, if and only if the presented identifiers do not include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client, then the client MAY as a last resort check for a string whose form matches that of a fully qualified DNS domain name in a Common Name field of the subject field (i.e., a CN-ID). I.e., the SAN field is the list of domains. The only time a CN will ever be used is if the SAN field doesn’t have any domain names at all - which these days is incredibly rare and, because that would be a gross violation of the baseline requirements CAs must follow, most likely to be a malformed certificate. So just to reiterate:

There is no technical distinction between ‘single’ and ‘multi’ domain name HTTPS certs. They’re just HTTPS certs.

Starting 2017 CertSimple has dropped separate single/multi domain name certs

There’s now a single base price to do the EV checks on your company including the base domain and www, and you add names now or later. This means: - Nobody ever has to change product types. - You can add domain names any time you want (we’ll update the certificate and only charge you for the time remaining) - Common certificate configuration with a base domain, www, and one extra domain name are now cheaper as there’s no minimum amount of domains required to get a multidomain cert. This isn’t CertSimple being good, it’s us being competent - the previous situation, despite being common in our industry, genuinely sucked and made things unnecessarily complicated. Sorry to everyone who had to put up with us handling things the way the rest of the industry does.