การออก CA root ที่ลงนามเองใหม่โดยไม่ทำให้ใบรับรองที่ลงชื่อนั้นถูกต้อง

ฉันสร้างผู้ออกใบรับรองที่ลงนามเองด้วยตนเองสำหรับบริการภายในไม่กี่แห่งใน บริษัท ของเราซึ่งฉันกำหนดค่าตัวเอง (ส่วนใหญ่ทำหน้าที่ผ่าน HTTPS) จากนั้นฉันสร้างใบรับรองสำหรับบริการเหล่านั้นลงนามด้วย CA นี้

ตอนนี้ฉันต้องการเพิ่มส่วนขยาย x509 (จุดแจกจ่าย CRL) ให้กับรูท CA โดยไม่ทำให้ใบรับรองเซิร์ฟเวอร์ที่มีอยู่ซึ่งออกจาก CA นี้ไม่ถูกต้อง เป็นไปได้ไหม

ความรู้สึกของฉันคือ "ใช่" เพราะอย่างที่ฉันเข้าใจการเข้าถึงกุญแจส่วนตัวที่เกี่ยวข้องนั้นเป็นสิ่งที่จำเป็นและเพียงพอสำหรับ "สิทธิ์เต็ม" ในการระบุตัวตนของใบรับรอง นั่นคือยกเว้นว่ามีการจัดเรียงของ nonce รวมกับคีย์สาธารณะในใบรับรองเมื่อมีการสร้าง (น่าจะ)

ฉันยังค่อนข้างใหม่ต่อการจัดการใบรับรอง SSL แต่ฉัน (คิดว่าฉัน) เข้าใจพื้นฐานของเครือข่ายความน่าเชื่อถือมาตรฐาน ฉันยังพอใจกับการใช้งานพื้นฐานของ crypto PKI อื่น ๆ : ฉันจัดการคีย์ SSH และใช้ GPG สำหรับการเซ็นชื่อและการเข้ารหัส ฉันเรียนวิชาวิทยาการคอมพิวเตอร์ถึงแม้ว่าฉันจะเป็นแค่คนทำเสียงเขียนด้วยตนเองในการเข้ารหัส

ฉันไม่เคยทำ CSR สำหรับ IIRC ดั้งเดิม (ฉันคิดว่ามันเป็นผลลัพธ์โดยตรงของopenssl req -new -x509) ฉันยังคงมีรหัสส่วนตัวดั้งเดิมของ CA และใช้มันฉันสามารถ "ย้อนกลับ" ใบรับรองดั้งเดิมในคำขอลงนามใบรับรอง: openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key

ฉันหวังว่าสิ่งนี้จะมีประสิทธิภาพ "แยก" ที่ไม่ได้กล่าวถึงข้างต้นและอนุญาตให้ฉันสร้างใบรับรองใหม่ แต่คราวนี้มีcrlDistributionPointsฟิลด์และดังนั้นใบรับรองทั้งหมดที่ลงนามกับ CA ดั้งเดิมจะยังคงตรวจสอบกับ CA ใหม่นี้ด้วยข้อยกเว้น ลูกค้าจะดึงไฟล์ CRL ของฉัน (ปัจจุบันว่าง) จาก URL HTTP ที่กำหนดไว้ในฟิลด์

ดังนั้นฉันจึงสร้างไฟล์ปรับแต่งส่วนขยายext.conf:

[ cert_ext ] 
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl

และฉันสร้าง CA รูตเวอร์ชันใหม่จาก CSR:

openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem

ตอนนี้เมื่อฉันดูใบรับรองด้วย openssl x509 -text -in MyNewCA.pem | less

ฉันเห็นส่วนขยาย 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`

แต่อนิจจา! ใบรับรองที่ลงนามก่อนหน้านี้ของฉันจะไม่ตรวจสอบกับใบรับรองนี้อีกต่อไป:

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

ส่วนใหญ่ฉันกำลังมองหาข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับวิธีการทำงานของใบรับรองและสาเหตุ แต่ฉันก็ยินดีต้อนรับวิธีแก้ปัญหาที่นำไปสู่ปัญหานี้ดังนั้นนี่คือข้อมูลเบื้องหลังบางส่วนเช่นกัน

ฉันเข้ามายุ่งกับเรื่องนี้ได้อย่างไร: HTTPS สำหรับบริการภายในทำงานได้ยอดเยี่ยมเมื่อ CA ของฉันถูกติดตั้งผ่าน Explorer RMB →ติดตั้ง GUI ใบรับรองบน ​​Windows หรือ/usr/local/share/ca-certificatesตามด้วยupdate-ca-certificatesDebian และ Ubuntu แต่ฉันเพิ่งพบข้อยกเว้น: Git บน Windows โดยเฉพาะถ้าติดตั้งเพื่อใช้ Windows Secure Channel เป็น SSL back-end ซึ่งเห็นได้ชัดว่าตามค่าเริ่มต้นยืนยันว่าจะต้องมีฟิลด์ CRL ในใบรับรอง SSL

ดังนั้นฉันคิดว่ามันเป็นปัญหาของ Windows Secure Channel เพราะข้อความแสดงข้อผิดพลาดที่ฉันยังคงทำงานดูเหมือนว่าเฉพาะ 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.

ถ้าฉันติดตั้ง Git ด้วย OpenSSL และต่อเชื่อม CA ของฉันเองเข้ากับไฟล์ที่ชี้ไปที่ git.http.sslcainfo แล้วก็ใช้งานได้ แต่ฉันเกรงว่าผู้ใช้ของฉันจะไม่สนใจการยืนยันตัวตน SSL หากพวกเขารู้สึกว่ากระบวนการนี้เป็นความพยายามมากกว่า คลิกผ่าน GUI ตัวติดตั้งใบรับรอง Windows "ที่ง่าย"

ใบรับรองสองใบจะถือว่าเหมือนกันกับชื่อเรื่องและรหัสสาธารณะของใบรับรองที่ตรงกัน

ดังนั้นสิ่งที่คุณต้องทำคือใช้กุญแจอีกครั้งและให้แน่ใจว่าชื่อหัวเรื่องในใบรับรองใหม่เหมือนกันกับของเก่า หลังจากนั้นคุณสามารถเปลี่ยนฟิลด์และ / หรือส่วนขยายอื่น ๆ และใบรับรองผลลัพธ์จะได้รับการพิจารณาเหมือนกัน

ตัวอย่างเช่นสร้างไฟล์คอนฟิกูเรชัน OpenSSL ของคุณ:

[ 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

rootca.cnfและบันทึกเป็นเช่น ตรวจสอบให้แน่ใจว่าองค์ประกอบขององค์ประกอบ[req_distinguished_name]นั้นเหมือนกับองค์ประกอบในใบรับรอง Root CA ดั้งเดิมของคุณ (นี่คือส่วนชื่อหัวเรื่องที่เหมือนกัน)

ถัดไปเรียกใช้:

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

โดยที่rootca.keyเป็นรหัสส่วนตัวที่ใช้ในใบรับรองดั้งเดิม (นี่คือส่วนสาธารณะ / ส่วนตัวคีย์ที่เหมือนกัน)

สิ่งนี้สร้างMyNewCA.pemขึ้นซึ่งคุณสามารถตรวจสอบได้ด้วย:

$ 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

ใช้ใบรับรองใหม่นี้แทนเอกสารต้นฉบับ

คุณสามารถเปลี่ยนฟิลด์และส่วนขยายอื่น ๆ เช่นช่วงเวลาที่มีผลบังคับใช้ของใบรับรองได้ แต่โปรดทราบว่าคุณไม่ควรมีข้อ จำกัด ใด ๆ (นอกเหนือจากbasicConstraints = critical,CA:true) ในใบรับรอง Root CA

หลังจากพิจารณาเพิ่มเติมแล้วปัญหาของคุณอาจเกิดขึ้นกับข้อเท็จจริงที่ว่าใบรับรอง Root CA ทดแทนของคุณไม่มีส่วนขยายbasicConstraintและอาจเป็นไปkeyUsageได้ อาจเป็นการลองเพิ่มส่วนขยายสองรายการนั้นในext.confครั้งแรกของคุณและทดสอบใบรับรอง Root CA ที่ได้รับใหม่โดยใช้-x509toreqวิธีที่คุณโพสต์