इसके द्वारा हस्ताक्षरित प्रमाणपत्रों को अमान्य किए बिना स्व-हस्ताक्षरित रूट सीए को फिर से जारी करना

12

मैंने हमारी कंपनी में कुछ आंतरिक सेवाओं के लिए एक स्व-हस्ताक्षरित रूट प्रमाणपत्र प्राधिकरण बनाया, जिसे मैंने खुद को कॉन्फ़िगर किया (ज्यादातर HTTPS पर काम किया)। फिर मैंने उन सेवाओं के लिए प्रमाण पत्र बनाए, इस सीए के साथ हस्ताक्षर किए।

अब मैं इस CA से जारी मौजूदा सर्वर प्रमाणपत्रों को अमान्य किए बिना रूट CA में एक x509 एक्सटेंशन (CRL वितरण बिंदु) जोड़ना चाहता हूं। क्या यह संभव है?

मेरी आंत महसूस "हाँ" है क्योंकि जैसा कि मैं समझता हूं, प्रमाणपत्र पहचान पर "पूर्ण अधिकार" के लिए संबंधित निजी कुंजी तक पहुंच आवश्यक और पर्याप्त है। यही है, जब तक कि प्रमाणपत्र में सार्वजनिक कुंजी के साथ किसी प्रकार की गैर-सम्‍मिलित नहीं की जाती है जब यह जेनरेट किया जाता है (संभावना)।

मैं अभी भी एसएसएल प्रमाणपत्र प्रबंधन के लिए काफी नया हूं, लेकिन मुझे (मुझे लगता है) मानक ट्रस्ट श्रृंखला की मूल बातें समझते हैं। मैं अन्य पीकेआई क्रिप्टो के बुनियादी उपयोग के साथ भी सहज हूं: मैं एसएसएच कुंजी का प्रबंधन करता हूं और हस्ताक्षर और एन्क्रिप्शन के लिए जीपीजी का उपयोग करता हूं। मैंने कंप्यूटर साइंस का अध्ययन किया है, हालांकि मैं क्रिप्टोग्राफी में केवल एक स्वयं-पढ़ा हुआ डब्बलर हूं।

मैंने मूल IIRC के लिए CSR कभी नहीं बनाया (मुझे लगता है कि यह प्रत्यक्ष उत्पादन था openssl req -new -x509)। मेरे पास अभी भी मूल सीए की निजी कुंजी है, निश्चित रूप से, और इसका उपयोग करते हुए मैं मूल प्रमाणपत्र को प्रमाणित करने के प्रयास में "रिवर्स" करने में सक्षम था: openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key

मैं उम्मीद कर रहा था कि यह प्रभावी रूप से उल्लिखित नॉन को "एक्स्ट्रेक्ट" करेगा, और मुझे प्रमाण पत्र को फिर से बनाने की अनुमति देगा लेकिन इस बार एक crlDistributionPointsक्षेत्र के साथ , और परिणामस्वरूप मूल सीए के साथ हस्ताक्षरित सभी प्रमाण पत्र अभी भी इस नए सीए के खिलाफ मान्य होंगे, अपवाद के साथ उस क्लाइंट को मेरे (वर्तमान में खाली) CRL फ़ाइल को HTTP URL से फ़ील्ड में निर्दिष्ट किया जाएगा।

इसलिए मैंने एक एक्सटेंशन कॉन्फिग फाइल बनाई ext.conf:

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

और मैंने CSR से रूट CA का नया संस्करण तैयार किया:

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

ज्यादातर मैं प्रमाण पत्र कैसे और क्यों काम में अधिक अंतर्दृष्टि के लिए देख रहा हूँ। लेकिन मैं इस समस्या का समाधान करने के लिए भी स्वागत करूंगा, इसलिए यहां कुछ पृष्ठभूमि की जानकारी भी है।

मैं इस गड़बड़ी में कैसे आया: मेरे सीए को एक्सप्लोरर आरएमबी के माध्यम से स्थापित करने के बाद एचटीटीपीएस आंतरिक सेवाओं में बहुत काम करता है → विंडोज पर प्रमाणपत्र जीयूआई स्थापित करें, या इसके /usr/local/share/ca-certificatesबाद update-ca-certificatesडेबियन और उबंटू। लेकिन मैं हाल ही में एक अपवाद में भाग गया: विंडोज पर गेट, विशेष रूप से अगर एसएसएल बैक-एंड के रूप में विंडोज सिक्योर चैनल का उपयोग करने के लिए स्थापित किया गया है। जो जाहिर तौर पर डिफ़ॉल्ट रूप से जोर देकर कहते हैं कि एसएसएल प्रमाणपत्रों में सीआरएल क्षेत्र होना चाहिए।

इसलिए मुझे लगता है कि यह वास्तव में एक विंडोज सिक्योर चैनल मुद्दा है क्योंकि त्रुटि संदेश जो मैं पूरी तरह से 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.

अगर मैं OpenSSL के साथ Git स्थापित करता हूं और git.http.sslcainfo द्वारा बताई गई फ़ाइल पर मैन्युअल रूप से अपने CA को सूचित करता हूं तो यह काम करता है, लेकिन मुझे डर है कि मेरे उपयोगकर्ता SSL पहचान सत्यापन पर रोक लगाने के लिए इच्छुक होंगे क्योंकि उन्हें लगता है कि यह प्रक्रिया अधिक प्रयास से अधिक है "आसान" विंडोज प्रमाणपत्र इंस्टॉलर जीयूआई के माध्यम से क्लिक करना।

ssl-certificate  openssl  certificate-authority 
— AngerySysadmin
स्रोत
1
केवल सार्वजनिक कुंजी और विषय प्रमाणपत्र को विशिष्ट बनाता है। इसलिए, यदि आप या तो नहीं बदलते हैं, तो आपको अपने दिल की सामग्री के लिए अन्य सभी क्षेत्रों और एक्सटेंशन को बदलकर अपने प्रमाण पत्र पर फिर से हस्ताक्षर करने में सक्षम होना चाहिए।
— garethTheRed
@garethTheRed आह, यह समझ में आता है। मुझे यकीन नहीं है कि यह कैसे करना है; क्या आप अधिक विवरण के साथ उत्तर दे सकते हैं या पोस्ट कर सकते हैं? मुझे उम्मीद थी कि -x509toreqमौजूदा रूट CA से सभी अद्वितीय जानकारी को पुनर्प्राप्त किया जाएगा, लेकिन या तो वहाँ से मेरी प्रक्रिया में कुछ गड़बड़ है या नहीं है।
— एंगरीसेड्समिन
1
req -new -x509और x509 -req -signkeyदोनों स्व-हस्ताक्षरित सर्टिफिकेट के सीरियल को एक यादृच्छिक संख्या के रूप में डिफ़ॉल्ट करते हैं (हालांकि यह ओवरराइड किया जा सकता है) प्रभावी रूप से एक गैर। यदि आपके बच्चे के प्रमाण पत्र (या उनमें से कोई भी) में + जारीकर्ता + सीरियल ’विकल्प (id कीड’ विकल्प के अलावा) का उपयोग करके अथॉरिटीआईडेंटिफायर शामिल है, जो caअपस्ट्रीम डिफ़ॉल्ट डिफॉल्ट फाइल के साथ प्रयोग किए जाने पर होगा। पुराने के रूप में एक ही धारावाहिक के साथ नई जड़ बनाने की जरूरत है; उपयोग करें -set_serial। ...
— dave_thompson_085
... लेकिन अगर आप एक ही नाम और धारावाहिक के साथ एक मौजूदा के रूप में एक नया प्रमाण पत्र आयात करने की कोशिश करते हैं तो कुछ लोग दुखी हो सकते हैं; आपको पहले पुराने को साफ करने की आवश्यकता हो सकती है।
— dave_thompson_085
1
निकट-पार शिकार security.stackexchange.com/questions/17331/... पुनश्च: मैं लगता है कि यह करने के लिए मैन्युअल रूप से विंडोज पाने के लिए एक सीए के लिए सीआरएल कैश जिस स्थिति में CRLDP की कमी बात नहीं हो सकता है हो सकता है, लेकिन कैसे असुविधाजनक हो सकता है कि मुझे नहीं पता।
— dave_thompson_085

जवाबों:

6

दो प्रमाण पत्रों को तब तक माना जाता है जब तक कि प्रमाणपत्र के विषय और सार्वजनिक कुंजी का मिलान नहीं हो जाता है।

इसलिए, आपको बस इतना करना है कि चाबियाँ फिर से उपयोग करें और यह सुनिश्चित करें कि नए प्रमाणपत्र में विषय का नाम पुराने जैसा ही है। उसके बाद, आप किसी भी अन्य फ़ील्ड और / या एक्सटेंशन को बदल सकते हैं और परिणामी प्रमाणपत्र को समान माना जाएगा।

उदाहरण के लिए, अपनी 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]आपके मूल रूट 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रूट CA प्रमाणपत्र पर वास्तव में कोई बाधा नहीं होनी चाहिए (इसके अलावा )।

आगे विचार करने के बाद, आपका मुद्दा बस इस तथ्य से कम हो सकता है कि आपके प्रतिस्थापन रूट CA प्रमाणपत्र में basicConstraintसंभवतः और keyUsageएक्सटेंशन नहीं हैं। यह उन दो एक्सटेंशनों को अपने ext.confपहले से जोड़ने और -x509toreqआपके द्वारा पोस्ट की गई विधि का उपयोग करके परिणामी नए रूट CA प्रमाणपत्र का परीक्षण करने के लायक हो सकता है ।

— garethTheRed
स्रोत
व्यापक उत्तर के लिए धन्यवाद, इसने वास्तव में मुझे चीजों को बेहतर ढंग से समझने में मदद की है। इसके साथ और @ dave_thompson_085 की टिप्पणियाँ मैंने अपने CA को इस तरह से पुनर्जीवित करने में कामयाब की हैं, जो बाल वध को अमान्य नहीं करता है। मेरे मूल प्रयास में कुछ चीजें गलत थीं (मुझे संभवतः अधिक विस्तार के साथ एक उत्तर पोस्ट करना चाहिए?) इसके अलावा उस स्पष्ट-पूर्वव्यापी लेकिन महत्वपूर्ण बिंदु के लिए धन्यवाद कि "विषय का नाम" उन विशेष क्षेत्रों से बना एक क्षेत्र है। मुझे किसी भी तरह से संदेह है कि कोई और उत्तर पोस्ट करेगा, इसलिए मैं इसे स्वीकार कर रहा हूं।
— एंग्रीसेड्समिन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.