Dlaczego GoDaddy usuwa ClientAuth EKU i przechodzi do hierarchii głównej R1 w celu wystawiania DV TLS?

Począwszy od 15 czerwca 2026 r., Publicznie zaufane certyfikaty SSL/TLS wystawione do użytku serwera nie będą już mogły obejmować rozszerzonego użycia klucza „Uwierzytelnianie klienta” (EKU: clientAuth). Oto kluczowe kwestie do zrozumienia:

• Zmiana jest częścią aktualizacji zasad programu Chrome Root: nowe certyfikaty muszą zawierać tylko element EKU „Uwierzytelnianie serwera”.
• Nowe certyfikaty publiczne wystawione po tej dacie, które zawierają clientAuth, nie będą zaufane w przeglądarce Chrome.
• Ta zmiana nie ma wpływu na certyfikaty wystawione za pomocą clientAuth przed 15 czerwca 2026 r., Które pozostaną ważne do czasu ich wygaśnięcia lub odwołania.
• Ta zmiana nie ma wpływu na certyfikaty CA prywatnych (do użytku wewnętrznego) & mdash; dotyczy ona tylko certyfikatów zaufanych publicznie.

W skrócie: jeśli Twoja organizacja używa publicznych certyfikatów TLS do uwierzytelniania klienta (za pośrednictwem klienta clientAuth EKU), musisz podjąć działania przed 15 czerwca 2026 r . W przypadku standardowego użycia protokołu TLS w witrynie (tylko uwierzytelnianie serwera) ta zmiana nie wymaga żadnych działań. Warto jednak przypomnieć, że warto przejrzeć certyfikat użytkowania, odpowiednio wydzielić funkcje i dostosować się do zmieniającego się modelu zaufania.

W jaki sposób GoDaddy wdroży tę zmianę

Nasze obecne pośredniczące podpisywanie/wystawianie podpisów G2 nie ma na liście żadnych rozszerzeń EKU, co powoduje, że ta hierarchia jest niezgodna z wymaganiem programu głównego Chrome. W związku z tym emisja produktów pośrednich G2, których dotyczy problem, musi zostać wstrzymana do tego dnia.

Zamiast tworzyć nowe pośredniczące emisje w łańcuchu G2 & mdash; który ma wygasnąć/zakończyć się z Google w kwietniu 2027 roku & mdash; przenosimy emisję DV do naszej nowej hierarchii R1, aby spełnić ograniczenia wynikające z zasad.

Zmieniamy publiczny łańcuch wystawiania certyfikatów DV, aby nowe certyfikaty liści DV były wystawiane z hierarchii głównego urzędu certyfikacji TLS firmy GoDaddy przy użyciu pośredniego urzędu certyfikacji TLS firmy GoDaddy DV - R1v1 wystawiającego certyfikaty CA.godaddy.com. Oznacza to, że łańcuch wystawców prezentowany przez serwery (liść + pośredni) może różnić się od tego, co w niektórych systemach widziało w przeszłości, a wszelkie narzędzia wewnętrzne, które zakładają, że określona starsza nazwa pośrednicząca lub kolejność łańcucha muszą zostać zaktualizowane, aby zaakceptować nowy łańcuch R1.

Ponadto certyfikaty liścia wystawione na podstawie tej hierarchii nie będą zawierać protokołu ClientAuth EKU. Każdy przepływ pracy, w którym certyfikaty liści DV były używane do uwierzytelniania klienta TLS, muszą zostać poddane migracji do odpowiedniego profilu certyfikatu/ścieżki PKI. Podczas wdrażania certyfikaty nadal działają w przeglądarkach, ponieważ klienci sprawdzają poprawność przy użyciu wymaganej ścieżki zaufania podpisanej krzyżowo R1 → G2 opublikowanej w naszym repozytorium (certs.godaddy.com).

Jak certyfikaty działają w przeglądarce podczas przejścia na R1 (znak krzyżowy R1 → G2)

W miarę jak przeprowadzamy migrację publicznego wydawania DV TLS do hierarchii R1, katalog główny R1 nadal cieszy się dużym zaufaniem/jest dystrybuowany w magazynach zaufania przeglądarki i systemu operacyjnego. Aby zapewnić natychmiastowe działanie nowo wystawionych certyfikatów R1 w przeglądarkach, opieramy się na ścieżce zaufania z podpisem krzyżowym z powrotem do już zaufanego katalogu głównego G2.

W praktyce certyfikat liścia jest wydawany w ramach urzędu certyfikacji R1 DV, ale klienci weryfikują go, tworząc łańcuch do GoDaddy Root - G2 przy użyciu opublikowanego certyfikatu krzyżowego R1 → G2. Odpowiednie artefakty w repozytorium to kotwica zaufania G2 (gdroot-g2), certyfikat krzyżowy (gd_tls_root-r1-cross-g2), element pośredniczący R1 DV (gd_tls_issuing_dv-r1v1) oraz natywny katalog główny hierarchii (gd_tls_root-r1) ) certs.godaddy.com. Takie podejście do cross-sign pozwala przeglądarkom na weryfikację łańcucha dzisiaj (zakotwiczenie w G2), podczas gdy zaufanie R1 propaguje się z czasem.

Dlaczego wprowadzono tę zmianę?

Istnieje kilka powodów, dla których warto odejść od certyfikatów obsługujących zarówno uwierzytelnianie servera, jak i uwierzytelnianie klienta (nazywane również certyfikatami o różnym przeznaczeniu):

• Oddzielenie uwierzytelniania serwera od uwierzytelniania klienta pomaga uprościć model zaufania dla certyfikatów.
• Lepsza higiena bezpieczeństwa: Certyfikaty o zbyt dużej liczbie celów zwiększają ryzyko (czyli niewłaściwe użycie clientAuth w niezamierzony sposób).
• Używanie dedykowanych hierarchii kluczy publicznych dla różnych funkcji pomaga zachować wyraźniejsze granice zaufania, dostosowując je do najlepszych praktyk w zakresie infrastruktury klucza publicznego (PKI).

Jakie są zalety tej zmiany?

• Zmniejszone ryzyko związane z certyfikatami uniwersalnymi: Ograniczenie certyfikatów publicznych tylko do uwierzytelniania serverAuth zmniejsza powierzchnię ataku, a granice zaufania są wyraźniejsze.
• Lepsza zgodność & Zarządzanie: Organizacje będą miały wyraźniejszy rozdział między uwierzytelnianiem serwera a uwierzytelnianiem klienta, co może zapewnić lepszą kontrolę i zarządzanie cyklem życia certyfikatu.
• Większa przejrzystość działania: gdy funkcjonalność clientAuth zostanie podzielona na odpowiednie certyfikaty lub infrastrukturę, łatwiej będzie zarządzać rolami, odwołaniami i odnowieniami oraz upewnić się, że używany jest właściwy certyfikat do właściwego celu.
• Gotowość na przyszłość: ta zmiana jest zgodna z ewoluującymi modelami PKI / zaufania przeglądarek i pomaga organizacjom w korzystaniu z nowszych modeli zabezpieczeń i automatyzacji.

Kogo to nie dotyczy?

Nie ma to wpływu na większość witryn, które używają certyfikatów tylko do uwierzytelniania serwera (czyli typowego protokołu TLS/HTTPS). Jeśli kiedykolwiek używasz certyfikatu tylko do zabezpieczenia witryny przed użytkownikami, ta zmiana nie wymaga żadnych działań.

Kogo to dotyczy?

Ta zmiana ma wpływ na organizacje, które używają publicznie zaufanych certyfikatów serwera do uwierzytelniania klienta (nazywanego również wzajemnym uwierzytelnianiem TLS / mTLS) lub uwierzytelniania serwer-serwer, które korzystają z protokołu EKU clientAuth. Na przykład niektóre usługi finansowe, usługi SaaS lub interfejsy API dla wielu dzierżawców mogą zostać objęte tą zmianą.

Co musisz zrobić

• Jeśli jesteś hostowany poza firmą GoDaddy : Upewnij się, że pełny pakiet dostarczony przez punkty końcowe pobierania lub interfejs klienta jest instalowany podczas aktualizacji następnego certyfikatu.
• Jeśli używasz certyfikatów w jakimkolwiek przypadku użycia, które opierają się na ClientAuth (mTLS) : Upewnij się, że dokonujesz migracji tych przepływów pracy, tak aby używały certyfikatu z podpisem własnym lub rozwiązania prywatnego urzędu certyfikacji.

Zespoły powinny również potwierdzić, że żadna wewnętrzna funkcja lub dokumentacja nie zakłada, że certyfikaty liścia DV zawierają ClientAuth EKU, ponieważ certyfikaty liścia wystawione przez R1 nie będą go obejmować.

Czy to oznacza, że wszystkie certyfikaty wydane po 15 czerwca 2026 r. Są nieważne?

Nie. Certyfikaty wystawione przed 15 czerwca 2026 r., Które zawierają atrybut clientAuth, zachowują ważność (do wygaśnięcia) w ramach istniejącego modelu zaufania. Zmiana dotyczy tylko nowych certyfikatów publicznych wydanych w tym dniu lub później.

Jeśli używam certyfikatu tylko dla typowego protokołu HTTPS (uwierzytelniania serwera), czy muszę coś robić?

Jeśli Twój hosting jest spoza GoDaddy, nadal musisz upewnić się, że pakiet jest prawidłowo używany.

Czym właściwie jest „uwierzytelnianie klienta” w tym kontekście?

Uwierzytelnianie klienta oznacza użycie certyfikatu przez klienta (użytkownika, urządzenie lub inny serwer) w celu uwierzytelnienia na serwerze. Jest to powszechnie używane w uwierzytelnianiu mTLS (wzajemny TLS) lub uwierzytelnianiu między serwerami za pomocą interfejsu API, w przypadku których serwer musi zweryfikować certyfikat przedstawiony przez łączącego się klienta.

Czy nadal mogę w ogóle używać certyfikatów clientAuth?

Tak & mdash; ale aby uzyskać zaufanie publiczne, musisz użyć certyfikatu wystawionego specjalnie na potrzeby uwierzytelniania klienta (czyli dedykowanego klienta Auth EKU) lub użyć prywatnego ośrodka certyfikacji dla systemów wewnętrznych. Certyfikaty serwerów publicznych z klientem Auth EKU nie będą już zaufane w przeglądarce Chrome, jeśli zostały wydane po 15 czerwca 2026 r.

Czy inne przeglądarki wymuszą tę zmianę, czy tylko Chrome?

Zasady te pochodzą z głównego programu Chrome, ale zmiany w publicznym ekosystemie kluczy publicznych często mają wpływ na inne przeglądarki i sklepy zaufania. Rozsądnie jest założyć, że szersze zastosowanie lub przynajmniej zgodność z przepisami będzie mieć znaczenie dla wszystkich platform.

Czy dotyczy to wewnętrznych/prywatnych certyfikatów CA?

Nie & mdash; zmiana dotyczy tylko publicznie zaufanych certyfikatów SSL/TLS (zaufanych w publicznych magazynach głównych). Nie ma to bezpośredniego wpływu na infrastrukturę prywatnego urzędu certyfikacji używaną do uwierzytelniania wewnętrznego klienta.

Kiedy musimy być gotowi na tę zmianę?

Docelowy harmonogram to 27 maja 2026 r. Do tego czasu odpowiedzialne zespoły powinny przeprowadzić weryfikację gotowości (konfiguracja wydań, poprawność pakietów/pobierania, wskazówki dotyczące instalacji w łańcuchu wdrożeń, monitorowanie i kontrole zależności EKU), aby wdrożenie mogło przebiegać bez zakłóceń w świadczeniu usług.

Więcej informacji

• Konfiguracja i instalacja certyfikatu SSL
• Jeśli Ty lub Twoi klienci widzicie „niezaufany katalog główny” lub błędy łańcucha certyfikatów, zobacz nasze kroki, aby rozwiązać problem .