For most small business websites, the SSL certificate is the part of the site nobody thinks about until it breaks. The padlock appears, the address starts with https and the renewal email lands in an inbox once a year or so. Then one morning a customer calls to say the browser is showing a full-page warning, the checkout will not load and the contact form has gone quiet.

The certificate world has been changing in ways that make that scenario both more avoidable and, for sites still renewing by hand, more likely. One of the largest certificate authorities has announced it will stop supporting an older method of checking whether certificates have been revoked. Certificate lifetimes have been short for years at some providers, and the practical answer to all of it is the same: automate renewals and know exactly which certificates you own.

This article explains what is changing, why it matters to an ordinary business site and what to ask your host or developer before the new year gets busy.

What an SSL certificate actually does

Strictly speaking, modern sites use TLS, the successor to SSL, but most people still say SSL certificate and we will too. The certificate does two jobs. It proves to a visitor’s browser that the site really belongs to the domain in the address bar, and it allows the browser and server to set up an encrypted connection so nobody in between can read what is sent.

The National Institute of Standards and Technology’s practice guide Securing Web Transactions: TLS Server Certificate Management, finalized in June 2020, explains why that matters in plain business terms. It warns that organizations risk losing revenue, customers and reputation if they do not properly manage these certificates, and that improper management results in significant outages to web applications and services.

The guide is written for larger enterprises, but the core problem scales down neatly. Every certificate has an expiration date. If a certificate is not replaced before that date, browsers show an error and stop the connection, which makes the site behind it unavailable to most visitors.

The OCSP change, in plain language

When a certificate needs to be cancelled early, for instance because its private key may have been exposed, the certificate authority revokes it. Browsers and other software need some way to learn about revocations. Two methods have been used for years: the Online Certificate Status Protocol, or OCSP, and Certificate Revocation Lists, or CRLs.

On December 5, 2024, Let’s Encrypt, the certificate authority operated by the Internet Security Research Group, or ISRG, published Ending OCSP Support in 2025. The post set out a timeline. From January 30, 2025, requests for certificates with the OCSP Must-Staple extension will fail unless the account has previously issued one. On May 7, 2025, OCSP addresses will be dropped from new certificates and all Must-Staple requests will fail. On August 6, 2025, its OCSP responders will be turned off.

The organization gave two main reasons. OCSP represents a privacy risk, because the authority answering each check learns which website is being visited from which IP address. And keeping its infrastructure simple matters for compliance, reliability and efficiency now that it supports CRLs.

For most business websites, the post says, websites and the people who visit them will not be affected. The exceptions are narrower: some non-browser software, such as a VPN that relies on certificates, and the small number of sites whose configuration requests the Must-Staple extension. If either applies to you, action is needed before May 2025.

Hands in red sleeves type on a laptop beside a small teal server box with green status lights.

Why short lifetimes and automation go together

Certificates from Let’s Encrypt have always been short-lived. In a November 9, 2015 post titled Why ninety-day lifetimes for certificates?, the organization explained its reasoning. Short lifetimes limit the damage from key compromise and mis-issuance, because a stolen key or wrongly issued certificate is valid for less time. And they encourage automation, which the post described as absolutely essential for ease of use.

The same post made a point that still holds: if the whole web is going to use HTTPS, system administrators cannot be expected to handle renewals by hand. Once issuance and renewal are automated, it argued, shorter lifetimes are no less convenient than longer ones. It recommended renewing every sixty days, leaving a cushion before the ninety-day expiry.

That cushion is the real lesson for small businesses. A renewal that runs automatically every couple of months, and that alerts someone when it fails, turns certificates into background plumbing. A renewal that depends on someone noticing an email and logging into a control panel is a scheduled outage waiting for a busy week.

Where small business sites get caught out

Most certificate outages do not come from exotic attacks. They come from ordinary gaps in ownership and process. A few patterns show up again and again.

The first is the forgotten certificate. The main website renews automatically through the host, but a second domain, a booking subdomain, a staging site or an old landing page still carries a certificate someone bought separately years ago. The NIST guide recommends establishing an inventory of certificates within the first 90 days of a management program, and for a small business that inventory might fit on a single page.

The second is the renewal that silently failed. Automation is only as good as its monitoring. If a domain’s DNS settings change, a server moves or a validation file is deleted during a redesign, the automated renewal may fail without anyone noticing until expiry.

The third is the departed contact. Renewal notices go to the email address of a former employee, a developer who has moved on or an agency that no longer manages the site. The warnings are sent on time and read by no one, and the first sign of trouble is a customer phoning to ask whether the site has been hacked.

The fourth is the intermediate chain. The NIST guide also notes that outages can be caused by mismanaged chains of intermediate certificates, the links between your certificate and the authority’s root. These problems often appear only on certain devices or apps, which makes them confusing to diagnose.

Free versus paid certificates

Owners sometimes ask whether a free certificate is good enough or whether paying for one adds protection. For the encryption itself, the answer is usually that both do the same job: the browser and server set up the same kind of secure connection either way.

The differences lie elsewhere. Some paid certificates include extra checks on the organization behind the domain, longer support arrangements or bundled services from the seller. Those can matter for certain businesses, such as companies with contractual or industry requirements. For a typical brochure site, booking page or small shop, a free certificate renewed automatically by the host is often the more reliable choice, simply because it removes the manual step.

Whichever route you choose, the management questions are the same. Someone needs to know where each certificate lives, when it expires and how renewal happens. A paid certificate that renews by hand once a year can still lapse if the reminder goes to the wrong person.

Questions to ask your host or developer

You do not need to understand the cryptography to manage this well. You need clear answers to a handful of questions.

Which certificates cover my domains and subdomains, who issued each one and when does each expire? Are all of them renewed automatically? How will I be notified if an automatic renewal fails, and who receives that alert? Does anything on my site or in my systems request OCSP Must-Staple, and does any non-browser software we use depend on OCSP? Are any certificates purchased and installed manually, and if so, can they be moved to automated renewal? Who has the login for the account where certificates are issued, and is that account tied to a current business email address?

Write the answers down and keep them with your other website records. If the answer to any question is “I’m not sure,” that is the first thing to fix.

A young woman in a teal shirt smiles at her phone at a cafe table beside a red cup.

A simple certificate routine for the new year

Start with an inventory. List every domain and subdomain you use, including ones for email marketing, booking, shops or old campaigns. For each, note the certificate issuer, the expiry date, whether renewal is automated and who is responsible.

Next, confirm monitoring. Many hosts and uptime services can alert you when a certificate is close to expiry. Set the alert to go to a shared business address rather than one person’s inbox, and test it.

Then retire what you do not need. Old subdomains that point nowhere useful are a renewal burden and a security risk. Remove them or redirect them properly.

Finally, review the routine twice a year. Put a reminder on the calendar to check the inventory, confirm the alerts still work and update contacts. It takes less than an hour and prevents the kind of outage that costs a day of sales, a stack of support calls and some hard-won customer trust too.

If a certificate expires anyway

Even with good habits, an expiry can slip through. Knowing the first steps keeps a bad morning from becoming a lost week.

Confirm the problem first. Open the site in a private browser window on a phone and a computer and note the exact warning. Check the certificate details in the browser to see the expiry date and which domain the certificate covers. Sometimes the issue is not expiry at all but a certificate issued for the wrong name or a missing intermediate link.

Then contact whoever manages renewal, usually your host or developer, and ask them to reissue and install the certificate. With automated tools that often takes minutes once someone looks. While you wait, tell staff what customers will see, so phone calls get a calm explanation instead of guesswork.

Afterward, find out why renewal failed and fix the cause, not just the symptom. A changed DNS record, a moved server or an expired payment card on a certificate account will cause the same outage again in a few months if nobody corrects it.

How this fits into wider site security

Certificates are one layer of a site’s protection, alongside software updates, secure logins, backups and sensible hosting choices. A lapsed certificate is often a symptom that nobody owns the technical health of the site, and the same gap tends to show up elsewhere.

If you would like help reviewing your certificates and the settings around them, Motta’s trust and security work starts with exactly this kind of inventory. Our website maintenance plans include monitoring for expiring certificates and failed renewals, and our web hosting is set up with automated renewal from the start, so the padlock keeps working while you focus on the business.