De SSL-verloop-noodsituatie: wanneer je beveiligde site onveilig wordt#

Een klant navigeert dinsdagochtend naar je SaaS-product. Hun browser gooit een angstaanjagende fout: "Your connection is not secure. This site's certificate has expired."

De eerste gedachte van de klant: "Is mijn data veilig? Zijn ze gehackt?" Ze sluiten het tabblad en komen niet terug.

Voor een SaaS-bedrijf is SSL-certificaatverloop niet zomaar een technisch probleem — het is een ramp voor klantvertrouwen. Eén verlopen certificaat kan maanden aan opgebouwde merkreputatie in minuten tenietdoen.

De omvang van het probleem: 65% van de websites krijgt op enig moment te maken met SSL-certificaatverloop. Voor SaaS-bedrijven met meerdere subdomeinen en regionale deployments is het risico nog groter. Elk subdomein (api.jouwdomein.nl, staging.jouwdomein.nl, eu.jouwdomein.nl) heeft zijn eigen certificaat nodig of een wildcard die ze allemaal dekt.

Mis er één, en je API wordt niet vertrouwd. Klant-requests falen. Hun integraties breken. Support-tickets stromen binnen.

Waarom SSL-certificaten van SaaS anders zijn#

1. Meerdere subdomeinen en certificaten

Een traditionele website heeft mogelijk één SSL-certificaat: jouwdomein.nl

Een SaaS-bedrijf heeft er veel:

jouwdomein.nl (hoofdwebsite)
app.jouwdomein.nl (SaaS-applicatie)
api.jouwdomein.nl (publieke API)
admin.jouwdomein.nl (admin-paneel)
webhooks.jouwdomein.nl (webhook-receiver)
cdn.jouwdomein.nl (CDN-distributie)
eu.jouwdomein.nl (regionale deployment)

Elk subdomein kan een eigen certificaat hebben, of je gebruikt een wildcardcertificaat (*.jouwdomein.nl) dat alle subdomeinen dekt. Hoe dan ook, je hebt meerdere faalpunten.

2. Certificaten over meerdere cloud-providers

Veel SaaS-bedrijven deployen over AWS, Google Cloud, Azure:

AWS Certificate Manager regelt certificaten voor us-east-1-instanties
Cloudflare beheert certificaten voor CDN
Let's Encrypt regelt certificaten voor self-hosted-componenten
Externe CA beheert certificaten voor legacy-systemen

Verloop beheren over deze systemen is chaotisch zonder gecentraliseerde monitoring.

3. Auto-renewal-failures zijn stil

De meeste certificaten worden automatisch vernieuwd via diensten zoals Let's Encrypt. Maar auto-renewal kan stilletjes falen:

Let's Encrypt stuurt renewal-request naar je server
DNS-misconfiguratie veroorzaakt validatiefout
Firewall blokkeert renewal-verkeer
Certificate store is vol, renewal kan het nieuwe cert niet wegschrijven

Je certificaat "verloopt over 5 dagen" maar niemand merkt het op tot klanten "connection not secure" melden.

4. Complexiteit van wildcardcertificaten

Wildcardcertificaten (*.jouwdomein.nl) dekken alle subdomeinen maar vereisen DNS-validatie. Als DNS-validatie tijdens renewal faalt, verloopt het wildcard-cert en worden alle subdomeinen niet langer vertrouwd.

De SSL-certificaatverloop-cascade#

Dag 0: certificaat staat op het punt te verlopen#

Je certificaat verloopt over 30 dagen. Als het wordt gemonitord, krijg je een e-mail-alert. Zo niet, krijg je niets.

Dagen 0-29: stille aftelling#

Niemand handelt. Het alert is begraven in e-mail. Engineering-team ziet het niet. Het is geen high-priority issue.

Dag 30: certificaat verloopt#

Op 00:00 UTC op de vervaldatum is je certificaat ongeldig. Browsers tonen "connection not secure" voor alle gebruikers.

Uren 1-2: klanten merken het#

De eerste klanten gaan naar je SaaS. Ze zien de beveiligingswaarschuwing. Ze sluiten het tabblad. Support-tickets beginnen te stromen: "Is jouwdomein.nl gehackt?"

Uren 2-4: klant-churn begint#

Meer klanten zien de waarschuwing. Sommigen nemen contact op met support. Anderen vertrekken gewoon. Als ze je SaaS aan het evalueren waren, geeft dit de doorslag — ze vertrouwen je niet.

Uren 4-8: engineering-team ontdekt het#

Je engineering-team merkt het probleem eindelijk op (via klant-klachten of wanneer ze toegang tot prod proberen te krijgen). Ze haasten zich om het certificaat te vernieuwen.

Uren 8-12: certificaat vernieuwd en uitgerold#

Certificaat is vernieuwd. Maar het uitrollen naar alle load balancers, CDN-edge-nodes en API's kost tijd. Verschillende regio's worden op verschillende momenten gedekt.

Uren 12-24: reputatieschade#

Zelfs nadat het certificaat is vernieuwd, herinneren klanten zich de schrik. Vertrouwen is geschaad. Sociale media-posts verschijnen: "Is [SaaS] te vertrouwen? Ze lieten hun SSL-certificaat verlopen."

Waarom certificaatverloop in SaaS-omgevingen gebeurt#

Reden 1: handmatige vernieuwingsprocessen#

Certificaten moeten elke 1-2 jaar handmatig worden vernieuwd. Iemand moet het onthouden. Diegene wordt gepromoveerd, neemt ontslag of is op vakantie als de tijd voor vernieuwing aanbreekt.

Reden 2: auto-renewal-failures#

Automatische vernieuwing van Let's Encrypt faalt stilletjes als:

DNS-validatie het validatie-endpoint niet kan bereiken
Firewall renewal-verkeer blokkeert
Server-storage vol is
Permissies van de certificate store fout zijn

De renewal faalt, niemand wordt geïnformeerd, het certificaat verloopt.

Reden 3: multi-cloud-complexiteit#

Je beheert certificaten over AWS (Certificate Manager auto-renewt), Cloudflare (aparte renewal) en Let's Encrypt (weer een ander systeem). Ze vernieuwen op verschillende momenten. Je hebt geen één plek om verloop te volgen.

Reden 4: vergeten subdomeinen#

Je monitort app.jouwdomein.nl en api.jouwdomein.nl. Maar webhooks.jouwdomein.nl is een nieuw subdomein dat vorig kwartaal is aangemaakt. Het heeft een eigen certificaat dat je vergeten bent. Het verloopt.

Reden 5: faalmodi van wildcard-renewal#

Renewal van een wildcardcertificaat vereist DNS-validatie. Als DNS-validatie faalt (verkeerd geconfigureerd DNS-record, firewall die validatie blokkeert), faalt de renewal stilletjes.

De SaaS-certificaat-levenscyclus: best practices#

1. Inventariseer alle certificaten

Maak een masterlijst van elk certificaat dat je beheert:

Domein                          Provider        Expiry          Auto-Renew?
jouwdomein.nl                   AWS ACM         2027-03-15      Ja
app.jouwdomein.nl               AWS ACM         2027-03-15      Ja
api.jouwdomein.nl               AWS ACM         2027-03-15      Ja
*.eu.jouwdomein.nl              Cloudflare      2026-08-20      Ja
cdn.jouwdomein.nl               Let's Encrypt   2026-04-10      Ja
webhooks.jouwdomein.nl          Let's Encrypt   2026-06-05      Ja
old-api.jouwdomein.nl           GoDaddy         2025-09-01      Nee (*)

(*) Oud API-endpoint nog actief maar gepland voor decommissioning over 3 maanden. Certificaat staat niet op auto-renew omdat het EOL is.

2. Centraliseer expiry-monitoring

Vertrouw niet op de e-mail-alerts van elke afzonderlijke provider. Maak een verenigd monitoring-dashboard:

# Check certificaatverloop
openssl s_client -connect jouwdomein.nl:443 -servername jouwdomein.nl | \
  openssl x509 -noout -dates

Of gebruik certificate-monitoring-tools die alle domeinen dagelijks checken.

3. Stel meerlaagse alerts in

Alert op verschillende intervallen:

90 dagen voor expiry: planning-alert (lage prioriteit)
30 dagen voor expiry: actie vereist (medium prioriteit)
14 dagen voor expiry: dringend (hoge prioriteit, wijs eigenaar toe)
7 dagen voor expiry: kritiek (maak iemand wakker)
1 dag voor expiry: noodgeval (als nog niet vernieuwd)

4. Test het renewal-proces per kwartaal

Wacht niet tot de expiry-dag om je renewal-proces te testen. Elk kwartaal:

1. Vernieuw een test-certificaat handmatig
2. Deploy het naar een testomgeving
3. Verifieer dat HTTPS correct werkt
4. Verifieer dat de certificate chain volledig is
5. Documenteer eventueel gevonden problemen
6. Update runbooks indien nodig

5. Implementeer geautomatiseerde renewals

Gebruik diensten met auto-renewal:

AWS Certificate Manager: vernieuwt automatisch 60 dagen voor expiry
Cloudflare: vernieuwt certificaten automatisch
Let's Encrypt: implementeer automatische renewal (certbot met cronjob)
ZeroSSL: auto-renewal beschikbaar

6. Monitor of auto-renewal slaagt

Auto-renewal werkt alleen als het ook daadwerkelijk afrondt. Zet monitoring op:

// Monitor of auto-renewal slaagt
Dagelijkse check:
  1. Vraag certificaatdetails op
  2. Vergelijk renewal_date met current_date
  3. Als renewal_date stale is (30+ dagen niet veranderd), alert
  4. Als certificaat-expiry < 30 dagen is en renewal_date niet is bijgewerkt, alert

Dit vangt stille renewal-failures op voordat ze tot expiry leiden.

Praktijkvoorbeeld: SSL-certificaat-failure case study#

Bedrijf: B2B-SaaS met 500 enterprise-klanten, $5M ARR

Setup: drie subdomeinen:

app.bedrijf.com (hoofd-SaaS)
api.bedrijf.com (publieke API)
webhooks.bedrijf.com (webhook-receiver)

Alle drie certificaten beheerd door AWS Certificate Manager met auto-renewal aan.

Het probleem: het certificaat van api.bedrijf.com verliep op een dinsdagochtend.

Waarom het gebeurde:

AWS ACM probeerde 60 dagen voor expiry auto-renewal
DNS-validatie voor api.bedrijf.com faalde door een recente DNS-migratie
Het validatie-subdomein (_acme-challenge.api.bedrijf.com) bestond niet meer na de migratie
AWS faalde stilletjes zonder te alerten
60 dagen later verliep het certificaat

De impact:

Alle API-calls vanuit klant-applicaties begonnen "certificate validation failed" terug te geven
Klant-integraties braken
Klanten konden geen data meer syncen met de SaaS
Support werd overspoeld met "API is down"-klachten
Omzet stond effectief op pauze (klanten konden de service niet gebruiken)

De ontdekking: customer-support-team ontdekte het 4 uur later toen ze "API outage"-klachten onderzochten.

De fix:

Certificaat handmatig vernieuwd
DNS-validatierecords gerepareerd
Monitoring toegevoegd voor alle drie de certificaten
Auto-renewal-proces per kwartaal getest

De les: "We dachten dat AWS auto-renewal kogelvrij was. Het renewde perfect — totdat DNS veranderde. We hadden monitoring nodig die daadwerkelijk valideert of renewal is afgerond, niet die ervan uitgaat dat het werkte."

Checklist voor certificaatmonitoring#

Pre-deployment#

☐ Alle domeinen en subdomeinen vermeld in certificaat-inventaris
☐ Certificaat-provider gekozen en geconfigureerd
☐ Auto-renewal getest en werkend bevonden
☐ Monitoring van renewal-succes geïmplementeerd
☐ Alert-ontvangers geconfigureerd (engineering + ops)
☐ Certificate chain gevalideerd (cert + intermediate + root)
☐ HTTPS werkt voor alle domeinen (geen mixed-content-waarschuwingen)

Tijdens werking#

☐ Dagelijks: monitoring van auto-renewal (verifieer dat renewals afronden)
☐ Wekelijks: certificaat-inventaris beoordeeld (nieuwe subdomeinen toegevoegd)
☐ Maandelijks: SSL Labs-test-score gecheckt (A+-rating behouden)
☐ Kwartaal: renewal-proces handmatig getest (problemen vroeg vangen)
☐ Jaarlijks: audit van certificaat-provider (nog steeds beste optie?)

Noodprotocol#

Als certificaat verloopt:
  1. Page on-call-engineer onmiddellijk
  2. Vernieuw certificaat vanuit provider-dashboard
  3. Deploy naar productie-omgeving
  4. Verifieer dat HTTPS werkt met curl/browser
  5. Check SSL Labs-score (moet A+ zijn)
  6. Informeer klanten (transparantie)
  7. Post-mortem: waarom miste de monitoring dit?

SaaS-specifieke overwegingen voor SSL-certificaten#

1. Regionale certificaten vs. wildcard

Wildcard (*.jouwdomein.nl):

Voordelen: één certificaat dekt alle subdomeinen
Nadelen: renewal-failure betekent dat alle subdomeinen onbetrouwbaar zijn

Regionale certificaten:

Voordelen: failure beperkt tot één regio
Nadelen: meer complexiteit, meer certificaten om te beheren

Aanbeveling: gebruik wildcard voor de meeste deployments, regionale certificaten alleen voor kritieke geografische scheiding.

2. Subject Alternative Names (SANs)

In plaats van één certificaat per domein, gebruik SANs om meerdere domeinen in één certificaat te dekken:

Certificate Subject: jouwdomein.nl
Subject Alt Names:
  - app.jouwdomein.nl
  - api.jouwdomein.nl
  - webhooks.jouwdomein.nl
  - eu.jouwdomein.nl

Eén certificaat dekt meerdere subdomeinen, eenvoudiger te beheren.

3. Certificate pinning (geavanceerd)

High-security-SaaS-bedrijven kunnen certificate pinning implementeren:

Mobiele app is voorgeconfigureerd met verwacht certificaat.
Als de server een ander certificaat retourneert, faalt de verbinding.
Voorkomt man-in-the-middle-aanvallen.

Maar pinning vereist zorgvuldige key-rotatie — gepinde certificaten kunnen niet worden geroteerd zonder app-update.

4. Custom-domain-ondersteuning

Als je SaaS klanten toestaat custom domains te gebruiken (bijv. dashboard.klant.com), heb je nodig:

Mechanisme voor klanten om CNAME-records toe te voegen
Geautomatiseerde certificaatcreatie (Let's Encrypt ACME-DNS-validatie)
Geautomatiseerde certificaat-renewal
Certificaatmonitoring voor alle klant-domeinen

Dit voegt aanzienlijke operationele complexiteit toe. Plan zorgvuldig.

Certificaatmonitoring automatiseren#

Optie 1: certificaat-monitoring-tools#

Diensten zoals:

SSL Labs: gratis SSL Labs-API checkt certificate-grade
crt.sh: certificate-transparency-logs (gratis monitoring)
Certly: gespecialiseerde certificaatmonitoring
Nova Uptime: geïntegreerde SSL-monitoring (inbegrepen bij uptime-monitoring)

Optie 2: DIY-monitoring#

#!/bin/bash
# Check certificaatverloop voor kritieke domeinen

DOMAINS=("jouwdomein.nl" "app.jouwdomein.nl" "api.jouwdomein.nl")
ALERT_DAYS=30

for domain in "${DOMAINS[@]}"; do
  expiry=$(openssl s_client -connect $domain:443 \
    -servername $domain 2>/dev/null | \
    openssl x509 -noout -dates | \
    grep "notAfter" | cut -d= -f2)

  expiry_epoch=$(date -d "$expiry" +%s)
  current_epoch=$(date +%s)
  days_remaining=$(( ($expiry_epoch - $current_epoch) / 86400 ))

  if [ $days_remaining -lt $ALERT_DAYS ]; then
    echo "ALERT: $domain verloopt over $days_remaining dagen"
    # Stuur naar monitoring-systeem
  fi
done

Run dit script dagelijks via cron en stuur resultaten naar je monitoring-dashboard.

SSL-certificaatmonitoring van Nova Uptime#

Nova Uptime combineert SSL-certificaatmonitoring met uptime-monitoring:

Automatische certificaatdetectie: detecteert alle SSL-certificaten op je domeinen
Expiry-alerts: waarschuwt 30, 14, 7 en 1 dagen voor expiry
Chain-validatie: verifieert volledige certificate chain (cert + intermediates + root)
Grade-tracking: monitoring van SSL Labs A+-rating
Historische monitoring: 90-daagse historie van certificaatstatus

Met Nova Uptime krijg je automatische SSL-monitoring geïntegreerd met je uptime-checks — geen aparte tool nodig.

Samenvatting: bescherm je SaaS met SSL-certificaatmonitoring#

SSL-certificaatverloop is stil, maar de impact is catastrofaal. Eén verlopen certificaat kan in uren klantvertrouwen en omzet beschadigen.

Je actieplan:

Inventariseer alle certificaten: lijst elk domein en certificaat dat je beheert
Schakel auto-renewal in: configureer Let's Encrypt, AWS ACM of provider auto-renewal
Verifieer dat renewal slaagt: ga niet uit van auto-renewal — monitor het
Stel meerlaagse alerts in: alert 90/30/14/7/1 dagen voor expiry
Test per kwartaal: test renewal-proces handmatig elk kwartaal
Centraliseer monitoring: gebruik tools zoals Nova Uptime om alle certificaten op één plek te monitoren

Je SSL-certificaten zijn de basis van klantvertrouwen. Laat ze niet stilletjes verlopen. Gebruik de free tier van Nova Uptime om SSL-verloop over al je domeinen te monitoren, geïntegreerd met uptime-monitoring voor compleet zicht op je infrastructuur.

Eén te laat vernieuwd certificaat = klantvertrouwen voor altijd vernietigd.