Does a TLS Certificate Need a Common Name?

Abstract

Technically: no. In practice: maybe.

Lot’s of teams are experimenting with shorter duration certificates from Let’s Encrypt to get ready for the 47-day mandate. Those certs come with a big gotcha: no more Common Name.

A modern browser is perfectly happy with a TLS certificate that has no Common Name. Your VPN or mail server might have other opinions. And since those are probably things you’d like to keep working, there’s a little more nuance to the answer.

Certificate Subjects

The Common Name, or CN, is part of a certificate’s Subject. If you’ve inspected a certificate and seen CN=www.example.com, you found it. The Subject can also contain things like an organization name and country. This used to be the only place to specify which domain or IP a certificate covered.

Since 2000, the covered domains and IPs now live in the Subject Alternative Name (SAN) extension. That’s where a certificate can list example.com, www.example.com, and whatever other names it covers. Some certificates have dozens of SANs.

For a domain-validated server certificate, the entire Subject can now be empty. The field still exists, even if it has nothing in it. The certificate standard allows this, provided the SAN extension is present and marked critical, which all Issuing CAs currently handle.

If you thought the IPv6 rollout was taking forever…

Unlike the 47-day mandate, the Common Name deprecation didn’t happen last year. The PKI folks have been working on this for a while:

• 1999: RFC 2459 standardized SAN for Internet certificates, allowing a single certificate to cover multiple DNS names, IP addresses, and URIs.
• 2000: RFC 2818 deprecated using the Common Name for HTTPS hostname checks. SAN was preferred, with CN available as a fallback.
• 2012: The rules for publicly trusted TLS certificates required SANs.
• 2017: Chrome 58 removed CN fallback. A name in the CN alone was no longer enough to validate.
• 2023: RFC 9525 removed CN from TLS service identity checking altogether. Names go in SAN once and for all.

Actually putting a CN in the certificate is still allowed by the CA/Browser Forum’s rules, though discouraged. If present, it must repeat a name from the SAN list.

So even though it’s technically deprecated, and has been for some time, you still see certificates with Common Names. Most certificates, in fact. And there’s a reason for this.

Let’s Encrypt starts removing the CN

Let’s Encrypt introduced certificate profiles in 2025, letting ACME clients request different kinds of certificates. Its newer profiles omit the CN entirely.

Here’s the current lineup:

The CN has a 64-character limit. If the selected name is longer, even classic leaves it out.

For the newer profiles, the domain names stay in SAN extension and the Subject is empty. The certificate still identifies your server. It just does so without the extra bytes in Subject.

And this is a huge problem for everyone using legacy software, which is pretty much everyone.

Lots of software still wants a Common Name

We’ve run in to over a dozen common pieces of software (and many more obscure ones) that still expect the certificate to have a Common Name. There are varying failure modes and workarounds, but in some cases the only path forward is to ensure your cert still has one. Some common examples:

Palo Alto GlobalProtect

Palo Alto’s GlobalProtect certificate guidance still says the CN and SAN must match the hostname or IP address used for the portal or gateway.

Cisco Umbrella

Cisco Umbrella’s Secure Web Gateway explicitly requires a CN when validating website certificates during HTTPS inspection. It even has a dedicated error: Upstream certificate missing common name.

Citrix NetScaler

NetScaler has a gotcha in its certificate renewal workflow. When updating an existing certificate, it compares the old and new Common Names. If they don’t match, the update needs the -noDomainCheck option.

Dropping the CN can trip that check even when the SANs haven’t changed. We already handle this in CertKit’s NetScaler integration. NetScaler can serve a certificate without a CN, but the default update check can fail if you don’t know the trick.

Microsoft Exchange connectors

Exchange has a different wrinkle. Its connectors use a setting called TlsCertificateName to select the certificate for mail flow. The value combines the certificate’s issuer and Subject:

<I>Issuer<S>Subject

This is still in Microsoft’s current documentation, including Exchange Server Subscription Edition.

Suppose the connector is configured for a certificate whose Subject is CN=mail.example.com. Your replacement has the same hostname in SAN, but an empty Subject. Now you have a problem.

Using the Subject was a singularly bad idea from Microsoft, but in my experience most of their software makes certificate automation harder than it needs to be.

How common is no Common Name?

The standards tell us what certificates should look like. Certificate Transparency logs let us see what’s actually being issued. Theory vs. Practice in a nutshell.

I looked at certificates in the CT logs that were issued in the last 200 days (the current maximum lifetime).

Across the issuers below, only about 4.2% had no Common Name. Roughly 96% still had one.

The Common Name is being retired very slowly indeed.

Issuer names appear as recorded, so some CAs have multiple entries.

Three of these 10 issuer entries had zero certificates without a CN in this sample. Microsoft had just four out of 90 million. Four.

ZeroSSL stands out, with roughly 27–34% missing a CN across its two entries. Even Let’s Encrypt still included one in about 96% of its certificates. Its remaining 4% does add up to almost 56 million certificates, though. A small percentage can still find plenty of software to annoy.

Before dropping the CN, check the software that has to use the certificate. Your browser is not the only thing that counts.

CertKit handles the deployment of certificates, with and without common names, to all your software and appliances.