SSL certificaat verlopen - wat te doen

Wat de bezoeker ziet

Een verlopen certificaat triggert een full-screen waarschuwing in de browser:

• Chrome / Edge: "Your connection is not private" (NET::ERR_CERT_DATE_INVALID)
• Firefox: "Warning: Potential Security Risk Ahead" (SEC_ERROR_EXPIRED_CERTIFICATE)
• Safari: "This Connection Is Not Private"

Een gewone bezoeker klikt op "Terug". De overgrote meerderheid van de bezoekers verlaat de pagina bij zo'n waarschuwing. Crawlers van zoekmachines (Googlebot, Bingbot) stoppen met indexeren en na een paar dagen verlies je posities in zoekmachines.

Procedure als het net is verlopen

1. Identificeer wie het cert heeft uitgegeven. In de terminal: openssl s_client -connect mywebsite.com:443 -servername mywebsite.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates
2. Let's Encrypt (gratis, 90-daagse geldigheid): typisch via certbot renew of via het hosting paneel (One-click renewal).
3. Commercieel cert (DigiCert, Sectigo, GlobalSign): log in op het admin paneel van de uitgever, genereer een nieuwe CSR en doorloop de domeinvalidatie (DNS TXT-record of email).
4. Deploy het nieuwe cert naar de reverse proxy (nginx, Caddy, Traefik) en herstart of reload het proces.
5. Verifieer via SSL Labs of via onze SSL check tool of het cert correct geserveerd wordt en de certificaatketen compleet is.

Let op: Vergeet het intermediate cert niet - zonder dat kunnen moderne browsers de chain via AIA ophalen, maar oudere clients en sommige API libraries zullen falen.

Automatische verlenging: Let's Encrypt + certbot

De eenvoudigste preventie is de verlenging volledig automatiseren. Het Let's Encrypt cert verlengt zich elke 90 dagen via certbot:

# /etc/cron.d/certbot-renew
0 3 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

Deze cron draait dagelijks om 3:00 's ochtends. Certbot controleert intern of het cert de vervaldatum nadert (wanneer minder dan een derde van zijn levensduur resteert, wat voor een 90-daags Let's Encrypt cert neerkomt op ongeveer 30 dagen voor het einde). Zo ja, vernieuwt het cert en reload bij succes nginx. Anders doet het niets.

Caddy en Traefik: volledig automatisch

Als je Caddy of Traefik gebruikt als reverse proxy, is de ACME challenge direct ingebouwd in de binary. Het volstaat het domein in de config te markeren en de server vraagt en vernieuwt het cert zelf:

# Caddyfile
mywebsite.com {
  reverse_proxy localhost:3000
}

Geen certbot, geen cron. Caddy roept op de achtergrond de Let's Encrypt API aan en beheert de hele renewal cycle.

Commerciële certs: 1-3 jaar geldigheid

Sinds september 2020 hebben alle publiek vertrouwde certs een maximale levensduur van 398 dagen (CA/B Forum baseline). Sommige bedrijven verkiezen toch nog steeds commerciële CA's, en wel om deze redenen:

• Extended Validation (EV) toont de organisatie in de adresbalk (Chrome toont het sinds 2019 niet meer prominent).
• Wildcard voor veel subdomeinen hoewel Let's Encrypt nu wildcards via DNS-01 ondersteunt.
• Garantie financiële aansprakelijkheid van de CA bij compromise.
• Compliance / audit sommige sectoren hebben externe vereisten.

Voor de meeste sites is Let's Encrypt of een andere gratis CA (ZeroSSL, Buypass) voldoende.

Vervaldatum monitoring als vangnet

Zelfs met automatische verlenging werkt vervaldatum monitoring als verzekering. De verlenging kan namelijk om verschillende redenen falen:

• rate limit aan de CA kant (Let's Encrypt: 5 duplicaten / 7 dagen)
• DNS wijziging die de ACME challenge breekt
• firewall regel die poort 80 blokkeert (HTTP-01 challenge)
• crash van certbot of de cron die niemand opmerkte

ePulz.io volgt de vervaldatum van elke gemonitorde endpoint en stuurt een alert 30, 14, 7, 3 en 1 dag voor het einde van geldigheid. Eén groen signaal volstaat dat het cert tijdig vernieuwd is - en je hebt zekerheid dat de automatisering werkt.

Activeer SSL monitoring

Alerts 30/14/7/3/1 dagen voor verloop. Zonder configuratie, zonder DNS wijzigingen. 7 dagen gratis.

Monitoring starten →