Jak sprawdzić, kiedy wygasa certyfikat SSL

Szybki sposób: kłódka i sprawdzenie online

W dowolnej przeglądarce kliknij kłódkę na pasku adresu, otwórz szczegóły certyfikatu i odczytaj "ważny od" i "ważny do". Zajmuje to dziesięć sekund i mówi Ci, co widzi Twoja własna przeglądarka. Ograniczeniem jest to, że obejmuje tylko certyfikat serwowany Tobie, z węzła brzegowego lub serwera, do którego akurat trafiłeś, w chwili, gdy sprawdzałeś.

Sprawdzenie SSL online wykonuje ten sam handshake spoza Twojej sieci i zgłasza datę wygaśnięcia, wystawcę, nazwy objęte certyfikatem oraz to, czy przesłany łańcuch jest kompletny. Przeglądarki ukrywają tę ostatnią kwestię, więc zewnętrzne sprawdzenie mówi Ci coś, czego kłódka nie potrafi.

Sposób ręczny z openssl

Jedno polecenie wypisuje okno ważności:

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

Flaga -servername wysyła SNI, co ma znaczenie, bo większość serwerów hostuje kilka certyfikatów pod jednym adresem i bez niej wyśle Ci niewłaściwy. Wynik podaje notBefore i notAfter w UTC, a także dla kogo certyfikat jest przeznaczony i kto go wystawił.

Aby zobaczyć cały łańcuch wysyłany przez serwer, a nie tylko liść:

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

Odczytaj blok "Certificate chain" na górze: powinieneś zobaczyć liść, a potem jeden lub więcej certyfikatów pośrednich. Linia "verify error: unable to get local issuer certificate" oznacza, że serwer nie wysyła certyfikatu pośredniego, co wiele przeglądarek maskuje, a wielu klientów API, aplikacji mobilnych i starszych systemów już nie.

Liść, łańcuch i co wygasa

W normalnym połączeniu HTTPS bierze udział trzy certyfikaty, każdy z własną datą wygaśnięcia:

• Liść to certyfikat wystawiony dla Twojej domeny. Jest krótkotrwały, zwykle 90 dni przy automatycznym wystawianiu i do około roku przy zakupionym, i to o nim ludzie myślą, mówiąc "certyfikat".
• Certyfikat pośredni podpisuje liść i musi być wysyłany przez serwer razem z nim. Trwa lata, i to właśnie dlatego, że zmienia się tak rzadko, jego wygaśnięcie zaskakuje zespoły.
• Root znajduje się w magazynie zaufania klienta, nie na Twoim serwerze. Gdy root wygasa albo traci zaufanie, starsze urządzenia, które nigdy nie otrzymały aktualizacji, zaczynają zawodzić, podczas gdy aktualne działają dobrze, co daje awarię wyglądającą na niemożliwą z poziomu Twojego własnego laptopa.

Waliduj więc łańcuch, nie tylko datę na liściu. Liść z dwoma miesiącami ważności na uszkodzonym łańcuchu już zawodzi dla części klientów.

Dlaczego wygaśnięcie to najczęstsza awaria, której można zapobiec

Wygaśnięcie certyfikatu to wyjątkowo dotkliwa awaria. Zawodzi całkowicie, a nie stopniowo, bo przeglądarka wprost odmawia połączenia i zamiast strony pokazuje ostrzeżenie na całym ekranie. Moment, w którym to nastąpi, był ustalony w dniu wystawienia certyfikatu, a nikt nie pilnował tej daty. Wyłącza też jednocześnie wszystko, co używa tej nazwy, nie tylko stronę internetową: API, backendy aplikacji mobilnych, webhooki i integracje. Nieudane wywołania zwrotne płatności i zerwane integracje często kosztują więcej niż widoczny przestój.

Jest to też w pełni możliwe do uniknięcia, dlatego to awaria, dla której najbardziej opłaca się zautomatyzować sprawdzenie.

Jak automatyczne odnowienie wciąż zawodzi

Automatyczne wystawianie wyeliminowało większość wygaśnięć i wprowadziło zestaw awarii trudniejszych do zauważenia:

• Odnowienie się wykonało, ale nic się nie przeładowało. Nowy certyfikat leży na dysku, podczas gdy serwer WWW nadal serwuje stary z pamięci, dopóki nie zostanie przeładowany.
• Wyzwanie walidacyjne się zepsuło. Reguła przekierowania, zmiana zapory albo nowe CDN przed źródłem blokuje ścieżkę wyzwania HTTP, więc odnowienie zawodzi tygodniami bez żadnego widocznego objawu.
• Walidacja DNS straciła poświadczenia. Token API został zrotowany albo wygasł, i wyzwanie DNS nie może już utworzyć swojego rekordu.
• Timer odnowienia nie działa. Kontener został przebudowany bez zadania cron albo timera systemd, albo maszyna została zmigrowana, a harmonogram nie pojechał razem z nią.
• Odnowił się tylko jeden węzeł. Za load balancerem jeden serwer ma nowy certyfikat, a drugi wciąż serwuje stary, więc awarie wyglądają na sporadyczne.
• E-maile o odnowieniu trafiły do kogoś, kto już odszedł. Ta sama wersja problemu, tylko dla certyfikatu zakupionego.
• Certyfikat się odnowił, ale nie dla każdej nazwy. Subdomena dodana później brakuje w nowym certyfikacie, więc zawodzi tylko ta jedna nazwa hosta.

Każda z tych sytuacji jest niewidoczna od wewnątrz systemu odnawiania i oczywista z zewnątrz. To argument za sprawdzaniem żywego handshake, a nie poleganiem na własnych logach automatyzacji.

Automatyzacja sprawdzenia

Odczytanie daty daje odpowiedź na dziś, a cały problem z wygaśnięciem polega na tym, że przychodzi w dniu, którego nikt nie wybrał do sprawdzenia. Zaplanowane monitorowanie certyfikatów wykonuje prawdziwy handshake z zewnątrz w regularnych odstępach, ostrzega określoną liczbę dni przed notAfter i wyłapuje problemy z łańcuchem i nazwą hosta, których przypomnienie w kalendarzu nigdy by nie wyłapało. HostTracker powiadamia e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i inne kanały, więc ostrzeżenie dociera do kogoś, zanim dotrze wygaśnięcie. Monitorowanie domeny i TLS wykonuje sprawdzenie w sposób ciągły, narzędzie do sprawdzania SSL wykonuje sprawdzenie jednorazowe, a poradnik jak sprawdzić, czy port jest otwarty zajmuje się handshake, który zawodzi, zanim jeszcze certyfikat zostanie zaproponowany.