Pengantar
HTTPS (melalui SSL /TLS) menggunakan enkripsi kunci publik untuk melindungi komunikasi browser agar tidak dibaca atau diubah saat transit melalui Internet. Server memberikan kunci publik kepada browser yang digunakan untuk membuat koneksi terenkripsi untuk semua pertukaran data selanjutnya.
Namun, hanya menerima a kerja kunci publik saja tidak menjamin bahwa itu (dan dengan ekstensi server) memang dimiliki oleh remote yang benar subyek (yaitu, orang, perusahaan, atau organisasi). Man-in-the-middle penyerang dapat memanipulasi jaringan untuk melayani kunci mereka sendiri, sehingga membahayakan komunikasi apa pun.
Browser mencegah hal ini dengan mengautentikasi Server HTTPS menggunakan sertifikat, yang merupakan dokumen digital itu mengikat kunci publik untuk subjek individual. Pengikatan ini ditegaskan dengan memiliki kunci publik tepercaya.otoritas sertifikasi (CA) seperti SSL.com memverifikasi identitas calon pemilik sertifikat, melalui pemeriksaan otomatis dan manual terhadap database yang memenuhi syarat.
Hubungan kepercayaan ini berarti bahwa keamanan pengguna web tidaklah mutlak; melainkan mengharuskan pengguna untuk memercayai peramban dan CA untuk melindungi keamanan mereka. Oleh karena itu, pemahaman dasar tentang cara kerja validasi sertifikat sangatlah penting bagi setiap pengguna.
Perhatikan bahwa proses validasi sertifikat (dijelaskan secara rinci dalam dokumen standar RFC 5280) cukup berbelit-belit. Pada artikel ini kami akan mencoba memandu Anda di sepanjang satu jalur (browser yang memvalidasi SSL /TLS sertifikat) dan menavigasi rincian rumit masa lalu yang tidak penting bagi sebagian besar pengguna.
Catatan: Pada 2024 Agustus, RFC 9618, sebuah dokumen Internet Engineering Task Force (IETF), telah memperbarui algoritma untuk memvalidasi batasan kebijakan dalam sertifikat digital X.509 dari RFC 5280.
Sertifikat dan format X.509
Sertifikat adalah berkas digital dalam segala hal, yang berarti bahwa sertifikat harus mengikuti format berkas untuk menyimpan informasi (misalnya, tanda tangan, kunci, penerbit, dll.). Meskipun bersifat pribadi, PKI konfigurasi dapat menerapkan format apa pun untuk sertifikat mereka, dipercaya secara publik PKIs (yaitu, yang dipercaya oleh browser) harus sesuai dengan RFC 5280, yang mengharuskan penggunaan X.509 v3 Format.
X.509 v3 memungkinkan sertifikat untuk memasukkan data tambahan, seperti batasan penggunaan atau informasi kebijakan, seperti ekstensi, dengan masing-masing ekstensi kritis or tidak kritis. Jika klien menemukan ekstensi non-kritis yang tidak dikenali, klien dapat mengabaikannya. Jika ekstensi tersebut bersifat kritis dan tidak dikenali atau tidak dapat diproses, sertifikat harus ditolak.
Jalur Sertifikasi dan Pemrosesan Jalur
CA menggunakan kunci privat untuk menandatangani semua sertifikat yang diterbitkan secara kriptografis. Tanda tangan semacam itu dapat secara kriptografis membuktikan bahwa sertifikat dikeluarkan oleh CA tertentu dan tidak diubah setelah ditandatangani.
CA menetapkan kepemilikan kunci penandatanganan mereka dengan memegang sertifikat yang diterbitkan sendiri (disebut akar) untuk kunci publik yang sesuai. CA harus mematuhi prosedur yang dikontrol dan diaudit secara ketat untuk membuat, mengelola, dan menggunakan root, dan untuk meminimalkan paparan, mereka biasanya akan menggunakan root untuk menerbitkan menengah sertifikat. Perantara ini kemudian dapat digunakan untuk menerbitkan sertifikat pelanggan mereka. Sertifikat CA root ditandatangani sendiri, dan kunci privatnya dilindungi melalui prosedur yang ketat. Penerbitan biasanya dilakukan melalui perantara, bukan langsung dari root.
Peramban dikirimkan dengan daftar akar tepercaya bawaan. (Ini adalah akar dari CA yang telah melewati kriteria ketat browser untuk penyertaan.) Untuk memverifikasi sertifikat, browser akan mendapatkan urutan sertifikat, masing-masing telah menandatangani sertifikat berikutnya secara berurutan, menghubungkan akar CA yang menandatangani ke server sertifikat.
Urutan sertifikat ini disebut a jalur sertifikasi. Akar jalan ini disebut a percaya pada jangkar dan sertifikat server disebut daun or entitas akhir sertifikat.
Konstruksi Jalur
Seringkali, peramban web dan klien perangkat lunak secara umum dapat membangun beberapa kandidat jangkar kepercayaan (misalnya, karena tanda silang) dan sering mengambil perantara yang hilang melalui AIA untuk melengkapi suatu rantai. Meskipun suatu jalur mungkin berisi sertifikat yang "dirantai" dengan benar ke jangkar yang diketahui, jalur itu sendiri dapat ditolak karena batasan panjang jalur, nama domain, penggunaan sertifikat, atau kebijakan.
Membangun dan mengevaluasi semua jalur yang mungkin adalah proses mahal yang dilakukan untuk setiap sertifikat baru yang ditemukan browser. Peramban telah menerapkan berbagai optimisasi untuk meminimalkan jumlah jalur kandidat yang ditolak, tetapi menyelidiki detail seperti itu jauh di luar cakupan artikel ini.
Validasi Jalur
Setelah jalur sertifikasi kandidat dibuat, browser memvalidasinya menggunakan informasi yang terdapat dalam sertifikat. Sebuah jalur valid jika browser dapat secara kriptografis membuktikan bahwa, mulai dari sertifikat yang secara langsung ditandatangani oleh jangkar kepercayaan, setiap kunci privat yang sesuai dari sertifikat digunakan untuk menerbitkan kunci berikutnya dalam jalur tersebut, hingga sertifikat daun.
Persyaratan Dasar mengharuskan nama Subjek dan Penerbit di seluruh semua jalur yang mungkin be identik byte-per-byte, yang menyederhanakan pembangunan jalur yang andal.
Algoritma Validasi Jalur Sertifikasi
Seperti yang telah disebutkan sebelumnya, per Agustus 2024, RFC 9618, sebuah dokumen Internet Engineering Task Force (IETF), telah memperbarui algoritme untuk memvalidasi batasan kebijakan dalam sertifikat digital X.509 dari RFC 5280. Pada dasarnya, peramban menelusuri semua sertifikat di jalur yang dimulai dengan jangkar kepercayaan (yaitu sertifikat akar), memvalidasi informasi dasar dan ekstensi penting setiap sertifikat.
Jika prosedur diakhiri dengan sertifikat terakhir di jalur tanpa kesalahan, maka jalur diterima sebagai valid. Jika kesalahan dihasilkan, jalur ditandai sebagai tidak valid.
Pemrosesan sertifikat dasar
Terlepas dari ekstensi apa pun, browser harus selalu memverifikasi informasi sertifikat dasar seperti tanda tangan atau penerbit. Bagian berikut menunjukkan urutan pemeriksaan yang dilakukan browser.
1. Browser memverifikasi integritas sertifikat
The tanda tangan pada sertifikat dapat diverifikasi menggunakan kriptografi kunci publik normal. Jika tanda tangan tidak valid, maka sertifikat dianggap dimodifikasi setelah diterbitkan dan karenanya ditolak.
2. Browser memverifikasi validitas sertifikat
Sertifikat masa berlaku adalah interval waktu selama CA penandatanganan menjamin bahwa ia akan mempertahankan informasi tentang statusnya. Peramban menolak semua sertifikat dengan masa berlaku yang berakhir sebelum atau mulai setelah tanggal dan waktu pemeriksaan validasi.
3. Browser memeriksa status pencabutan sertifikat
Ketika sertifikat dikeluarkan, diharapkan akan digunakan untuk seluruh periode validitasnya. Tentu saja, berbagai keadaan dapat menyebabkan sertifikat menjadi tidak valid sebelum berakhir secara alami.
Keadaan seperti itu mungkin termasuk subjek yang mengubah nama mereka atau dugaan penyusupan kunci pribadi mereka. Dalam kasus seperti ini, CA perlu mencabut sertifikat yang sesuai, dan pengguna juga memercayai CA untuk memberi tahu browser tentang status pencabutan sertifikat mereka.
Daftar Pencabutan Sertifikat (CRL)
Daftar Pencabutan Sertifikat (CRL) telah menjadi standar industri untuk pemeriksaan pencabutan sertifikat sejak tahun 2024. CA secara berkala menerbitkan daftar sertifikat yang dicabut yang ditandatangani dan diberi cap waktu yang dapat diunduh dan disimpan dalam cache lokal oleh browser.
Meskipun CRL sebelumnya dianggap kurang efisien dibandingkan metode pemeriksaan waktu nyata, industri telah menyadari keunggulan signifikan yang menjadikannya pendekatan yang disukai:
- Privasi yang Ditingkatkan:CRL melindungi privasi pengguna dengan menghilangkan kebutuhan untuk menanyakan server eksternal tentang sertifikat tertentu, yang dapat mengungkapkan pola penelusuran
- Efisiensi operasional:CA dapat mengelola pencabutan dengan lebih efisien tanpa mempertahankan layanan respons waktu nyata dengan ketersediaan tinggi
- Mengurangi Biaya Infrastruktur:Menghilangkan kebutuhan akan responden OCSP 24/7 secara signifikan mengurangi biaya operasional
- Caching yang Lebih Baik:Browser modern dapat secara efisien menyimpan dan memperbarui CRL, meminimalkan masalah latensi yang sebelumnya lebih disukai metode waktu nyata
Pada Maret 2024, Forum CA/Browser mengharuskan semua CA yang dipercaya publik untuk menyediakan CRL sambil menjadikan metode pencabutan lainnya opsionalBeberapa otoritas sertifikat utama telah menghentikan layanan pencabutan alternatif dan beralih ke pendekatan CRL saja.
Protokol Status Sertifikat Online (OCSP)
Protokol Status Sertifikat Online (OCSP), dijelaskan dalam RFC 6960, dirancang untuk menyediakan pemeriksaan pencabutan sertifikat secara real-time dengan memungkinkan peramban untuk menanyakan server OCSP (responder) tentang sertifikat tertentu. Meskipun OCSP diadopsi secara luas pada tahun 2010-an sebagai penyempurnaan dari pengunduhan CRL berkala, industri sebagian besar telah menjauh dari pendekatan ini.
- OCSP sekarang menjadi opsional bagi CA yang dipercaya publik (berlaku mulai Maret 2024). Pentingnya OCSP adalah menolak; sebagai contoh, Mari Enkripsi menghapus URL OCSP pada bulan Mei 2025 dan menutup responden di Agustus 2025.
- Beberapa browser telah menonaktifkan pemeriksaan OCSP atau menerapkannya dengan cara yang memberikan manfaat keamanan minimal
Stapel OCSP: Varian yang disebut Stapel OCSP tetap berguna dalam beberapa skenario, di mana server menyertakan respons OCSP langsung di TLS jabat tangan, menghindari kueri klien terpisah ke responden OCSP. Namun, hal ini memerlukan konfigurasi server khusus. Stapling didukung oleh sebagian besar server/CDN, tetapi utilitasnya semakin berkurang karena CA besar menarik OCSP.
Bagaimana cara kerjanya saat ini di browser: Sejak 15 Maret 2024, Forum CA/B mewajibkan CA yang dipercaya publik untuk menerbitkan CRL, sementara OCSP bersifat opsional. Peramban modern umumnya tidak meminta OCSP atau mengunduh CRL per situs. Sebaliknya, mereka menggunakan mekanisme agregat yang dibangun dari CRL yang diterbitkan CA: CRLSets Chrome dan CRLite Firefox memberikan data pencabutan yang cepat dan menjaga privasi kepada klien. Akibatnya, peran OCSP di Web publik semakin berkurang; misalnya, Let's Encrypt menghapus URL OCSP pada Mei 2025 dan menutup responden OCSP pada Agustus 2025.
4. Browser memverifikasi penerbit
Sertifikat biasanya dikaitkan dengan dua entitas:
- The penerbit, yang merupakan entitas yang memiliki kunci penandatanganan dan
- The subyek, yang merujuk pada pemilik kunci publik yang diautentikasi sertifikat.
Klien memverifikasi bahwa setiap sertifikat di jalur ditandatangani oleh kunci publik sertifikat sebelumnya dan bahwa nama Penerbit/Subjek sama persis di sepanjang jalur. Untuk keamanan tambahan, sebagian besar PKI Implementasi juga memverifikasi bahwa kunci penerbit sama dengan kunci yang menandatangani sertifikat saat ini. (Perhatikan bahwa hal ini tidak berlaku untuk jangkar kepercayaan, karena root diterbitkan sendiri – artinya, mereka memiliki penerbit dan subjek yang sama.)
Pemrosesan kendala
Format X.509 v3 memungkinkan CA untuk mendefinisikan batasan atau batasan tentang bagaimana setiap sertifikat divalidasi dan digunakan sebagai ekstensi kritis. Setiap sertifikat di jalur dapat mengenakan batasan tambahan yang harus dipatuhi semua sertifikat berikutnya.
Kendala sertifikat jarang mempengaruhi pengguna Internet rata-rata, meskipun mereka cukup umum dalam solusi SSL perusahaan. Kendala fungsional dapat melayani beberapa tujuan operasional, tetapi penggunaannya yang paling signifikan adalah untuk mengurangi masalah keamanan yang diketahui.
5. Browser memeriksa batasan nama
CA perantara milik pribadi (tapi dipercaya publik) dengan yang sesuai batasan nama dapat memberikan organisasi kendali yang sangat ketat atas manajemen dan penerbitan sertifikat. Sertifikat dapat dibatasi pada domain atau pohon domain tertentu (termasuk subdomain) untuk nama domain perusahaan atau organisasi. Pembatasan nama sering digunakan untuk sertifikat CA perantara yang dibeli dari CA tepercaya publik untuk mencegah CA perantara menerbitkan sertifikat yang benar-benar valid untuk domain pihak ketiga (misalnya google.com).
6. Browser memeriksa batasan kebijakan
Kebijakan sertifikat adalah dokumen hukum yang diterbitkan oleh CA, yang secara resmi merinci prosedur yang mereka ikuti untuk mengeluarkan dan mengelola sertifikat mereka. CA dapat mengeluarkan sertifikat di bawah satu atau beberapa kebijakan, dan tautan ke ini disertakan dalam setiap sertifikat yang dikeluarkan sehingga pihak yang bersandar dapat mengevaluasi kebijakan ini sebelum memutuskan untuk mempercayai sertifikat itu.
Untuk alasan hukum dan operasional, sertifikat dapat memberlakukan batasan pada kebijakan mana mereka dapat dikenakan. Jika sertifikat ditemukan mengandung batasan kebijakan penting, browser harus memvalidasinya sebelum melanjutkan. (Namun, kendala kebijakan kritis jarang dijumpai di dunia nyata dan karenanya akan diabaikan selama sisa artikel ini.)
7. Browser memeriksa batasan dasar (alias panjang jalur)
Format X.509 v3 memungkinkan penerbit menentukan panjang jalur maksimum yang dapat didukung sertifikat. Ini memberikan kontrol atas seberapa jauh setiap sertifikat dapat ditempatkan di jalur sertifikasi. Ini sebenarnya penting - browser digunakan untuk mengabaikan panjang jalur sertifikasi sampai seorang peneliti mendemonstrasikannya, pada tahun 2009 presentasi, bagaimana dia menggunakan sertifikat daun situs webnya untuk memalsukan sertifikat yang sah untuk situs web e-dagang besar.
8. Browser memverifikasi penggunaan kunci
Ekstensi “penggunaan kunci” menyatakan tujuan dari kunci yang terdapat dalam sertifikat. Contoh tujuan tersebut termasuk penyandian, tanda tangan, penandatanganan sertifikat, dan sebagainya. Browser menolak sertifikat yang melanggar batasan penggunaan kuncinya, seperti mendapatkan sertifikat server dengan kunci yang dimaksudkan hanya untuk penandatanganan CRL.
9. Browser terus memproses semua ekstensi penting yang tersisa
Setelah memproses ekstensi yang disebutkan di atas, browser melanjutkan untuk memvalidasi semua ekstensi yang tersisa yang ditetapkan oleh sertifikat saat ini sebagai penting, sebelum melanjutkan ke ekstensi berikutnya. Jika browser mencapai sertifikat daun jalur tanpa kesalahan, maka jalur tersebut diterima sebagai valid. Jika ada kesalahan yang dihasilkan, jalur ditandai sebagai tidak valid dan koneksi aman tidak dibuat.
Manajemen Sertifikat Modern: Umur Sertifikat yang Lebih Pendek dan Otomatisasi
SSL /TLS Industri ini telah mengalami beberapa perubahan dalam beberapa tahun terakhir, yang secara fundamental mengubah cara penerbitan dan pengelolaan sertifikat. Memahami perubahan ini sangat penting untuk PKI manajer, profesional TI, dan/atau siapa pun yang bekerja dengan sertifikat digital.
Masa Berlaku Sertifikat Dipersingkat
Pada bulan April 2025, Forum CA/Browser menyetujui keputusan penting (Surat Suara SC-081v3) untuk secara drastis mengurangi masa berlaku sertifikat secara bertahap:
- Saat ini (hingga Maret 2026): Maksimum 398 hari (sekitar 13 bulan)
- 15 Maret, 2026: Maksimal 200 hari
- 15 Maret, 2027: Maksimal 100 hari
- 15 Maret, 2029: Maksimal 47 hari
Perubahan Validasi Kontrol Domain (DCV)
Selain masa berlaku sertifikat, periode penggunaan kembali informasi validasi domain juga semakin pendek:
- Maret 2026: Maksimal penggunaan kembali 200 hari
- Maret 2027: Maksimal penggunaan kembali 100 hari
- Maret 2029: Maksimal penggunaan kembali 10 hari
Ini berarti organisasi perlu memvalidasi kepemilikan domain lebih sering, menjadikan otomatisasi penting untuk manajemen sertifikat praktis.
Mengapa Perubahan Ini Penting
Manfaat Keamanan:
- Masa berlaku sertifikat yang lebih pendek mengurangi kemungkinan terjadinya pencurian kunci
- Validasi yang lebih sering memastikan kepemilikan domain tetap terkini
- Penerapan peningkatan keamanan yang lebih cepat di seluruh web
Dampak Operasional:
- Manajemen sertifikat manual menjadi hampir tidak mungkin
- Organisasi harus menerapkan manajemen siklus hidup sertifikat otomatis
- Diperlukan prosedur validasi domain yang lebih sering
Persyaratan Otomasi
Perubahan-perubahan ini menjadikan otomatisasi sertifikat tidak hanya bermanfaat, tetapi juga penting. Organisasi harus mempertimbangkan dengan serius:
- Implementasi VE ACME (Lingkungan Manajemen Sertifikat Otomatis) atau protokol serupa
- Menyebarkan solusi manajemen siklus hidup sertifikat
- Siapkan infrastruktur untuk pembaruan dan validasi yang sering dilakukan
- Bersiap untuk transisi menuju masa berlaku sertifikat yang lebih pendek
Integrasi Transparansi Sertifikat
Peramban modern semakin membutuhkan atau memvalidasi log Transparansi Sertifikat (CT), yang menyediakan catatan publik yang dapat diaudit dari semua sertifikat yang diterbitkan. Ini membantu mendeteksi:
- Sertifikat yang salah diterbitkan
- Penerbitan sertifikat tidak sah
- Masalah kepatuhan CA
Kesimpulan
Lanskap digital tetap menjadi sistem kompleks yang saling terhubung, dan keamanan browser terus menjadi area pengembangan aktif yang mencakup:
- Masa berlaku sertifikat lebih pendek:Industri ini bergerak menuju masa berlaku sertifikat 47 hari pada tahun 2029, menjadikan otomatisasi penting untuk manajemen sertifikat praktis
- Perubahan Metode Pencabutan:Peralihan dari OCSP kembali ke CRL mencerminkan prioritas industri terhadap privasi pengguna dan efisiensi operasional
- Pengawasan CA yang Lebih Ketat:Peramban menjadi lebih agresif dalam menegakkan kepatuhan dan menghilangkan kepercayaan dari otoritas sertifikat yang berkinerja buruk
Perubahan-perubahan ini menunjukkan pergeseran mendasar menuju manajemen sertifikat yang lebih otomatis, mengutamakan privasi, dan berfokus pada keamanan. Organisasi harus mulai mempersiapkan diri sekarang untuk masa berlaku sertifikat yang lebih pendek dan proses pembaruan otomatis.
Kepercayaan terus memainkan peran penting dalam menjaga keamanan pengguna daring. Kami mengimbau Anda untuk selalu mengikuti perkembangan standar ini dan meninjau kebijakan serta catatan kepatuhan otoritas sertifikat Anda. Sebagaimana ditunjukkan oleh perubahan ini, ekosistem sertifikat secara aktif beradaptasi untuk meningkatkan keamanan dan perlindungan privasi.
Untuk informasi terkini tentang praktik terbaik manajemen sertifikat dan pendekatan SSL.com terhadap perubahan industri ini, silakan kunjungi halaman perbandingan sertifikat.
Terima kasih telah memilih SSL.com, di mana kami percaya a lebih aman Internet adalah lebih baik Internet.
