Names, jobs and asking for a certificate

The situation

Your team bought a wildcard certificate for *.example.com and installed it everywhere. www.example.com works. But the bare example.com and the new api.eu.example.com both show NET::ERR_CERT_COMMON_NAME_INVALID.

Was the certificate faulty, or was it the wrong certificate for the job?

What is going on

Names: the SAN is what counts

A certificate is valid only for the names listed in its Subject Alternative Name (SAN) extension. A browser compares the address you typed with those names, and nothing else.

The older Common Name (CN) field in the subject is ignored for this by modern browsers, and by other modern clients whenever a SAN is present. For example, Chrome ignores the Common Name and requires the hostname in the Subject Alternative Name, a change made in Chrome 58 (April 2017). Chrome’s error is still called COMMON_NAME_INVALID for historical reasons, but it is about the SAN.

A wildcard name such as *.example.com covers exactly one label in place of the asterisk:

So the certificate in the situation was fine; it was the wrong certificate for two of the names. The fix is to list example.com as a separate SAN entry, and to cover the API with its own name or with *.eu.example.com.

Jobs: what the key may do

Extensions also say what the certificate is for. Extended Key Usage lists purposes such as TLS server authentication (serverAuth), client authentication (clientAuth) or code signing. Basic Constraints says whether the certificate belongs to a CA. A website certificate has CA:FALSE: it can identify a server, but anything it “signs” as a certificate is rejected.

Asking for a certificate

Swipe sideways to see the whole diagram.

1. You generate a key pair on your own server, or in hardware built to hold keys.
2. You create a certificate signing request (CSR, RFC 2986 (PKCS #10)). It holds your public key and the names you want, and you sign it with your private key to prove you hold it.
3. The CA checks that you control those names, then issues a certificate.

The private key never leaves your side. If a portal offers to generate it for you and send it by email, someone else has held your private key.

Proving you own the name

For a domain-validated (DV) certificate, the CA checks that you control the domain right now, for example by asking you to publish a value on the website or in DNS. For wildcard certificates, Let’s Encrypt accepts only the DNS method. Organisation-validated (OV) and extended-validation (EV) certificates add checks on the company itself, but the encryption is the same.

A valid certificate, and the padlock some browsers still show, means the connection reaches that domain. It does not mean the business behind it is honest: phishing sites get DV certificates too.

A CAA record (RFC 8659) in your DNS lists which CAs may issue for your domain. CAs must check it before issuing. It is free and takes minutes to set up.

Try it

Try it: Hostname matcherOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

What do you have?

A certificateA list of names

Paste the server's certificate

Try a sampleChoose a sample…A wildcard certificate (*.example.com)A website certificate (www.example.com)A certificate with a Common Name but no SAN

-----BEGIN CERTIFICATE----- MIIDkDCCAzagAwIBAgIQWMoxwkHd0IeKOVJbof+xFzAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGDEWMBQGA1UEAwwNKi5leGFtcGxlLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKxCIh60qPF0ODk0Z3x6knBBykpImDplqqqn ITnmRvyt0Rnh1BDIvSfvFhkIltlduWbSs8ORd93AEg5YvlvtayYdkoIUcJFghQB4 k53309ULzJcRSZlJsixbKzt0jFHnTAfkmt7D9usTAsuZQx0Ak60gf9ccb+i1m+Zc /CUiCM69FZTaGL+GGLArLRvko71F0zhTjkEFTpFR/bOoP9MZvSTNpxNdeSFhnhqL Uhf4dOT3bes1pc/9O6WzzvVOUCzxb4Q/AghVmPJEKd2pWdCCwX4oG2HJcJ9/yodO jgw2evnJjiWLulVPj6isQRxZ5HPtTte8dP57kgaYO7s/xQcnScUCAwEAAaOCAS8w ggErMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsG AQUFBwMBMBgGA1UdEQQRMA+CDSouZXhhbXBsZS5jb20wHQYDVR0OBBYEFHhtIlz5 703vofxqWsGthT0RpsdCMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/zOvSNjJqe MEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5leGFtcGxl LmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCgLoYsaHR0 cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmwwEwYDVR0g BAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSAAwRQIgPj6NTChaz1x1y8IKmStJ zQeNp1eq2qzumFC0Kf9NBykCIQC8CdKps/XAEzPQhDd7L6Vy7xZeQsy3Z39RSbcy M3PaoA== -----END CERTIFICATE-----

Choose a file

Host name you connect to

Read the wildcard name in this certificate, then test three hostnames: one label in place of the asterisk, the bare domain, and a name with two labels in front. Only the first should match.

Check

Check yourself

A certificate's only SAN entry is *.example.com. Which hostname does it cover?

1. shop.example.com
2. example.com
3. a.b.example.com

Show answer

Answer A shop.example.com

What happened

Only shop.example.com matches: the asterisk stands for exactly one label.

Why

The bare domain has no label in place of the asterisk, and a.b.example.com has two. Neither matches.

The rule

A wildcard covers exactly one label and never the apex; list the bare domain as its own SAN.

Check yourself

A certificate's CN says www.example.com, but its SAN lists only example.com. What happens when a browser visits www.example.com?

1. It is accepted, because the CN matches
2. It is accepted with a small warning
3. It is rejected, because modern clients match names only against the SAN

Show answer

Answer C It is rejected, because modern clients match names only against the SAN

What happened

The browser rejects it with a name-mismatch error.

Why

Modern clients ignore the CN for hostname matching. The only name they consider is in the SAN, and www.example.com is not there.

The rule

Every hostname a certificate must serve goes in the SAN; the CN does not count.

Check yourself

Your CA's web portal offers to generate the private key and the certificate for you and email both as one file. What is the better choice?

1. Accept: the CA is trusted anyway
2. Generate the key pair yourself and send only the CSR, so the private key never leaves your systems
3. Accept, but ask for the key in a separate email

Show answer

Answer B Generate the key pair yourself and send only the CSR, so the private key never leaves your systems

What happened

You generate the key where it will be used and send only the CSR, which contains the public key.

Why

Anyone who has held your private key can impersonate your service. Email copies live on in mailboxes and backups that you do not control.

The rule

The requester creates and keeps the private key; the CA only ever needs the CSR.

Takeaways

• Names come from the SAN only, and a wildcard covers exactly one label, never the bare domain.
• Extensions limit what a certificate may do; a website certificate is CA:FALSE and cannot issue others.
• You send a CSR and keep the private key; the CA checks you control the name, and CAA limits which CAs may try.

Go further

• Handbook: Names and jobs: SANs, wildcards, key usage and the CA flag
• Handbook: Asking for a certificate: key generation and the CSR
• Handbook: Proving you own the name: DV, OV, EV and CAA
• Tool: CSR decoder, to see what a CSR contains
• Error: NET::ERR_CERT_COMMON_NAME_INVALID
• Next lesson: Chains and trust stores

In the gameLevel 9: Names and jobsName Registry, Keystone. In development