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


12

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://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".


1
Hanya kunci publik dan Subjek yang membuat sertifikat unik. Karena itu, jika Anda tidak berubah, Anda harus dapat menandatangani ulang sertifikat Anda sambil mengubah semua bidang dan ekstensi lainnya sesuai dengan isi hati Anda.
garethTheRed

@garethTheRed ah, itu masuk akal. Saya tidak yakin bagaimana melakukan ini; dapatkah Anda menguraikan atau memposting jawaban dengan lebih detail? Saya berharap bahwa -x509toreqakan memulihkan semua info unik dari CA root yang ada, tetapi entah itu tidak ada atau ada sesuatu yang salah dengan proses saya dari sana.
AngerySysadmin

1
req -new -x509dan x509 -req -signkeykeduanya 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 cafile konfigurasi default upstream, Anda perlu membuat root baru dengan serial yang sama dengan yang lama; gunakan -set_serial. ...
dave_thompson_085

... Tetapi beberapa sw mungkin tidak senang jika Anda mencoba mengimpor sertifikat baru dengan nama dan seri yang sama dengan yang sudah ada; Anda mungkin perlu membersihkan yang lama terlebih dahulu.
dave_thompson_085

1
Near-cross-dupe security.stackexchange.com/questions/17331/... PS: Saya pikir itu mungkin untuk membuat Windows secara manual men-cache CRL untuk CA yang dalam hal kekurangan CRLDP mungkin tidak masalah, tetapi seberapa tidak nyamannya itu akan menjadi Saya tidak tahu
dave_thompson_085

Jawaban:


6

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.


Terima kasih atas jawaban yang komprehensif, itu benar-benar membantu saya memahami hal-hal dengan lebih baik. Dengan ini dan komentar @ dave_thompson_085 saya telah berhasil membuat ulang CA saya dengan cara yang tidak membatalkan sertifikat anak. Ada beberapa hal yang salah dengan upaya awal saya (saya mungkin harus mengirim jawaban dengan lebih detail?) Juga terima kasih untuk poin yang jelas-dalam-retrospeksi tetapi penting bahwa "Nama Subjek" adalah bidang yang terdiri dari bidang-bidang tertentu. Entah bagaimana, saya ragu orang lain akan mengirim jawaban, jadi saya menerima jawaban ini.
AngerySysadmin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.