Vraag Certificeringsinstantie rootcertificering verlopen en verlengen


In 2004 heb ik een kleine certificeringsinstantie opgezet met behulp van OpenSSL op Linux en de eenvoudige beheerscripts die bij OpenVPN zijn geleverd. In overeenstemming met de gidsen die ik destijds vond, heb ik de geldigheidsperiode voor het basiscertificaat ingesteld op 10 jaar. Sindsdien heb ik veel certificaten ondertekend voor OpenVPN-tunnels, websites en e-mailservers, die allemaal ook een geldigheidsperiode van 10 jaar hebben (dit kan verkeerd zijn geweest, maar ik wist toen niet hoe het beter was).

Ik heb veel handleidingen over het opzetten van een CA gevonden, maar slechts heel weinig informatie over het beheer ervan, en in het bijzonder over wat er moet gebeuren wanneer het certificaat van de basiscertificeringsinstantie vervalt, wat in 2014 ergens zal gebeuren. Ik heb dus het volgende vragen:

  • Worden de certificaten met een geldigheidsperiode die na het verstrijken van het root-CA-certificaat wordt verlengd, ongeldig zodra deze verloopt of blijven ze geldig (omdat ze zijn ondertekend tijdens de geldigheidsperiode van het CA-certificaat)?
  • Welke bewerkingen zijn nodig om het root-CA-certificaat te vernieuwen en te zorgen voor een soepele overgang bij het verlopen ervan?
    • Kan ik het huidige root-CA-certificaat op een of andere manier opnieuw ondertekenen met een andere geldigheidsperiode en het nieuw ondertekende certificaat uploaden naar clients zodat clientcertificaten geldig blijven?
    • Of moet ik alle clientcertificaten vervangen door nieuwe die zijn ondertekend door een nieuw root-CA-certificaat?
  • Wanneer moet het CA-basiscertificaat worden vernieuwd? In de buurt van expiratie, of een redelijke tijd voordat deze verloopt?
  • Als de vernieuwing van het root-CA-certificaat een belangrijk stuk werk wordt, wat kan ik nu beter doen om te zorgen voor een soepelere overgang bij de volgende vernieuwing (behalve wanneer de geldigheidsperiode wordt ingesteld op 100 jaar natuurlijk)?

De situatie wordt iets ingewikkelder gemaakt door het feit dat mijn enige toegang tot een aantal van de clients is via een OpenVPN-tunnel die een certificaat gebruikt dat is ondertekend door het huidige CA-certificaat, dus als ik alle client-certificaten moet vervangen, moet ik dit kopiëren de nieuwe bestanden naar de client, herstart de tunnel, steek mijn vingers over en hoop dat het daarna komt.


87
2017-08-30 08:34


oorsprong




antwoorden:


Als u dezelfde persoonlijke sleutel op uw basis-CA behoudt, kunnen alle certificaten met succes worden gevalideerd tegen de nieuwe root; alles wat van je wordt verlangd is om de nieuwe root te vertrouwen.

De ondertekening van het certificaat is gebaseerd op een handtekening van de privésleutel; het behouden van dezelfde privésleutel (en impliciet dezelfde publieke sleutel) bij het genereren van een nieuw openbaar certificaat, met een nieuwe geldigheidsperiode en eventuele andere nieuwe kenmerken die worden gewijzigd als dat nodig is, houdt de vertrouwensrelatie op zijn plaats. CRL's kunnen ook doorgaan van het oude cert naar het nieuwe, omdat ze, net als certificaten, worden ondertekend door de private sleutel.


Dus laten we het verifiëren!

Maak een root-CA:

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

Genereer er een onderliggende certificaat van:

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

Onderteken het kind cert:

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

Alles staat daar, normale certificaatrelatie. Laten we het vertrouwen verifiëren:

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

Oké, laten we nu zeggen 10 jaar voorbij. Laten we een nieuw openbaar certificaat genereren met dezelfde root-private sleutel.

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

En ... werkte het?

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

Maar waarom? Het zijn verschillende bestanden, toch?

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

Ja, maar dat betekent niet dat de nieuwe openbare sleutel niet cryptografisch overeenkomt met de handtekening op het certificaat. Verschillende serienummers, dezelfde modulus:

# 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

Laten we iets verder gaan om te verifiëren dat het werkt in echte certificaatverificatie.

Start een Apache-instantie op en laten we het eens proberen (debian-bestandsstructuur, aanpassen indien nodig):

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

We zullen deze richtlijnen instellen op a VirtualHost luisteren op 443 - onthoud, de newroot.pem rootcertificaat bestond niet eens toen cert.pem werd gegenereerd en ondertekend.

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

Laten we eens kijken hoe openssl het ziet:

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

Ok, en hoe zit het met een browser met MS crypto-API? Moet de root vertrouwen, ten eerste, dan is het allemaal goed, met het serienummer van de nieuwe root:

newroot

En we zouden ook nog steeds met de oude root moeten werken. Schakel de configuratie van Apache om:

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

Voer een volledige herstart uit op Apache, een reload schakelt de certs niet correct om.

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

En, met de crypto API-browser van MS, presenteert Apache de oude root, maar de nieuwe root staat nog steeds in de vertrouwde root-store van de computer. Het vindt het automatisch en valideert de cert tegen de vertrouwde (nieuwe) root, ondanks dat Apache een andere keten presenteert (de oude root). Na het verwijderen van de nieuwe root van vertrouwde roots en het toevoegen van de originele root cert, is alles goed:

oldroot


Dus dat is het! Bewaar dezelfde privésleutel wanneer u deze verlengt, wissel de nieuwe vertrouwde root in en het vrijwel allemaal werkt gewoon. Succes!


124
2017-09-04 18:40



Hoe dan ook, wat heeft het voor zin om een ​​nieuw basiscertificaat te maken als je dezelfde privésleutel gewoon opnieuw gaat gebruiken? Als je dit steeds weer opnieuw doet, waarom zou je dan een vervaldatum voor het certificaat hebben? Ik dacht dat de root-expiratie werd gebruikt om beheerders te dwingen een nieuwere (waarschijnlijk sterkere) privésleutel te maken die beter beveiligd is tegen de steeds verder gaande machines die de sleutels proberen te verbreken. Een 40-bits sleutel die 20 jaar geleden is gemaakt, is niet veilig genoeg voor - jvhashe
@jvhashe Als het rootcertificaat niet langer cryptografisch sterk genoeg is, zou u het moeten verwijderen, ongeacht de vervaldatum. Als je je eigen root genereert, is er niets dat je ervan weerhoudt het in te stellen om honderden jaren voorbij te gaan wanneer je niet langer op de planeet bent. Vervaldatum is nauwelijks relevant op een rootcertificaat - en voor een kindcertificaat gaat de expiratie ook niet echt over cryptografische sterkte (vraag de CA's die zich voorbereiden op het intrekken van alle 1024-bit-certificaten in oktober) - zie hier voor meer informatie. - Shane Madden♦
In aanvulling op het bovenstaande, vond ik dat het serienummer hetzelfde moet zijn om deze methode te laten werken. - Scott Presnell
-set_serial 01 - WTF ??? JE KUNT GEEN SERIUMNUMMERS HERGEBRUIKEN. Heb je zelfs geraadpleegd RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building? Of verzin je het gewoon terwijl je doorgaat? U hebt geen idee van de problemen die u veroorzaakt in gebruikersagenten wanneer ze beginnen met het maken van een pad. - jww
@jww Heb je het antwoord gelezen? Dat is slechts een demonstratie van het feit dat de cryptografie werkt. Die opdracht genereert letterlijk een testcertificaat dat we later kunnen verifiëren om de relatie tussen het oude en het nieuwe rootcertificaat te testen. Als iemand is als ik die commando's rechtstreeks gebruik, hoop ik echt dat er iets breekt, en ze beseffen dat ze aandacht moeten schenken aan de context van iets voordat ze het blindelings rennen (of uit de buurt komen van het feit of 01 is een acceptabele serie in een lab). - Shane Madden♦


Ik heb gemerkt dat CA-extensies mogelijk ontbreken in het vernieuwde certificaat van de oorspronkelijke CA-sleutel. Dit werkte meer geschikt voor mij (het creëert een ./renewedselfsignedca.conf waar v3 CA-extensies zijn gedefinieerd, en ca.key en ca.crt worden verondersteld de originele CA-sleutel en het certificaat te zijn):

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



Dit is een zeer nuttige toevoeging geweest. Het feitelijk geldige antwoord resulteert niet in een voldoende compatibel certificaat voor mij als je willekeurige instellingen op je originele root hebt. - Theuni
Gedetacheerd, zeer nuttig. Een andere toevoeging: zoals Scott Presnell in de opmerkingen bij het geaccepteerde antwoord, moest ik ook het hexadecimale serienummer van het vernieuwde certificaat handmatig opgeven, zodat het overeenkwam met het oude certificaat. Dit betekende toevoegen -set_serial 0xdeadbeefabba (niet het echte serienummer nee :)) voor het laatste x509-commando. Pas toen controleerden mijn clientcertificaten met succes het vernieuwde CA-certificaat. - JK Laiho
Deze methode is eenvoudiger omdat deze dezelfde informatie behoudt als het vorige certificaat. - lepe
Ik heb een script gemaakt voor deze oplossing plus -set_serial - zie mijn antwoord - Wolfgang Fahl
Dit antwoord heeft me veel werk bespaard, na bijna een dag aan een kwestie te hebben besteed die dit vereiste, stond ik bijna op het punt om op te geven, ik tip hier mijn pet voor! - Onitlikesonic


Basismodus om de geldige rootperiode te verlengen (u heeft de openbare X.509 en de toegewezen private sleutel nodig):

Genereer de CSR van openbare X.509 en privésleutel:

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

Onderteken de CSR met privésleutel:

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

2
2018-01-22 16:35





Wanneer uw rootcertificaat vervalt, nemen ook de certificaten waarmee u zich hebt aangemeld. U zult een nieuwe root cert moeten genereren en nieuwe certificaten ermee moeten ondertekenen. Als je om de paar jaar het proces niet wilt herhalen, is de enige echte optie om de geldige datum op de root cert uit te breiden naar iets als tien of twintig jaar: de root die ik heb gegenereerd voor eigen gebruik heb ik twintig jaar uiteengezet.

U kunt een root cert niet "vernieuwen". Het enige dat u kunt doen, is een nieuwe genereren.

Genereer een nieuwe root minstens een jaar of twee voordat je oude vervalt, zodat je de tijd hebt om over te schakelen zonder tegen een tijdmuur te zijn als er iets misgaat. Op die manier kunt u altijd tijdelijk terugschakelen naar de oude certificaten totdat u uw kinderziektes met de nieuwe hebt opgelost.

Wat de VPN-tunnels betreft, zou ik een paar testbedservers instellen om mee te experimenteren, zodat u precies begrijpt wat u moet doen voordat u het met de computer van een klant doet.


0
2017-09-03 23:59



Dit antwoord lijkt te suggereren dat het mogelijk is om een ​​rootcertificaat te vernieuwen door de sleutel opnieuw te gebruiken. Maar ik vermoed dat dit niet anders is dan helemaal opnieuw beginnen, omdat de nieuwe cert een andere handtekening zal hebben en daarom geen bestaande client-certificaten zal valideren. - Remy Blank
ja, je kunt de geldige periode verlengen ... en is minder werk dan het opnieuw aanmaken van alle pki, client-certificaten en het opnieuw toewijzen van nieuwe root ... - ggrandes
Het deel over het uitgeven van nieuwe eindentiteitscertificaten is niet noodzakelijk waar. Dit hangt af van hoe de Authority Key Identifier (AKID) wordt gerepresenteerd in de CA's voor ondergeschikten en eindentiteitscertificaten. Als de AKID is gebaseerd op {Distinguished Name, Serial Number}, dan zal de continuïteit worden bereikt. Zie ook RFC 4518, Internet X.509 Public Key Infrastructure: Certification Path Building. - jww


@Bianconiglio plus -set_serial werkte voor mij. Mijn server is alleen intranet, dus ik maak me niet veel zorgen over de bijwerkingen en ik heb nu de tijd om aan een "juiste" oplossing te werken.

Ik heb het volgende configureerbare script gebruikt. Stel gewoon de variabelen CACRT, CAKEY en NEWCA in.

# 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





We hebben hetzelfde probleem gehad, en dat was in ons geval omdat de Debian-server up-to-date was en de openSSL dit probleem had:

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

De laatste versie van OpenSSL die beschikbaar is voor Debian 6 brengt dit probleem. Alle certificaten die na 23.01.2018 zijn gemaakt, produceren een Vality: voor 1901 jaar!

De oplossing is om de OpenSSL bij te werken. U kunt opnieuw de configuratiebestanden (met de certificaten) voor de clients maken.


0
2018-03-09 10:38