Certyfikat wygasł w nocy. Jak to przestaje być Twój problem

Telefon dzwoni o 3:12 w nocy. Klient pisze, że strona pokazuje ostrzeżenie „Połączenie nie jest prywatne", a formularz płatności przestał działać. Certyfikat SSL wygasł kilka godzin wcześniej — cicho, bez żadnego alarmu, bo nikt go nie pilnował. Winny nie jest atak ani awaria serwera — tylko jedna data w kalendarzu, o której nikt nie pamiętał.

Anatomia wpadki: jedna czerwona plansza i klient ucieka

Przeglądarki traktują wygasły certyfikat bardzo poważnie — Chrome i Firefox pokazują pełnoekranowe ostrzeżenie, które trzeba świadomie obejść, żeby w ogóle zobaczyć stronę. Większość odwiedzających tego nie robi. Klienci uciekają, koszyki zostają porzucone, a jeśli strona obsługuje płatności albo logowanie, ostrzeżenie podważa zaufanie na dłużej niż trwa sama awaria — użytkownik, który raz zobaczył czerwoną planszę, wraca rzadziej niż ten, który jej nie widział. Do tego dochodzi efekt, o którym łatwo zapomnieć: wyszukiwarki i część przeglądarek traktują niedziałający certyfikat jako sygnał problemu z bezpieczeństwem strony, co może obniżyć zaufanie do domeny na dłużej niż trwa sama naprawa.

Dlaczego auto-renewal zawodzi, mimo że „miał się odnawiać sam"

• Cron padł po aktualizacji serwera — zadanie odnawiające certyfikat przestało się uruchamiać po rutynowej aktualizacji systemu, a nikt tego nie zauważył, bo brak logów też nie generuje alertu.
• Limit zapytań API u dostawcy certyfikatów — automat próbuje odnowić certyfikaty na wielu serwerach jednocześnie i trafia na dzienny limit, więc jedna odnowa cicho się nie udaje, a kolejna próba dopiero następnego dnia.
• Zmiana DNS bez aktualizacji walidacji — przeniesienie domeny do innego dostawcy DNS zrywa mechanizm walidacji (np. rekord TXT), a auto-renewal przestaje przechodzić bez żadnego komunikatu do właściciela.
• Zapomniana subdomena w konfiguracji — certyfikat główny odnawia się poprawnie, ale subdomena dodana pół roku temu nigdy nie trafiła do listy automatycznego odnawiania i wygasa osobno, po cichu.

Każdy z tych scenariuszy ma jedną wspólną cechę: system nie zgłasza błędu, bo z jego punktu widzenia nic się nie stało — zadanie po prostu się nie wykonało. Bez zewnętrznej czujki, która sprawdza sam certyfikat, a nie logi automatu odnawiającego, nikt nie dowie się o problemie, dopóki nie zobaczy go klient. To nie jest kwestia niedbałości — to strukturalna słabość automatyzacji, która nie ma nikogo, kto zweryfikowałby jej własny sukces.

Jak wygląda monitoring certyfikatów i domen w KRKN

Czujka domen i certyfikatów regularnie sprawdza termin wygaśnięcia każdego certyfikatu TLS i każdej domeny w Twojej infrastrukturze — niezależnie od tego, czy odnawiają się automatycznie, czy ręcznie. Progi ostrzegawcze ustawione są na 14 i 7 dni przed wygaśnięciem, więc masz realny czas na reakcję, zanim ktokolwiek zobaczy ostrzeżenie w przeglądarce. Sprawdzenie działa niezależnie od samego serwera i automatu odnawiającego, dzięki czemu wychwytuje też sytuacje, w których problem leży poza Twoją infrastrukturą — na przykład po stronie dostawcy DNS.

Gdy termin się zbliża, alert eskaluje: najpierw e-mail przy progu 14 dni, potem e-mail i SMS przy progu 7 dni, jeśli certyfikat wciąż nie został odnowiony. To samo dotyczy wygasających domen — rzadszy, ale znacznie boleśniejszy scenariusz, bo utraconej domeny nie da się odzyskać w kilka minut, tak jak certyfikatu.

Co zrobić, gdy dostaniesz alert 14 dni przed wygaśnięciem

Czternaście dni to wystarczająco dużo czasu, żeby spokojnie sprawdzić, czy auto-renewal faktycznie zadziała, czy trzeba odnowić certyfikat ręcznie. W opiece zarządzanej KRKN ten krok wykonuje inżynier zgodnie z SLA — dostajesz potwierdzenie odnowienia, a nie dopiero informację o awarii następnego dnia. Zamiast dowiadywać się o problemie z wiadomości od klienta, dostajesz maila, na który możesz odpowiedzieć spokojnie, w ciągu dnia pracy — nie w środku nocy, pod presją. To jest ta różnica: certyfikat, który wygasa, przestaje być Twoim problemem, zanim w ogóle zdąży nim być.

← wszystkie wpisy