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

96

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

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

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

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

openssl certificate-authority

— रेमी ब्लैंक
स्रोत

142

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

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

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

एक जड़ बनाओ CA:

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/

हम इन निर्देशों को VirtualHost443 पर एक सुनवाई पर सेट करेंगे - याद रखें, 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 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)

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

newroot

और, हमें अभी भी पुरानी जड़ के साथ काम करना चाहिए। अपाचे के विन्यास को चारों ओर घुमाएँ:

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

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

# 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)

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

oldroot

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

— शेन मैडेन
स्रोत

2

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

— jvhashe

2

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

— शेन मैडेन

3

उपरोक्त के अलावा, मैंने पाया कि इस पद्धति के काम करने के लिए क्रम संख्या समान होनी चाहिए।

— स्कॉट प्रेस्नेल

2

-set_serial 01- डब्ल्यूटीएफ ??? आप सीरियल नंबरों को याद नहीं कर सकते । क्या आपने RFC 4158, इंटरनेट X.509 पब्लिक की इन्फ्रास्ट्रक्चर: सर्टिफिकेशन पाथ बिल्डिंग से भी सलाह ली थी ? या आप बस इसे बना रहे हैं जैसे आप साथ चलते हैं? पथ निर्माण शुरू करने पर आपको उपयोगकर्ता एजेंटों में होने वाली समस्याओं का कोई पता नहीं है।

1

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

— शेन झुंझलाना

14

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

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

— Bianconiglio
स्रोत

2

यह एक अत्यंत सहायक जोड़ रहा है। यदि आपके पास मूल रूट सीए पर मनमानी सेटिंग्स है, तो वास्तव में मान्य उत्तर मेरे लिए पर्याप्त रूप से संगत प्रमाण पत्र नहीं है।

— औनी

1

दूसरा, बहुत मददगार। एक और जोड़: स्कॉट प्रेस्नेल की तरह स्वीकार किए गए उत्तर की टिप्पणियों में, मुझे नए सिरे से प्रमाणपत्र के हेक्साडेसिमल सीरियल नंबर को मैन्युअल रूप से निर्दिष्ट करना पड़ा ताकि यह पुराने से मेल खाए। इसका अर्थ -set_serial 0xdeadbeefabbaबाद के x509 कमांड में वास्तविक सीरियल नंबर :) नहीं जोड़ना है। तभी मेरे ग्राहक प्रमाणपत्रों को नए सिरे से CA प्रमाणपत्र के खिलाफ सफलतापूर्वक सत्यापित किया गया।

— जेके लाहो

यह विधि आसान है क्योंकि यह पिछले प्रमाण पत्र की तुलना में समान जानकारी रखती है।

— 6

मैंने इस समाधान के लिए एक स्क्रिप्ट बनाई है प्लस -set_serial - मेरा उत्तर देखें

— वोल्फगैंग

इस उत्तर ने मुझे बहुत सारे काम बचाए, लगभग एक दिन एक मुद्दे पर खर्च करने के बाद, इसके लिए मुझे लगभग हार माननी पड़ी, मैंने इसके लिए आपसे अपनी टोपी टिप ली!

— Onitlikesonic

2

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

सार्वजनिक X.509 और निजी कुंजी से CSR उत्पन्न करें:

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

— ggrandes
स्रोत

1

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

मैंने निम्नलिखित विन्यास योग्य स्क्रिप्ट का उपयोग किया। बस चर CACRT, केक और NEWCA निर्धारित करें।

# 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

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

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

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

जहाँ तक वीपीएन टनल जाने के बाद, मैं प्रयोग करने के लिए परीक्षण किए गए सर्वरों के एक जोड़े को स्थापित करूँगा ताकि आप ठीक से समझ सकें कि आपको क्लाइंट की मशीन के साथ करने से पहले आपको क्या करना है।

— Snowhare
स्रोत

इस उत्तर से लगता है कि इसकी कुंजी को फिर से उपयोग करके, रूट प्रमाणपत्र को नवीनीकृत करना संभव है। लेकिन मुझे संदेह है कि यह स्क्रैच से शुरू होने से अलग नहीं है, क्योंकि नए सर्टिफिकेट में एक अलग हस्ताक्षर होगा, और इसलिए यह मौजूदा क्लाइंट सीट्स को मान्य नहीं करेगा।

— रेमी ब्लैंक

हां, आप वैध अवधि बढ़ा सकते हैं ... और सभी पक्की, ग्राहक प्रमाणपत्रों को फिर से बनाने और नए रूट को फिर से बनाने से कम काम है ...

— बधाई

नए अंत-इकाई प्रमाण पत्र जारी करने के बारे में भाग जरूरी नहीं कि सच हो। यह इस बात पर निर्भर करता है कि प्राधिकरण कुंजी पहचानकर्ता (AKID) को अधीनस्थ सीए और अंतिम-इकाई प्रमाणपत्रों में कैसे दर्शाया जाता है। यदि AKID {विशिष्ट नाम, क्रम संख्या} पर आधारित है , तो निरंतरता प्राप्त की जाएगी। इसके अलावा RFC 4518, इंटरनेट X.509 पब्लिक की इन्फ्रास्ट्रक्चर: सर्टिफिकेशन पाथ बिल्डिंग ।

0

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

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

डेबियन 6 के लिए उपलब्ध ओपनएसएसएल का अंतिम संस्करण इस समस्या को लाता है। २३.०१.२०१.01 के बाद बनाए गए सभी प्रमाणपत्र एक वैधता का उत्पादन करते हैं: १ ९ ०१ वर्ष के लिए!

समाधान OpenSSL को अद्यतन करना है। आप क्लाइंट के लिए फिर से कॉन्फिग फाइल (सर्टिफिकेट के साथ) बना सकते हैं।

— मैनुएल
स्रोत