Applies to: SSL-sertifikater

SSL-sertifikater 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 -rothierarkiet for DV TLS -utstedelse?

Merk: Hvis du eller kundene dine ser feilmeldinger "ikke -klarert rot" eller sertifikatkjede -feil, kan du se trinnene for å rette problemet .

Fra og med 15. juni 2026 vil offentlig pålitelige SSL/TLS -sertifikater utstedt for serverbruk ikke lenger ha lov til å inkludere utvidelsen til "Client Authentication" (EKU: clientAuth). Her er de viktigste punktene du må forstå:

  • Endringen er en del av oppdateringen av retningslinjene for Chrome -rotprogram: nye sertifikater må bare inkludere «Server Authentication» -EKU.
  • Nye offentlige sertifikater utstedt etter den datoen som inkluderer clientAuth, vil ikke være klarert av Chrome.
  • Sertifikater utstedt med clientAuth før 15. juni 2026 påvirkes ikke av denne endringen, og vil være gyldige til de utløper eller blir tilbakekalt.
  • Private CA-sertifikater (for internt bruk) blir ikke påvirket av denne endringen & mdash; den gjelder kun for offentlig klarerte sertifikater.

Kort sagt: Hvis organisasjonen din bruker offentlige TLS -sertifikater for klientautentisering (via clientAuth EKU), må du handle før 15. juni 2026 . For standard nettsted -TLS -bruk (kun serverautentisering) krever ikke denne endringen handling. Det er imidlertid en betimelig påminnelse om å gjennomgå brukssertifikatet ditt, skille funksjonene på riktig måte, og sørge for at du er i samsvar med den utviklende tillitsmodellen.

Hvordan GoDaddy vil implementere denne endringen

Våre nåværende mellomledninger for G2 -signering/-utstedelse har ingen EKU oppført, noe som gjør dette hierarkiet i samsvar med Chrome Root Program -kravet. Som et resultat må utstedelse fra de berørte G2 -mellomproduktene stoppe innen den datoen.

I stedet for å opprette nye mellomprodukter i G2 -kjeden & mdash; som er planlagt utløpt/avsluttet med Google i april 2027 & mdash; flytter vi DV -utstedelse til vårt nye R1 -hierarki for å oppfylle retningslinjebegrensningene fremover.

Vi endrer den offentlige DV -utstedelseskjeden, slik at nye DV -sertifikater utstedes fra GoDaddy TLS Root CA - R1 -hierarkiet, ved å bruke GoDaddy TLS Intermediate CA DV - R1v1 som utsteder CA -sertifikater.godaddy.com. Dette betyr at utstederkjeden presentert av servere (blad + mellomliggende) kan være forskjellig fra det som noen systemer tidligere har sett, og alle interne verktøy som forutsetter et spesifikt eldre mellomliggende navn eller kjedeordre må oppdateres for å godta den nye R1 -kjeden.

I tillegg vil bladsertifikater utstedt fra dette hierarkiet ikke inneholde ClientAuth EKU. Enhver arbeidsflyt som stolte på at DV -bladsertifikater kunne brukes for TLS -klientautentisering, må overføres til en passende sertifikatprofil/PKI -bane. Under utrullingen forblir sertifikatene i nettlesere fordi klienter validerer ved hjelp av den påkrevde R1 → G2-kryssignerte tillitsbanen som er publisert i oppbevaringsstedet vårt (certs.godaddy.com).

Hvordan sertifikater forblir nettleseroperative under R1-overgangen (R1 → G2-kryssskilt)

Når vi overfører offentlig DV TLS -utstedelse til R1 -hierarkiet, er R1 -roten fortsatt i ferd med å bli bredt klarert/distribuert i nettleser- og OS -tillitsbutikker. For å sikre at nylig utstedte R1-sertifikater fungerer umiddelbart i nettlesere, er vi avhengige av en kryssignert tillitsbane tilbake til den allerede klarerte G2-roten.

Rent praktisk er bladsertifikatet utstedt under R1 DV -utstedende CA, men klienter validerer det ved å bygge en kjede til GoDaddy klasse 2 -rot - G2 med det publiserte kryssertifikatet R1 → G2. De relevante gjenstandene i oppbevaringsstedet er G2-tillitsankeret (gdroot-g2), kryssertifikatet (gd_tls_root-r1-cross-g2), R1 DV-utstedende mellomliggende (gd_tls_issuing_dv-r1v1), og den opprinnelige hierarkiroten (gd_tls_root-r1 ) certs.godaddy.com. Denne kryssskilttilnærmingen lar nettlesere validere kjeden i dag (forankring på G2), mens R1-tillit forplantes over tid.
r1 - g2 kryssskiltbane

Hvorfor gjøres denne endringen?

Det er flere grunner til å flytte vekk fra sertifikater som støtter både serverAuth og clientAuth (også kjent som blandede sertifikater):

  • Å skille serverautentisering fra klientgodkjenning bidrar til å forenkle sertifikatmodellen.
  • Forbedret sikkerhetshygiene: Sertifikater med for mange formål øker risikoen (det vil si misbruk av clientAuth på utilsiktede måter).
  • Å bruke dedikerte PKI -hierarkier for forskjellige funksjoner bidrar til å opprettholde klarere tillitsgrenser, og tilpasse seg til bredere praksis for PKI (Public Key Infrastructure).

Hva er fordelene med denne endringen?

  • Redusert risiko fra flerbrukssertifikater: Ved å begrense offentlige sertifikater til kun serverAuth, blir angrepsoverflaten redusert, og tillitsgrenser er tydeligere.
  • Bedre samsvar & styring: Organisasjoner vil ha klarere skille mellom serverautentisering og klientautentisering, noe som kan støtte bedre revisjon og sertifikatets livssyklusadministrasjon.
  • Forbedret klarhet i driften: Når clientAuth -funksjonaliteten skilles ut i passende sertifikater eller infrastruktur, er det lettere å administrere roller, tilbakekallinger, fornyelser og sikre at riktig sertifikat brukes til riktig formål.
  • Fremtidig beredskap: Denne endringen er i samsvar med utviklende PKI / nettlesertillitsmodeller og hjelper med å plassere organisasjoner for nyere sikkerhetsmodeller og automatisering.

Hvem blir ikke berørt?

De fleste nettsteder som kun bruker sertifikater for serverautentisering (det vil si typisk TLS/HTTPS), blir ikke påvirket. Hvis du bare bruker sertifikatet for å sikre nettstedet ditt for brukere, krever ikke denne endringen handling.

Hvem er berørt?

Denne endringen påvirker organisasjoner som bruker serversertifikater som er offentlig klarert for klientautentisering (også kjent som gjensidig TLS / mTLS) eller server-til-server-autentisering som er avhengige av clientAuth EKU. For eksempel kan noen finanstjenester, SaaS-tjenester eller API-er for flere leiere påvirkes av denne endringen.

Hva du trenger å gjøre

  • Hvis du er vert utenfor GoDaddy : Sørg for at hele pakken som tilbys fra nedlastingsendepunktene eller kundegrensesnittet installeres når du oppdaterer ditt neste sertifikat.
  • Hvis du bruker sertifikater i en hvilken som helst brukssak som er avhengig av ClientAuth (mTLS) : Sørg for at du overfører disse arbeidsflytene til å bruke et selvsignert sertifikat eller en privat CA-løsning.

Teamene bør også bekrefte at ingen intern funksjon eller dokumentasjon forutsetter at DV-bladsertifikater inkluderer ClientAuth EKU, siden R1-utstedte bladsertifikater ikke vil inkludere det.

Betyr dette at alle sertifikater utstedt etter 15. juni 2026 er ugyldige?

Nei. Sertifikater utstedt før 15. juni 2026, som inkluderer clientAuth, forblir gyldige (til utløpsdatoen) i henhold til den eksisterende tillitsmodellen. Endringen påvirker bare nye offentlige sertifikater utstedt på eller etter denne datoen.

Hvis jeg bare bruker sertifikatet mitt for typisk HTTPS (serverautentisering) på nettstedet, må jeg da gjøre noe?

Hvis hosting er utenfor GoDaddy, må du fremdeles sørge for at pakken blir brukt riktig.

Hva er egentlig «klientautentisering» i denne sammenhengen?

Klientautentisering refererer til bruk av et sertifikat av en klient (bruker, enhet eller en annen server) for å autentisere til serveren. Det brukes ofte i mTLS (gjensidig TLS) eller server-til-server API-autentisering, der serveren trenger å bekrefte sertifikatet presentert av den tilkoblende klienten.

Kan jeg fremdeles bruke clientAuth -sertifikater?

Ja & mdash; men for offentlig tillit må du bruke et sertifikat spesifikt utstedt for klientautentisering (det vil si dedikert clientAuth EKU) eller bruke en privat CA for dine interne systemer. Offentlige serversertifikater med clientAuth EKU vil ikke lenger være klarert i Chrome hvis de utstedes etter 15. juni 2026.

Vil andre nettlesere håndheve denne endringen eller bare Chrome?

Retningslinjene kommer fra Chrome Root Program, men endringer i det offentlige PKI -økosystemet påvirker ofte andre nettlesere og tillitsbutikker. Det er lurt å anta bredere anvendelighet, eller i det minste at fremtidig samsvar vil ha betydning på tvers av plattformene.

Gjelder dette interne/private CA -sertifikater?

Ingen & mdash; endringen påvirker kun offentlig pålitelige SSL/TLS-sertifikater (de som er klarert av de offentlige rotbutikkene). Privat CA -infrastruktur som brukes for intern klientautentisering blir ikke direkte påvirket.

Når trenger vi å være klar for denne endringen?

Måletidslinjen er 27. mai 2026. Ansvarlige team skal innen denne datoen ha fullført beredskapsvalidering (konfigurasjon av utstedelse, korrekte pakke-/nedlastingsveiledninger, installasjonsveiledning for distribusjonskjeden, overvåking og EKU -avhengighetskontroll), slik at utrullingen kan fortsette uten tjenesteforstyrrelser.

Mer informasjon