Let’s Encrypt kończy z OCSP: naprawa OCSP stapling na NGINX

Let’s Encrypt ogłosił 23 lipca 2024 r., że zamierza zakończyć obsługę OCSP na rzecz list unieważnionych certyfikatów. OCSP stapling na NGINX z tymi certyfikatami prędzej czy później nie będzie więc miał czego dołączać. Czy Twoja strona przestanie obsługiwać TLS? Nie. Ale dyrektywy staplingu w konfiguracji powoli zamieniają się w balast. Poniżej: co ogłoszono, co to oznacza dla konfiguracji z ssl_stapling i co warto już teraz sprawdzić na własnym serwerze.

Co Let’s Encrypt ogłosił w sprawie OCSP?

W skrócie: urząd certyfikacji chce jak najszybciej odejść od protokołu Online Certificate Status Protocol i przejść na listy unieważnionych certyfikatów. Według ogłoszenia Let’s Encrypt o zastąpieniu OCSP urząd utrzymuje responder OCSP od startu prawie dziesięć lat temu, a obsługę CRL dodał w 2022 roku. Następnie w sierpniu 2023 roku CA/Browser Forum przyjęło w głosowaniu zmianę, po której usługi OCSP są opcjonalne dla publicznie zaufanych urzędów certyfikacji. Został jeden wyjątek: Microsoft Root Program.

Konkretne daty? Jeszcze ich nie ma. Szczegółowy harmonogram pojawi się, gdy Microsoft również uzna OCSP za opcjonalny, a urząd liczy, że nastąpi to w ciągu najbliższych sześciu do dwunastu miesięcy. Ostatnią odpowiedź chce wysłać od trzech do sześciu miesięcy po tym, jak opublikuje harmonogram wyłączenia usługi. Aktualizacje będą trafiać do kategorii API Announcements na forum Discourse projektu. Zapisz się tam - to jedyny pewny sposób, żeby się o tym dowiedzieć.

CRL a OCSP: dlaczego urząd zmienia mechanizm

OCSP to zapytanie o status pojedynczego certyfikatu wysyłane do respondera urzędu. CRL to publikowana lista wszystkich certyfikatów, które urząd unieważnił. Głównym powodem zmiany jest prywatność. Zapytanie OCSP mówi urzędowi, która strona jest odwiedzana i z jakiego adresu IP, a nawet urząd, który celowo nie przechowuje takich zapisów, mógłby zostać prawnie zmuszony do ich gromadzenia. Listy unieważnień nie mają tego problemu, bo klient pobiera całą listę, zamiast pytać o jedną stronę.

Drugi powód to zwykłe utrzymanie. W tym samym ogłoszeniu czytamy, że możliwie prosta infrastruktura urzędu ma znaczenie dla zgodności z wymogami, niezawodności i wydajności, że utrzymywanie OCSP co roku pochłaniało znaczne zasoby, a sama usługa stała się zbędna, odkąd obsługiwane są listy CRL. Trudno się nie zgodzić.

Jak dziś działa OCSP stapling na NGINX

Przy staplingu serwer WWW sam pobiera odpowiedź OCSP i dołącza ją do uzgadniania TLS. Klient odwiedzającego w ogóle nie musi kontaktować się z urzędem. W NGINX odpowiadają za to trzy dyrektywy: ssl_stapling, ssl_stapling_verify i ssl_trusted_certificate, wszystkie opisane w dokumentacji modułu ssl nginx. Ta strona stawia jeden wymóg (i to na nim ludzie się potykają): certyfikat wystawcy musi być znany. Jeśli więc plik ssl_certificate nie zawiera certyfikatów pośrednich, certyfikat wystawcy musi znaleźć się w pliku ssl_trusted_certificate.

Typowy blok server dla Let’s Encrypt z włączonym staplingiem wygląda tak:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate         /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_stapling            on;
    ssl_stapling_verify     on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
}

Co się zmienia dla konfiguracji ssl_stapling w nginx

Stapling zależy w całości od respondera urzędu. Gdy odpowiedzi przestaną być wysyłane, NGINX nie będzie miał czego pobrać ani dołączyć. W ogłoszeniu zaznaczono, że większość implementacji OCSP działa w trybie fail open, czyli brak możliwości pobrania odpowiedzi nie psuje systemu. Twoja strona dalej obsługuje TLS. Uzgadnianie po prostu odbywa się bez dołączonego statusu.

W praktyce dyrektywy stają się martwą konfiguracją, która może co najwyżej zaśmiecać logi. To porządki do zrobienia, a nie sytuacja awaryjna. Jedno sprawdziłbym jednak w pierwszej kolejności: gdzie w Twojej infrastrukturze faktycznie kończy się połączenie TLS? Przy HTTPS za reverse proxy ustawienia staplingu mogą leżeć na innej maszynie niż ta, o której myślisz w pierwszej chwili.

Zastosowania poza przeglądarką to inna sprawa i wymagają większej uwagi. Jeśli zabezpieczasz tymi certyfikatami na przykład VPN, urząd radzi upewnić się, że Twoje oprogramowanie działa poprawnie, gdy certyfikat nie zawiera adresu URL OCSP.

Lista kontrolna: przygotowanie serwera na koniec OCSP

Zasadniczo chodzi o to, żeby znaleźć każde miejsce, które polega na OCSP, i zaplanować, jak się go pozbyć. Przejdź te kroki na własnym hoście:

1. Znajdź dyrektywy. Przeszukaj każdy blok server pod kątem ssl_stapling i ssl_stapling_verify, także współdzielone snippety i pliki dołączane przez include: grep -rn "ssl_stapling" /etc/nginx/.
2. Obejrzyj certyfikat. Czy nadal zawiera adres URL OCSP? Sprawdź poleceniem openssl x509 -in fullchain.pem -noout -ocsp_uri.
3. Przetestuj uzgadnianie. Uruchom openssl s_client -connect example.com:443 -servername example.com -status i poszukaj sekcji z odpowiedzią OCSP, żeby zobaczyć, czy wraca dołączona odpowiedź.
4. Przejrzyj monitoring i skrypty wdrożeniowe. Każdy test, który traktuje brak dołączonej odpowiedzi jako błąd, zacznie zgłaszać fałszywe alarmy.
5. Wskaż twarde zależności. Wszystko, co do działania wymaga odpowiedzi OCSP, potrzebuje planu odejścia od tej zależności, zgodnie z zaleceniem urzędu, żeby zacząć jak najszybciej.
6. Zaplanuj usunięcie. Gdy harmonogram wyłączenia zostanie opublikowany, usuń dyrektywy staplingu, uruchom nginx -t i przeładuj konfigurację.
7. Zapisz się na API Announcements. To tam pojawi się szczegółowy harmonogram.

Które kontrole certyfikatu TLS nadal mają znaczenie po zmianie

Sprawdzanie unieważnień przenosi się na stronę klienta i przeglądarki, przez listy CRL. Na serwerze WWW nie ma tu nic do skonfigurowania. W Twoich rękach zostaje reszta cyklu życia certyfikatu:

• pełny łańcuch serwowany z pliku ssl_certificate,
• automatyczne odnawianie, które działa i potem przeładowuje NGINX,
• monitoring ważności, który ostrzega, zanim certyfikat wygaśnie,
• test uzgadniania po każdej zmianie konfiguracji.

Wszystko to widać z zewnątrz. Każdy może sprawdzić, co zdradzają konfiguracje TLS o serwerze, więc spójna konfiguracja jest warta wysiłku. Czysta konfiguracja służy też robotom tak samo jak odwiedzającym, co ma znaczenie, gdy Googlebot crawluje przez HTTP/2 na połączeniach negocjowanych w tym samym uzgadnianiu.

Dopóki responder nie zostanie wyłączony, OCSP stapling działa dokładnie tak jak dziś. Jaki ruch ma więc sens w lipcu 2024 roku? Zrób audyt konfiguracji, zapisz każdą zależność od dołączanej odpowiedzi i usuń je spokojnie, gdy pojawi się harmonogram. Bez pośpiechu.

FAQ