Certyfikaty Entrust bez zaufania Chrome: co robią właściciele stron

Chrome przestanie ufać certyfikatom Entrust wydanym po 31 października 2024. Jeśli więc Twoje serwisy działają na certyfikatach Entrust, spisz, co masz, i przenieś wydawanie nowych do innego urzędu certyfikacji przed najbliższym odnowieniem. Do terminu zostały dni. Mimo to nic nie zepsuje się z dnia na dzień: zgodnie z komunikatem Chrome Root Program o Entrust certyfikaty już wdrożone działają dalej. To zadanie do zaplanowania. Nie awaria.

Co właściwie zmienia wycofanie zaufania Chrome do Entrust?

Chrome 131 i nowsze wersje nie będą już ufać certyfikatom TLS, których łańcuch prowadzi do certyfikatów głównych Entrust, jeśli zostały wydane po 31 października 2024. Google opisuje zakres zmian we wpisie o wycofaniu zaufania na swoim Security Blog. I tu jest rzecz, którą wiele osób rozumie źle: reguła zależy od daty wydania, a Chrome odczytuje ją z najwcześniejszego znacznika Signed Certificate Timestamp osadzonego w certyfikacie. Dzień, w którym odwiedzający ładuje stronę? Bez znaczenia. Dlaczego Google w ogóle to robi? Wskazuje na powtarzające się naruszenia zgodności, niespełnione zobowiązania do poprawy i brak mierzalnych postępów w odpowiedzi na publicznie ujawnione raporty o incydentach. Wszystko to podważyło jego zaufanie do Entrust jako właściciela CA.

Które certyfikaty Entrust będą działać, a które przestaną?

Wydane w dniu granicznym lub wcześniej: zaufane do wygaśnięcia. Wydane później: ostrzeżenie przeglądarki w wersjach Chrome objętych zmianą. I nie jest ono dyskretne, bo odwiedzający, który trafi na certyfikat bez zaufania, zamiast strony zobaczy pełnoekranową planszę z ostrzeżeniem. Wyjątki wymienione przez Google są wąskie: firmy mogą jawnie zaufać tym certyfikatom głównym przez lokalne ustawienia zaufania na maszynach, które kontrolują (co nic nie daje publicznym odwiedzającym).

W praktyce serwis psuje się w chwili odnowienia lub ponownego wydania certyfikatu po terminie. Dlatego prawdziwy termin dla każdej domeny wyznacza Twój kalendarz odnowień. Jedna pułapka: ponowne wydanie wywołane rotacją klucza albo zmianą nazwy hosta liczy się tak samo jak planowe odnowienie.

Jak znaleźć każdy certyfikat Entrust, którego używasz

Sprawdź wystawcę i datę wydania każdego certyfikatu na każdej nazwie hosta, także na tych, których nie obsługuje główny serwer WWW. Niespodzianki biorą się z zapomnianych punktów końcowych. Przejdź przez:

• główne serwisy i wszystkie subdomeny
• load balancery i proxy, które terminują TLS
• punkty końcowe poczty i API
• hosty stagingowe i testowe
• certyfikaty kupione przez dostawcę hostingu lub resellera, gdzie wystawcy nie zawsze widać na fakturze

Dla pojedynczego serwisu oba pola pokaże podgląd certyfikatu w przeglądarce. Masz ich całą partię? Uruchom to polecenie dla każdego hosta ze swojej maszyny:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -issuer -dates

Zapisz nazwę hosta, wystawcę, datę wydania, datę wygaśnięcia, miejsce przechowywania klucza prywatnego i osobę, która odnawia certyfikat. Nudne, wiem. Ale jeśli dla części domen stosujesz kierowanie DNS na proxy, zanotuj też, która maszyna faktycznie przedstawia certyfikat odwiedzającym, bo to ją będziesz aktualizować.

Jak wymienić certyfikat SSL na certyfikat innego urzędu

Wygeneruj nowy klucz i CSR, zamów certyfikat w innym publicznie zaufanym CA, zainstaluj go z pełnym łańcuchem i przeładuj serwer WWW. Wszystko to, zanim stary trzeba będzie odnowić. Na własnym serwerze lub u dostawcy kolejność wygląda tak:

1. Wybierz nowy CA i potrzebny typ walidacji.
2. Utwórz nowy klucz prywatny i CSR na serwerze źródłowym.
3. Przejdź walidację domeny przez DNS, HTTP lub e-mail.
4. Zainstaluj certyfikat i łańcuch pośredni w konfiguracji NGINX lub innego serwera.
5. Przetestuj konfigurację, a potem przeładuj serwer zamiast go restartować.
6. Zweryfikuj z zewnątrz przeglądarką i powyższym poleceniem openssl.

Zostaw stary certyfikat na miejscu, dopóki nowy nie zostanie zweryfikowany. Sama podmiana nie wymaga przestoju, więc nie ma powodu się spieszyć. A skoro i tak zmieniasz urząd certyfikacji, radzę przy okazji zrezygnować z ręcznych zakupów i przejść na automatyczne wydawanie przez ACME na serwerze źródłowym. Jeden haczyk: gdy ten serwer stoi za kolejną warstwą, żądania walidacyjne muszą do niego dotrzeć. Taką konfigurację opisujemy w poradniku o Let’s Encrypt za proxy.

Zaktualizuj rekord CAA w DNS, zanim zamówisz nowy certyfikat

Rekord CAA w DNS wskazuje, które urzędy certyfikacji mogą wydawać certyfikaty dla domeny. Jeśli nie dodasz tam nowego CA, wydanie zostanie odrzucone. Po prostu. CAA to skrót od Certification Authority Authorization, a wpis dopuszczający nowego wystawcę wygląda tak:

example.com. IN CAA 0 issue "letsencrypt.org"

Sprawdź, co już istnieje, poleceniem dig CAA example.com dla domeny głównej, a potem powtórz to dla każdej subdomeny, bo nazwa bez własnego rekordu dziedziczy politykę domeny nadrzędnej. Kolejność ma znaczenie. Najpierw dodaj nowy urząd, wydaj i wdróż certyfikat, a wpis Entrust usuń dopiero wtedy, gdy nie zależy od niego żadna nazwa hosta. Walidacja nie przechodzi zaraz po zmianie? Odczekaj TTL rekordu, zanim spróbujesz ponownie.

Błędy certyfikatu a SEO: ile kosztuje przegapione odnowienie

Certyfikat bez zaufania stawia stronę z ostrzeżeniem między Tobą a odwiedzającymi. Ruch i konwersje spadają od razu, choć sam serwer nadal odpowiada. I to jest w tym najgorsze. Inaczej niż przy awarii serwer źródłowy dalej zwraca treść, ale użytkownicy Chrome do niej nie docierają, więc monitoring dostępności, który nie sprawdza zaufania, będzie spokojnie raportował, że wszystko działa. Porównaj to z tym, co widzą odwiedzający podczas awarii, gdy kod statusu przynajmniej mówi klientom, że coś poszło nie tak.

Czego się spodziewać: porzuconych wizyt, nieudanych zamówień i niewysłanych formularzy, a do tego zerwanych wywołań API lub webhooków od klientów, którzy weryfikują łańcuch. Zapobieganie jest jednak tanie. Monitoruj datę wygaśnięcia i wystawcę dla każdej nazwy hosta, ustaw przypomnienie o odnowieniu z dużym wyprzedzeniem przed każdą datą i po każdej zmianie certyfikatu testuj serwis w aktualnym Chrome.

Plan zmiany certyfikatów Entrust dla kilku serwisów

Posortuj serwisy według daty odnowienia i migruj najpierw te z najwcześniejszym terminem. W ramach tej kolejności: certyfikaty wygasające najszybciej, potem hosty kluczowe dla przychodów, potem nazwy wewnętrzne i stagingowe. Dla każdego serwisu trzeba podjąć decyzję. Wydać certyfikat ponownie w Entrust przed terminem granicznym, żeby zyskać czas do jego wygaśnięcia? Czy od razu przejść do nowego CA i mieć to z głowy?

Zapisz, kto teraz odpowiada za odnowienia i jaka automatyzacja za nimi stoi, żeby za rok nikt nie musiał powtarzać migracji ręcznie. A jedno zadanie na ten miesiąc jest proste: wypisz wszystkie swoje certyfikaty Entrust z datami wydania i wygaśnięcia i przypisz każdemu urząd zastępczy, zanim przyjdzie jego kolejne odnowienie.

FAQ