SSL Certificates: Types, Renewal and Common Mistakes

The padlock in the browser address bar is easy to take for granted until it disappears. An expired or misconfigured certificate turns your website into a full-page security warning, stops API integrations and can break email services that rely on the same certificate. This SSL certificate guide explains the types of certificate available, how renewal works now that lifetimes are getting shorter, and the mistakes we see most often when taking over existing websites.

What an SSL/TLS certificate does

"SSL" is the familiar name; the modern protocol is TLS, but the certificates are still commonly called SSL certificates. A certificate does two things:

1. Encrypts the connection between a visitor's browser and your server, so data such as passwords, form entries and payment details cannot be read or altered in transit.
2. Proves identity — that the server really belongs to the domain shown, verified by a trusted Certificate Authority (CA).

HTTPS is now expected for every website, not only those that take payments. Browsers label plain HTTP pages as "not secure", and many modern browser features only work over HTTPS.

Validation levels: DV, OV and EV

Certificates differ by how thoroughly the CA verifies who you are, not by the strength of encryption.

For most business websites, a DV certificate — often free and automated — is entirely appropriate. OV or EV certificates are worth considering when a client contract, industry policy or internal security standard specifically requires them.

Coverage: single, wildcard and multi-domain

• Single-domain certificates cover one hostname, such as www.example.com (often the bare domain too).
• Wildcard certificates cover all first-level subdomains, such as *.example.com. They are convenient but mean one private key protects many services, so guard it carefully.
• Multi-domain (SAN) certificates list several specific hostnames, possibly across different domains, in one certificate.

Choose based on how your services are organized. Automated certificates per hostname are often simpler and safer than one wildcard shared across many servers.

Key takeaway: The type of certificate rarely matters as much as the process around it. Automated renewal, monitoring and a correct server configuration prevent nearly every certificate-related outage.

Renewal in an era of shorter lifetimes

Certificate lifetimes have shortened significantly over the years, and the industry has agreed to shorten them further in stages. The direction is clear: manual renewal once a year is no longer a sustainable approach.

Automate with ACME

The ACME protocol, popularized by Let's Encrypt and now supported by many commercial CAs, lets servers request and renew certificates automatically. Control panels such as cPanel's AutoSSL, web servers with built-in ACME clients and tools like Certbot handle this for most websites.

Monitor anyway

Automation fails silently more often than people expect:

• DNS changes break the validation challenge.
• A firewall or CDN rule blocks the validation request.
• A certificate renews on the server, but a load balancer or CDN keeps serving the old one.
• An API key for DNS validation expires.

Monitor certificate expiry from outside your infrastructure and alert well before the deadline. Our article on website uptime monitoring covers how to fit this into broader monitoring.

Common SSL mistakes

These are the issues we encounter most when reviewing existing sites:

1. Missing intermediate certificate. The site works in some browsers but fails in others or in API clients. The server must send the full certificate chain.
2. Mixed content. HTTPS pages load images or scripts over HTTP, producing warnings or broken pages.
3. No redirect from HTTP to HTTPS, or redirect chains that hop several times before reaching the final URL — which also wastes crawl budget and slows visitors.
4. Certificate does not cover all hostnames, for example example.com works but www.example.com shows a warning.
5. Forgotten services. The website certificate renews automatically, but the mail server, admin subdomain or API endpoint uses a manually installed certificate that expires.
6. Outdated protocols and ciphers. Old TLS versions remain enabled for no reason.
7. Private keys handled carelessly — emailed, shared in chat, or reused across unrelated servers.
8. HSTS added too hastily. HTTP Strict Transport Security is valuable, but enabling a long policy with includeSubDomains before every subdomain supports HTTPS can lock users out of those services.

A good HTTPS configuration checklist

• Certificates issued and renewed automatically for every hostname, including mail and admin subdomains.
• Full certificate chain served correctly.
• TLS 1.2 and TLS 1.3 enabled, older versions disabled.
• Permanent single-step redirect from HTTP to HTTPS.
• HSTS enabled after confirming all subdomains support HTTPS.
• No mixed content on any page.
• External expiry monitoring with alerts.
• Private keys stored with restricted permissions and never shared over insecure channels.

Free online TLS testing tools can grade your configuration and highlight most of these issues in a few minutes.

SSL during website migrations

Certificates are a frequent source of trouble during server moves and redesigns. Before switching DNS, make sure the new server can obtain a certificate (some validation methods need DNS to point to it first, so plan accordingly), and that redirects, canonical URLs and internal links all use HTTPS. Our guide to SEO site migration explains why a clean HTTPS setup also matters for rankings.

Who should own certificates in your organization

Many certificate outages are organizational rather than technical. The person who bought a certificate leaves, renewal reminders go to an unmonitored mailbox, or nobody realises that a separate team runs the API subdomain. A few simple practices prevent this:

1. Keep an inventory of every certificate: hostname, issuer, expiry date, renewal method and the system it is installed on.
2. Send CA and registrar notices to a shared mailbox, not to an individual's address.
3. Assign a clear owner — usually your hosting or infrastructure provider — for renewal and monitoring.
4. Standardize the renewal method so most certificates renew the same automated way, and document the exceptions.
5. Use Certificate Transparency monitoring to receive alerts when any certificate is issued for your domains. This also helps spot certificates issued by someone who should not have them.
6. Consider CAA records in DNS, which specify which Certificate Authorities are permitted to issue certificates for your domain.

Certificates beyond the website

Remember that TLS certificates also protect mail servers (SMTP, IMAP), internal admin tools, API endpoints, VPNs and sometimes devices on your network. These are often installed manually and forgotten. Include them in the same inventory and monitoring, because an expired certificate on a mail server can quietly stop email delivery or trigger warnings on every staff member's phone.

Choosing between free and paid certificates

For most organizations the decision is straightforward:

Paying for a certificate does not remove the need for monitoring. Whichever option you choose, the renewal process and the alerts around it are what keep the padlock in place.

Next steps

If you cannot say with confidence when each of your certificates expires and how it renews, that is worth fixing this week. DigiVort manages certificates, automatic renewal and expiry monitoring for every site on our managed hosting, and reviews TLS configuration as part of our security and compliance work. Contact us if you would like a quick review of your domains.