SSL / TLS certificates
A certificate is what lets a browser trust that the server answering for a name really belongs to that name. It ties one or more names to a public key, and it is signed by a certificate authority (CA) the browser already trusts. SSL is the old name of the protocol, TLS replaced it long ago, but "SSL certificate" stuck, and both words mean the same certificate. This page is not about setting up a web server. It is about the places where certificates and DNS meet, because that is where most of the confusion starts.
Who issues them: DV, OV and EV
Free, automated certificate authorities such as Let's Encrypt issue certificates through ACME, a protocol a hosting panel or a small tool on the server speaks for you, which is why many hosting panels offer a certificate with one click. Paid certificate authorities issue the same kind of certificate, and two more:
- DV, domain validated: the certificate authority checks only that you control the domain. This is what nearly every site uses, and the only kind Let's Encrypt issues.
- OV, organisation validated: the certificate authority also checks the organisation behind the domain, and its name ends up in the certificate's details.
- EV, extended validation: a stricter version of the same organisation check. Browsers used to show the organisation's name next to the address. Chrome moved it into the details behind the padlock in version 77, Firefox in version 70, so since 2019 a visitor cannot tell EV from DV without clicking.
The encryption is the same for all three. What OV and EV add is a vetted organisation name, and that check cannot be fully automated, which is why Let's Encrypt does not offer them. For DNS it makes no difference: every kind starts with the same proof that you control the domain, so everything below applies to all three.
Proving you control the name
Before it issues anything, a certificate authority checks that whoever asks for the certificate controls the name. The two common ways both involve DNS, one directly and one indirectly. HTTP-01 places a file on the web server and fetches it through the name, so the name's A or AAAA record must already point at that server. DNS-01 asks for a TXT record at _acme-challenge, and it is the only one of the two allowed for a wildcard certificate.
A proxying CDN can get in the way of either: the certificate authority sees the CDN's answer instead of yours. The CNAME page has a section on that, including when it does and does not matter.
Who is allowed to issue
A CAA record names the certificate authorities that may issue for a domain, and every certificate authority has to check it before issuing. Since September 2025 they also make that check, and the control check above, from several network locations at once, and the answers have to agree. DNS that answers differently depending on where it is asked from, for example a nameserver that is out of step with the others or not answering at all, can make issuance fail even when the records themselves are right.
Which names a certificate covers
A certificate lists the exact names it is valid for. The bare domain and www are two different names, so a site that answers on both needs both in its certificate. A wildcard certificate for *.example.com covers one level only: www.example.com yes, example.com itself no, and a.b.example.com no. A wildcard certificate is also not the same thing as a wildcard DNS record: one says which names the certificate may be used for, the other makes every name resolve. The CAA page shows how to refuse wildcard certificates altogether.
Every publicly trusted certificate is published in Certificate Transparency logs, which anyone can search, because browsers refuse certificates that were not logged. Every name you put in a certificate therefore becomes public, a test or internal subdomain included. That is by design, and worth knowing before naming something you would rather keep quiet.
A certificate pinned in DNS: TLSA after a renewal
A TLSA record publishes a fingerprint of a certificate or of its key, and is checked mostly by mail servers. Whether a renewal breaks it depends on what it pins. The pragmatic choice, and the one Expert Tools' DANE wizard offers first, is to pin the certificate authority's current and announced intermediates (2 1 1): your own certificate can then be renewed with a new key without touching DNS, as long as one of those intermediates signs it. Pinning your own key (3 1 1) is stricter and cleaner, but breaks when a renewal brings a new key, which with Let's Encrypt means every few weeks. Two ways around that: keep the same key when renewing (Certbot, a common ACME tool, does this with its --reuse-key option), or publish the next key's TLSA record next to the current one well before the switch, wait at least the record's TTL, and only then switch. The shorter lifetimes below make this come up more often.
Shorter lifetimes, and why that is a DNS matter
The CA/Browser Forum, the body whose rules every publicly trusted certificate authority follows, has set a schedule that shortens how long a certificate may be valid:
| Issued from | Longest allowed validity |
|---|---|
| Before 15 March 2026 | 398 days |
| 15 March 2026 | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
How long a certificate authority may reuse an earlier control check shrinks along with it, eventually to 10 days. Let's Encrypt, already at 90 days, plans to move its default to 64 days on 10 February 2027 and to 45 days on 16 February 2028.
For DNS this means one thing: a TXT record typed by hand at every renewal stops being workable. DNS-01 needs automating, through your DNS provider's API or, if your provider has none, by delegating _acme-challenge with a CNAME, as the _acme-challenge page explains. HTTP-01 is already automatic on most hosting.
Still settling: a validation record that stays
A newer method, DNS-PERSIST-01, uses one TXT record at _validation-persist that names the certificate authority and your account with it, and stays in place, so a renewal needs no change in DNS at all. The CA/Browser Forum allowed it in October 2025 and Google Trust Services has supported it since 28 September 2026. Let's Encrypt has held it back since June 2026 while a weakness in the design is fixed, and the document describing it was revised in September 2026. Because the details may still change, this page shows no example record. Checked
Checking a live certificate
Expert Tools' TLS check shows the certificate chain as the server actually sends it, which protocol versions the server accepts, the redirect from HTTP to HTTPS, and HSTS.
Sources: CA/Browser Forum, ballot SC-081v3, Let's Encrypt's From 90 to 45, FAQ and DNS-PERSIST-01 pages, Google Trust Services on DNS-PERSIST-01, Chromium's documents on Certificate Transparency and moving EV to Page Info, and Sectigo on checks from several network locations.