Applies to: Sertifikat SSL

Sertifikat SSL Bantuan

Kami berusaha sebaik mungkin menerjemahkan halaman ini untuk Anda. Halaman juga tersedia dalam bahasa Inggris.

Mengapa GoDaddy menghapus ClientAuth EKU dan melakukan transisi ke hierarki akar R1 untuk penerbitan DV TLS?

Catatan: Jika Anda atau pelanggan melihat "akar tidak tepercaya" atau kesalahan rantai sertifikat, lihat langkah-langkah kami untuk memperbaiki masalah tersebut .

Mulai 15 Juni 2026, sertifikat SSL / TLS yang dipercaya secara publik yang diterbitkan untuk penggunaan server tidak akan lagi diizinkan untuk menyertakan penggunaan kunci yang diperpanjang "Otentikasi Klien" (EKU: clientAuth). Berikut adalah poin-poin penting untuk dipahami:

  • Perubahan tersebut adalah bagian dari pembaruan kebijakan Program Akar Chrome: sertifikat baru harus menyertakan hanya EKU "Otentikasi Server".
  • Sertifikat publik baru yang diterbitkan setelah tanggal tersebut yang mencakup clientAuth tidak akan dipercaya oleh Chrome.
  • Sertifikat yang diterbitkan dengan clientAuth sebelum 15 Juni 2026 tidak terpengaruh oleh perubahan ini, dan akan tetap valid hingga kedaluwarsa atau dicabut.
  • Sertifikat CA pribadi (untuk penggunaan internal) tidak terpengaruh oleh perubahan ini & mdash; ini hanya berlaku untuk sertifikat yang dipercaya secara publik.

Singkatnya: jika organisasi Anda menggunakan sertifikat TLS publik untuk otentikasi klien (melalui clientAuth EKU), Anda harus bertindak sebelum 15 Juni 2026 . Untuk penggunaan TLS situs web standar (hanya otentikasi server), perubahan ini tidak memerlukan tindakan. Namun, ini adalah pengingat yang tepat untuk meninjau sertifikat penggunaan Anda, memisahkan fungsi dengan tepat, dan memastikan Anda selaras dengan model kepercayaan yang berkembang.

Bagaimana GoDaddy akan menerapkan perubahan ini

Perantara penandatangan / penerbit G2 kami saat ini tidak memiliki EKU yang terdaftar, yang membuat hierarki tersebut tidak sesuai dengan persyaratan Program Akar Chrome. Akibatnya, penerbitan dari perantara G2 yang terpengaruh harus dihentikan pada tanggal tersebut.

Daripada membuat perantara penerbitan baru pada rantai G2 & mdash; yang rencananya akan kedaluwarsa / diakhiri dengan Google pada April 2027 & mdash; kami memindahkan penerbitan DV ke hierarki R1 baru untuk memenuhi batasan kebijakan di masa mendatang.

Kami mengubah rantai penerbitan DV publik sehingga sertifikat daun DV baru diterbitkan dari hierarki CA Akar TLS GoDaddy - R1, dengan menggunakan sertifikat CA peralihan TLS GoDaddy - R1v1 CA yang menerbitkan sertifikat CA.godaddy.com. Ini berarti rantai penerbit yang disajikan oleh server (perantara + perantara) mungkin berbeda dari apa yang secara historis dilihat oleh beberapa sistem, dan setiap perkakas internal yang mengasumsikan nama perantara atau urutan rantai warisan tertentu harus diperbarui untuk menerima rantai R1 yang baru.

Selain itu, sertifikat daun yang diterbitkan dari hierarki ini tidak akan berisi EKU ClientAuth. Alur kerja apa pun yang mengandalkan sertifikat daun DV yang dapat digunakan untuk otentikasi klien TLS harus bermigrasi ke jalur profil sertifikat / PKI yang sesuai. Selama peluncuran, sertifikat tetap beroperasi di browser karena klien memvalidasi menggunakan jalur kepercayaan bertanda tangan silang R1 → G2 yang dipublikasikan di repositori kami (certs.godaddy.com).

Bagaimana sertifikat tetap dapat dioperasikan oleh browser selama transisi R1 (R1 → tanda silang G2)

Saat kami memigrasi penerbitan DV TLS publik ke hierarki R1, akar R1 masih dalam proses untuk dipercaya / didistribusikan secara luas di penyimpanan kepercayaan browser dan OS. Untuk memastikan sertifikat R1 yang baru diterbitkan dapat langsung berfungsi di browser, kami mengandalkan jalur kepercayaan silang untuk kembali ke akar G2 yang telah dipercaya.

Secara praktis, sertifikat peralihan diterbitkan berdasarkan CA penerbit R1 DV, tetapi klien memvalidasinya dengan membuat rantai ke Akar Kelas 2 GoDaddy - G2 menggunakan sertifikat silang R1 → G2 yang dipublikasikan. Artefak yang relevan dalam repositori adalah jangkar kepercayaan G2 (gdroot-g2), sertifikat silang (gd_tls_root-r1-cross-g2), perantara penerbit DV R1 (gd_tls_issue_dv-r1v1), dan akar hierarki asli (gd_tls_root-r1) ) certs.godaddy.com. Pendekatan tanda silang ini memungkinkan browser memvalidasi rantai saat ini (berlabuh di G2), sementara kepercayaan R1 menyebar seiring waktu.
r1 - g2 jalur tanda silang

Mengapa perubahan ini dilakukan?

Ada beberapa alasan untuk beralih dari sertifikat yang mendukung serverAuth dan clientAuth (juga dikenal sebagai sertifikat tujuan campuran):

  • Memisahkan otentikasi server dari otentikasi klien membantu menyederhanakan model kepercayaan sertifikat.
  • Keamanan yang lebih baik: Sertifikat dengan terlalu banyak tujuan meningkatkan risiko (yaitu, penyalahgunaan clientAuth dengan cara yang tidak disengaja).
  • Menggunakan hierarki PKI khusus untuk fungsi berbeda membantu mempertahankan batas kepercayaan yang lebih jelas, selaras dengan praktik terbaik PKI (Infrastruktur Kunci Publik) yang lebih luas.

Apa manfaat dari perubahan ini?

  • Pengurangan risiko dari sertifikat multiguna: Dengan membatasi sertifikat publik hanya pada serverAuth, permukaan serangan akan berkurang, dan batas kepercayaan menjadi lebih jelas.
  • Kepatuhan yang lebih baik & tata kelola: Organisasi akan memiliki pemisahan yang lebih jelas antara otentikasi server dan otentikasi klien, yang dapat mendukung audit yang lebih baik dan manajemen siklus hidup sertifikat.
  • Kejelasan operasional yang ditingkatkan: Bila fungsi clientAuth dipisahkan menjadi sertifikat atau infrastruktur yang sesuai, maka akan lebih mudah untuk mengelola peran, pencabutan, perpanjangan, dan memastikan sertifikat yang tepat digunakan untuk tujuan yang benar.
  • Kesiapan di masa mendatang: Perubahan ini sejalan dengan model kepercayaan PKI / browser yang terus berkembang dan membantu memposisikan organisasi untuk model keamanan dan otomatisasi yang lebih baru.

Siapa yang tidak terpengaruh?

Sebagian besar situs web yang menggunakan sertifikat hanya untuk otentikasi server (yakni TLS / HTTPS biasa) tidak terpengaruh. Jika Anda hanya menggunakan sertifikat untuk mengamankan situs web bagi pengguna, perubahan ini tidak memerlukan tindakan.

Siapa yang terpengaruh?

Perubahan ini mempengaruhi organisasi yang menggunakan sertifikat server yang dipercaya secara publik untuk otentikasi klien (juga dikenal sebagai TLS / mTLS bersama) atau otentikasi server-ke-server yang mengandalkan EKU clientAuth. Misalnya, beberapa layanan keuangan, layanan SaaS, atau API multi-tenant mungkin terpengaruh oleh perubahan ini.

Apa yang perlu Anda lakukan

  • Jika Anda dihosting di luar GoDaddy : Pastikan bundel lengkap yang disediakan oleh titik akhir unduhan atau antarmuka pelanggan sedang diinstal saat memperbarui sertifikat Anda berikutnya.
  • Jika Anda menggunakan sertifikat dalam kasus penggunaan apa pun yang mengandalkan ClientAuth (mTLS) : Pastikan Anda memigrasi alur kerja tersebut untuk menggunakan sertifikat yang ditandatangani sendiri atau solusi CA pribadi.

Tim juga harus mengkonfirmasi bahwa tidak ada fitur internal atau dokumentasi yang mengasumsikan sertifikat daun DV menyertakan EKU ClientAuth, karena sertifikat daun yang diterbitkan R1 tidak akan menyertakannya.

Apakah ini berarti semua sertifikat yang diterbitkan setelah 15 Juni 2026 tidak valid?

Tidak. Sertifikat yang diterbitkan sebelum 15 Juni 2026, yang mencakup clientAuth, tetap valid (hingga kedaluwarsa) berdasarkan model kepercayaan yang ada. Perubahan hanya mempengaruhi sertifikat publik baru yang diterbitkan pada atau setelah tanggal tersebut.

Jika saya hanya menggunakan sertifikat untuk HTTPS situs web biasa (otentikasi server), apakah saya perlu melakukan sesuatu?

Jika hosting Anda di luar GoDaddy, Anda masih perlu memastikan bundel digunakan dengan benar.

Apa sebenarnya "otentikasi klien" dalam konteks ini?

Otentikasi klien mengacu pada penggunaan sertifikat oleh klien (pengguna, perangkat atau server lain) untuk mengotentikasi ke server. Ini biasanya digunakan dalam otentikasi API mTLS (mutual TLS) atau server-ke-server di mana server perlu memverifikasi sertifikat yang diberikan oleh klien penghubung.

Apakah saya masih bisa menggunakan sertifikat clientAuth?

Ya & mdash; tetapi untuk kepercayaan publik, Anda perlu menggunakan sertifikat yang secara khusus diterbitkan untuk otentikasi klien (yaitu, clientAuth EKU khusus) atau menggunakan CA pribadi untuk sistem internal Anda. Sertifikat server publik dengan clientAuth EKU tidak akan dipercaya lagi di Chrome jika diterbitkan setelah 15 Juni 2026.

Akankah browser lain memberlakukan perubahan ini atau hanya Chrome?

Kebijakan ini berasal dari Program Akar Chrome, namun perubahan dalam ekosistem PKI publik sering kali memengaruhi browser dan penyimpanan kepercayaan lainnya. Sebaiknya asumsikan penerapan yang lebih luas atau setidaknya kepatuhan di masa mendatang akan menjadi masalah di seluruh platform.

Apakah ini berlaku untuk sertifikat CA internal / pribadi?

Tidak & mdash; perubahan hanya mempengaruhi sertifikat SSL / TLS yang dipercaya secara publik (yang dipercaya oleh penyimpanan akar publik). Infrastruktur CA pribadi yang digunakan untuk otentikasi klien internal tidak terpengaruh secara langsung.

Kapan kita harus siap menghadapi perubahan ini?

Jangka waktu target adalah 27 Mei 2026. Pada tanggal tersebut, tim yang bertanggung jawab seharusnya telah menyelesaikan validasi kesiapan (konfigurasi penerbitan, ketepatan bundel / unduhan, panduan penginstalan rantai penerapan, pemantauan, dan pemeriksaan ketergantungan EKU) sehingga peluncuran dapat dilanjutkan tanpa gangguan layanan.

Info selengkapnya