Menerbitkan ulang CA yang ditandatangani sendiri root tanpa membatalkan sertifikat yang ditandatangani olehnya

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 crlDistributionPointsbidang, 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-certificatesdiikuti oleh update-ca-certificatesDebian 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://[email protected]/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".

Dua sertifikat dianggap sama selama Nama Subjek dan Kunci Publik dari kecocokan sertifikat.

Karena itu, yang perlu Anda lakukan adalah menggunakan kembali kunci dan memastikan bahwa Nama Subjek dalam sertifikat baru sama dengan yang lama. Setelah itu, Anda dapat mengubah bidang dan / atau ekstensi lainnya dan sertifikat yang dihasilkan akan dianggap sama.

Misalnya, buat file konfigurasi OpenSSL Anda:

[ req ]

prompt             = no
string_mask        = default
distinguished_name = x509_distinguished_name
x509_extensions     = x509_ext

[ x509_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:

countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA

[ x509_ext ]

basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl

dan simpan sebagai contoh rootca.cnf. Pastikan bahwa elemen-elemen [req_distinguished_name]identik dengan yang ada di sertifikat CA Root asli Anda (ini adalah bagian Nama Subjek yang identik).

Selanjutnya, jalankan:

openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf

di mana rootca.keykunci privat digunakan dalam sertifikat asli (ini adalah bagian Public / Private Key yang identik).

Ini menciptakan MyNewCA.pem, yang dapat Anda periksa dengan:

$ openssl x509 -noout -text -in MyNewCA.pem

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
    Validity
        Not Before: Jul 15 05:05:54 2017 GMT
        Not After : Aug 14 05:05:54 2017 GMT
    Subject: C=za, O=My Company, OU=Security, CN=My Root CA
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
                ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
                50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
                d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
                0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
                01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
                90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
                a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
                e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
                d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
                c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
                14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
                48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
                d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
                ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
                f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
                14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
                58:93
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 Subject Key Identifier: 
            3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://security.mycompany.co.za/root.crl

Signature Algorithm: sha256WithRSAEncryption
     4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
     1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
     73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
     62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
     ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
     40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
     eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
     ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
     d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
     06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
     71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
     3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
     a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
     2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
     2a:dd:1a:d6

Gunakan sertifikat baru ini sebagai pengganti aslinya.

Anda dapat mengubah bidang dan ekstensi lain, seperti masa berlaku sertifikat, tetapi ingatlah bahwa Anda seharusnya tidak benar-benar memiliki kendala (selain basicConstraints = critical,CA:true) pada sertifikat CA Root.

Setelah pertimbangan lebih lanjut, masalah Anda mungkin hanya karena fakta bahwa sertifikat CA Root pengganti Anda tidak memiliki basicConstraintdan mungkin keyUsageekstensi. Mungkin patut mencoba menambahkan kedua ekstensi itu ke ekstensi Anda yang ext.confpertama dan menguji sertifikat CA Root baru yang dihasilkan menggunakan -x509toreqmetode yang Anda posting.