GoDaddy DV TLS düzenlemesi için ClientAuth EKU’yu kaldırıp R1 kök hiyerarşisine neden geçiş yapıyor?

15 Haziran 2026 tarihinden itibaren, sunucu kullanımı için verilen genel güvenilen SSL / TLS sertifikalarının “İstemci Kimlik Doğrulaması” (EKU: clientAuth) genişletilmiş anahtar kullanımını içermesine artık izin verilmeyecektir. İşte anlaşılması gereken temel noktalar:

• Değişiklik, Chrome Kök Programı politika güncellemesinin bir parçasıdır: yeni sertifikalar yalnızca “Sunucu Kimlik Doğrulaması” EKU'sunu içermelidir.
• Bu tarihten sonra yayınlanan ve clientAuth içeren yeni genel sertifikalara Chrome tarafından güvenilmez.
• 15 Haziran 2026 tarihinden önce clientAuth ile verilen sertifikalar bu değişiklikten etkilenmeyecek ve süreleri dolana ya da iptal edilene kadar geçerliliğini koruyacaktır.
• Özel CA sertifikaları (dahili kullanım için) bu değişiklikten etkilenmez & mdash; yalnızca genel olarak güvenilen sertifikalar için geçerlidir.

Kısaca: Kuruluşunuz istemci kimlik doğrulaması için genel TLS sertifikaları kullanıyorsa (clientAuth EKU aracılığıyla), 15 Haziran 2026'dan önce harekete geçmeniz gerekir. Standart web sitesi TLS kullanımı için (yalnızca sunucu kimlik doğrulaması), bu değişiklik eylemi gerektirmez. Ancak kullanım sertifikanızı incelemeniz, işlevleri uygun şekilde ayırmanız ve gelişen güven modeliyle uyumlu olduğunuzdan emin olmanız için zamanında bir hatırlatmadır.

GoDaddy bu değişikliği nasıl uygulayacak?

Geçerli G2 imzalama / düzenleme ara ürünlerimizde listelenen herhangi bir EKU yok, bu da bu hiyerarşiyi Chrome Kök Programı gerekliliğiyle uyumlu hale getiriyor. Sonuç olarak, etkilenen G2 ara ürünlerinin ihracı bu tarihe kadar durdurulmalıdır.

Nisan 2027’de Google’da süresi dolması / sona ermesi planlanan G2 zincirinde & mdash; yeni veren ara ürünler oluşturmak yerine, ileriye yönelik politika kısıtlamalarını karşılamak için DV verme işlemini yeni R1 hiyerarşimize taşıyacağız.

Ortak DV düzenleme zincirini değiştirerek, GoDaddy TLS Kök CA - R1 hiyerarşisinden CA certs.godaddy.com veren GoDaddy TLS Intermediate CA DV - R1v1 kullanılarak düzenlenir. Bu, sunucular tarafından sunulan yayıncı zincirinin (yaprak + ara ürün), bazı sistemlerin geçmişte gördüklerinden farklı olabileceği ve belirli bir eski ara ad veya zincir siparişini varsayan tüm dahili araçların yeni R1 zincirini kabul edecek şekilde güncellenmesi gerektiği anlamına gelir.

Ayrıca, bu hiyerarşiden yayınlanan yaprak sertifikalar ClientAuth EKU içermeyecektir. TLS istemci kimlik doğrulaması için kullanılabilir olan DV yaprak sertifikalarına dayanan tüm iş akışları, uygun bir sertifika profiline / PKI yoluna taşınmalıdır. Sunum sırasında, istemciler depomuzda yayınlanan zorunlu R1 → G2 çapraz imzalı güven yolunu (certs.godaddy.com) kullanarak doğruladığı için sertifikalar tarayıcılarda işlevsel kalır.

R1 geçişi sırasında sertifikalar tarayıcıda nasıl çalışır? (R1 → G2 çapraz imzalama)

Herkese açık DV TLS düzenlenmesini R1 hiyerarşisine geçirirken, R1 kökü hâlâ geniş ölçüde güvenilir olma / tarayıcı ve işletim sistemi güven depolarında dağıtılma sürecindedir. Yeni yayınlanan R1 sertifikalarının tarayıcılarda hemen çalışmasını sağlamak için, önceden güvenilen G2 köküne geri dönmek için çapraz imzalı bir güven yolunu kullanıyoruz.

Pratik açıdan, yaprak sertifika R1 DV düzenleyen CA altında düzenlenir, ancak müşteriler yayınlanan R1 → G2 çapraz sertifikasını kullanarak GoDaddy Sınıf 2 Kök - G2'ye bir zincir oluşturarak sertifikayı doğrular. Depodaki ilgili yapılar, G2 güven bağlantısı (gdroot-g2), çapraz sertifika (gd_tls_root-r1-cross-g2), R1 DV yayınlama aracı (gd_tls_issuing_dv-r1v1) ve yerel hiyerarşi köküdür (gd_tls_root-r1 ) certs.godaddy.com. Bu çapraz işaret yaklaşımı, R1 güveni zaman içinde yayılırken, tarayıcıların zinciri bugün doğrulamasına olanak tanır (G2'de sabitleme).

Bu değişiklik neden yapılıyor?

Hem serverAuth hem de clientAuth destekleyen sertifikalardan (karma amaçlı sertifikalar olarak da bilinir) ayrılmanın birkaç nedeni vardır:

• Sunucu kimlik doğrulamasını istemci kimlik doğrulamasından ayırmak, sertifika güven modelini basitleştirmeye yardımcı olur.
• Gelişmiş güvenlik hijyeni: Çok fazla amaca yönelik sertifikalar riski artırır (yani, clientAuth'un istenmeyen şekillerde kötüye kullanılması).
• Farklı işlevler için adanmış PKI hiyerarşilerinin kullanılması, daha geniş PKI (Açık Anahtar Altyapısı) en iyi uygulamalarıyla uyumlu olarak daha açık güven sınırlarının korunmasına yardımcı olur.

Bu değişikliğin faydaları nelerdir?

• Çok amaçlı sertifikalardan daha az risk: Genel sertifikalar yalnızca serverAuth ile sınırlandırılarak, saldırı yüzeyi azaltılır ve güven sınırları daha net hale gelir.
• Daha iyi uyumluluk & Yönetişim: Kuruluşlar, sunucu kimlik doğrulaması ve istemci kimlik doğrulaması arasında daha net bir ayrıma sahip olacak ve bu da daha iyi bir denetim ve sertifika yaşam döngüsü yönetimini destekleyebilecek.
• Gelişmiş operasyonel netlik: clientAuth işlevi uygun sertifikalara veya altyapıya ayrıldığında rolleri, iptalleri, yenilemeleri yönetmek ve doğru sertifikanın doğru amaç için kullanıldığından emin olmak daha kolaydır.
• Geleceğe hazırlık: Bu değişiklik, gelişen PKI / tarayıcı güven modelleriyle uyumludur ve kuruluşların daha yeni güvenlik modelleri ve otomasyon için konumlandırılmasına yardımcı olur.

Kim etkilenmez?

Sertifikaları yalnızca sunucu kimlik doğrulaması için (yani tipik TLS / HTTPS) kullanan çoğu web sitesi etkilenmez. Sertifikayı yalnızca web sitenizin güvenliğini sağlamak için kullanıyorsanız, bu değişiklik eylemi gerektirmez.

Kimler etkilenecek?

Bu değişiklik, istemci kimlik doğrulaması (karşılıklı TLS / mTLS olarak da bilinir) veya clientAuth EKU'ya dayanan sunucudan sunucuya kimlik doğrulaması için genel olarak güvenilen sunucu sertifikalarını kullanan kuruluşları etkiler. Örneğin bazı finansal hizmetler, SaaS hizmetleri veya çok kiracılı API'ler bu değişiklikten etkilenebilir.

Yapmanız gerekenler

• GoDaddy dışında barındırılıyorsanız : Bir sonraki sertifikanızı güncellerken, indirme uç noktaları veya müşteri arayüzü tarafından sağlanan tam paketin yüklendiğinden emin olun.
• Herhangi bir kullanım durumunda ClientAuth (mTLS) tabanlı sertifikalar kullanıyorsanız : Kendinden imzalı bir sertifika veya özel CA çözümü kullanmak için bu iş akışlarını taşıdığınızdan emin olun.

R1 tarafından verilen yaprak sertifikalar dahil edilmeyeceği için, ekipler hiçbir dahili özelliğin veya belgenin DV yaprak sertifikalarının ClientAuth EKU içermediğini de doğrulamalıdır.

Bu, 15 Haziran 2026 tarihinden sonra düzenlenen tüm sertifikaların geçersiz olduğu anlamına mı gelir?

Hayır. 15 Haziran 2026 tarihinden önce düzenlenen ve clientAuth içeren sertifikalar, mevcut güven modeli kapsamında (süresi dolana kadar) geçerlidir. Değişiklik yalnızca bu tarihte veya daha sonra düzenlenen yeni genel sertifikaları etkiler.

Sertifikamı yalnızca tipik web sitesi HTTPS (sunucu kimlik doğrulaması) için kullanıyorsam herhangi bir şey yapmam gerekir mi?

Hosting’iniz GoDaddy dışındaysa, paketin doğru bir şekilde kullanıldığından emin olmanız gerekir.

Bu bağlamda “istemci kimlik doğrulaması” tam olarak nedir?

İstemci kimlik doğrulaması, bir sertifikanın bir istemci (kullanıcı, cihaz veya başka bir sunucu) tarafından sunucuda kimlik doğrulaması için kullanılmasını ifade eder. Genellikle mTLS (karşılıklı TLS) veya sunucunun bağlanan istemci tarafından sunulan sertifikayı doğrulaması gereken sunucudan sunucuya API kimlik doğrulamasında kullanılır.

Yine de clientAuth sertifikalarını kullanabilir miyim?

Evet & mdash; ancak genel güven için istemci kimlik doğrulaması için özel olarak düzenlenmiş bir sertifika (yani, adanmış clientAuth EKU) kullanmanız veya dahili sistemleriniz için özel bir CA kullanmanız gerekir. ClientAuth EKU ile genel sunucu sertifikaları, 15 Haziran 2026 tarihinden sonra verilirse Chrome'da artık güvenilir olmayacaktır.

Bu değişikliği diğer tarayıcılar mı uygular yoksa yalnızca Chrome mu?

Politika, Chrome Kök Programından kaynaklanır, ancak genel PKI ekosistemindeki değişiklikler genellikle diğer tarayıcıları ve güven mağazalarını etkiler. Daha geniş bir uygulanabilirlik olduğunu veya en azından gelecekteki uyumluluğun platformlar arasında önemli olacağını varsaymak akıllıca olacaktır.

Bu dahili / özel CA sertifikaları için geçerli mi?

Hayır & mdash; değişiklik yalnızca genel olarak güvenilen SSL / TLS sertifikalarını (genel kök depoların güvendiği sertifikaları) etkiler. Dahili istemci kimlik doğrulaması için kullanılan özel CA altyapısı doğrudan etkilenmez.

Bu değişikliğe ne zaman hazır olmamız gerekiyor?

Hedef zaman çizelgesi 27 Mayıs 2026'dır. Sunumun hizmet kesintisi olmadan devam edebilmesi için sorumlu ekiplerin bu tarihe kadar hazır olma doğrulamasını tamamlamış olması gerekir (düzenleme yapılandırması, paket / indirme doğruluğu, dağıtım zinciri kurulum kılavuzu, izleme ve EKU bağımlılık kontrolleri).

Daha fazla bilgi

• SSL sertifikası kurma ve yükleme
• Siz veya müşterileriniz "güvenilmeyen kök" veya sertifika zinciri hataları görüyorsanız, sorunu çözmek için adımlarımıza bakın.