Saya membuat Otoritas Sertifikat root yang ditandatangani sendiri untuk beberapa layanan internal di perusahaan kami, yang saya konfigurasikan sendiri (kebanyakan dilayani melalui HTTPS). Kemudian saya membuat sertifikat untuk layanan tersebut, ditandatangani dengan CA.
Sekarang saya ingin menambahkan ekstensi x509 (titik distribusi CRL) ke root CA tanpa membatalkan sertifikat server yang ada yang dikeluarkan dari CA ini. Apakah ini mungkin?
Perasaan saya adalah "ya" karena seperti yang saya mengerti, akses ke kunci pribadi yang sesuai diperlukan dan cukup untuk "otoritas penuh" atas identitas sertifikat. Yaitu, kecuali ada semacam nonce dimasukkan bersama dengan kunci publik ke dalam sertifikat ketika itu dihasilkan (kemungkinan).
Saya masih cukup baru dalam manajemen sertifikat SSL, tapi saya (pikir saya) mengerti dasar-dasar rantai kepercayaan standar. Saya juga nyaman dengan penggunaan dasar cryptto PKI lainnya: Saya mengelola kunci SSH dan menggunakan GPG untuk penandatanganan dan enkripsi. Saya belajar Ilmu Komputer, meskipun saya hanya pengajar otodidak dalam kriptografi.
Saya tidak pernah membuat CSR untuk IIRC asli (saya pikir itu adalah hasil langsung dari openssl req -new -x509
). Saya masih memiliki kunci pribadi CA asli, tentu saja, dan menggunakannya saya bisa "membalikkan" sertifikat asli menjadi Permintaan Penandatanganan Sertifikat:
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
Saya berharap ini akan secara efektif "mengekstrak" angka yang disebutkan di atas, dan memungkinkan saya untuk membuat ulang sertifikat tetapi kali ini dengan crlDistributionPoints
bidang, dan akibatnya semua sertifikat yang ditandatangani dengan CA asli masih akan divalidasi terhadap CA baru ini, dengan pengecualian bahwa klien akan mengambil file CRL saya (saat ini kosong) dari URL HTTP yang ditentukan di bidang.
Jadi saya membuat file konfigurasi ekstensi ext.conf
:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
Dan saya menghasilkan versi baru dari root CA dari CSR:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Sekarang ketika saya melihat sertifikat dengan openssl x509 -text -in MyNewCA.pem | less
Saya dapat melihat bagian ekstensi CRL:
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
Namun sayang! Sertifikat yang saya tandatangani sebelumnya tidak lagi valid terhadap yang ini:
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
Sebagian besar saya mencari lebih banyak wawasan tentang cara kerja sertifikat dan mengapa. Tapi saya juga menyambut solusi untuk masalah yang mengarah ke yang satu ini, jadi inilah beberapa info latar belakang juga.
Bagaimana saya masuk ke kekacauan ini: HTTPS ke layanan internal berfungsi dengan baik setelah CA saya diinstal melalui RMB Explorer → Instal Sertifikat GUI pada Windows, atau /usr/local/share/ca-certificates
diikuti oleh update-ca-certificates
Debian dan Ubuntu. Tapi baru-baru ini saya menemukan pengecualian: Git di Windows, khususnya jika diinstal untuk menggunakan Windows Secure Channel sebagai SSL back-end. Yang tampaknya secara default menegaskan bahwa harus ada bidang CRL dalam sertifikat SSL.
Jadi saya kira itu benar-benar masalah Saluran Aman Windows karena pesan kesalahan yang terus saya temui sepertinya sepenuhnya spesifik Microsoft: fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Jika saya menginstal Git dengan OpenSSL dan secara manual menggabungkan CA saya ke file yang ditunjuk oleh git.http.sslcainfo, maka itu akan berhasil, tetapi saya khawatir pengguna saya akan cenderung untuk tidak melakukan verifikasi identitas SSL jika mereka merasa proses ini lebih mudah daripada mengklik melalui GUI installer sertifikat Windows "mudah".
-x509toreq
akan memulihkan semua info unik dari CA root yang ada, tetapi entah itu tidak ada atau ada sesuatu yang salah dengan proses saya dari sana.
req -new -x509
dan x509 -req -signkey
keduanya default serial dari sertifikat yang ditandatangani sendiri ke nomor acak (meskipun ini dapat diganti) secara efektif. Jika sertifikat anak Anda (atau salah satu dari mereka) mengandung AuthorityKeyIdentifier menggunakan opsi 'penerbit + serial' (bukan atau di samping opsi 'keyid'), yang akan menjadi kasus jika Anda menggunakan ca
file konfigurasi default upstream, Anda perlu membuat root baru dengan serial yang sama dengan yang lama; gunakan -set_serial
. ...