> Lesson 5 of PKI in 90 minutes: SAN names, one-label wildcards, key usage and the CA flag, the CSR, and how a CA checks you control a domain. Source: https://pkizerotohero.com/course/names-and-requests/ · Last reviewed: 2026-10-20 # Names, jobs and asking for a certificate About 10 minutesCrash course **In one sentence:** A certificate is valid only for the names in its SAN and the jobs in its extensions; you get one by sending a CSR and keeping the private key. ## 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](https://pkizerotohero.com/handbook/glossary/#subject-alternative-name) (SAN) extension. A browser compares the address you typed with those names, and nothing else. The older [Common Name](https://pkizerotohero.com/handbook/glossary/#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](https://pkizerotohero.com/handbook/glossary/#wildcard-certificate) name such as `*.example.com` covers **exactly one label** in place of the asterisk: | Hostname | Covered by `*.example.com`? | | --- | --- | | `www.example.com` | ✓ yes: one label | | `example.com` | ✗ no: the bare domain (apex) is never covered | | `api.eu.example.com` | ✗ no: two labels | 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](https://pkizerotohero.com/handbook/glossary/#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 *Diagram: On your side, step 1: generate a key pair; the private key stays there. Step 2: create a CSR containing the public key and the names, signed with the private key. The CSR goes to the CA. Step 3: the CA checks that you control the name and that CAA allows it. The CA issues the certificate, signed by the CA, and sends it back. Step 4: you install it with the private key. A note says the private key never travels.* You keep the private key. The CA only ever sees the CSR. 1. You generate a key pair on your own server, or in hardware built to hold keys. 2. You create a [certificate signing request](https://pkizerotohero.com/handbook/glossary/#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](https://pkizerotohero.com/handbook/glossary/#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. Why it matters to the business Ask your team Do we have CAA records listing only the CAs we actually use? Who can request certificates for our domains, and does any process send private keys by email? ## Try it *Interactive tool: Hostname matcher (runs in the browser at [/tools/hostname/](https://pkizerotohero.com/tools/hostname/))* 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](https://pkizerotohero.com/handbook/names-and-key-usage/) - Handbook: [Asking for a certificate: key generation and the CSR](https://pkizerotohero.com/handbook/csr/) - Handbook: [Proving you own the name: DV, OV, EV and CAA](https://pkizerotohero.com/handbook/domain-validation/) - Tool: [CSR decoder](https://pkizerotohero.com/tools/csr/), to see what a CSR contains - Error: [NET::ERR\_CERT\_COMMON\_NAME\_INVALID](https://pkizerotohero.com/errors/chrome-err-cert-common-name-invalid/) - Next lesson: [Chains and trust stores](https://pkizerotohero.com/course/chains-and-trust-stores/) **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/course/names-and-requests/). Last reviewed 20 October 2026Edition 0.9 ## Go deeper in the handbook - [Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag](https://pkizerotohero.com/handbook/names-and-key-usage/) - [Chapter 10: Asking for a certificate: key generation and the CSR](https://pkizerotohero.com/handbook/csr/) - [Chapter 11: Proving you own the name: DV, OV, EV and CAA](https://pkizerotohero.com/handbook/domain-validation/)