SSL/TLS
SSL/TLS-certificaatmonitoring
Het SSL/TLS-certificaat dat een host aanbiedt, en hoeveel dagen het nog geldig is voordat het verloopt.
Probeer het nu
Eén check, vanaf één plek, direct, en niets wordt opgeslagen. Een monitor checkt vanaf elke locatie waar we draaien en bevestigt een fout vanaf twee andere continenten voordat iemand wordt gewekt, wat één blik je niet kan laten zien.
Waar het voor is
Certificaatverloop is de storing die iedereen heeft gehad en niemand plant. Vernieuwing is geautomatiseerd tot de dag dat de automatisering stilletjes faalt, en het eerste teken is dat elke browser ter wereld je site ineens weigert met NET::ERR_CERT_DATE_INVALID.
Dit opent een TLS-verbinding op poort 443, of waar je maar aangeeft, en leest het X.509-certificaat dat de host echt aanbiedt. Dat is niet altijd degene die je vernieuwingsjob heeft geschreven: een load balancer met één verouderde node, een tweede virtuele host die niemand heeft herladen, een CDN die de oude keten vasthoudt. Het rapporteert het subject, de uitgevende certificaatautoriteit en de notAfter-datum, dus een aftelling in plaats van een up of down.
Wildcard- en SAN-certificaten zijn één certificaat, dus houd de host in de gaten waar elk daadwerkelijk van wordt aangeboden. Een certificaat dat *.example.com dekt op drie load balancers is drie monitors, omdat wat misgaat is dat één van de drie niet wordt herladen.
Zoals elke check hier draait het vanaf Amsterdam, New York, Sydney and Singapore, en een fout wordt bevestigd vanaf twee andere continenten voordat iemand wordt gewekt. Hoe dat werkt.
Wat je kunt instellen
Alles hieronder staat op het formulier wanneer je er een toevoegt, bij elk abonnement.
- Host
- Een hostname, een host en poort, of een URL: example.com, example.com:8443 en https://example.com werken allemaal. Poort 443 tenzij je er een opgeeft.
Je krijgt drie waarschuwingen: op veertien dagen, zeven dagen en twee dagen, elk één keer verstuurd. Dagelijkse herinneringen worden genegeerd, dus dit herhaalt niet. Dertig dagen wordt expres overgeslagen: dat is wanneer Let's Encrypt vernieuwt, dus het zou afgaan op elk gezond certificaat. Als het certificaat verlopen is, of we kunnen het helemaal niet lezen (verbinding geweigerd, handshake mislukt, niets antwoordt), dan is dat een alert, geen waarschuwing, en die gaat af zodra we het zien.
Vragen
Wat is het verschil tussen een SSL-certificaat en een TLS-certificaat?
Niets, voor dit doel. SSL is de oude naam voor het protocol, TLS is de huidige, en SSL 2.0 en 3.0 zijn al meer dan tien jaar dood. Het bestand zelf is hoe dan ook een X.509-certificaat en weet niet welk protocol het zal presenteren. De meeste mensen zoeken nog steeds op SSL, dus we schrijven SSL/TLS en bedoelen hetzelfde als jij.
Waarom zegt mijn browser NET::ERR_CERT_DATE_INVALID?
Het certificaat dat de browser kreeg is verlopen, of de notBefore-datum is nog niet bereikt, wat gebeurt als de klok van de server verkeerd staat. Chrome toont deze code, Firefox zegt SEC_ERROR_EXPIRED_CERTIFICATE en Safari zegt dat het certificaat niet geldig is. Deze monitor vertelt het je twee dagen voordat je bezoekers dat doen.
Controleert dit de certificaatketen?
Deze check leest de vervaldatum, dus een incomplete chain of een ontbrekend intermediate certificate laat hem niet falen. Een HTTPS-monitor checkt wel de chain: hij maakt verbinding zoals een browser dat doet en faalt bij een ongeldige chain, een self-signed certificaat of een hostname mismatch. Gebruik beide voor alles wat belangrijk is, daarom zit HTTPS in elk abonnement.
Hoe zit het met wildcard- en SAN-certificaten?
Beide werken. Een wildcard-certificaat, of een met meerdere subject alternative names, is één certificaat met één vervaldatum. Wat verschilt is welke host het serveert, dus voeg één monitor per host toe in plaats van één per naam op het certificaat.
Check je OCSP of certificate transparency?
Nee, en dat zeggen we ook in plaats van iets anders te impliceren. Dit leest het certificaat dat een host serveert en meldt de resterende dagen. Revocation checking en CT log monitoring zijn andere producten die andere problemen oplossen, en een monitor die ze half doet zou slechter zijn dan een die ze niet doet.
Mijn verlenging is geautomatiseerd. Heb ik dit dan nog nodig?
Dat is precies voor wie dit is. Niemand met een handmatige verlenging vergeet het negentig dagen lang; de storingen komen door een Let's Encrypt-verlenging die zes weken geleden stilletjes faalde, of slaagde op de machine die het certificaat schrijft en niet op degene die het serveert.
Wat als de host helemaal niet antwoordt?
Een TLS-handshake failure, een geweigerde verbinding of een timeout wordt gemeld als een failure van de check in plaats van als een expiry warning, omdat dat verschillende problemen zijn met verschillende oplossingen. De expiry countdown beweegt alleen als we daadwerkelijk een certificaat lezen.
Waarom zet je de verlengingsdatum niet gewoon in een agenda?
Een herinnering kost niets en is beter dan niets, dus zet er ook een in. Het probleem is dat de datum in je agenda een datum is die iemand heeft getypt, en het certificaat op de server is wat er daadwerkelijk staat. Ze komen overeen totdat een verlenging half slaagt, een deploy een oude bundle levert, één host in een pool het nieuwe bestand mist, of het certificaat dat verlengd is niet het certificaat is dat geserveerd wordt. Dit leest het certificaat zoals een bezoeker het krijgt, dus de datum waarover het waarschuwt is de echte.