A TLS certificate is one of those things nobody in the company thinks about — until it expires. Then within an hour the shop, the customer portal, the browser login to the ERP and half the integrations everyone had forgotten about all go down. It's worth having a system for this before the system takes revenge.
We saw it up close at a 30-person metal-fabrication manufacturer: the B2B portal customers used to place orders had an SSL certificate expiring at 23:00 on a Sunday. Nobody got an alert (because the alerts went to a former admin's email), and on Monday at 8:00 customers saw "Your connection is not private" instead of the order form. Four hours of paralysis, a dozen or so lost orders, roughly 60,000 PLN of revenue to claw back. The technical fix took 20 minutes. Restoring trust with a few large customers took months.
This text is about how a 10–50 person company can organise certificate management so this doesn't repeat. No enterprise PKI, no expensive tooling. A few habits and one spreadsheet are enough.
Start with an inventory — you have more certificates than you think
The first question nobody in a typical company can answer: "how many active TLS certificates do we have right now, and where are they?". "The one on the main website" rarely covers it. In practice, in an SME you'll find certificates in at least these places:
- The corporate website and its regional variants.
- The online shop, B2B portal, customer portal.
- Browser login panels to systems (webmail, HR portal, ERP service portal).
- Mail servers (SMTP/IMAPS) — even with Microsoft 365 you own subdomains with certificates for autodiscover or SPF/DMARC endpoints.
- VPN servers and firewalls (remote access, admin panel).
- Internal apps and APIs exposed over HTTPS, even on the LAN.
- Network devices with HTTPS panels (printers, NAS units, industrial cameras).
- Code-signing certificates (if you ship a desktop app or installers).
Do a simple spreadsheet — Excel or Google Sheets. Columns: name (FQDN), where installed (server/device), issuer, expiry date, business owner (not IT — the person who confirms "yes, this portal is critical"), where the private key lives, when it was last renewed. This sheet has two functions: it tells you what you have, and it exposes what you'd forgotten. The first pass at a client typically uncovers 2–3 certificates nobody knew about.
Separate "automated" from "manual"
For most external certificates (site, portal, shop) the best answer is ACME — usually Let's Encrypt — with automatic renewal every 60–75 days. The certificate lasts 90 days, the client (certbot, acme.sh, the web server's built-in mechanism) renews it with no human involved. If the automation works, it never expires. If it doesn't, you find out from an alert, not from a customer's phone call.
There are still situations where you're stuck renewing manually once a year:
- EV / OV certificates required by some banking integrations or corporate customers.
- Certificates on devices ACME can't reach (a firewall without a suitable API, an old printer, a PLC controller with an HTTPS panel).
- Code-signing certificates — by definition they don't renew themselves.
- Certificates for integrations where the other side maintains an allow-list of issuers (e.g. the public sector).
For these "manual" ones you need a procedure, because nothing will remind you on its own.
Alerts at 60, 30, 14, 7 and 1 day
Don't rely on the issuer (Let's Encrypt, DigiCert, Sectigo) to remind you. Yes, they send emails — but often to an admin who left two years ago, or with subject lines that look like spam. Run your own monitoring that regularly checks a dozen public domains and alerts a shared channel (the whole IT team's mailbox, a Teams/Slack channel — not one person's inbox).
A practical set of alert thresholds that works well in an SME:
- 60 days before expiry — soft warning, informational. It lands in the inbox, you can ignore it, but you know it's coming.
- 30 days — treat it as a task: renew, or diagnose why the automation didn't renew.
- 14 days — alarm. Someone owns it and closes it this week.
- 7 days — red light. Loop in IT leadership, escalate to the business owner of the service.
- 1 day — phone call to whoever is on duty. Seriously.
To check public TLS certificates you only need a small cron script that runs openssl s_client and reads notAfter, or free tools like Uptime Kuma with a TLS module. You don't need to buy a 20 000-a-year platform. The important part is that alerts go to a team channel, not one mailbox.
Private keys — where they live and who has access
The certificate is half the story. The private key is the other half. If the key leaks, the certificate has to be revoked and reissued — ideally yesterday. In SMEs private keys most often live in three places: directly on the production server, in the configuration repository (sometimes, unfortunately, in git unencrypted) and "just in case" in a folder named old_certs on the network share.
Rules worth holding to:
- The private key is generated on the device that will use it — not on an admin laptop and then mailed around.
- The key backup (someone will have to rebuild the server one day) lives in an encrypted secrets manager or in an offline archive, not on a shared network drive.
- Whoever had access to the key had it — after they leave the company, the key is rotated alongside the certificate.
- Keys are not in the git configuration repo. Ever. Not even in a "private" repo.
This sounds like obvious hygiene. It isn't. In practice we still find .pem files with private keys inside PowerPoint onboarding decks and in email attachments from five years ago.
Wildcard, SAN and internal CAs
Two technical choices worth making deliberately, not by momentum:
- **Wildcard (
.company.com) vs SAN (several domains in one certificate).* Wildcard is convenient — one certificate covers all subdomains. But if it leaks, the blast radius is bigger, because it covers the whole space. SAN gives you more control but has to be updated for every new subdomain. In an SME with 5–10 subdomains, SAN usually wins. In a company where subdomains sprout like weeds, a short-lived wildcard is a fair trade. - Internal certificates (your own CA) for the LAN. If you have a dozen internal panels (printers, NAS units, internal apps), stand up a small internal CA (e.g.
step-ca,smallstep) and distribute the root CA to browsers through GPO / Intune. The alternative — self-signed certificates everywhere the browser ignores — trains your team to click "Accept anyway", and that's exactly the reflex you don't want.
What next
Start with four questions:
- When was the last time anyone checked the list of all your TLS certificates — public and internal?
- Where do expiry alerts land? In one person's inbox, or in a team channel?
- Which certificates renew manually, and who specifically has that in their calendar?
- Where do the private keys of your most critical certificates live, and who has access to them today — not "historically"?
If any answer sounds like "I'm not sure" — treat it as an invitation to do the inventory this week. A one-hour meeting with one person from IT is enough for a first draft. If you need help standing up the monitoring and renewal procedure, we help SMEs with this regularly. The first call is free and takes half an hour.
The certificate nobody remembers always expires on a Friday night. Never on Wednesday at 10:00.