Hoe u controleert wanneer een SSL-certificaat verloopt

De snelle manier: het hangslot en een online controle

Klik in elke browser op het hangslot in de adresbalk, open de certificaatdetails, en lees "geldig vanaf" en "geldig tot". Dat kost tien seconden en vertelt u wat uw eigen browser ziet. De beperking is dat het alleen het certificaat dekt dat aan u is aangeboden, vanaf het edge-knooppunt of de server die u toevallig bereikte, op het moment dat u keek.

Een online SSL-controle voert dezelfde handshake uit van buiten uw netwerk en rapporteert de vervaldatum, de uitgever, de namen die het certificaat dekt, en of de aangeboden keten compleet is. Browsers verbergen dat laatste punt, dus vertelt de externe controle u iets wat het hangslot niet kan.

De handmatige manier met openssl

Eén commando print het geldigheidsvenster:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -subject -issuer

De vlag -servername stuurt SNI, wat ertoe doet omdat de meeste servers meerdere certificaten op één adres hosten en u zonder die vlag het verkeerde certificaat geven. De uitvoer geeft notBefore en notAfter in UTC, plus voor wie het certificaat is en wie het heeft uitgegeven.

Om de hele keten te zien die de server stuurt, in plaats van alleen het eindcertificaat:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Lees het blok "Certificate chain" bovenaan: u zou het eindcertificaat moeten zien, gevolgd door één of meer tussenliggende certificaten. Een regel "verify error: unable to get local issuer certificate" betekent dat de server het tussenliggende certificaat niet meestuurt, wat veel browsers gladstrijken en veel API-clients, mobiele apps en oudere systemen niet.

Eindcertificaat, keten en wat er verloopt

Bij een normale HTTPS-verbinding zijn drie certificaten betrokken, elk met een eigen vervaldatum:

• Het eindcertificaat is het certificaat dat voor uw domein is uitgegeven. Het is het kortlevende, doorgaans 90 dagen bij geautomatiseerde uitgifte en tot ongeveer een jaar bij een gekocht certificaat, en het is wat mensen bedoelen met "het certificaat".
• Het tussenliggende certificaat ondertekent het eindcertificaat en moet door de server ernaast worden meegestuurd. Het gaat jaren mee, en juist omdat het zo zelden verandert, overvalt het verlopen ervan teams onverwacht.
• Het rootcertificaat leeft in de trust store van de client, niet op uw server. Verloopt een root of wordt hij niet meer vertrouwd, dan beginnen oudere apparaten die de update nooit ontvingen te falen, terwijl actuele apparaten prima werken, wat een storing oplevert die vanaf uw eigen laptop onmogelijk lijkt.

Valideer dus de keten, niet alleen de datum op het eindcertificaat. Een eindcertificaat met nog twee maanden op een kapotte keten faalt voor sommige clients al.

Waarom verloop de meest te voorkomen storing is

Certificaatverloop is een ongewoon schadelijke storing. Hij faalt volledig in plaats van geleidelijk, want een browser weigert de verbinding botweg en toont een volledige waarschuwingspagina in plaats van de site. Het moment waarop het gebeurt, stond al vast op de dag dat het certificaat werd uitgegeven, en niemand hield die datum in de gaten. Bovendien valt alles wat de naam gebruikt tegelijk uit, niet alleen de website: API's, backends van mobiele apps, webhooks en integraties. Mislukte betalingscallbacks en kapotte integraties kosten vaak meer dan de zichtbare downtime.

Het is ook volledig te voorkomen, wat precies is waarom deze storing het meest de moeite waard is om een controle voor te automatiseren.

Hoe automatische vernieuwing toch faalt

Geautomatiseerde uitgifte heeft de meeste verlopen certificaten weggenomen en een reeks storingen geïntroduceerd die lastiger te zien zijn:

• De vernieuwing liep, maar niets herlaadde. Een nieuw certificaat staat op schijf terwijl de webserver het oude uit het geheugen blijft serveren totdat hij wordt herladen.
• De validatiechallenge brak. Een redirectregel, een firewallwijziging of een nieuwe CDN voor de oorsprong blokkeert het HTTP-challengepad, waardoor vernieuwing wekenlang blijft falen zonder zichtbaar symptoom.
• DNS-validatie verloor zijn credentials. Een API-token is geroteerd of verlopen en de DNS-challenge kan zijn record niet meer aanmaken.
• De vernieuwingstimer draait niet. Een container is herbouwd zonder de cronjob of systemd-timer, of de machine is gemigreerd en het schema is niet meeverhuisd.
• Slechts één node vernieuwde. Achter een load balancer heeft de ene server het nieuwe certificaat en serveert de andere nog het oude, waardoor storingen intermitterend lijken.
• Vernieuwingsmails gingen naar iemand die vertrokken is. De variant van hetzelfde probleem voor een gekocht certificaat.
• Het certificaat vernieuwde, maar niet voor elke naam. Een later toegevoegd subdomein ontbreekt op het nieuwe certificaat, waardoor die ene hostnaam faalt.

Elk van deze is onzichtbaar van binnen het vernieuwingssysteem en overduidelijk van buitenaf. Dat is het argument om de live handshake te controleren in plaats van te vertrouwen op de eigen logs van de automatisering.

De controle automatiseren

Een datum aflezen geeft u het antwoord van vandaag, en het hele probleem met verloop is dat het aanbreekt op een dag die niemand koos om te controleren. Geplande certificaatmonitoring voert de echte handshake van buitenaf uit volgens een interval, waarschuwt een ingesteld aantal dagen voor notAfter, en betrapt de keten- en hostnaamproblemen die een agendaherinnering nooit zou zien. HostTracker waarschuwt via e-mail, sms, spraakoproep, Slack, Telegram en meer, zodat de waarschuwing iemand bereikt voordat het verloop dat doet. Domein- en TLS-monitoring voert de controle continu uit, de SSL-controletool doet een eenmalige controle, en hoe u controleert of een poort open is behandelt een handshake die al faalt voordat een certificaat zelfs wordt aangeboden.