Wygasający certyfikat to najbardziej przewidywalna awaria: inwentarz i monitoring

W poniedziałek rano żadna aplikacja nie loguje użytkowników przez LDAPS. Kontrolery domeny działają, konta są w porządku, a w dziennikach aplikacji powtarza się błąd weryfikacji certyfikatu. Certyfikat kontrolera wygasł w niedzielę wieczorem. Data była zapisana w certyfikacie od dwóch lat, ale nie było jej w żadnym kalendarzu, monitoringu ani dokumencie.

Wygaśnięcie certyfikatu jest jedyną awarią, której dokładną datę zna się z góry. Przyczyną przestojów prawie nigdy nie jest brak wiedzy, że certyfikat wygaśnie, tylko brak wiedzy, że ten konkretny certyfikat istnieje. Rozwiązaniem jest inwentarz z kilku źródeł, codzienny pomiar dni do wygaśnięcia i progi, które zamieniają datę w zadania z właścicielem.

Gdzie certyfikaty się ukrywają

Certyfikat strony WWW pamięta każdy. Miejsca, o których zapomina się częściej:

LDAPS na kontrolerach domeny. Wygaśnięcie certyfikatu kontrolera zatrzymuje logowanie we wszystkich aplikacjach, które łączą się z katalogiem przez TLS.
Federacja i logowanie jednokrotne. Certyfikaty podpisujące tokeny SAML mają okres ważności liczony w latach, więc nikt nie pamięta, jak się je wymienia.
Wewnętrzny urząd certyfikacji. Wygaśnięcie urzędu pośredniego unieważnia wszystko, co wystawił.
Klastry Kubernetes. W k3s certyfikaty komponentów są ważne rok i odnawiane przy starcie usługi, gdy zbliża się koniec ważności. Klaster, którego nikt nie restartował przez rok, potrafi zaskoczyć.
Urządzenia. Interfejsy zarządzania serwerów, przełączników, macierzy i zasilaczy awaryjnych.
Integracje. Certyfikaty klienckie, którymi aplikacje uwierzytelniają się w API partnerów, banków i urzędów.
Poczta. TLS na przekaźnikach i łącznikach, certyfikaty do podpisywania wiadomości.

Inwentarz z trzech źródeł

Żadne źródło nie jest kompletne samo w sobie, dlatego inwentarz łączy trzy.

Skanowanie sieci znajduje wszystko, co przedstawia certyfikat na porcie TLS, łącznie z urządzeniami, o których nikt nie pamięta. Skan własnej sieci warto uzgodnić z osobami odpowiedzialnymi za bezpieczeństwo, bo systemy wykrywania włamań go zauważą.

# Wynik zawiera m.in. linie Subject, Issuer i Not valid after dla każdego portu
nmap -p 443,636,993,5986,8443 --script ssl-cert 10.10.0.0/24 -oN certyfikaty-$(date +%F).txt

Rejestr wystawców zna certyfikaty, których skan nie zobaczy, bo nie są wystawione na żadnym porcie: certyfikaty klienckie i podpisujące. Wewnętrzny urząd certyfikacji pokazuje je w konsoli w widoku wystawionych certyfikatów, a publiczne certyfikaty dla własnych domen są widoczne w dziennikach Certificate Transparency, na przykład przez wyszukiwarkę crt.sh.

Konfiguracja systemów uzupełnia resztę: magazyny certyfikatów serwerów Windows, pliki na serwerach Linux, sekrety typu kubernetes.io/tls i zasoby Certificate w klastrze.

Każdy certyfikat dostaje wpis z tymi samymi polami. Format jest drugorzędny, ważne, żeby inwentarz dało się przeszukać i porównać z wynikami skanu:

- nazwa: ldaps-dc01
  gdzie: dc01.corp.example.com:636
  wystawca: wewnętrzny CA (Corp Issuing CA)
  wygasa: 2027-03-14
  odnawianie: automatyczna rejestracja, szablon Kontroler domeny
  właściciel: zespół infrastruktury
  po_odnowieniu: sprawdzić, czy LDAPS przedstawia nowy certyfikat
  zależności: aplikacje z przypiętym certyfikatem (lista w dokumentacji)

Inwentarz jest wiarygodny tylko wtedy, gdy regularnie porównuje się go z rzeczywistością. Raz w tygodniu wynik skanu zestawia się z listą. Certyfikat widoczny w skanie, a nieobecny w inwentarzu, to wpis do uzupełnienia razem z właścicielem. Wpis, którego skan nie znalazł, oznacza usługę wyłączoną albo przeniesioną pod inny adres. Nowe usługi trafiają do inwentarza w chwili wdrożenia, jako krok procedury, a nie przy pierwszym alercie.

Progi i akcje

Metryka podstawowa to liczba dni do wygaśnięcia, liczona codziennie dla każdego wpisu. Progi zależą od sposobu odnawiania.

Próg	Certyfikat odnawiany ręcznie	Certyfikat odnawiany automatycznie	Kto reaguje
30 dni	zgłoszenie z terminem wymiany	brak akcji, jeśli automat odnawia wcześniej	właściciel
Minął zwykły termin odnowienia	nie dotyczy	alert: automat nie zadziałał	zespół
14 dni	alert na kanale zespołu	alert na kanale zespołu	zespół i przełożony właściciela
7 dni	powiadomienie natychmiastowe, obsługa jak incydent	jak dla ręcznego	dyżur

Zwykły termin odnowienia wynika z narzędzia. certbot domyślnie odnawia certyfikat, gdy do końca ważności zostaje 30 dni, a cert-manager, gdy minęły dwie trzecie okresu ważności, czyli dla certyfikatu 90-dniowego także około 30 dni przed końcem. Jeśli zostało 20 dni, a certyfikat nadal jest stary, odnowienie się nie udało i trzeba to wiedzieć od razu.

Pomiar realizuje system monitoringu, którego zespół już używa. W Prometheus z blackbox_exporter czas do wygaśnięcia daje metryka probe_ssl_earliest_cert_expiry, a cert-manager eksportuje certmanager_certificate_expiration_timestamp_seconds. W Zabbix agent 2 ten sam odczyt zapewnia element web.certificate.get.

# usługi sprawdzane przez blackbox_exporter: mniej niż 14 dni
(probe_ssl_earliest_cert_expiry - time()) / 86400 < 14

# certyfikaty cert-manager: mniej niż 21 dni, czyli automat nie odnowił w terminie
(certmanager_certificate_expiration_timestamp_seconds - time()) / 86400 < 21

openssl x509 -noout -serial -enddate -in /etc/ssl/certs/portal.crt
echo | openssl s_client -connect portal.example.com:443 -servername portal.example.com 2>/dev/null \
  | openssl x509 -noout -serial -enddate

Odnawianie

Protokół ACME dla publicznych certyfikatów i automatyczna rejestracja w wewnętrznym urzędzie dla certyfikatów domenowych usuwają większość pracy ręcznej. Certyfikaty, których nie da się zautomatyzować, na przykład wgrywane do zewnętrznych portali, mają spisaną procedurę i termin w kalendarzu zespołu, nie jednej osoby.

Raz w roku, dla certyfikatów z długim okresem ważności, takich jak urzędy pośrednie i certyfikaty federacji: próbna wymiana w środowisku testowym. Procedura, której nikt nie wykonywał od trzech lat, prawie na pewno jest nieaktualna.

Sprawdź u siebie

Pierwszy blok odczytuje datę wygaśnięcia certyfikatu przedstawianego przez usługę sieciową.

# HTTPS (SNI ma znaczenie, gdy pod jednym adresem działa kilka witryn)
echo | openssl s_client -connect portal.example.com:443 -servername portal.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate
# LDAPS na kontrolerze domeny
echo | openssl s_client -connect dc01.corp.example.com:636 2>/dev/null | openssl x509 -noout -enddate
# SMTP z STARTTLS
echo | openssl s_client -connect mail.example.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -enddate
# Kod wyjścia 1 i komunikat Certificate will expire, gdy zostało mniej niż 14 dni
echo | openssl s_client -connect portal.example.com:443 -servername portal.example.com 2>/dev/null \
  | openssl x509 -noout -checkend 1209600

Data w polu notAfter powinna być odległa o więcej niż zwykły termin odnowienia. Komunikat Certificate will expire oznacza, że certyfikat przekroczył próg 14 dni.

Drugi blok wypisuje certyfikaty w magazynie komputera Windows, które wygasną w ciągu 30 dni, oraz certyfikaty na kontrolerach domeny.

$limit = (Get-Date).AddDays(30)
Get-ChildItem Cert:\LocalMachine\My |
    Where-Object NotAfter -lt $limit |
    Sort-Object NotAfter |
    Select-Object Subject, NotAfter, Thumbprint,
        @{ n = 'DniDoKonca'; e = { ($_.NotAfter - (Get-Date)).Days } }

# Certyfikaty na kontrolerach domeny (w tym LDAPS)
Invoke-Command -ComputerName dc01, dc02 -ScriptBlock {
    Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint
}

Pusty wynik pierwszego polecenia jest dobry. Wartości ujemne w kolumnie DniDoKonca to certyfikaty już wygasłe: jeśli usługa korzysta z nowszego, są tylko pozostałością, a jeśli z tego, usługa właśnie przestała działać.

Trzeci blok pokazuje certyfikaty zarządzane przez cert-manager i ich terminy odnowienia.

kubectl get certificate -A
kubectl get certificate -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,EXPIRES:.status.notAfter,RENEWAL:.status.renewalTime

Każdy certyfikat powinien mieć READY równe True, a RENEWAL w przyszłości. Termin odnowienia w przeszłości przy niezmienionej dacie wygaśnięcia oznacza, że odnowienie się nie udaje; przyczynę pokaże kubectl describe certificate.

Ostatni blok, uruchamiany jako root na węźle serwerowym k3s, pokazuje ważność certyfikatów komponentów klastra.

for f in /var/lib/rancher/k3s/server/tls/*.crt; do
  printf '%-60s %s\n' "$f" "$(openssl x509 -noout -enddate -in "$f")"
done

Certyfikaty urzędów klastra (pliki z ca w nazwie) są ważne wiele lat. Pozostałe powinny kończyć się nie wcześniej niż za kilka miesięcy; termin bliższy niż 90 dni oznacza, że usługa dawno nie była restartowana.