Names and jobs: SANs, wildcards, key usage and the CA flag

A certificate answers two questions for the software that checks it:

1. Is this certificate for the name I asked for? You typed shop.example.com. The certificate must say shop.example.com, or something that covers it.
2. Is this key allowed to do this job? A key that is meant to run a website should not be able to sign software or create new certificates.

The names live in a list inside the certificate called the Subject Alternative Name (SAN). A shop’s certificate might list example.com and www.example.com. If you visit shop.example.com with that certificate, your browser stops with a name error, even though everything else about the certificate is fine.

Older certificates also put a name in a field called the Common Name (CN). Browsers no longer look at it for website names. Only the SAN list counts.

A wildcard certificate uses a star as a shortcut. *.example.com means “any one name directly under example.com”: www.example.com and shop.example.com both match. It does not cover example.com itself, and it does not cover a.b.example.com, which is two levels down.

The jobs are written in three places:

• Key usage says which basic operations the key may perform, such as creating signatures.
• Extended key usage says for which purpose: a website server, a client logging in, code signing, and so on.
• Basic constraints says whether the certificate belongs to a certificate authority. Only a CA certificate may sign other certificates.

That last flag matters a great deal. If any website certificate could sign other certificates, every website owner could make a certificate for any other website, and the whole system would collapse.

Where do the names live?

The SAN extension is defined in RFC 5280 section 4.2.1.6. It holds a list of typed names: dNSName for host names, iPAddress for IP addresses, and other types such as email addresses (rfc822Name) and URIs.

The rules for matching a server’s name are in RFC 9525. It is blunt about the Common Name: “The Common Name RDN MUST NOT be used to identify a service” (section 2). Browsers acted on this long ago: since Chrome 58 (April 2017), Chrome ignores the Common Name and requires the hostname in the Subject Alternative Name.

The Baseline Requirements for publicly trusted certificates say the same from the CA’s side: the SAN must be present and contain at least one DNS name or IP address, and the CN is “NOT RECOMMENDED”. If a CA includes a CN, it must repeat one of the SAN values (section 7.1.2.7).

How is a host name matched?

The client builds the name it expects, for example shop.example.com, and compares it with each dNSName in the SAN:

• The comparison ignores upper and lower case.
• Names are compared label by label. A label is one part between dots: shop, example and com.
• International names appear in their ASCII form, which starts with xn--.
• If no SAN entry matches, the connection fails. There is no partial credit.

What exactly does a wildcard cover?

RFC 9525 section 6.3 sets three rules, and clients follow them closely:

1. The star must be “the complete content of the left-most label”. So *.example.com is valid, while www.*.example.com and w*.example.com are not.
2. “There is only one wildcard character.”
3. “A wildcard in a presented identifier can only match one label in a reference identifier.”

The third rule is why *.example.com covers neither a.b.example.com (two labels) nor example.com (no label at all where the star is). The Baseline Requirements define a wildcard name the same way: “*.” followed by a fully qualified domain name. They also forbid public CAs from issuing wildcards directly under a public suffix, such as *.co.uk, unless the applicant controls that entire namespace (section 3.2.2.6).

Most organisations that want both put two entries in one certificate: example.com and *.example.com.

Swipe sideways to see the whole diagram.

What about IP addresses?

To connect to https://10.0.0.5, the certificate needs an iPAddress entry in its SAN. RFC 9525 section 6.2 says an IP address “MUST exactly match the value of an iPAddress entry in subjectAltName”. An IP address written in the CN, or as a dNSName, does not count. Java reports this case as No subject alternative names matching IP address … found.

Public CAs may issue certificates for public IP addresses they have validated, and Let’s Encrypt has offered certificates for IP addresses since 15 January 2026. For private addresses such as 10.0.0.5, use a private CA (chapter 22).

What is the difference between key usage and extended key usage?

Key usage (RFC 5280 section 4.2.1.3) is a set of bits for low-level operations:

Extended key usage (EKU, section 4.2.1.12) names whole purposes, each with an OID:

RFC 5280 is strict: “If the extension is present, then the certificate MUST only be used for one of the purposes indicated.” Both checks apply at the same time: a TLS server certificate needs a key usage that allows its handshake signature and an EKU that includes serverAuth.

Public TLS certificates are moving to a single purpose. Chrome's root program starts phasing out root hierarchies that are not dedicated to TLS server authentication (from 15 June 2026), and CAs are removing clientAuth from website certificates. If you use certificates to log machines in with mutual TLS, plan for a private CA (chapter 23).

What does the CA flag do?

The basic constraints extension (section 4.2.1.9) has two fields:

• cA: TRUE for a CA certificate, FALSE (or absent) for a leaf. A key may sign certificates only if its certificate has cA set to TRUE and its key usage includes keyCertSign (section 4.2.1.3). CAs must mark this extension critical in CA certificates.
• pathLenConstraint: “the maximum number of non-self-issued intermediate certificates that may follow this certificate”. pathlen:0 means the CA may sign leaf certificates but no further CAs.

A related extension, name constraints (section 4.2.1.10), limits a CA to a namespace, for example only names under corp.example.com. It is mainly used for private and delegated CAs (chapter 22).

How do I see a certificate’s names and jobs?

Ask openssl for just these four extensions. This is the test certificate from chapter 8:

openssl x509 -in www.crt -noout -ext subjectAltName,keyUsage,extendedKeyUsage,basicConstraints

X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature
X509v3 Extended Key Usage: 
    TLS Web Server Authentication
X509v3 Subject Alternative Name: 
    DNS:www.example.com, DNS:example.com

The issuing CA above it looks different. It may sign certificates, but no further CAs:

X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
X509v3 Key Usage: critical
    Certificate Sign, CRL Sign

How do I test a host name before deploying?

openssl x509 -checkhost applies the matching rules for you. Here is a certificate whose only SAN entry is *.example.com:

for h in www.example.com shop.example.com a.b.example.com example.com; do
  openssl x509 -in wild.crt -noout -checkhost "$h"
done

Hostname www.example.com does match certificate
Hostname shop.example.com does match certificate
Hostname a.b.example.com does NOT match certificate
Hostname example.com does NOT match certificate

For IP addresses, use -checkip. This certificate has the SAN DNS:app.internal.example, IP Address:10.0.0.5:

$ openssl x509 -in ip.crt -noout -checkip 10.0.0.5
IP 10.0.0.5 does match certificate
$ openssl x509 -in ip.crt -noout -checkip 10.0.0.6
IP 10.0.0.6 does NOT match certificate

A certificate with CN=10.0.0.5 and no SAN fails the same check: IP 10.0.0.5 does NOT match certificate.

What does a name mismatch look like?

We served the www.example.com certificate from a local test server and connected to it as shop.example.com. Each client says the same thing in its own words:

# Python 3.13
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'shop.example.com'. (_ssl.c:1028)

# Node.js 23
ERR_TLS_CERT_ALTNAME_INVALID: Hostname/IP does not match certificate's altnames: Host: shop.example.com. is not in the cert's altnames: DNS:www.example.com, DNS:example.com

Browsers show NET::ERR_CERT_COMMON_NAME_INVALID in Chrome and Edge, and SSL_ERROR_BAD_CERT_DOMAIN in Firefox. The error pages for Python and Node.js walk through the fixes. In almost every case the fix is the same: issue a new certificate whose SAN lists the exact name that clients use, or point clients at a name that is already listed. Do not turn off hostname checking. Without it, any valid certificate for any name would be accepted, including one for an attacker’s own domain.

How do I check what a CA flag prevents?

A quick experiment shows the CA flag at work. We used the www.example.com key, a leaf with CA:FALSE, to sign a certificate for another name, then asked OpenSSL to verify it:

openssl verify -CAfile root.crt -untrusted www-and-int.pem leaf-signed.crt

C=BE, O=Example Shop, CN=www.example.com
error 79 at 1 depth lookup: invalid CA certificate
C=BE, O=Keystone Demo, CN=Keystone Demo Issuing CA 1
error 25 at 2 depth lookup: path length constraint exceeded
C=BE, O=Example Shop, CN=www.example.com
error 32 at 1 depth lookup: key usage does not include certificate signing
error leaf-signed.crt: verification failed

Three separate rules reject it: the leaf is not a CA, the issuing CA’s pathlen:0 allows no CA below it, and the leaf’s key usage lacks keyCertSign.

What should I ask for in a certificate request?

• List every name that clients will use in the SAN, including the bare domain if you need it.
• Prefer separate certificates per service over one huge wildcard, so that one stolen key does not expose everything.
• For internal services reached by IP address, add an IP: SAN entry.
• Leave key usage and EKU to the CA’s profile, unless you run the CA yourself.

Chapter 10 shows how to put SAN entries into a CSR.

Try the hostname matcher with a wildcard certificate, then change the host name:

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

Type a host name such as example.com or a.b.example.com and see which SAN entry matches, or why none does. The leaf-cn-only sample shows a certificate with no SAN at all.

Common mistakes

• “Browsers check the Common Name.” They ignore it. Only the SAN counts for host names, as RFC 9525 requires.
• “*.example.com covers example.com.” It does not. The star must match exactly one label, and the bare domain has none there. Add example.com as a separate SAN entry.
• “*.example.com covers api.eu.example.com.” It does not. A wildcard covers exactly one label. You need *.eu.example.com or the exact name.
• “Key usage and extended key usage are the same thing.” Key usage lists low-level operations, such as signing. EKU lists purposes, such as server authentication. Clients check both.
• “Any certificate can sign other certificates.” Only a certificate with CA:TRUE and keyCertSign can. Every modern client checks this, along with pathlen.
• “An IP address in the CN is enough.” Modern clients need an iPAddress entry in the SAN.

Check yourself

Check yourself

Your certificate's SAN lists only *.example.com. Which address shows a certificate name error?

1. https://www.example.com
2. https://example.com
3. https://api.example.com

Show answer

Answer B https://example.com

What happened

example.com fails, while the other two match.

Why

A wildcard stands for exactly one label on the left. The bare domain example.com has no label in that position.

The rule

List the bare domain separately: example.com and *.example.com.

Check yourself

A certificate has CN=portal.example.com and no SAN extension. Chrome shows a name error for https://portal.example.com. Why?

1. The CN is spelled in upper case
2. Chrome ignores the CN and finds no SAN to match
3. Chrome needs the organisation name as well

Show answer

Answer B Chrome ignores the CN and finds no SAN to match

What happened

Chrome ignores the Common Name, so the certificate has no usable name at all.

Why

RFC 9525 says the CN must not be used to identify a service, and Chrome stopped using it years ago.

The rule

Put every host name in the Subject Alternative Name extension.

Check yourself

Which certificate is allowed to sign other certificates?

1. Basic constraints CA:FALSE, key usage Digital Signature
2. Basic constraints CA:TRUE, key usage Certificate Sign
3. Extended key usage TLS Web Server Authentication

Show answer

Answer B Basic constraints CA:TRUE, key usage Certificate Sign

What happened

Only the certificate with CA:TRUE and the Certificate Sign key usage may sign certificates.

Why

RFC 5280 requires both the cA flag in basic constraints and the keyCertSign bit. EKU does not grant this power.

The rule

Leaf certificates carry CA:FALSE. Clients reject any chain where a non-CA certificate signs another.

Go deeper

• RFC 9525: the current rules for matching server names, including wildcards and IP addresses.
• RFC 5280, sections 4.2.1.3 to 4.2.1.12: key usage, SAN, basic constraints, name constraints and extended key usage.
• CA/Browser Forum Baseline Requirements, sections 3.2.2.6 and 7.1.2.7: the wildcard and certificate profile rules for public CAs.
• Chrome Platform Status: remove CN matching: Chrome’s own record of dropping the Common Name.
• OpenSSL x509 command: -checkhost, -checkip and -ext.
• Python ssl module: check_hostname and hostname_checks_common_name.

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

The crash course covers names and jobs in lesson 5, Names, jobs and asking for a certificate.