SSL-certificaatmonitoring: vervalwaarschuwingen voor certificaten en domeinen

Een verlopen SSL-certificaat is niet de enige deadline die een site offline kan halen - HostTracker's domeinvervaldatum checker bewaakt je registratiestatus naast je certificaten, zonder extra kosten.

Een SSL-certificaat vervalmonitor wordt vaak verkocht als een agendaherinnering, en verval is inderdaad de meest voorkomende manier waarop certificaten kapotgaan. Het is niet de enige manier. Elke run van HostTracker opent een echte TLS-verbinding en beoordeelt het certificaat dat de server daadwerkelijk aanbiedt - waardoor ook storingen worden opgemerkt die optreden zonder dat er ook maar één datum verandert.

Onder de motorkap is een certificaatmonitor een TLS-verbinding naar een host en een poort. De poort staat standaard op 443, en je kunt een andere opgeven - example.com:8443 - zodat een API-gateway, een alternatieve HTTPS-poort of een dienst op een impliciete TLS-poort op precies dezelfde manier wordt bewaakt. De hostnaam wordt via SNI verstuurd, zodat een server die meerdere certificaten op één IP-adres host het juiste certificaat teruggeeft.

Wanneer een server uitvalt, ziet een bezoeker een browserfout en probeert het meestal later opnieuw. Wanneer een certificaat verloopt, is de server nog volkomen gezond - hij beantwoordt elk verzoek - maar de browser weigert te tonen wat hij heeft ontvangen. Dat verschil is op vier manieren belangrijk, die je makkelijk onderschat totdat het gebeurt.

• De waarschuwing is bedoeld om afschrikwekkend te zijn. Een schermvullende waarschuwing over een onveilige verbinding is hetzelfde scherm dat een browser toont bij een onderscheppingsaanval. Bezoekers lezen het niet als "hun certificaat is verlopen"; ze lezen het als "deze site is niet veilig".
• Op een site met HSTS is er geen manier omheen. Als je ooit een Strict-Transport-Security-header hebt verstuurd - en dat zou je moeten hebben gedaan - verwijderen browsers de optie "toch doorgaan" volledig. Elke bezoeker wordt hard geblokkeerd totdat het certificaat is vervangen.
• Machines falen harder dan mensen. Je mobiele app, je betalingswebhooks, de integraties van je partners en elke API-client valideren het certificaat ook, en geen van hen heeft een knop om er voorbij te klikken. Een verval is een volledige integratiestoring, niet alleen een websitestoring.
• Je eigen monitoring kan groen blijven ogen. Een check die is ingesteld om certificaatproblemen te negeren, rapporteert nog steeds HTTP 200 vanaf een server waarvan het certificaat een uur geleden is verlopen. De applicatie heeft er niets van gemerkt. Precies dat gat is de reden dat een certificaatmonitor bestaat.

Dezelfde asymmetrie geldt voor een verlopen domein, alleen langzamer en minder omkeerbaar: een certificaat kan binnen enkele minuten opnieuw worden uitgegeven, terwijl een domein dat de redemption-periode verlaat door iedereen geregistreerd kan worden.

Certificaatbewaking is er in twee vormen, en de meeste accounts willen de eerste.

Een certificaat verandert niet van de ene op de andere minuut, dus geen van beide vormen controleert vaker dan nuttig is. Zes uur betekent dat in het slechtste geval een paar uur verstrijkt tussen het kapotgaan van een certificaat en het moment dat HostTracker het opmerkt - op iets dat je normaal gesproken 30 dagen van tevoren waarschuwt.

HostTracker stuurt herinneringen op 30 dagen, 7 dagen en 1 dag voor een vervaldatum - zowel voor SSL/TLS-certificaten als voor domeinregistraties. Drie stappen in plaats van één, omdat elke stap een ander soort misser opvangt: 30 dagen is genoeg tijd om een inkooporder te regelen of een kapotte verlengingsjob te repareren, 7 dagen vangt het ticket op dat niemand heeft opgepakt, en 1 dag is de laatste kans voordat browsers je bezoekers gaan waarschuwen.

Een herinnering is geen storingsmelding, en HostTracker houdt de twee gescheiden. Als het certificaat op dit moment daadwerkelijk ongeldig is - verlopen, ingetrokken, gekoppeld aan een niet-vertrouwde root, of uitgegeven voor een andere hostname - dan is dat een mislukte check, en die escaleert direct via je normale down-alert-contacten, op de vertraging die elk van hen heeft gekozen: direct, of na 3, 5, 15, 30 of 60 minuten, of na 3, 6, 12 of 24 uur.

Meldingen worden verstuurd via de negen kanalen die HostTracker ondersteunt - e-mail, sms, spraakoproep, webhook, Slack, webpush en de berichten-apps Telegram, Discord en Viber. Certificaatverlengingen en domeinverlengingen zijn meestal de verantwoordelijkheid van verschillende mensen, dus zet ze allebei op de contactenlijst: de herinnering die alleen de inbox bereikt van wie de monitor heeft ingesteld, is de herinnering die wordt gemist.

De ladder hierboven is precies wat een SSL-certificaat vervaldatum-tracker in de praktijk is. Elke zes uur leest HostTracker het certificaat opnieuw dat je server werkelijk heeft geserveerd en berekent het aantal resterende dagen opnieuw; aan drie van die getallen hangt een herinnering.

De drie treden liggen vast op 30, 7 en 1 dag, en dezelfde ladder geldt voor domeinregistraties net zo goed als voor certificaten. Een herinnering is informatief en zet een monitor nooit op zichzelf op Down; een certificaat dat werkelijk ongeldig is - verlopen, ingetrokken, uitgegeven voor een andere hostnaam of geketend aan een niet-vertrouwde root - is een mislukte controle en escaleert als elke andere storing.

Nog geen monitoring? De gratis directe SSL-controle leest hetzelfde certificaat en rapporteert dezelfde vervaldatum, uitgever, keten en onderhandelde TLS-versie - één keer, nu meteen, zonder account. De vervaldatum-tracker is diezelfde controle in een lus van zes uur, met de drie herinneringen eraan vast.

De certificaatmonitor hierboven beantwoordt de vraag "is dit certificaat geldig". Een aparte set schakelaars op een HTTPS-beschikbaarheidsmonitor beantwoordt een lastigere vraag - "voldoet deze verbinding aan onze norm" - en elke schakelaar is opt-in, omdat ze standaard voor iedereen aanzetten een groot aantal sites zou laten falen die precies werken zoals hun eigenaren bedoelden.

• Vereis een geldige certificaatketen. Standaard uit, zodat een zelfondertekend certificaat op een interne host de uptime-check niet laat falen. Schakel dit in voor alles wat publiek toegankelijk is.
• Vereis een sterk TLS-protocol. Laat de check falen wanneer de server iets onder TLS 1.2 afspreekt - de handige schakelaar na een hardeningsproject, zodat een teruggedraaide configuratie niet stilletjes een verouderd protocol terugbrengt.
• Blokkeer zwakke ciphers. Laat de check falen wanneer de afgesproken cipher zwakker is dan 128-bit.
• Controleer certificaatintrekking. Voegt een OCSP/CRL-opzoeking toe aan de beschikbaarheidscheck zelf.

Een losstaande certificaatvervalmonitor past ketenvalidatie en intrekkingscontrole al standaard toe, zonder een van deze schakelaars - ze bestaan zodat je uptime-check net zo streng gemaakt kan worden als je beveiligingsbeleid vereist, onafhankelijk van wat de certificaatmonitor rapporteert.

Automatische verlenging zou een einde moeten maken aan vervalincidenten, en dat is grotendeels ook gelukt. Wat er is veranderd, is de vorm van de overgebleven incidenten: in plaats van een mens die een datum vergeet, stopt een stukje automatisering met werken zonder dat iemand het merkt, omdat werkende automatisering stil is en kapotte automatisering op precies dezelfde manier stil is. Certificaatlevensduren worden in de hele branche steeds korter - de veelgebruikte gratis autoriteiten geven certificaten uit met een looptijd van 90 dagen, en de maximale levensduur die browsers accepteren wordt stapsgewijs verkort - waardoor verlenging nu vele keren per jaar plaatsvindt, en elke van die verlengingen degene kan zijn die mislukt.

De storingen die we gerapporteerd zien, zien er zo uit:

• De cronjob voor verlenging is maanden geleden al gestopt. Het certificaat dat als laatste werd verlengd, was 90 dagen geldig, dus de storing werd pas op dag 91 zichtbaar.
• De verlenging is geslaagd, maar er is niets herladen. Het nieuwe certificaat staat op schijf terwijl de webserver, de load balancer of de container het oude certificaat vanuit het geheugen blijft serveren. Elk verlengingslog meldt succes.
• Eén node van meerdere werd overgeslagen. Achter een load balancer krijgt het merendeel van de verzoeken het nieuwe certificaat en een deel het verlopen certificaat - daarom is een sporadische certificaatfout van het type "werkt bij mij wel" bijna altijd een consistentieprobleem in de vloot.
• De edge is in orde, de origin niet. Je CDN toont zijn eigen geldige certificaat, terwijl het certificaat van de origin daaronder is verlopen. Alles wat rechtstreeks met de origin communiceert, gaat kapot.
• De validatiemethode is gestopt met werken. Een DNS-record is opgeruimd, een /.well-known/-pad begon door te verwijzen, een firewallregel is gewijzigd - en de verlenging die daarvan afhangt, is stilletjes gestopt met slagen.
• Het wildcardcertificaat dekte het nieuwe subdomein niet. Een wildcardcertificaat dekt één niveau, dus een host die onder een dieper label is toegevoegd, valt er helemaal niet onder.

Elk van deze problemen is onzichtbaar vanuit je eigen deploymentpijplijn en overduidelijk van buitenaf, en dat is precies het argument voor een externe bewaker. Een monitor die verbinding maakt zoals de browser van een vreemde dat doet, ziet het certificaat dat je daadwerkelijk serveert - niet het certificaat waarvan je automatisering denkt dat het is geïnstalleerd.

Aan de domeinkant wordt het register bevraagd, niet de server. HostTracker zoekt het domein op via RDAP - de moderne, gestructureerde opvolger van WHOIS - waarbij wordt bepaald welk register verantwoordelijk is voor jouw TLD aan de hand van de door IANA gepubliceerde directory, en valt terug op een klassieke WHOIS-query op poort 43 voor TLD's die nog geen RDAP-service publiceren. De opzoeking draait op een vaste cadans van zes uur, en de check rapporteert:

• de vervaldatum die het register aanhoudt - de gezaghebbende datum, niet die uit je factureringssysteem;
• de registry-statuscodes op het domein, waar RDAP deze levert - inclusief of er een transferlock actief is;
• een aparte melding "vervaldatum gewijzigd" wanneer de datum van het register afwijkt van de vorige check - hiermee bevestig je dat een verlenging daadwerkelijk is doorgevoerd, en kom je erachter over een verlenging die je niet hebt geautoriseerd.

Dat laatste is stilletjes het nuttigste signaal op deze pagina. Een verlenging waarvoor je hebt betaald maar die nooit bij het register is aangekomen, ziet er identiek uit als een gezond domein, tot het moment dat de 30-dagenherinnering afgaat. Door de datum zelf te volgen, verandert een verlenging van iets waarvan je hoopt dat het is gebeurd in iets wat je kunt zien.

Wil je het volledige registerrecord - registrar, nameservers, aanmaakdatum - nu meteen zien in plaats van als monitor? Voer de gratis WHOIS- en domeinvervalopzoeking uit; geen login vereist. De terugkerende monitor rapporteert bewust minder, omdat verval en status de dingen zijn die veranderen.

1. Zoek het domein eerst op met de gratis directe check, zodat je weet wat de huidige vervaldatums zijn voordat je iets automatiseert.
2. Als je de uptime van de site al bewaakt, open dan die monitor en schakel certificaatbewaking en domeinvervalbewaking in. Geen nieuwe monitor, geen extra verzoek.
3. Voeg voor alles waarvan je de uptime niet bewaakt - een mailhost, een interne gateway, een alternatieve poort - een losstaande Certificaatverval-monitor toe en geef deze host:poort mee. Poort 443 wordt aangenomen als je de poort weglaat.
4. Voeg een Domeinverval-monitor toe voor elk registreerbaar domein dat je bezit, inclusief de defensieve registraties en de doorverwijzingsdomeinen. Dat zijn precies de domeinen die verlopen, omdat niemand een domein bewaakt waar geen site op staat.
5. Zet meer dan één persoon op de contactenlijst. Certificaten en domeinen zijn meestal de verantwoordelijkheid van verschillende teams, en de herinnering die alleen degene bereikt die de monitor heeft ingesteld, is de herinnering die ongelezen blijft zodra die persoon van baan verandert.
6. Houd de herinneringsladder in gedachten - 30, 7 en 1 dag - en zorg dat je verlengingsproces binnen 30 dagen past. Als een inkooporder zes weken duurt, is niet de ladder je beperking, maar het proces.

Gratis SSL-checktools - inclusief die van HostTracker zelf - zijn oprecht nuttig en beantwoorden een andere vraag. Een check vertelt je de status van een certificaat op het moment dat je erom vraagt. Monitoring vertelt je wanneer die status verandert terwijl je niet kijkt, en dat is nu juist het enige moment dat ertoe doet.

Certificaten staan naast de andere dingen aan een domein die mis kunnen gaan zonder dat iemand je server aanraakt. Zodra de vervalkant wordt bewaakt, zijn de gebruikelijke volgende twee malware- en phishingmeldingen en DNS-blacklistvermeldingen - allebei stille reputatiestoringen die de site online laten terwijl het verkeer verdwijnt.

• Geen STARTTLS. De check maakt verbinding en start meteen de TLS-handshake, dus het werkt op elke poort die rechtstreeks TLS spreekt. Protocollen die in platte tekst beginnen en halverwege de sessie opwaarderen - SMTP op 587, IMAP op 143, explicit-TLS FTP - vereisen een onderhandeling die de check niet uitvoert. Richt de check in dat geval op de impliciete TLS-poort.
• De herinneringsdagen liggen vast op 30, 7 en 1. Dit is momenteel geen instelling per monitor.
• Een onbereikbare intrekkingsresponder wordt gerapporteerd, niet als storing aangemerkt. Dat is bewust zo - een OCSP-storing bij een certificaatautoriteit is niet jouw storing - maar het betekent wel dat de dekking van intrekkingscontrole afhangt van de beschikbaarheid van een derde partij.
• Certificate Transparency-logs worden niet bewaakt. HostTracker vertelt je iets over het certificaat dat wordt geserveerd; het houdt geen publieke CT-logs in de gaten voor certificaten die door iemand anders voor jouw domein zijn uitgegeven.
• Clientcertificaten worden niet getest. De check valideert het certificaat dat de server aanbiedt, niet een mutual-TLS-handshake.
• Domeindekking volgt de registers. RDAP wordt gebruikt waar de TLD dit publiceert en klassieke WHOIS waar dat niet het geval is; een klein aantal obscure TLD's publiceert geen van beide goed, en de check rapporteert dan een mislukte opzoeking in plaats van te doen alsof er een datum bekend is.