SSL certificaat verlopen - wat te doen

Kort: Het verloop van een SSL certificaat zorgt ervoor dat browsers de toegang blokkeren met de melding "Je verbinding is niet privé". Conversie zakt naar nul totdat je het certificaat vernieuwt. Dit artikel is een snelle procedure over wat onmiddellijk te doen en hoe te voorkomen.

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". Meer dan 95 % van het organisch verkeer vertrekt gewoon. Bot crawlers (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, doorloop domeinvalidatie (DNS TXT of email).
4. Deploy het nieuwe cert naar de reverse proxy (nginx, Caddy, Traefik) en herstart / reload het proces.
5. Verifieer via SSL Labs of via onze SSL check tool, of het cert correct geserveerd wordt en de chain compleet is.

Let op: Vergeet het intermediate cert niet - zonder 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 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 (standaard 30 dagen vooraf). Zo ja, vernieuwt het 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 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 renewal cycle.

Commerciële certs: 1-3 jaar geldigheid

Sinds september 2020 hebben alle publiek vertrouwde certs een maximale levensduur van 397 dagen (CA/B Forum baseline). Sommige bedrijven verkiezen nog steeds commerciële CA's vanwege:

• 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. Verlenging kan falen door:

• 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 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 →