Salah satu persyaratan ini ditentukan dalam klausul 4.9.9 dengan tanda HARUS:
Tanggapan OCSP (Protokol Status Sertifikat Online) HARUS sesuai dengan RFC 6960 dan / atau RFC 5019. Tanggapan OCSP HARUS:
- Ditandatangani oleh CA yang mengeluarkan sertifikat yang status pencabutannya sedang diperiksa, atau
- Memiliki OCSP Responder tanda tangan yang sertifikatnya ditandatangani oleh CA yang mengeluarkan sertifikat, yang status pencabutannya diperiksa
Dalam kasus terakhir, sertifikat penandatanganan OCSP HARUS berisi ekstensi jenis id-pkix-ocsp-nocheck seperti yang ditentukan dalam RFC 6960.
Aturan ini dilanggar oleh hampir semua otoritas sertifikasi (CA), yang memiliki beberapa konsekuensi.
Berikut adalah tangkapan layar dari Persyaratan Dasar untuk Penerbitan dan Pengelolaan Sertifikat Tepercaya Publik (versi terbaru 1.7.0, 4 Mei 2020, pdf ):
Standar RFC6960 di bagian 4.2.2.2 mendefinisikan "Penanggap Terdelegasi OCSP" dengan adanya id-kp- Penandatanganan OCS.
Pengembang Ryan Sleevi, yang perusahaannya mengkhususkan diri dalam menangani sertifikat, telah membuktikan bahwa CA secara besar-besaran melanggar aturan 4.9.9.
Setelah memeriksa data crt.sh, Ryan Slavy menemukan 293 sertifikat perantara tanpa ekstensi pkix-nocheck, 180 di antaranya saat ini valid dan 113 dicabut.
Pemfilteran pada Census.io mengeluarkan 276 sertifikatcocok dengan kondisi ini.
Dengan demikian, sertifikat ini melanggar persyaratan dasar CA / Browser, terlebih lagi, persyaratan wajib .
Menurut Ryan Slavy, CA harus lebih berhati-hati tentang aturan CA / Browser. Mungkin, beberapa CA tidak terbiasa dengan persyaratan RFC 6960. Tidak
adanya ekstensi yang sesuai bukan hanya formalitas. Tidak ada masalah di sini dalam arti bahwa CA perantara tidak dapat mencabut sertifikat CA perantara lain dari CA akar yang sama.
Masalah sebenarnya adalah bahwa dengan tidak adanya perpanjangan, CA perantara secara teoritis dapat membatalkan pencabutan sertifikatCA perantara lain atau CA root itu sendiri. Ini benar-benar masalah. Faktanya, otoritas sertifikasi dalam situasi seperti ini tidak memiliki opsi yang dapat diandalkan untuk pencabutan sertifikat yang lengkap dan tidak dapat diubah. Prosedur pencabutan tidak bekerja seperti yang diharapkan, yang membuka pintu bagi penyerang yang berpotensi melakukan serangan untuk memulihkan sertifikat yang dicabut.
Untuk memperbaiki masalah ini, disarankan bahwa saat mencabut sertifikat, hapus semua salinan kunci secara permanen sehingga pembatalan juga menjadi tidak dapat diubah.
Untuk membenarkan CA, kita dapat mengatakan bahwa bahkan tanpa kekurangan ini, prosedur pencabutan sertifikat tidak berfungsi seperti yang diharapkan sekarang. Misalnya, browser utama menyimpan salinan CRL-nya sendiri - dan tidak selalu memeriksa bahwa salinan tersebut adalah yang terbaru. CRL ini hanya berisi informasi dasar dan terpenting, tetapi masih jauh dari lengkap. Misalnya, Chrome tidak repot-repot memeriksa untuk melihat apakah setiap sertifikat TLS tertentu telah dicabut, sedangkan Firefox melakukannya. Artinya, terkadang dengan Chrome Anda dapat membuka situs dengan sertifikat yang kedaluwarsa dengan aman, dan Firefox akan mengeluarkan peringatan dan tidak mengizinkan Anda ke sana.
Menariknya, menurut aturan, sertifikat yang salah harus dicabut di browser dalam waktu 7 hari, tetapi pengecualian dibuat untuk situasi ini. Ben Wilson dari Mozilla mengatakan mereka tidak akan melakukannyacabut sertifikat tanpa ekstensi id-pkix-ocsp-nocheck. Meskipun sertifikat tersebut tidak sesuai, browser Firefox tidak terpengaruh oleh kerentanan keamanan khusus ini karena tidak menerima tanggapan OCSP yang ditandatangani oleh CA perantara.
CA harus mengganti sertifikat yang salah, tetapi tidak ada tenggat waktu akhir untuk mereka.
Untuk informasi lebih lanjut tentang solusi PKI untuk perusahaan , hubungi manajer GlobalSign +7 (499) 678 2210, sales-ru@globalsign.com.