सवाल प्रमाणन प्राधिकरण रूट प्रमाणपत्र समाप्ति और नवीनीकरण


2004 में, मैंने लिनक्स पर ओपनएसएसएल और ओपनवीपीएन के साथ प्रदान की गई सरल प्रबंधन स्क्रिप्ट का उपयोग करके एक छोटा प्रमाणन प्राधिकरण स्थापित किया। उस समय मिले मार्गदर्शकों के अनुसार, मैंने रूट सीए प्रमाणपत्र के लिए वैधता अवधि 10 साल तक निर्धारित की है। तब से, मैंने ओपनवीपीएन सुरंगों, वेब साइटों और ई-मेल सर्वरों के लिए कई प्रमाणपत्रों पर हस्ताक्षर किए हैं, जिनमें से सभी की वैधता अवधि 10 साल है (यह गलत हो सकती है, लेकिन उस समय मैं बेहतर नहीं जानता था)।

मुझे सीए स्थापित करने के बारे में कई मार्गदर्शिकाएं मिली हैं, लेकिन इसके प्रबंधन के बारे में बहुत ही कम जानकारी है, और विशेष रूप से, रूट सीए प्रमाणपत्र की अवधि समाप्त होने पर क्या किया जाना है, जो 2014 में कुछ समय होगा। इसलिए मेरे पास निम्नलिखित है प्रशन:

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

इस तथ्य से स्थिति थोड़ा और जटिल हो गई है कि कुछ ग्राहकों के लिए मेरी एकमात्र पहुंच ओपनवीपीएन सुरंग के माध्यम से है जो मौजूदा सीए प्रमाण पत्र द्वारा हस्ताक्षरित प्रमाणपत्र का उपयोग करती है, इसलिए यदि मुझे सभी क्लाइंट कॉर्ट्स को प्रतिस्थापित करना है, तो मुझे कॉपी करने की आवश्यकता होगी क्लाइंट को नई फाइलें, सुरंग को पुनरारंभ करें, मेरी उंगलियों को पार करें और उम्मीद करें कि यह बाद में आता है।


87
2017-08-30 08:34


मूल




जवाब:


अपने रूट सीए पर एक ही निजी कुंजी रखने से सभी प्रमाणपत्रों को नई रूट के खिलाफ सफलतापूर्वक सत्यापन जारी रखने की अनुमति मिलती है; आपके लिए जरूरी चीज नई जड़ पर भरोसा करना है।

प्रमाण पत्र हस्ताक्षर संबंध निजी कुंजी से हस्ताक्षर पर आधारित है; एक नई सार्वजनिक प्रमाण पत्र उत्पन्न करते समय एक ही निजी कुंजी (और, निस्संदेह, एक ही सार्वजनिक कुंजी) रखते हुए, एक नई वैधता अवधि के साथ और किसी भी अन्य नए गुणों को आवश्यकतानुसार बदल दिया जाता है, ट्रस्ट संबंध को जगह में रखता है। सीआरएल भी पुराने प्रमाण से नए तक जारी रख सकते हैं, क्योंकि वे निजी कुंजी द्वारा हस्ताक्षरित प्रमाण पत्र की तरह हैं।


तो, चलो सत्यापित करें!

एक रूट सीए बनाओ:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

इससे एक बाल प्रमाण पत्र उत्पन्न करें:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

बाल प्रमाण पत्र पर हस्ताक्षर करें:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

सभी वहाँ सेट, सामान्य प्रमाणपत्र संबंध। आइए ट्रस्ट को सत्यापित करें:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

ठीक है, तो, अब मान लें कि 10 साल बीत चुके हैं। चलो एक ही रूट निजी कुंजी से एक नया सार्वजनिक प्रमाणपत्र उत्पन्न करते हैं।

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

और .. क्या यह काम करता है?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

पर क्यों? वे अलग फाइलें हैं, है ना?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

हां, लेकिन, इसका मतलब यह नहीं है कि नई सार्वजनिक कुंजी क्रिप्टोग्राफिक रूप से प्रमाणपत्र पर हस्ताक्षर से मेल नहीं खाती है। विभिन्न सीरियल नंबर, एक ही मॉड्यूलस:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

आइए यह सत्यापित करने के लिए थोड़ा आगे जाएं कि यह वास्तविक विश्व प्रमाण पत्र सत्यापन में काम कर रहा है।

एक अपाचे उदाहरण को फायर करें, और चलो इसे जाने दें (डेबियन फ़ाइल संरचना, आवश्यकतानुसार समायोजित करें):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

हम इन निर्देशों को एक पर सेट करेंगे VirtualHost 443 पर सुनना - याद रखें, newroot.pem रूट प्रमाणपत्र तब भी मौजूद नहीं था जब cert.pem उत्पन्न और हस्ताक्षरित किया गया था।

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

चलो देखते हैं कि openssl इसे कैसे देखता है:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

ठीक है, और एमएस के क्रिप्टो एपीआई का उपयोग कर ब्राउज़र के बारे में कैसे? रूट पर भरोसा करना चाहिए, पहले, तो यह सब अच्छा है, नए रूट के सीरियल नंबर के साथ:

newroot

और, हमें अभी भी पुरानी जड़ के साथ काम करना चाहिए। Apache की कॉन्फ़िगरेशन को चारों ओर स्विच करें:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

अपाचे पर पूर्ण पुनरारंभ करें, एक रीलोड कर्ट को ठीक से स्विच नहीं करेगा।

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

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

oldroot


तो यह बात है! जब आप नवीनीकरण करते हैं, वही निजी कुंजी रखें, नए विश्वसनीय रूट में स्वैप करें, और यह बहुत कुछ है बस काम करता है। सौभाग्य!


124
2017-09-04 18:40



वैसे भी, यदि आप एक ही निजी कुंजी का पुन: उपयोग करने जा रहे हैं तो नया रूट प्रमाणपत्र बनाने का क्या मतलब है? यदि आप इसे और अधिक करते रहते हैं, तो प्रमाणपत्र के लिए समाप्ति तिथि होने का क्या मतलब है? मैंने सोचा कि रूट की समाप्ति का उपयोग प्रशासकों को एक नई (सबसे अधिक संभावना मजबूत) निजी कुंजी बनाने के लिए मजबूर करने के लिए किया गया था जो कुंजी को तोड़ने की कोशिश कर रहे अग्रिम मशीनों के खिलाफ अधिक सुरक्षित है। 20 साल पहले बनाई गई 40 बिट कुंजी पर्याप्त सुरक्षित नहीं है - jvhashe
@jvhashe अगर रूट प्रमाणपत्र अब क्रिप्टोग्राफ़िक रूप से पर्याप्त मजबूत नहीं है, तो आपको इसकी समाप्ति तिथि के बावजूद इसे से छुटकारा पाना चाहिए। यदि आप अपनी खुद की जड़ पैदा कर रहे हैं, तो आपको सैकड़ों वर्षों की अवधि समाप्त होने के लिए इसे सेट करने से रोकना कुछ भी नहीं है जब आप ग्रह पर नहीं रहेंगे। समाप्ति रूट प्रमाण पत्र पर शायद ही प्रासंगिक है - और एक बाल प्रमाण पत्र के लिए, समाप्ति वास्तव में क्रिप्टोग्राफिक शक्ति के बारे में नहीं है (सीए पूछें जो अक्टूबर में सभी 1024-बिट कॉर्ट को रद्द करने के लिए तैयार हैं) - देखें यहाँ अधिक जानकारी के लिए। - Shane Madden♦
उपरोक्त के अलावा, मैंने पाया कि काम करने के लिए इस विधि के लिए सीरियल नंबर समान होना चाहिए। - Scott Presnell
-set_serial 01 - डब्ल्यूटीएफ ??? आप गंभीर संख्याओं का उपयोग नहीं कर सकते हैं। क्या आपने परामर्श भी किया था आरएफसी 4158, इंटरनेट एक्स.50 9 पब्लिक की इंफ्रास्ट्रक्चर: सर्टिफिकेशन पाथ बिल्डिंग? या आप इसे साथ बना रहे हैं जैसे आप साथ जाते हैं? जब आप पथ निर्माण शुरू करते हैं तो आपको उपयोगकर्ता एजेंटों में होने वाली समस्याओं का कोई अंदाजा नहीं है। - jww
@jww क्या आपने जवाब पढ़ा? यह सिर्फ इस तथ्य का एक प्रदर्शन है कि क्रिप्टोग्राफी काम करता है। वह आदेश सचमुच सिर्फ एक परीक्षण प्रमाण उत्पन्न कर रहा है जिसे हम पुराने और नए रूट प्रमाण के बीच संबंधों का परीक्षण करने के प्रयोजनों के लिए बाद में सत्यापित कर सकते हैं। यदि कोई है उन आदेशों का सीधे उपयोग करके, मुझे निश्चित रूप से कुछ ब्रेक की उम्मीद है, और वे महसूस करते हैं कि उन्हें अंधेरे से चलने से पहले कुछ के संदर्भ पर ध्यान देना होगा (या इस बारे में हैंडल से उड़ना चाहे 01 एक प्रयोगशाला में एक स्वीकार्य धारावाहिक है)। - Shane Madden♦


मैंने देखा है कि मूल सीए कुंजी के नवीनीकृत प्रमाणपत्र में सीए एक्सटेंशन गुम हो सकते हैं। यह मेरे लिए अधिक उचित काम करता है (यह एक बनाता है ./renewedselfsignedca.conf जहां v3 सीए एक्सटेंशन परिभाषित किए जाते हैं, और ca.key तथा ca.crt मूल सीए कुंजी और प्रमाण पत्र माना जाता है):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

13
2018-04-22 10:31



यह एक बेहद सहायक जोड़ रहा है। वास्तव में वैध उत्तर का परिणाम मेरे लिए पर्याप्त संगत प्रमाणपत्र नहीं है यदि आपके मूल रूट सीए पर मनमानी सेटिंग्स हैं। - Theuni
सेकेंड, बहुत उपयोगी। एक और जोड़ा: स्वीकार्य उत्तर पर टिप्पणियों में स्कॉट प्रेनेल की तरह, मुझे भी नवीनीकृत प्रमाण पत्र के हेक्साडेसिमल सीरियल नंबर को मैन्युअल रूप से निर्दिष्ट करना था ताकि यह पुराने से मेल खा सके। इसका मतलब जोड़ना था -set_serial 0xdeadbeefabba (असली धारावाहिक नहीं :) :) बाद वाले x509 कमांड के लिए। केवल तब ही मेरे क्लाइंट प्रमाण पत्र नवीनीकृत सीए प्रमाणपत्र के खिलाफ सफलतापूर्वक सत्यापित करते थे। - JK Laiho
यह विधि आसान है क्योंकि यह पिछले प्रमाणपत्र की तुलना में एक ही जानकारी रखती है। - lepe
मैंने इस समाधान के लिए एक स्क्रिप्ट बनाई है -set_serial - मेरा उत्तर देखें - Wolfgang Fahl
इस जवाब ने मुझे एक पूरे मुद्दे पर बचाया, जिसकी आवश्यकता उस मुद्दे पर लगभग एक दिन बिताने के बाद, मैं लगभग हारने वाला था, मैं इसके लिए आपकी टोपी को टिपता हूं! - Onitlikesonic


रूट की वैध अवधि बढ़ाने के लिए मूल मोड (आपको सार्वजनिक X.50 9 और संबद्ध निजी कुंजी की आवश्यकता है):

सार्वजनिक X.50 9 और निजी कुंजी से सीएसआर उत्पन्न करें:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

निजी कुंजी के साथ सीएसआर पुनः हस्ताक्षर करें:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

2
2018-01-22 16:35





जब आपका रूट प्रमाणपत्र समाप्त हो जाता है, तो ऐसे कर्ट करें जिन्हें आपने इसके साथ हस्ताक्षर किया है। आपको एक नया रूट प्रमाण उत्पन्न करना होगा और इसके साथ नए प्रमाणपत्र हस्ताक्षर करना होगा। यदि आप हर कुछ वर्षों में प्रक्रिया को दोहराना नहीं चाहते हैं तो केवल वास्तविक विकल्प रूट प्रमाण पर मान्य तिथि को दस या बीस साल की तरह विस्तारित करना है: मैंने अपने स्वयं के उपयोग के लिए उत्पन्न जड़ को बीस साल निर्धारित किया है।

आप रूट प्रमाण को "नवीनीकृत" नहीं कर सकते हैं। आप जो भी कर सकते हैं वह एक नया उत्पन्न होता है।

अपने पुराने व्यक्ति की समयसीमा समाप्त होने से कम से कम एक या दो साल पहले एक नई जड़ उत्पन्न करें ताकि कुछ गलत होने पर समय की दीवार के बिना आपके पास बदलने का समय हो। इस तरह आप हमेशा अस्थायी रूप से पुरानी कर्टों पर वापस स्विच कर सकते हैं जब तक आपको नए समाधान के साथ आपकी परेशानी की समस्या न हो जाए।

जहां तक ​​वीपीएन सुरंगें चलती हैं, मैं प्रयोग करने के लिए कुछ टेस्टबेड सर्वर स्थापित करूँगा ताकि आप समझ सकें कि क्लाइंट की मशीन के साथ ऐसा करने से पहले आपको क्या करना है।


0
2017-09-03 23:59



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


@Bianconiglio plus -set_serial मेरे लिए काम किया। मेरा सर्वर केवल इंट्रानेट है इसलिए मैं साइड इफेक्ट्स के बारे में ज्यादा चिंता नहीं कर रहा हूं और अब मेरे पास "उचित" समाधान पर काम करने का समय है।

मैंने निम्नलिखित कॉन्फ़िगर करने योग्य स्क्रिप्ट का उपयोग किया। बस चरम सीएसीआरटी, केकी और न्यूका सेट करें।

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

0
2018-06-30 17:33





हमारे पास एक ही समस्या है, और यह हमारे मामले में था क्योंकि डेबियन सर्वर पुराना था, और ओपनएसएसएल को यह समस्या थी:

https://en.wikipedia.org/wiki/Year_2038_problem

डेबियन 6 के लिए उपलब्ध ओपनएसएसएल का अंतिम संस्करण इस समस्या को लाता है। 23.01.2018 के बाद बनाए गए सभी प्रमाणपत्र एक वैधता पैदा करते हैं: 1 9 01 साल के लिए!

समाधान ओपनएसएसएल को अपडेट करना है। आप क्लाइंट के लिए कॉन्फ़िगरेशन फ़ाइलों (प्रमाणपत्रों के साथ) फिर से बना सकते हैं।


0
2018-03-09 10:38