Monitoring SSL.
Jak uniknąć awarii certyfikatów?

Wygasły certyfikat potrafi zatrzymać stronę internetową, sklep, API, VPN albo wewnętrzny panel administracyjny w jednej chwili.

Użytkownik zamiast serwisu widzi komunikat: „Połączenie nie jest prywatne." Aplikacja mobilna przestaje komunikować się z API. Integracja pomiędzy systemami zaczyna zwracać błędy. Pracownicy tracą dostęp do VPN albo wewnętrznej aplikacji.

W praktyce awaria certyfikatu rzadko wynika z braku możliwości jego odnowienia. Znacznie częściej przyczyną jest brak monitoringu, nieudana automatyzacja albo certyfikat zainstalowany w miejscu, o którym nikt już nie pamięta.

Monitoring SSL powinien być więc stałym elementem monitoringu infrastruktury, podobnie jak kontrola dostępności serwerów, backupów, miejsca na dyskach czy usług systemowych.

Potocznie nadal mówimy o certyfikatach SSL, choć współczesne systemy korzystają z protokołu TLS. W artykule używamy obu nazw, ponieważ fraza „monitoring SSL" jest powszechnie stosowana przez administratorów i użytkowników.

Dlaczego certyfikat może wygasnąć?

Certyfikat posiada określony czas ważności i zawiera między innymi datę wygaśnięcia, nazwę domeny lub listę nazw, wystawcę oraz klucz publiczny. Po przekroczeniu daty ważności klient nie powinien ufać certyfikatowi.

W przypadku strony internetowej zwykle oznacza to ostrzeżenie w przeglądarce. W przypadku API, aplikacji, poczty albo VPN połączenie może zostać całkowicie odrzucone.

Certyfikaty wygasają najczęściej przez:

Największym błędem jest założenie, że skoro certyfikat odnawia się automatycznie, monitoring nie jest potrzebny.

Automatyzacja i monitoring rozwiązują dwa różne problemy. Automatyzacja ma odnowić certyfikat. Monitoring ma wykryć, że z jakiegoś powodu to się nie udało.

Samo odnowienie certyfikatu nie wystarczy

To jeden z najczęstszych problemów. Proces ACME może poprawnie pobrać nowy certyfikat i zapisać go na dysku, ale aplikacja nadal korzysta ze starego certyfikatu załadowanego w pamięci.

Po odnowieniu może być konieczne przeładowanie Nginx, Apache lub HAProxy, aktualizacja load balancera, podmiana certyfikatu w panelu urządzenia, aktualizacja sekretu w Kubernetes albo wdrożenie certyfikatu na pozostałych węzłach klastra.

Dlatego monitoring powinien sprawdzać certyfikat rzeczywiście prezentowany klientowi, a nie tylko plik znajdujący się na serwerze.

Co się dzieje po wygaśnięciu certyfikatu?

Skutki zależą od rodzaju usługi.

Co powinien sprawdzać monitoring SSL?

Sprawdzanie samej daty wygaśnięcia to absolutne minimum. Dobry monitoring powinien kontrolować kilka elementów.

Data wygaśnięcia

System powinien pokazywać liczbę dni pozostałych do wygaśnięcia, z rosnącym poziomem alertu: 30 dni ostrzeżenie, 14 dni alert wysoki, 7 dni alert krytyczny, 3 dni natychmiastowa eskalacja. Dla certyfikatów automatycznie odnawianych krótki pozostały czas zwykle oznacza, że proces odnowienia nie działa.

Poprawność nazwy domeny

Certyfikat musi obejmować nazwę, z którą łączy się klient. Lista nazw znajduje się zwykle w polu SAN (Subject Alternative Name). Certyfikat dla www.example.pl nie musi obejmować example.pl, api.example.pl ani panel.example.pl. Każdą nazwę używaną przez klientów trzeba sprawdzać osobno.

Wildcard nie obejmuje wszystkiego

Certyfikat *.example.pl obejmuje między innymi www.example.pl i api.example.pl. Nie obejmuje jednak automatycznie domeny głównej example.pl ani domeny na kolejnym poziomie, jak api.test.example.pl.

W praktyce certyfikat wildcard często powinien zawierać jednocześnie example.pl i *.example.pl.

Łańcuch certyfikatów

Serwer powinien prezentować nie tylko certyfikat domeny, ale również prawidłowe certyfikaty pośrednie. Brakujący intermediate może powodować sytuację, w której certyfikat działa na części komputerów, ale nie działa na starszym urządzeniu albo w innej aplikacji. Monitoring powinien weryfikować, czy klient otrzymuje kompletny i poprawny łańcuch.

Wystawcę certyfikatu

Warto obserwować, kto wystawił certyfikat. Niespodziewana zmiana wystawcy może oznaczać planowaną migrację, błędne wdrożenie albo przejęcie kontroli nad domeną lub DNS. Zmiana certyfikatu nie zawsze jest zagrożeniem, ale powinna być widoczna.

Algorytm, długość klucza i wersje TLS

Monitoring bezpieczeństwa może wykrywać SHA-1, zbyt krótkie klucze RSA i przestarzałe algorytmy. Dla typowego wdrożenia rozsądnym minimum jest SHA-256 lub nowszy oraz RSA 2048-bit albo odpowiedni klucz ECC.

Ważny certyfikat nie gwarantuje bezpiecznej konfiguracji serwera - należy też sprawdzić, czy usługa nie pozwala na SSLv3, TLS 1.0 czy TLS 1.1. W typowym środowisku publicznym powinny być dostępne TLS 1.2 i, jeżeli technologia na to pozwala, TLS 1.3. Wyłączenie starszych protokołów trzeba jednak poprzedzić analizą klientów - niektóre stare aplikacje czy urządzenia przemysłowe mogą nie obsługiwać współczesnych ustawień.

Czas odpowiedzi, dostępność i odcisk certyfikatu

Monitoring certyfikatu warto połączyć z testem całej usługi: czy port odpowiada, czy handshake TLS się udaje, ile trwa odpowiedź. Certyfikat może być ważny, mimo że sama aplikacja nie działa.

W środowiskach o podwyższonych wymaganiach można monitorować fingerprint certyfikatu. Alert o zmianie fingerprintu powinien uwzględniać planowane odnowienia, aby nie generować niepotrzebnego szumu.

Monitoring publiczny i wewnętrzny

Jednym z najważniejszych elementów projektu jest określenie, skąd wykonywany jest test. Monitoring z internetu pokazuje certyfikat widoczny dla klienta - sprawdza się dla stron, API publicznych, VPN i poczty. Monitoring z sieci wewnętrznej jest potrzebny dla intranetu, LDAPS, paneli administracyjnych i certyfikatów prywatnego CA. Najlepszy system monitoringu często posiada obie sondy.

Reverse proxy, CDN i load balancer

Współczesna infrastruktura często wygląda tak: użytkownik → CDN → firewall/load balancer → HAProxy lub Nginx → aplikacja. W takim środowisku może istnieć kilka niezależnych certyfikatów - Cloudflare prezentuje poprawny certyfikat użytkownikowi, ale połączenie Cloudflare z serwerem origin może korzystać ze starego certyfikatu, a backend API z jeszcze innym.

Publiczny test strony nie wykryje wszystkich problemów. Monitoring powinien objąć każdy istotny odcinek komunikacji.

Sprawdzaj certyfikat z użyciem SNI

Wiele domen może działać pod jednym adresem IP. Serwer wybiera właściwy certyfikat na podstawie SNI, czyli nazwy przesyłanej podczas zestawiania połączenia TLS. Bez podania SNI narzędzie może pokazać certyfikat domyślnego virtual hosta zamiast certyfikatu sprawdzanej domeny. Dlatego w OpenSSL warto zawsze dodawać parametr -servername.

Jak ręcznie sprawdzić certyfikat?

OpenSSL

Wyświetlenie dat ważności:

echo | openssl s_client \
  -connect example.pl:443 \
  -servername example.pl 2>/dev/null \
  | openssl x509 -noout -dates

Wyświetlenie wystawcy i nazw:

echo | openssl s_client \
  -connect example.pl:443 \
  -servername example.pl 2>/dev/null \
  | openssl x509 -noout -issuer -subject -ext subjectAltName

OpenSSL jest bardzo dobry do diagnostyki, ale ręczne wykonywanie komend nie zastępuje ciągłego monitoringu.

cURL, Nmap i testssl.sh

Do sprawdzenia całego połączenia HTTPS: curl -vI https://example.pl. Parametr -k wyłącza weryfikację certyfikatu i powinien być używany wyłącznie diagnostycznie, nigdy jako stałe obejście w produkcyjnych skryptach.

Nmap pozwala sprawdzić certyfikat i obsługiwane protokoły: nmap --script ssl-cert,ssl-enum-ciphers -p 443 example.pl. Do dokładniejszego audytu konfiguracji można wykorzystać testssl.sh, które nadaje się bardziej do okresowego audytu niż do ciągłego monitorowania.

SSL Labs i Certificate Transparency

SSL Labs jest przydatny do ręcznego testowania publicznych usług HTTPS - dobrze sprawdza się podczas wdrożenia nowej strony czy zmiany reverse proxy, ale nie zastępuje ciągłego monitoringu.

Publiczne certyfikaty są rejestrowane w logach Certificate Transparency. Serwisy takie jak crt.sh pozwalają znaleźć certyfikaty wystawione dla domeny i jej subdomen, co może pomóc wykryć zapomniane subdomeny lub nieoczekiwane wystawienie certyfikatu. Trzeba jednak pamiętać, że log CT pokazuje wydane certyfikaty, a nie kompletną listę aktualnie działających usług.

Jakie narzędzia do stałego monitoringu?

Przykładowa konfiguracja modułu Blackbox Exporter:

modules:
  http_2xx:
    prober: http
    timeout: 10s
    http:
      method: GET
      preferred_ip_protocol: ip4
      tls_config:
        insecure_skip_verify: false

Przykładowe cele w Prometheusie:

scrape_configs:
  - job_name: blackbox_https
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.pl
          - https://api.example.pl
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Grafana jako centralny dashboard certyfikatów

Grafana może pokazywać dane z Prometheusa, InfluxDB, Zabbixa i innych źródeł. Praktyczny dashboard SSL:

Dashboard powinien pomagać znaleźć problemy, a nie tylko prezentować kolorowe wykresy.

Jak ustawić alerty?

Alert powinien trafić do osoby, która może wykonać konkretne działanie.

Dla certyfikatu wystawianego automatycznie przez Let's Encrypt nie należy czekać do siedmiu dni. Jeśli pozostało mniej niż 30 dni, proces automatycznego odnowienia prawdopodobnie już nie działa prawidłowo.

Dobry system powinien alertować nie tylko o wygaśnięciu, ale też o błędzie weryfikacji certyfikatu, niezgodności nazwy domeny, niepełnym łańcuchu, zmianie wystawcy, błędach procesu ACME i braku reloadu usługi.

Automatyczne odnowienie przez ACME

Najlepszym rozwiązaniem jest połączenie automatycznego odnawiania, monitoringu zewnętrznego, alertowania i testów procesu.

Certbot i Let's Encrypt

Przykład dla Nginx:

sudo certbot --nginx \
  -d example.pl \
  -d www.example.pl

Test odnowienia:

sudo certbot renew --dry-run

Test powinien być wykonywany okresowo, szczególnie po zmianach w firewallu, DNS, reverse proxy lub uprawnieniach.

Deploy hook

Po odnowieniu warto wykonać kontrolowany reload usługi:

#!/bin/sh
systemctl reload nginx

Skrypt można umieścić w katalogu /etc/letsencrypt/renewal-hooks/deploy/. Reload jest zwykle lepszy niż restart, ponieważ ogranicza przerwę w obsłudze ruchu. Po wykonaniu hooka monitoring powinien ponownie sprawdzić certyfikat prezentowany przez usługę.

HTTP-01 i DNS-01

HTTP-01: urząd certyfikacji sprawdza specjalny plik dostępny przez HTTP. Problemy mogą powodować blokada portu 80, złe przekierowanie albo reverse proxy i WAF.

DNS-01: weryfikacja odbywa się przez rekord TXT w DNS i jest potrzebna między innymi dla certyfikatów wildcard. Najlepiej automatyzować ją za pomocą API dostawcy DNS - dane dostępowe do API powinny mieć minimalne wymagane uprawnienia i nie powinny znajdować się w publicznym repozytorium.

Certyfikaty w Kubernetes

W Kubernetes często używa się cert-managera, który automatyzuje wystawianie certyfikatów, odnawianie i zapis do Secretów. Monitoring powinien jednak sprawdzać nie tylko obiekt Certificate, ale także certyfikat rzeczywiście prezentowany przez ingress albo load balancer - możliwa jest sytuacja, w której cert-manager odnowił Secret, ale ingress nie załadował zmiany.

Inwentaryzacja certyfikatów

Monitoring nie zadziała, jeśli nie wiadomo, jakie certyfikaty istnieją. Dla każdego certyfikatu warto zapisać domenę, właściciela, lokalizację, wystawcę i sposób odnowienia:

Taka lista powinna być regularnie aktualizowana.

Prywatne CA i mTLS

Wewnętrzna infrastruktura może korzystać z własnego urzędu certyfikacji dla urządzeń, użytkowników, LDAPS czy Wi-Fi 802.1X. Takie certyfikaty również wygasają - trzeba monitorować certyfikaty serwerów, certyfikaty pośrednie i certyfikat root CA. Wygaśnięcie certyfikatu pośredniego albo CA może wpłynąć na znacznie większą liczbę usług niż wygaśnięcie pojedynczego certyfikatu strony.

W mTLS certyfikat posiada zarówno serwer, jak i klient - wykorzystywane jest to w integracjach bankowych, API B2B i mikrousługach. Monitoring musi obejmować obie strony połączenia, ponieważ wygaśnięcie certyfikatu klienta może być trudniejsze do wykrycia - publiczny test serwera nadal będzie działał poprawnie.

Gdzie przechowywać klucze prywatne?

Klucze prywatne powinny być chronione przed odczytem przez nieuprawnionych użytkowników, kopiowaniem i umieszczeniem w repozytorium. Można wykorzystać odpowiednio zabezpieczony system plików, HashiCorp Vault, Azure Key Vault, AWS Secrets Manager lub HSM.

Monitoring nie powinien wymagać dostępu do klucza prywatnego. Do sprawdzenia certyfikatu prezentowanego przez usługę wystarczy połączenie TLS.

Co robić, gdy certyfikat już wygasł?

Najpierw trzeba ustalić, gdzie kończy się połączenie TLS - może to być CDN, WAF, load balancer, reverse proxy albo serwer aplikacyjny. Następnie:

1. 1 potwierdź domenę i zakres awarii,
2. 2 sprawdź certyfikat prezentowany klientowi,
3. 3 ustal, czy nowy certyfikat został już wystawiony,
4. 4 sprawdź proces ACME lub panel CA,
5. 5 wygeneruj lub odnów certyfikat,
6. 6 wdroż go we wszystkich wymaganych miejscach,
7. 7 przeładuj usługi,
8. 8 sprawdź pełny łańcuch,
9. 9 przetestuj usługę z zewnątrz,
10. 10 sprawdź zależne API i integracje,
11. 11 ustal, dlaczego monitoring lub automatyzacja zawiodły.

Nie należy wyłączać HTTPS jako standardowego obejścia. Może to narazić dane użytkowników i spowodować dodatkowe problemy z HSTS, przekierowaniami i sesjami.

Runbook awarii certyfikatu

Dobrze przygotowany runbook powinien zawierać nazwę usługi, lokalizację certyfikatu, sposób odnowienia, dane właściciela, polecenie reloadu i sposób testowania. Przykładowy skrócony runbook:

Usługa: api.example.pl
Terminacja TLS: HAProxy LB01 i LB02
Metoda: ACME DNS-01
Dostawca DNS: Cloudflare
Plik certyfikatu: /etc/haproxy/certs/api.example.pl.pem
Reload: systemctl reload haproxy
Test: openssl s_client -connect api.example.pl:443 -servername api.example.pl
Właściciel: dział infrastruktury

Runbook powinien być dostępny poza serwerem, którego dotyczy.

Plan wdrożenia monitoringu SSL

Najczęstsze błędy

Certyfikat na dysku może być nowy, ale Nginx nadal prezentuje stary. Kilka osób może otrzymywać alert i każda zakłada, że ktoś inny go obsłuży. A automatyzacja skonfigurowana rok temu może przestać działać po zmianie DNS, o czym nikt się nie dowie bez regularnego testu.

Jak wygląda dobry monitoring SSL?

Dobry system zna wszystkie certyfikaty, sprawdza je automatycznie z właściwego miejsca w sieci, korzysta z SNI, weryfikuje nazwę i łańcuch, testuje dostępność usługi, monitoruje proces odnowienia, wykrywa zmianę certyfikatu i prowadzi do aktualnego runbooka.

Najważniejsze jest rozdzielenie trzech elementów: automatyczne odnowienie, niezależny monitoring i procedura awaryjna. Jeśli jeden z nich zawiedzie, pozostałe powinny ograniczyć ryzyko awarii.

Podsumowanie

Monitoring SSL nie powinien sprowadzać się do wpisania daty wygaśnięcia w kalendarzu. Certyfikaty są dziś wykorzystywane przez znacznie więcej usług niż publiczne strony internetowe - chronią API, VPN, pocztę, integracje, systemy wewnętrzne i komunikację między aplikacjami.

Skuteczny monitoring powinien sprawdzać datę ważności, zgodność domeny, łańcuch zaufania, wersję TLS, dostępność usługi, proces automatycznego odnawiania i certyfikat rzeczywiście prezentowany użytkownikowi.

Samo posiadanie Certbota, cert-managera albo automatyzacji u dostawcy chmury nie usuwa ryzyka. Każda automatyzacja może przestać działać po zmianie DNS, firewalla, uprawnień albo architektury.

W PRO-Admin wdrażamy monitoring certyfikatów jako część szerszego monitoringu infrastruktury. Obejmuje on serwery Windows i Linux, Proxmox, VMware, urządzenia sieciowe, strony, API, VPN, pocztę, backupy i usługi biznesowe. Celem nie jest jedynie ostrzeżenie, że certyfikat niedługo wygaśnie. Celem jest wykrycie problemu odpowiednio wcześnie, wskazanie jego właściciela i doprowadzenie do naprawy, zanim użytkownicy zobaczą błąd połączenia.