At 3 am on a Friday an online store’s certificate expired, and every visitor got a full-screen warning instead of the shop. Nobody noticed until noon. This failure is about to get more common: since 15 March 2026, certificate authorities no longer issue certificates valid for more than 200 days, and the limit drops to 47 days in 2029. Understanding certificates today goes beyond the padlock in the address bar: what a certificate really proves, how the browser checks it, which type and key to choose, and how to automate its renewal and check it yourself.
01What a certificate proves, and what it doesn’t
A certificate is a small document that binds a public key to domain names, signed by a the browser trusts. When your visitor connects to your site over , your server proves it holds the matching private key, so the browser knows it’s talking to whoever really controls the domain. The two then agree on keys that encrypt everything they exchange. The common name “SSL certificate” survives from an old protocol; the connection itself runs on TLS 1.2 or 1.3 today.
- What it proves: That the server holds the private key for a name whose control the CA validated, and for OV and EV certificates, the organization’s name and country too.
- What it doesn’t prove: That the site is honest: phishing sites carry valid DV certificates. Nor that the server is free of compromise, nor that data is protected once it arrives there.
So the padlock means “encrypted connection to whoever owns this name”, not “safe website”. That alone is worth having: without it, passwords and card numbers can be read by anyone along the way, from café Wi-Fi to any hop on the path.
02The TLS 1.3 handshake in brief
Before the first byte of your page arrives, the browser and server run a handshake that takes a single round trip in TLS 1.3:
- 01ClientHello: The browser sends the versions and algorithms it supports, the requested domain name (SNI) so the server can pick the right certificate, and its share of the key exchange.
- 02ServerHello: The server picks the algorithm and sends its share, both sides derive the session keys, and everything that follows is encrypted.
- 03Certificate and signature: The server sends its certificate with the intermediate certificates, and signs the handshake with its private key to prove it holds it.
- 04Verification: The browser checks that the chain ends at a root it trusts, that the name is listed in the certificate and that it’s within its validity period; then data starts flowing.
Session keys are ephemeral, derived for each connection and then discarded, so someone who steals your server’s key later can’t decrypt connections they recorded in the past. TLS 1.0 and 1.1 have been switched off in browsers since 2020 and were formally deprecated by the IETF in 2021, so set TLS 1.2 as your server’s minimum, and prefer 1.3.
03DV, OV and EV, and what each covers
The validation level sets what the CA checked before signing, not the strength of the encryption: the key and the algorithm are the same at all three levels.
| Level | What the CA validates | Issuance | What visitors see today |
|---|---|---|---|
| DV | Control of the domain: an email, a DNS record or a file on the site | Within minutes | The padlock only |
| OV | The domain, then the organization’s legal documents and physical location | After document review | The padlock, and the organization’s name in the certificate details |
| EV | Strict checks of the legal entity, its address and the representative’s authority | After address and representative checks | The padlock, and the organization’s name, country and entity details in the details |
The green bar with the company name is gone: since 2019 the major browsers no longer show the organization’s name in the address bar, and in 2023 Chrome replaced the padlock itself with a neutral icon. So choose OV or EV when you need anyone who opens the certificate details to find your verified identity, or when a contract or compliance audit requires it.
Certificates also differ in the names they cover, and the browser accepts only the names written in them:
- Single domain: Usually lists both forms, with and without www.
- Wildcard: Named with a leading asterisk such as *.luban-dhofar.com, it covers the domain and all its first-level subdomains, but not deeper ones such as api.v2.luban-dhofar.com.
- Multi-domain (SAN): Different names in one certificate, such as luban-dhofar.com and luban-dhofar.net.
Illevante offers twenty certificates from five certificate authorities, Sectigo, DigiCert, GeoTrust, thawte and RapidSSL, at all three levels, for a single domain, a Wildcard or several domains, and some can be issued for an IP address.
04The key, the chain and CAA
RSA or ECDSA
You choose the key type when you create the certificate signing request (CSR). An ECDSA key on the P-256 curve gives security roughly equal to a 3072-bit RSA key, with a smaller signature and a lighter handshake on the server’s CPU, and every modern browser and operating system supports it. Keep RSA 2048 when you serve very old devices or systems; some servers offer both certificates and pick one per client.
# An ECDSA P-256 key and a signing request covering the domain and www (OpenSSL 1.1.1 or later)openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \ -keyout luban-dhofar.key -out luban-dhofar.csr \ -subj "/CN=luban-dhofar.com" \ -addext "subjectAltName=DNS:luban-dhofar.com,DNS:www.luban-dhofar.com"# The private key never leaves the server: readable by its owner onlychmod 600 luban-dhofar.key
The chain and the intermediate certificate
Certificate authorities don’t sign your site’s certificate with their root directly but with an , and only the root is preinstalled in browsers and operating systems. So your server must send its certificate together with the intermediate, in one file usually called fullchain. Forget it, and the site may work in a desktop browser that fetches or caches the missing intermediate, yet fail in curl, mobile apps and APIs. It’s one of the most deceptive certificate faults.
The CAA record
A CAA record in DNS lists the certificate authorities allowed to issue certificates for your domain, and every CA checks it before issuing. GeoTrust, thawte and RapidSSL are brands issued by DigiCert, so a digicert.com line usually covers them, but check your CA’s documentation to be sure. And don’t forget the CA your automatic certificates come from, or their renewal will fail without you noticing.
# Paid certificates from Sectigoluban-dhofar.com. 3600 IN CAA 0 issue "sectigo.com"# Automatic certificates from Let’s Encrypt, if you use themluban-dhofar.com. 3600 IN CAA 0 issue "letsencrypt.org"# An address that gets an alert for every refused requestluban-dhofar.com. 3600 IN CAA 0 iodef "mailto:[email protected]"
05Lifetimes are shrinking: 200 days, then 100, then 47
The CA/Browser Forum, which sets the rules for certificate authorities and browsers, passed ballot SC-081 to shorten certificate lifetimes in stages, along with how long a domain validation may be reused before it must be repeated:
| From | Maximum certificate lifetime | Domain validation reuse |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
In practice, renewing by hand once a year is over. Today every certificate needs a new copy at least twice a year, and by 2029 eight times or more, with nearly every issuance needing a fresh domain validation. Only holds up to that: the protocol a program on your server uses to request the certificate, prove control of the domain, and renew and install it on its own.
And paid certificates? You buy one for a year, and Illevante lets you reissue it throughout its validity, so you issue a new copy within the subscription whenever the installed one nears the limit the rules set. Large CAs such as Sectigo and DigiCert offer ACME to their accounts too; if it isn’t available to you, monitor the expiry date automatically rather than relying on memory.
On Illevante’s cPanel hosting, AutoSSL does this for you: it issues a certificate for every domain or subdomain you connect to the hosting and renews it before it expires. On a VPS, a tool such as certbot takes care of it:
# Ubuntu or Debian with nginxsudo apt install -y certbot python3-certbot-nginxsudo certbot --nginx --key-type ecdsa -d luban-dhofar.com -d www.luban-dhofar.com# Test renewal without issuing a real certificatesudo certbot renew --dry-run# The renewal timer the package installedsystemctl list-timers | grep certbot
06HTTPS all the way, then check it yourself
An installed certificate is half the job. Redirect every HTTP request to HTTPS with a permanent (301) redirect, then tell the browser not to try HTTP at all with an header. Start with a short duration, and add includeSubDomains only once all your subdomains run on HTTPS, because the browser will refuse any unencrypted subdomain for the whole period.
# nginx: redirect all HTTP to HTTPSserver { listen 80; server_name luban-dhofar.com www.luban-dhofar.com; return 301 https://$host$request_uri;}# Inside the server block listening on 443: protocols and HSTS (start with a day, then raise it to a year)ssl_protocols TLSv1.2 TLSv1.3;add_header Strict-Transport-Security "max-age=86400" always;
After the switch, look for mixed content: an HTTPS page loading a script or an image over http. Browsers block unencrypted scripts and frames, and try to upgrade images and media to https, blocking them if that fails, so parts of your page vanish or stop working. The fix is to correct the links in your templates and database, not to ignore the warning. Then check what your server actually sends, from outside it:
# The chain as the server sends it, and the verification result (look for Verify return code: 0)openssl s_client -connect luban-dhofar.com:443 -servername luban-dhofar.com -showcerts </dev/null# Subject, issuer and validity datesecho | openssl s_client -connect luban-dhofar.com:443 -servername luban-dhofar.com 2>/dev/null | openssl x509 -noout -dates -issuer -subject# The names written in the certificateecho | openssl s_client -connect luban-dhofar.com:443 -servername luban-dhofar.com 2>/dev/null | openssl x509 -noout -ext subjectAltName# Exit code 1 if it expires within 21 days: hook it into your monitoringecho | openssl s_client -connect luban-dhofar.com:443 -servername luban-dhofar.com 2>/dev/null | openssl x509 -noout -checkend 1814400# Protocol version, cipher and the HSTS header as a real client sees themcurl -svI https://luban-dhofar.com 2>&1 | grep -Ei "SSL connection|expire date|issuer|strict-transport"
If you’d rather not open a terminal, Illevante’s SSL certificate check shows the issuer, the expiry date and the chain of trust for any website. These are the faults that keep coming back after installation or renewal:
- ProblemThe site works in a desktop browser but fails in curl and mobile apps with “unable to get local issuer certificate”
- FixThe server isn’t sending the intermediate certificate. Install the full chain file (fullchain), and confirm with openssl s_client that the server sends more than one certificate.
- ProblemA name-mismatch warning on www or on the bare domain
- FixThe name isn’t in the SAN list. Reissue the certificate with both names.
- ProblemIssuance or automatic renewal suddenly fails
- FixCheck the CAA record: the CA may not be listed. Then make sure the validation record in DNS, or the validation path on the site, reaches your server.
- ProblemThe certificate was renewed, but the browser still shows the old, expired one
- FixThe web server hasn’t reloaded its configuration. Reload it, and have your renewal tool do so after every renewal.
- ProblemThe padlock shows with a “not fully secure” warning
- FixMixed content: resources loaded over http. Fix their links in your templates and database.
07Practical recommendation
Make automation the starting point, not an afterthought: AutoSSL on cPanel hosting, or certbot or any ACME client on your server, plus expiry monitoring that warns you at least 21 days ahead. Choose an ECDSA P-256 key, limit the server to TLS 1.2 and 1.3, serve the full chain, add CAA with every CA you use, and turn on HSTS once you’re sure everything works over HTTPS.
A DV certificate is enough for most websites. When you need your organization’s identity verified in the certificate at OV or EV level, an insurance warranty, or direct support from the CA, choose a paid certificate, and plan to reissue it at least twice in each subscription year. With lifetimes dropping to 100 days in March 2027, every certificate renewed by hand today is an outage waiting to happen.
