Applies to: SSL-certifikater

SSL-certifikater Help

We tried our best to translate this page for you. The English page is also available.

Hvorfor fjerner GoDaddy ClientAuth EKU og går over til R1 -rodhierarkiet for DV TLS -udstedelse?

Bemærk: Hvis du eller dine kunder ser fejlen "ikke -tillid til rod" eller certifikatkæde, skal du læse vores trin for at løse problemet .

Fra den 15. juni 2026 har offentligt tillid til SSL/TLS -certifikater, der er udstedt til serverbrug, ikke længere tilladelse til at medtage brugen af "Client Authentication" (EKU: clientAuth). Her er de vigtigste punkter at forstå:

  • Ændringen er en del af opdateringen af politik for Chrome -rodprogram: Nye certifikater må kun indeholde EKU'en "Servergodkendelse".
  • Nye offentlige certifikater, der er udstedt efter den dato, og som inkluderer clientAuth, har ikke tillid fra Chrome.
  • Certifikater udstedt med clientAuth før den 15. juni 2026 påvirkes ikke af denne ændring og forbliver gyldige, indtil de udløber eller tilbagekaldes.
  • Private CA-certifikater (til intern brug) påvirkes ikke af denne ændring & mdash; den gælder kun for offentligt tillidte certifikater.

Kort fortalt: Hvis din organisation bruger offentlige TLS -certifikater til klientgodkendelse (via clientAuth EKU), skal du handle inden den 15. juni 2026 . For standard -TLS -brug (kun servergodkendelse) kræver denne ændring ikke nogen handling. Det er dog en påmindelse i tide om at gennemgå dit brugscertifikat, adskille funktioner korrekt og sikre, at du er tilpasset den udviklende tillidsmodel.

Hvordan GoDaddy implementerer denne ændring

Vores nuværende mellemliggende mellemliggende G2 -signering/udstedelse har ikke nogen EKU, hvilket gør dette hierarki ikke i overensstemmelse med kravene i Chrome Root Program. Som et resultat skal udstedelse fra de berørte G2 -mellemprodukter stoppe inden den dato.

I stedet for at oprette nye mellemprodukter i G2 -kæden & mdash; som er planlagt udløbet/afsluttet med Google i april 2027 & mdash; vi flytter DV -udstedelse til vores nye R1 -hierarki for at leve op til de politiske begrænsninger fremover.

Vi ændrer den offentlige DV -udstedelseskæde, så nye DV -bladcertifikater udstedes fra GoDaddy TLS Root CA - R1 -hierarkiet ved brug af GoDaddy TLS Intermediate CA DV - R1v1, der udsteder CA -certifikater.godaddy.com. Dette betyder, at udstederkæden, som præsenteres af servere (blad + mellemliggende), kan adskille sig fra, hvad nogle systemer historisk set har set, og ethvert internt værktøj, som antager et specifikt ældre mellemnavn eller kæderækkefølge skal opdateres for at acceptere den nye R1 -kæde.

Desuden indeholder bladcertifikater, der er udstedt fra dette hierarki, ikke ClientAuth EKU. Enhver arbejdsgang, der er afhængig af, at DV -bladcertifikater kan bruges til TLS -klientgodkendelse, skal migrere til en passende certifikatprofil/PKI -sti. Under udrulningen forbliver certifikater operationelle i browsere, fordi klienter validerer ved hjælp af den påkrævede R1 → G2-krydssignerede tillidsti, der er offentliggjort i vores lager (certs.godaddy.com).

Sådan forbliver certifikater browser-operationelle under overgangen til R1 (R1 → G2 krydssignal)

Når vi migrerer offentlig DV TLS -udstedelse til R1 -hierarkiet, er R1 -rod stadig i færd med at have bred tillid/distribution i browser- og OS -tillidsbutikker. For at sikre, at nyudstedte R1-certifikater fungerer med det samme i browsere, er vi afhængige af en krydssigneret tillidssti tilbage til den allerede pålidelige G2-rod.

Rent praktisk er bladcertifikatet udstedt under udstedelsescertifikatet R1 DV, men klienter validerer det ved at bygge en kæde til GoDaddy klasse 2 rod - G2 ved hjælp af det udgivne krydscertifikat R1 → G2. De relevante artefakter i arkivet er G2-tillidsanker (gdroot-g2), krydscertifikatet (gd_tls_root-r1-cross-g2), det R1 DV-udstedende mellemprodukt (gd_tls_issuing_dv-r1v1) og den oprindelige hierarkirot (gd_tls_root-r1 ) certs.godaddy.com. Denne kryds-tegn-tilgang gør det muligt for browsere at validere kæden i dag (forankring på G2), mens tillid fra R1 spredes over tid.
r1 - g2 krydsskiltsti

Hvorfor foretages denne ændring?

Der er flere grunde til at flytte væk fra certifikater, der understøtter både serverAuth og clientAuth (også kendt som blandede certifikater):

  • Adskillelse af servergodkendelse fra klientgodkendelse hjælper med at forenkle certifikatets tillidsmodel.
  • Forbedret sikkerhedshygiejne: Certifikater med for mange formål øger risikoen (dvs. misbrug af clientAuth på utilsigtede måder).
  • Brug af dedikerede PKI -hierarkier til forskellige funktioner hjælper med at opretholde klarere tillidsgrænser og tilpasser sig bredere PKI (Public Key Infrastructure) bedste praksis.

Hvad er fordelene ved denne ændring?

  • Reduceret risiko fra MP-certifikater: Ved at begrænse offentlige certifikater til kun serverAuth bliver angrebsoverfladen reduceret, og tillidsgrænser er tydeligere.
  • Bedre overholdelse & styring: Organisationer har en klarere adskillelse mellem servergodkendelse og klientgodkendelse, hvilket kan understøtte bedre revision og certifikatets livscyklusadministration.
  • Forbedret operationel klarhed: Når clientAuth -funktionalitet er adskilt i passende certifikater eller infrastruktur, er det lettere at administrere roller, tilbagekaldelser, fornyelser og sikre, at det rigtige certifikat bruges til det rigtige formål.
  • Fremtidens beredskab: Denne ændring stemmer overens med udviklende PKI / browser -tillidsmodeller og hjælper med at placere organisationer for nyere sikkerhedsmodeller og automatisering.

Hvem er ikke berørt?

De fleste hjemmesider, der kun bruger certifikater til servergodkendelse (dvs. typisk TLS/HTTPS), er ikke påvirket. Hvis du kun bruger certifikatet til at beskytte dit website for brugere, kræver denne ændring ikke nogen handling.

Hvem er berørt?

Denne ændring påvirker organisationer, der bruger offentligt tillid til servercertifikater til klientgodkendelse (også kendt som gensidig TLS / mTLS) eller server-til-server-godkendelse, der er afhængige af clientAuth EKU. For eksempel kan visse finansielle tjenester, SaaS-tjenester eller multi-tenant API'er blive påvirket af denne ændring.

Hvad skal du gøre?

  • Hvis du hostes uden for GoDaddy : Sørg for, at den fulde pakke, der leveres af download -slutpunkterne eller kundegrænsefladen, installeres, når du opdaterer dit næste certifikat.
  • Hvis du bruger certifikater i enhver brugssag, der er afhængige af ClientAuth (mTLS) : Sørg for, at du migrerer disse arbejdsgange til at bruge et selvsigneret certifikat eller en privat CA-løsning.

Teams bør også bekræfte, at ingen intern funktion eller dokumentation forudsætter, at DV-bladcertifikater inkluderer ClientAuth EKU, da R1-udstedte bladcertifikater ikke vil inkludere det.

Betyder det, at alle certifikater, der er udstedt efter den 15. juni 2026, er ugyldige?

Nej. Certifikater udstedt inden den 15. juni 2026, som inkluderer clientAuth, forbliver gyldige (indtil udløb) i henhold til den nuværende tillidsmodel. Ændringen påvirker kun nye offentlige certifikater, der er udstedt på eller efter denne dato.

Hvis jeg kun bruger mit certifikat til typisk website -HTTPS (servergodkendelse), skal jeg så gøre noget?

Hvis din hosting er uden for GoDaddy, skal du stadig sikre dig, at pakken bruges korrekt.

Hvad er egentlig "klientgodkendelse" i denne sammenhæng?

Klientgodkendelse refererer til brugen af et certifikat fra en klient (bruger, enhed eller en anden server) til at godkende til serveren. Det bruges almindeligvis i mTLS (gensidig TLS) eller server-til-server API-godkendelse, hvor serveren skal bekræfte certifikatet, der præsenteres af den tilsluttende klient.

Kan jeg overhovedet bruge clientAuth -certifikater?

Ja & mdash; men for offentlig tillid skal du bruge et certifikat, der er specifikt udstedt til klientgodkendelse (dvs. dedikeret clientAuth EKU) eller bruge en privat CA til dine interne systemer. Offentlige servercertifikater med clientAuth EKU har ikke længere tillid til i Chrome, hvis de udstedes efter den 15. juni 2026.

Vil andre browsere håndhæve denne ændring eller bare Chrome?

Politik kommer fra Chrome Root -programmet, men ændringer i det offentlige PKI -økosystem påvirker ofte andre browsere og tillidsbutikker. Det er klogt at antage en bredere anvendelighed, eller i det mindste at fremtidig overholdelse vil have betydning på tværs af platforme.

Gælder dette for interne/private CA -certifikater?

Nej & mdash; ændringen påvirker kun offentligt tillid til SSL/TLS-certifikater (certifikater, der er tillid fra de offentlige rodbutikker). Privat CA -infrastruktur, der anvendes til intern klientgodkendelse, påvirkes ikke direkte.

Hvornår skal vi være klar til denne ændring?

Måltidslinjen er den 27. maj 2026. På denne dato skulle ansvarlige teams have gennemført beredskabsvalideringen (udstedelseskonfiguration, korrektion af pakke/download, installationsvejledning til installationskæde, overvågning og EKU -afhængighedskontrol), så implementeringen kan fortsætte uden afbrydelser i tjenesten.

Flere oplysninger