Een verlopen SSL-certificaat maakt van een normale sessie een veiligheidswaarschuwing. Browsers kunnen toegang blokkeren, API-clients kunnen verbindingen weigeren en mobiele apps kunnen een dienst niet meer bereiken. Alleen de einddatum controleren is daarom onvoldoende. Je moet ook de aangevraagde hostnaam, SAN-namen, certificaatketen, adressen en de installatie na vernieuwing controleren. De nuttigste meting is wat een echte client ziet, niet alleen wat een uitgiftesysteem meldt.
Een X.509-certificaat koppelt een publieke sleutel aan namen en geldigheidsdata. De client controleert naam, tijd, handtekening en keten naar een vertrouwde root. Een geldig certificaat helpt niet wanneer api.voorbeeld.nl niet in de SAN staat. Een ontbrekend tussen-certificaat kan in één browser werken en in een nieuwe mobiele app falen. De SSL-certificaatchecker laat de publieke identiteit van één host zien. Voeg daar eigenaar, kritieke werking en vorige metingen aan toe.
Maak een compleet naam-inventaris
Begin bij DNS, klantpaden en applicaties, niet alleen bij de marketingwebsite. Neem root, www, login, API, status, support, betaling, webhooks en internationale varianten op. Controleer IPv4 en IPv6 los, omdat ze naar verschillende systemen kunnen wijzen. Noteer voor elke host eigenaar, dienst, prioriteit, vernieuwing, verwachte uitgever, SAN en laatste externe controle. Ook test- en campagnehosts hebben een eigenaar nodig. Een vergeten naam kan een vervalalarm veroorzaken of een publieke endpoint vormen die niemand meer onderhoudt.
- Volledige hostnaam en werkelijk gebruikte HTTPS-URL.
- Not Before, Not After en resterende dagen.
- SAN-lijst en de echte betekenis van wildcards.
- Geleverde tussen-certificaten en verwachte keten.
- Vernieuwingsjob, rechten en verantwoordelijke.
- IPv4, IPv6, regio’s en endpoints met eigen meetgeschiedenis.
Gebruik duidelijke statussen in plaats van één lampje
Maak onderscheid tussen verlopen, bijna verlopen, naam ontbreekt, keten onvolledig, verbindingsfout en onbekend. Een timeout bewijst niet dat het certificaat ontbreekt en een HTTP-403 bewijst niet dat TLS defect is. Bewaar meettijd, hostnaam, uitgever, fingerprint, SAN en een minimale foutmelding. Een beheerteam kan dan de vorige meting vergelijken zonder privésleutels of persoonsgegevens in tickets te zetten. Onzekerheid leidt tot een begrensde nieuwe controle, niet tot een verzonnen veilig of onveilig resultaat.
Pas waarschuwingsgrenzen aan de kritikaliteit aan. Een betaal- of loginendpoint kan dertig, veertien, zeven en twee dagen nodig hebben; een testhost misschien één herinnering. De termijn moet ruimte geven voor diagnose, vernieuwing en installatie op alle plekken. Elke melding noemt actie, eigenaar en escalatiekanaal. Test ook dat een melding pas gesloten kan worden na een publieke meting. Een groen automatiseringsproces is onvoldoende wanneer een oude load balancer nog de vorige versie aanbiedt.
Automatische vernieuwing extern bewijzen
Automatisering vermindert handwerk maar blijft afhankelijk van HTTP- of DNS-challenges, rechten en installatie op iedere TLS-terminator. Let's Encrypt adviseert tijdige automatische vernieuwing, maar uitgifte is slechts één stap. Test na uitgifte de echte host met SNI, vergelijk geldigheid en SAN en controleer iedere regio, load balancer en IPv6-route. De SSL-verval API kan zulke controles in een lijst of deploymentproces plaatsen. Sluit pas nadat de publieke meting de nieuwe versie toont.
Oefen het proces gecontroleerd. Controleer of een waarschuwing bij de juiste dienst terechtkomt, wie DNS of deployment mag wijzigen en hoe een mislukte installatie zichtbaar wordt. Simuleer een fout zonder productie te raken en documenteer herstel. Maak na DNS-, load-balancer-, IPv6- of TLS-wijzigingen een nieuwe baseline. Zo zie je dat slechts één endpoint is bijgewerkt en voorkomt je dat een oud systeem tot de volgende vervaldatum onopgemerkt blijft.
Keten en echte clients controleren
De SSL-score kan protocol- en configuratiesignalen tonen, maar vervangt geen compatibiliteitstest van jouw applicaties. Inventariseer mobiele clients, integraties en partners. Schakel oude protocollen niet alleen uit omdat een algemene score dat suggereert; controleer eerst wie ze nog nodig heeft en geef uitzonderingen een einddatum. Test handshake, keten, naam en verwachte inhoud na iedere wijziging. Een goede pagina met een verkeerd certificaat blijft fout, net als een goed certificaat op de verkeerde backend.
Voor internationalized domain names bewaar je zichtbare en technische vorm samen. Een ontbrekende SAN kan eruitzien als een vernieuwingsfout, terwijl de werkelijke oorzaak een onvolledig inventaris is. Controleer root, www, API en redirects afzonderlijk. Als een laag door blokkering of timeout onbekend blijft, plan een nieuwe meting. Presenteer een ontbrekende observatie nooit als bewezen storing of bewijs dat de host veilig is.
Certificate Transparency als inventarsignaal
Openbare Certificate Transparency-logboeken maken nieuwe certificaten en onbekende hostnamen zichtbaar. Dat kan een vergeten API, campagneomgeving of onverwachte aanvraag onthullen. Een logboekvermelding bewijst niet dat een dienst actief is of dat er een incident plaatsvindt. Vergelijk naam, uitgever, tijd en goedgekeurde wijziging. De Certificate Transparency API helpt bij het vinden van signalen; de domeineigenaar bepaalt daarna of het een verwachte ontwikkeling of onderzoekspunt is.
Meten na veranderingen en incidenten
Bewaar vóór een migratie een baseline van DNS, TLS, HTTP en certificaatidentiteit. Herhaal exact dezelfde controles na de wijziging per host, adres en regio. Zo vind je een oude node, een nieuwe IPv6-respons of een certificaat dat maar deels is uitgerold. Verbind iedere uitzondering met een wijziging en eigenaar. De Domeingezondheid geeft aanvullende context. Bij een beperkte meting meldt het rapport onbekend met een nieuwe poging, in plaats van een alarmstatus te verzinnen.
Bepaal ook wanneer een certificaat uit het inventaris mag. Een gestopte host kan nog DNS, e-mail, redirects of mobiele koppelingen hebben. Controleer eerst eigendom en afhankelijkheden en leg de verwijdering vast. Bij een nieuwe Nederlandse campagne hoort de eerste TLS-meting bij de releasegoedkeuring. Bij uitfasering leg je reden, datum en eigenaar vast. Zo verdwijnt een endpoint niet uit beeld voordat alle publieke verwijzingen zijn gecontroleerd.
Maak waarschuwingen ook organisatorisch betrouwbaar. Noteer een primaire eigenaar, vervanger en bereikbaar kanaal voor weekenden, feestdagen en leverancierswissels. Beperk rechten voor DNS en deployment en leg vast wie een uitzondering mag goedkeuren. Na herstel koppelt de sluiter de publieke meting aan hostnaam en tijd. Een korte evaluatie vraagt of de drempel te laat was, de host niet in het inventaris stond of een contact onbereikbaar was. Zo wordt monitoring een leerproces in plaats van dezelfde verrassing bij ieder verval.
Bij Nederlandse campagnes controleer je ook URL’s in apps, QR-codes, facturen en redirects. Een certificaat voor een oude campagne mag niet zomaar uit het inventaris verdwijnen zolang DNS, mail of mobiele koppelingen bestaan. Bij uitfasering documenteer je eigenaar, datum en reden. Voor een nieuwe release hoort TLS-controle bij de goedkeuring: controleer SAN, keten, inhoud, IPv4, IPv6 en regio. Als een endpoint door een blokkade onbekend blijft, rapporteer je onbekend en plan je een herhaling, niet een geruststellende status.
Koppel iedere waarschuwing aan de dienst die er financieel of operationeel door wordt geraakt. Een betaalendpoint, klantportaal en zakelijke API verdienen een andere escalatie dan een tijdelijke campagne. Neem weekend, vakantie en leverancierswissel mee in de bereikbaarheidsroute. Beperk DNS- en deployrechten, bewaar geen privésleutels in tickets en laat een tweede persoon de sluiting controleren. Na herstel vergelijk je host, SAN, keten, inhoud en adres opnieuw. Het record vermeldt waarom de correctie voldoende is en wanneer de uitzondering opnieuw wordt bekeken.
Voor Nederlandse gebruikers test je daarnaast links in apps, QR-codes, facturen en regionale campagnes. Controleer Unicode- en technische domeinvormen samen. Bij uitfasering verifieer je eerst redirects, mail, DNS en mobiele koppelingen voordat je de naam uit het inventaris verwijdert. Een onbekende endpoint door blokkade of timeout blijft onbekend met een geplande retry. Zo voorkom je dat een oude node of IPv6-route tot de volgende vervaldatum een ander certificaat blijft aanbieden.
Voor kritieke certificaten maak je bovendien een herstelpad met goedkeuring, beperkte rechten en een tweede controleur. Controleer na een vervanging ook oude nodes, redirects en IPv6, want een gedeeltelijke uitrol kan alleen bepaalde klanten raken. Bewaar oorzaak, herstelactie en publieke meetresultaat. Bij een gestopte campagne controleer je eerst e-mail, DNS en mobiele links voordat je het certificaat uit het inventaris verwijdert. Zo blijft het proces bruikbaar voor Nederlandse teams met regionale websites en tijdelijke acties.
Een sluitingsbewijs vermeldt hostnaam, versie, SAN, keten, tijdstip en waargenomen endpoint. Koppel het aan de change die de vernieuwing veroorzaakte. Als een eindpunt nog onbekend is, blijft de waarschuwing open met een nieuwe controledatum. Bij een Nederlandse campagne controleer je bovendien QR-links, mobiele clients en regionale redirects. Deze extra stap voorkomt dat alleen de homepage wordt gecontroleerd terwijl klanten een ander certificaat op een API of IPv6-adres krijgen.
Een goede sluitingsmeting koppelt hostnaam, versie, SAN, keten, endpoint en tijd aan de change. Als één regio of IPv6-adres nog onbekend is, blijft de waarschuwing open. Controleer bij Nederlandse campagnes ook links in apps, QR-codes en redirects. Bij uitfasering verifieer je mail, DNS en mobiele koppelingen vóór je de naam uit het inventaris verwijdert. Zo voorkom je dat een oude node ongemerkt een andere certificaatversie blijft aanbieden.
Koppel de sluitingscontrole aan de deployment en bewaar hostnaam, SAN, keten, versie en tijdstip. Laat een tweede persoon controleren dat iedere kritieke regio en IPv6-route is gemeten. Een certificaat is pas klaar wanneer de echte client de verwachte versie ontvangt; de uitgifte alleen is geen eindbewijs.
Leg tenslotte vast welke meting nodig is om een waarschuwing te sluiten en wie die meting beoordeelt. Voor een betaal-API zijn naam, keten, IPv6 en regio essentieel; voor een reservenaam volstaat mogelijk een minder frequente controle. Geef uitzonderingen een vervaldatum en plan een herbeoordeling, zodat tijdelijke risico’s niet permanent worden.
- Hosts, eigenaren, SAN’s en prioriteit inventariseren.
- Datum, keten, DNS en TLS extern meten.
- Drempels, kanalen en waarschuwingsverantwoordelijkheid instellen.
- Vernieuwing en installatie op ieder endpoint testen.
- Clients en regio’s na veranderingen vergelijken.
- Onverwachte certificaten onderzoeken en onbekende staten bewaren.
Een certificaat is vernieuwd wanneer de juiste identiteit bij het juiste endpoint aankomt, niet wanneer een taak eindigt.
Principe voor TLS-beheer
SSL-monitoring verbindt beschikbaarheid, identiteit en verantwoordelijkheid. Maak een inventaris, controleer namen en ketens, vernieuw met marge en meet na iedere wijziging van buitenaf. Gebruik de SSL-certificaatchecker voor één host en de SSL-verval API voor herhaalbare controles. Combineer dit met Domeingezondheid, zodat DNS, TLS en bereikbaarheid samen worden beoordeeld.