Wir haben mehr als 700 Zertifikate, die von Easy-RSA 2 für die OpenVPN-Nutzung generiert wurden. Ich weiß nicht, wie das passiert ist (ich vermute, dass es einmal von jemandem gelöscht wurde index.txt, serialoder beides), aber mehr als die Hälfte der generierten Zertifikate haben identische Seriennummern. Außerdem index.txtenthält das Original nur die Hälfte aller Zertifikate (die letzte Hälfte), die vorherigen nicht mitgerechnet.
Neue Zertifikate können also erstellt werden, das ist OK. Aber wenn ich versuche, ein Zertifikat zu widerrufen, das nicht vorhanden ist index.txt, tritt ein Fehler auf.
index.txtIch habe versucht, es per Skript neu zu erstellen :
for cert in *.crt
do
echo "-> $cert"
enddate=`openssl x509 -enddate -noout -in $cert | sed 's/notAfter=//' | awk '\
{ year=$4-2000;
months="JanFebMarAprMayJunJulAugSepOctNovDec" ;
month=1+index(months, $1)/3 ;
day=$2;
hour=substr($3,1,2) ;
minutes=substr($3,4,2);
seconds=substr($3,7,2);
printf "%02d%02d%02d%02d%02d%02dZ", year, month, day, hour, minutes, seconds}'`
serial=`openssl x509 -serial -noout -in $cert |sed 's/serial=//'`
subject=`openssl x509 -subject -noout -in $cert |sed 's/subject= //'`
echo -e "V\t$enddate\t\t$serial\tunknown\t$subject" >>index.txt
done
Es liest die Zertifikate einzeln, ruft ihre Daten ab und füllt neue aus index.txt. Alles scheint in Ordnung zu sein.
Aber laut dem oberen Text füllt das Skript es mit Zertifikaten, die die gleichen Seriennummern haben. Mit diesem neu erstellten Zertifikat index.txtkann ich also nichts mit Zertifikaten machen (erstellen, widerrufen usw.).
Die Frage ist: Gibt es Möglichkeiten, index.txtdie Basis zu reparieren, wenn ich alle Zertifikate habe? Oder vielleicht irgendwie die Seriennummer eines Zertifikats zu ändern (einfach den Dateikopf zu ändern *.crtbewirkt nichts – die Seriennummer bleibt alt, wenn sie abgefragt wird openssl)
Wenn nicht, muss ich nur die Zertifikate widerrufen, die nicht in sind index.txt. Kann ich das ohne index.txtBasis tun?
Antwort1
Wir haben mehr als 700 Zertifikate ... mehr als die Hälfte der generierten Zertifikate haben identische Seriennummern ... Die ursprüngliche Datei „index.txt“ enthält nur die Hälfte aller Zertifikate (letzte Hälfte), die vorherigen nicht eingeschlossen.
Ich werde versuchen, Sie in die richtige Richtung zu lenken, aber ich kann es wahrscheinlich nicht bis zum Ende durchziehen, da ich keinen Prüfstand eingerichtet und das Problem reproduziert habe. Ich entschuldige mich im Voraus.
Wenn Sie einen umfassenderen Überblick über die Ausstellung eines Zertifikats in einer privaten PKI wünschen, lesen SieWie unterzeichnen Sie eine Zertifikatsignieranforderung bei Ihrer Zertifizierungsstelle?Es wird erklärt, wie Sie die Dinge manuell erledigen würden, wenn Easy-RSA sie nicht für Sie erledigen würde.
Ein weiteres wichtiges Dokument istRFC 4158, Internet X.509 Public Key Infrastructure: Aufbau eines Zertifizierungspfads. Das ist__Die__{Issuer Distinguished Name,Serial Number}Dokument, in dem erklärt wird, was Übereinstimmungen sind und wie Sie Tupel wie oder verwenden können, {Subject Distinguished Name,Public Key Identifier}um zwei Zertifikate auf Gleichwertigkeit zu vergleichen. OpenSSL verwendet dieses Dokument zum Abgleichen. Siehe auch Abschnitt 3.5.15,„Endpunkt-Distinguished Name (DN)-Übereinstimmung“und Abschnitt 3.5.12,„Übereinstimmende Schlüsselkennungen (KIDs)“.
Die Seriennummern müssen eindeutig sein. Dies ist das zu lösende Problem.Betreff: Distinguished Names (DN)sind eine andere Geschichte. Wenn Ihr openssl.cnfhat unique_subject=yes, können sie nicht dupliziert werden. Wenn unique_subject=no, können die DNs dupliziert werden.
Ich denke, Sie müssen ein paar Dinge tun. Verwenden Sie zunächst eine moderne oder aktualisierte Version der OpenSSL-Dienstprogramme. „Modern“ bedeutet hier eine der neueren Versionen 1.0.2 oder 1.1.0. Frühere Versionen des Dienstprogramms hatten subtile Probleme beim Abgleichen von Namen und Seriennummern.
Zweitens, untersuchen Sie Ihre Konfigurationsdatei (normalerweise, openssl.cnfaber Sie können eine andere, möglicherweise kopierte Datei mit verwenden -config filename) und notieren Sie sich die relevanten Einstellungen, wie serial.txtund unique_subject=no. Ich glaube, dies sind die relevanten von [CA_Default]von openssl.cnf:
base_dir = .
certificate = $base_dir/cacert.pem # The CA certifcate
private_key = $base_dir/cakey.pem # The CA private key
new_certs_dir = $base_dir # Location for new certs after signing
database = $base_dir/index.txt # Database index file
serial = $base_dir/serial.txt # The current serial number
unique_subject = no # Allow reuse of subjects
Drittens: Sichern Sie alles, insbesondere die wichtigen Dinge wie index.txtund serial.txt.
Viertens: Erstellen Sie eine Liste der Zertifikate, die Sie widerrufen möchten. Die Liste kann Einträge wie Dateinamen - enthalten john-doe-vpn.pem. Verschieben Sie sie bei Bedarf in einen eigenen Ordner. Vorzugsweise sollte jedes eine eindeutige Seriennummer haben und sie MÜSSEN alle denselben Ausstellernamen haben; die Funktionen openssl caund ocspkönnen nicht mehr als einen Aussteller gleichzeitig verarbeiten, obwohl das Protokoll dies für OCSP könnte.
Fünftens: Erstellen Sie eine neue index.txtZeile, die eine Zeile für jede Seriennummer enthält. Ein Ansatz besteht darin, den Betreff, die Seriennummer und das Ablaufdatum aus jeder Zertifikatsdatei zu extrahieren, wie in dem von Ihnen geposteten Skript, obwohl Sie den Großteil der Shell-Arbeit in ein OpenSSL und ein Awk pro Zertifikat zusammenfassen können:
for f in *files*; do
openssl x509 -noout -enddate -serial -subject -in $f \
| awk 'BEGIN{FS="=";OFS="\t"} /^serial/{num=$2} /^subject/{sub=$2}
/^notAfter/{split($2,a,/ /);mon=index(months,a[1])/3+1;day=a[2]...exp=sprintf(...)}
END{print "V",exp,"",num,sub}' >>index.txt
done
Wenn es schwierig ist, doppelte Seriennummern im Voraus (zuverlässig) zu entfernen, können Sie alles eingeben und dann Duplikate mit awk -F'\t' '!already[$4]++'oder sort -t$'\t' -k4,4 -uoder ähnlich verwerfen.
Ein anderer Ansatz, der ab 1.0.2 verfügbar, aber nur in 1.1.0 dokumentiert ist, besteht darin, openssl ca [-config conffile] -valid certfilediese Extraktion automatisch durchzuführen. Dabei wird jedoch -validder private CA-Schlüssel jedes Mal unnötigerweise geladen. Wenn Ihr privater Schlüssel also – wie empfohlen – kennwortverschlüsselt ist, müssen Sie Ihr Kennwort immer wieder eingeben. Um Zeit zu sparen, ersetzen Sie den echten CA-Schlüssel und das Zertifikat vorübergehend durch einen nicht verschlüsselten Arbeitsschlüssel und ein passendes, aber ansonsten gefälschtes (wahrscheinlich selbst signiertes) Zertifikat. -validEs wird kein doppelter Serieneintrag geschrieben, Sie müssen sich also nicht darum kümmern, sie auszuschließen oder zu entfernen.
Tragen Sie in die serialDatei einen Wert ein, dermindestensder höchste Wert aller zuvor ausgestellten Zertifikate; wenn Sie aus Sicherheitsgründen und vielleicht auch zur besseren Übersichtlichkeit zum nächsten 10000oder was auch immer springen möchten , ist das in Ordnung. Möglicherweise müssen Sie an dieser Stelle festlegen.1000000unique_subject=no
Sechstens, markieren Sie jedes Zertifikat (Seriennummer) in der indexDatei als widerrufen. Sie können die Zertifikatsdateien durchlaufen, indem Sie jeweils „ openssl ca -revokeon each“ verwenden, aber es ist einfacher, einfach awk zu verwenden, wie:
awk -F'\t' -vOFS='\t' '{$1="R"; $3="161101000000Z"}' <index.txt >temp && mv temp index.txt
# if you want, you can add a comma and a reason, see man ca or
# online at https://www.openssl.org/docs/manmaster/man1/ca.html
# under -crl_reason. But there isn't a code for 'CA stupid', and
# in practice the reason doesn't really matter to reliers except
# you should't use hold or remove (latter noted in the man)
Siebtens: Generieren Sie daraus eine CRL indexund openssl ca -gencrl [-crldays n] [-out file]/oder richten Sie damit einen OCSP-Responder ein, wenn (eines der) alten Zertifikate die OCSP-Erweiterung angegeben hat.
Achtens: Sobald Sie die CRL verteilt haben und/oder den (neuen) OCSP-Responder ausführen,alleZertifikate mit den betroffenen Seriennummern werden widerrufen und führen bei Verwendung (und ordnungsgemäßer Überprüfung) zum Kommunikationsfehler. Wennbeliebigder duplizierten Seriennummern in Zertifikaten enthalten sind, die Ihre Systeme noch verwenden, müssen diese zuerst ersetzt werden. Wenn Sie noch die Anforderungsdateien (CSRs) von den Systemen haben, die die betroffenen Zertifikate verwenden, können Sie openssl ca [-config conffile] [-in reqfile | -infiles reqfile...]die neuen Zertifikate einfach neu ausstellen und an die betreffenden Systeme senden und sie von den Betreibern dieser Systeme installieren lassen. Andernfalls müssen Sie sich zuerst vom Betreiber jedes Systems eine CSR senden lassen, die er zuvor verwendet (und gespeichert) hat, oder eine neue, die er generiert.
Stellen Sie abschließend alle „guten“ Einträge (Seriennummern, die Sie nicht widerrufen haben) aus der alten indexDatei wieder her und kombinieren Sie sie mit allen neuen Einträgen für Ersatzzertifikate, die in #8 oben ausgestellt wurden. Wenn Sie einen OCSP-Responder verwenden (siehe oben), müssen Sie auch die widerrufenen Einträge behalten; es spielt keine Rolle, ist aber wahrscheinlich einfacher.nichtStellen Sie den alten Wert wieder her, serialwenn dieser niedriger ist als der höchste alte Zertifikatswert.oderdas höchste neue Ersatzzertifikat, sondern lassen Sie es vom neuen Wert aus weiter hochzählen.
Zu den for-loopDruckdaten:
hour=substr($3,1,2) ;
minutes=substr($3,4,2);
seconds=substr($3,7,2);
printf "%02d%02d%02d%02d%02d%02dZ", year, month, day, hour, minutes, seconds}'`
Machen Sie sich keine Gedanken über die Daten. Wenn sie abgelaufen sind, können sie nicht verwendet werden, wenn Ihre PKI ordnungsgemäß funktioniert. Wenn Sie sich dann besser fühlen, löschen Sie den privaten Schlüssel, der mit dem Zertifikat und dem öffentlichen Schlüssel verknüpft ist.
Sie interessieren sich nur für die Liste der zu widerrufenden Zertifikate sowie deren Seriennummer und eindeutigen Namen. Hier würde Ihre Liste aus Zertifikaten wie (1) eines ausscheidenden Mitarbeiters bestehen, der ein nicht abgelaufenes Zertifikat und einen nicht abgelaufenen privaten Schlüssel besitzt (d. h. der Mitarbeiter geht in den Ruhestand oder wird entlassen); (2) eines Mitarbeiters, der ein Gerät verloren hat (d. h. der private Schlüssel ist im Umlauf); usw.
Sie haben noch eine weitere Option: Verbrennen Sie die vorhandene PKI und beginnen Sie von vorne. In diesem Fall besteht Schritt (1) darin, die Stammzertifizierungsstelle und alle Zwischen-/Untergeordneten Zertifizierungsstellen zu widerrufen. Dann werfen Sie den privaten Schlüssel weg. Schritt (2) besteht darin, eine neue Stammzertifizierungsstelle zu erstellen, neue Zwischen-/Untergeordnete Zertifizierungsstellen auszustellen und schließlich neue Endentitätszertifikate auszustellen. Für Schritt (2) können Sie sogar den Signing-Party-Tanz aufführen.
Ob Sie es glauben oder nicht, OpenStack verwendet diese Strategie (oder hat zumindest überlegt, sie zu verwenden). Es handelt sich um eine Art „flüchtige PKI“, die lange genug bestehen bleiben soll, um Ihre Anforderungen zu erfüllen, und dann verworfen wird, wenn etwas schief geht.
Zum Lachen können Sie sich Peter GutmannsTechnische Sicherheit. Er ist gnadenlos, wenn es um PKIs und öffentliche CAs geht.