Why does a certificate work in my browser but not in curl or an API client?

The server is probably not sending its intermediate certificate. Browsers often fill the gap, either from a built-in list of known intermediates or by downloading the issuer from the address in the certificate; most other clients do not, and fail with an unknown issuer. The TLS certificate check verifies like a strict client, so it shows the problem as TLS_UNTRUSTED .

Does the common name still matter?

No. RFC 9525 says clients match the server's name only against the DNS names in the subject alternative name extension; RFC 6125 before it still allowed the common name as a last resort when there were none. Publicly trusted certificates must list every name there, and current browsers ignore the common name for matching.

How long can a certificate be valid?

The CA/Browser Forum Baseline Requirements set the maximum. It was 398 days from 2020, and ballot SC-081 shortens it in steps: 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Short lifetimes only work with automated renewal, for example with ACME.

Is a wildcard certificate valid for the bare domain?

No. A wildcard such as *.example.com stands for exactly one label, so it covers www.example.com but neither example.com nor a.b.example.com . Certificates that should cover both list example.com and *.example.com as separate names.

TLS certificates explained: expiry, chain and names

When a browser, an API client or a mail server opens a TLS connection, the server presents a certificate. The client accepts it only when three things hold: it was issued, directly or through intermediates, by a certificate authority the client trusts; it is valid today; and it is issued for the name the client asked for. RFC 5280 defines the certificate format and how a chain is validated, RFC 9525 how the name is matched, and RFC 8446 the TLS 1.3 handshake that carries it.

The chain of trust

A client trusts a small set of root certificates, shipped with the operating system or the browser. Roots rarely sign server certificates themselves. They sign intermediate certificates, and an intermediate signs the server's certificate, the leaf. The server must send the leaf and every intermediate; the client adds the root from its own store.

If an intermediate is missing, the client cannot build the chain. Some clients repair it, most do not, and the result is an error such as "unable to get local issuer certificate". The TLS certificate check reports this as TLS_UNTRUSTED with the reason unknown_issuer or incomplete_chain. A self-signed certificate, which is its own issuer, gives the reason self_signed.

The fix is a server configuration change: serve the full chain file your certificate authority provides (often called fullchain.pem), not only the leaf.

Validity dates

Every certificate has a notBefore and a notAfter date. Outside that window it is invalid, and clients refuse it; after notAfter the check reports TLS_CERT_EXPIRED.

Lifetimes are getting shorter. The CA/Browser Forum Baseline Requirements, which publicly trusted authorities must follow, allowed 398 days from 2020. Ballot SC-081 lowers the maximum to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Renewing by hand once a year therefore stops working; automated renewal, usually with the ACME protocol, is the normal case.

Automated renewal normally runs about 30 days before expiry. The check gives information from 30 days (TLS_CERT_EXPIRING) and a warning below 14 days (TLS_CERT_EXPIRING_SOON), when a failed renewal is the likely explanation.

Names

The names a certificate covers are in its subject alternative name extension, as DNS names. RFC 9525 tells clients to compare the requested name with these DNS names only; the subject's common name is not used. A wildcard is allowed only as the complete left-most label: *.example.com matches www.example.com, but not example.com, a.b.example.com or wwwexample.com.

A certificate that does not list the name gives TLS_HOSTNAME_MISMATCH. Typical causes are a certificate for www.example.com served on example.com, or a shared hosting server that answers with another customer's certificate because the client's server name (SNI) is not configured.

Keys and signatures

The Baseline Requirements ask for RSA keys of at least 2048 bits or elliptic curve keys on the NIST curves P-256, P-384 or P-521. Smaller keys give TLS_WEAK_KEY. Signatures made with SHA-1 or MD5 are no longer accepted, because collisions for both have been shown; they give TLS_WEAK_SIGNATURE. The signature on a root certificate is not checked, because clients trust the root directly.

Who may issue

CAA records let a domain name the certificate authorities that may issue for it. They do not affect certificates that already exist, but they stop an authority you do not use from issuing a new one. The CAA record check shows the current policy.

Common mistakes

Serving only the leaf certificate, so strict clients cannot build the chain.
Renewing the certificate but not reloading the web server, so the old one is still served.
A certificate for www.example.com on a server that also answers for example.com.
A load balancer or CDN with its own certificate that is renewed separately and forgotten.
Monitoring only the browser view, which hides chain problems that break API clients and mail servers.