Sentinela.
← Volver al blog

14 de abril de 2026 · 5 min · Carol

SSL TLS certificado seguridad

Certificado SSL expirado: qué pasa y cómo evitarlo

Un certificado SSL vencido tira tu sitio sin aviso. Por qué pasa, qué ve el usuario, y por qué solo te enteras cuando alguien llama a quejarse.

It's 2:37 PM on a Tuesday. Your site stops taking orders. Nobody deployed. The server is up. The database responds. But Chrome shows a giant red screen saying "Your connection is not private" and nobody gets past it.

Welcome to the club of people who let their SSL certificate expire.

What an SSL certificate is and why it expires

An SSL/TLS certificate is a file signed by a certificate authority (Let's Encrypt, DigiCert, Sectigo, etc.) that says: "this server really is the owner of the domain yoursite.com". The browser trusts that file because it trusts whoever signed it.

Every signature has an expiry date. It used to be 2 years, then 1 year, now the standard is 90 days (Let's Encrypt) and the industry is moving toward 47 days by 2029. The logic: short-lived certificates limit the damage if the private key leaks.

The problem is simple: if nobody renews before expiry, the browser stops trusting and the site becomes inaccessible.

What the user sees

Each browser has its own version of the same warning. In Chrome:

Your connection is not private NET::ERR_CERT_DATE_INVALID Attackers might be trying to steal your information from yoursite.com

There's a tiny "Advanced" link that lets you continue anyway — but:

  1. The vast majority of users give up right there.
  2. Mobile apps consuming your API simply fail, with no "proceed" option.
  3. Webhooks from other systems (Stripe, payment gateways) stop arriving — they validate the certificate and abort silently.
  4. Google's bots record the error and may demote you in ranking.

In e-commerce, the effect is instant: zero orders until someone notices.

Why this still happens in 2026

You might think that with Let's Encrypt and automatic renewal, nobody lets a certificate expire anymore. Wrong. The most common causes:

1. Auto-renewal broke and nobody saw. The Certbot cron was configured, but the server was migrated and the task didn't come along. Nobody tested it. The previous certificate had 80 days left when it migrated. Ten days later, it expires.

2. The domain was added to the certificate but never included in the renewal. You bought shop.yoursite.com, generated a certificate for that subdomain, but the automatic script only renews yoursite.com. Three months later, only the shop goes down.

3. The IP changed, the provider changed, the challenge method changed. Let's Encrypt needs to prove you control the domain. If the old method (HTTP-01 at the root) stops working because you moved the server behind a Cloudflare proxy, renewal fails silently.

4. Manually issued certificate. Someone bought an annual certificate from a paid CA, configured it by hand, and left the company. Renewal isn't automated anywhere. It expires without warning.

5. The warning email goes to a dead inbox. CAs send a warning 30/14/7 days before expiry — to the technical contact email registered in WHOIS, which is often admin@company.com of someone who left two years ago.

How to find out before the user does

The only real defense is to actively monitor validity, off the server (because if the server breaks, it won't warn you).

A simple check: every hour, an external bot connects to your domain, reads the certificate, sees the expiry date, and fires an alert if there are fewer than 30 days left, then 7, then 1. Three alert tiers give you room to act before disaster.

What the monitor should check:

  • Expiry date (not enough — catches 99% but misses misissuance)
  • Full certificate chain — a missing intermediate causes errors in Firefox/Safari even with a valid cert
  • CN/SAN match with the hostname accessed
  • TLS version (1.0/1.1 still active count as a problem)
  • Revocation via OCSP

How Sentinela warns you

We do all of this. The TLS probe checks:

  • Leaf certificate expiry
  • Full chain validity
  • CN/SAN match
  • Enabled TLS versions (alerts on 1.0/1.1 and missing 1.3)
  • Weak cipher suites
  • HSTS configured

And the uptime monitor checks every minute whether the TLS handshake still completes. If the certificate expires at 3:47 AM on a Sunday, you're notified within 60 seconds by email, webhook or Telegram — not by the furious customer on Monday morning.

There's a 14-day free trial on the monitoring plan — set it up in 2 minutes and never miss an expiry again.

The simple rule

If your business depends on a site being up, monitoring uptime without monitoring the SSL certificate is leaving half the house unlocked. The server can be perfect, the code can be perfect, and a 4kb file expired — and nobody bought anything today.

Check today. Set up an alert today. Sleep better.

Sigue leyendo