The Case of the Montenegro Certificate

written by James Larisch on December 4th, 2020.

This story is false, but the observations are not.

One day, in the Montenegro TLS Certificate Issuance Office, the Bureaucrat asked the Intern to issue a new TLS certificate for the Government of Montenegro. This TLS Certificate, the Bureaucrat told the Intern, should be valid for all domains under In other words, it should be valid for,,, etc.

By valid, we mean that browsers must be able to successfully open a TLS (via HTTPS) connection to as long as the corresponding web server serves this yet-to-be-created certificate (and the rest of the chain). Furthermore, this exact same certificate, per the Bureaucrat’s orders, must be valid for,, and every other domain for which the suffix is (.) We will put aside the fact that issuing a certificate which is valid for all domains across an entire government is a questionable idea.

On September 9th, 2020, the Intern issues this certificate. Note that browsers will reject a TLS certificate if the name(s) it was issued for does not match the domain name requested (i.e. you can’t serve a certificate for if the browser is trying to connect to But there are two domain name fields. Where do certificates store this name? They used to store it in the Subject X.509 field, where you would find it after CN = (denoted the Common Name). The Common Name was deprecated in favor of the X.509 extension Subject Alternative Names. (As an aside, note that Firefox respects the Common Name if no Subject Alternative Name extension is present, whereas Chrome will never respect the Common Name).

We see the above certificate’s Subject Alternative Names here:

X509v3 Subject Alternative Name:

We see a wildcard * Clearly the Intern is trying to follow the Bureaucrat’s orders — the Intern believes this certificate will be valid for all domains under The Intern distributes this certificate across all government webservers.

Wildcards & Public Suffixes

The Bureaucrat wakes up the next day and tries to access from both Chrome and Firefox. To his delight, it works in Firefox. Unfortunately it does not work in Chrome.

Why not?

Note that is on the public suffix list. Chrome does not allow wildcards to the left of domains on the public suffix list (in the Subject Alternative Name). You can see list of domains for which Chrome rejects such certificates here. You’ll notice there.

Firefox, however, only checks whether there are at least two labels to the right of the wildcard. This means * is allowed, while *.com is not.

What do the standards say? The Certificate Authority / Browser (CA/B) Forum Baseline Requirements claims CAs should issue such certificates (with wildcards to the left of public suffixes) if the requesting entity can prove that they own the entire domain space. See this, section They also say that there is no standardized way of determining what a “registry-controlled” domain space is, so using the Public Suffix List is best practice.

There’s an interesting discussion between Firefox devs, Chrome devs, and the maintainer of the Public Suffix List here.

The Intern’s Solution

After noticing the failure in Chrome, the Bureaucrat became angry. The Bureaucrat instructed the Intern to fix it. So the Intern did what all great programmers do — hardcoded the solution. Here is the subsequent certificate’s Subject Alternative Names list, issued two days later:

X509v3 Subject Alternative Name: