Trouble with local HTTPS certificate for *.test domain

Question

I spent this beautiful day by fighting with wildcard certificates...

Nowdays, it's not possible to use .dev for local development, so we're using *.test. I need to test HTTPS, so I created wildcard certificate.

Since Chrome v58 the "commonName" is ignored and user should use SAN for specifying domain names (more on this topic here: https://www.thesslstore.com/blog/security-changes-in-chrome-58/).

Anyway: on my system (mac os / Docker / Chrome) there is trouble with wildcard - if I specify whole domain in certificate, it works (like something.test) - but when i use wildcard, Chrome still generate this error message: NET::ERR_CERT_COMMON_NAME_INVALID

I tried almost everything possible, but no luck :(

More info:

• http://grokify.github.io/security/wildcard-subject-alternative-name-ssl-tls-certificates/
• https://www.openssl.org/docs/man1.0.2/apps/x509v3_config.html#Subject-Alternative-Name
• https://medium.com/carwow-product-engineering/chrome-58-and-self-signed-ssl-certificate-c28a874d80fa
• https://github.com/webpack/webpack-dev-server/issues/854

My bash script:

openssl req \
-x509 \
-nodes \
-new \
-newkey rsa:2048 \
-keyout test.key \
-out test.crt \
-sha256 \
-days 3650 \
-config <(cat <<EOF

[ req ]
prompt = no
distinguished_name = subject
x509_extensions    = x509_ext

[ subject ]
commonName = *.test

[ x509_ext ]
subjectAltName = @alternate_names

[ alternate_names ]
DNS.1 = *.test
DNS.2 = test

EOF
)

Answer 1

[ alternate_names ]
DNS.1 = *.test
DNS.2 = test

You are OK to use *.test for personal use. Also see RFC 6761, Special-Use Domain Names. RFC 6761 is very specific that user software should NOT treat *.test differently than any other domain name, so don't expect the browsers or other user agents to do something special for *.test. The problem lies elsewhere.

Painting with a broad brush, there are two organizations that publish standards for running a public PKI. The first is the CA/Browser Forums, and the issuing polices are followed by Browsers. The second is the IETF, and its issuing policies are followed by other user agents like cURL, OpenSSL and Wget.

From the browsers point of view, *.test appears to be a Brand Top Level Domains (i.e., Vanity Domain like *.google). The CA/B Baseline Requirements do not allow top level wild cards.

In contrast, the IETF does not forbid wildcarding the top level domain like *.com, *.net or *.test. User agents like cURL and Wget will likely allow wildcarding *.test.

This is from the CA/B Baseline Requirements document. It has been in effect since 2013:

Authorization Domain Name:

The Domain Name used to obtain authorization for certificate issuance for a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN contains a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation.

---

if I specify whole domain in certificate, it works (like something.test)

If you want a Browser to consume the certificate, then you must use something.test or *.something.test.

Or, use a different user agent like cURL or Wget.

---

but when i use wildcard, Chrome still generate this error message: NET::ERR_CERT_COMMON_NAME_INVALID

And

[ subject ]
commonName = *.test

The name is invalid because you wildcarded the top level domain and the user agent follows the CA/B issuing policies.

In addition, putting a hostname in the CommonName has been deprecated for years. For the last several years it has not been forbidden. I understand the CA/B Baseline Requirements will be making it forbidden soon. The IETF stll allows it. This is from the CA/B Baseline Requirements document:

Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: 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 (see Section7.1.4.2.1).

The short of it is, don't put hostname in the CommonName. Put a friendly name there, like Example Widgets, LLC. Put hostnames and other names in the SubjectAltName.

I'm aware of certificates that omit the CommonName altogether. See, for example, Crypto++ website. The Crypto++ website tried to have the common name set to "Crypto++" because it is a friendly name, but the issuer feared the the "+" sign would break scripts on occasion. So the field was omitted altogether.

---

Nowdays, it's not possible to use .dev for local development...

That's interesting in a morbid sort of way. I would be interested to learn why it is not possible since it seems like a good choice for dev network segments.

For completeness, my home network is *.pvt. I have a CA that issues certificates when needed. I have never had any troubles.

---

Anyway: on my system (mac os / Docker / Chrome) there is trouble with wildcard

It is kind of interesting Docker is having trouble with it. I expected Docker to follow the IETF issuing policies and allow it. I was not aware they were following CA/B issuing policies and rejecting it.

Docker may be running with a hardened installation and rejecting it. Tim Rühsen has a GitHub that provides libpsl. I believe libpsl will reject a wildcard on the top level domain.