Seite wählen

NETWAYS Blog

SSL leicht gemacht – Zusammengehörigkeit von Zertifikaten überprüfen

von | Aug 23, 2017 | , , ,

Kürzlich hatten wir den Fall, dass uns ein Zertifikat auf einen alten CSR ausgestellt wurde und wir beim Einbinden in den Webserver Fehler erhielten.
Im Apache äußerte sich das ganze mit der Logausgabe:

[error] Unable to configure RSA server private key
[error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Dahingehend wurde bei der Einrichtung und Erneuerung der Zertifikate bei uns der Workflow angepasst. Jetzt werden zusätzlich vor dem Einlesen der Config noch die Prüfsummen der einzelnen Bestandteile verglichen, um solche Fehler zu vermeiden.
Mit den nachfolgenden Kommandos lassen sich die jeweiligen Prüfsummen ausgeben. Diese müssen jeweils zu allen anderen übereinstimmen.

openssl rsa -noout -modulus -in /etc/apache2/ssl/netways.de/netways.de.key | md5sum
d0ed27eb1ecf771abc1e789c96e9b640
openssl req -noout -modulus -in /etc/apache2/ssl/netways.de/netways.de.csr | md5sum
d0ed27eb1ecf771abc1e789c96e9b640
openssl x509 -noout -modulus -in /etc/apache2/ssl/netways.de/certificate.crt | md5sum
d0ed27eb1ecf771abc1e789c96e9b640

Dann klappts auch mit dem Zertifikat und man kann sich sicher sein, alle zusammengehörigen Dateien zu haben.
Hinweis: Im Internet gibt es SSL Validation Checker wie Sand am mehr, allerdings rate ich auch an dieser Stelle dringend davon ab, SSL Keyfiles aus Produktionsumgebungen aus der Hand zu geben und in ein Online-Formular einzufügen. Diese Online-Checker greifen übrigens auch nur auf dieses einfache Verfahren zurück.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Zeit ist einzigartig

von | Aug 21, 2015 | , , , ,


Einige haben erst am 12. Dezember 2012 gemerkt, dass die Zeit einzigartig ist. CAs hingegen wissen das schon seit Längerem und wissen dies auch effektiv zu nutzen. Bei meinem letzten Setup bin ich wieder über diese Falle gestolpert: Die Einrichtung der externen CA und des Puppetmasters ging wie immer ohne Probleme, nur jegliche Zertifikate wollten nicht akzeptiert werden. Wer Puppet einsetzt wird diese Fehlermeldung sofort erkennen:
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet ]
Wir können in diesem Fall zum einen prüfen, ob unsere CA die selbe ist.
Mit OpenSSL können Zertifikate lesbar dargestellt werden.
openssl x509 -text -noout -in /path/to/ssl/certs/ca.pem | grep Issuer
In dem Output sollte dann eine Zeile mit dem Issuer zu sehen sein und wenn dieser mit der Puppet CA nicht übereinstimmt, müssen deren Einstellungen überprüft werden. Dabei können diese Befehle hilfreich sein.
sudo puppet master --configprint certname
sudo puppet master --configprint ca
Sobald aber hier alles richtig konfiguriert wurde, ist es zum anderen gut ein Auge auf die Zeit zu werfen.
Wenn die Zeit nicht stimmt kann es dazu kommen, dass Zertifikate in der Zukunft ausgestellt werden und diese für die CA keine Gültigkeit besitzen.
Ein einheitlicher Zeitserver kommt diesem Problem entgegen, denn mit ihm vermeiden wir Zertifikate in der Zukunft auszustellen. Wenn dieser nicht vorhanden ist, reicht ein einfaches:
sudo apt-get install ntp
und eventuell ein kurzer Neustart. Danach muss der Puppet Agent neu signiert werden. Dazu müssen alle Zertifikate gelöscht werden.
Auf dem Puppetmaster:
sudo puppet cert clean yourserver.localdomain
Auf dem Client:
sudo rm -rf /path/to/puppet/ssl/*  #Default ist /var/lib/puppet/ssl/
Anschließend kann ein neuer Testlauf auf dem Agent ausgeführt werden, der dann ein neues Zertifikat generiert
sudo puppet agent --test
und durch den Puppetmaster validieren lässt.
sudo puppet cert sign yourserver.localdomain
P.S.: Achtet bei eurer Icinga2 HA Installation auch auf die Zeit, hier werden ebenfalls SSL Zertifikate benutzt und unterschiedliche Zeitserver können zu Zeitverschiebungen (im Projekt) führen. 😉

Thilo Wening
Thilo Wening
Manager Consulting
Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.
Lies mehr von Thilo und triff unser Team

Safari durch den Zertifikatsdschungel

von | Aug 16, 2011 | , , ,

PEM ist das mt Abstand meistgenutze Format. Es handelt sich hierbei um Base64 kodierte ASCII-Dateien, die ein „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE Statement beinhalten. Ülicherweise werden sie mit einem Suffix wie .pem, .crt, .cer oder .key versehen.
Serverzertifikate, Zwischenzertifikate und private Schlüssel können alle im PEM-Format vorliegen oder in dieses konvertiert werden. Apache oder ähnliche Server benutzen das PEM-Format. Mehrere PEM Zertifikate und auch der private Schlüssel können in einer Datei zusammengefaßt werden. Aber die meisten Plattformen, wie z.B. der Apache erwarten Zertifiakte und privaten Schlüssel in unterschiedlichen Dateien.
DER ist ein binäres Format. Es hat manchmal .der als Suffix, kann aber auch auf .cer enden. Um herauszufinden, ob das vorligende Zertifikat im PEM- oder DER-Format vorliegt, ist einfach zu prüfen, ob die oben beschriebenen Statements vorkommen. Dieses kann man auch durch einfaches öffnen in einem Texteditor ermitteln.
Alle Zertifikatesformen und auch der private Schlüssel können im DER-Format kodiert werden. DER wird typischerweise auf JAVA-Plattformen eingesetzt, da der dortige SSL-Converter nur Zertifikate im DER-Format konvertiert.
PKCS#7 bzw. P7B sind üblicherweise in Base64 kodiert und benutzen ein Suffix, wie .p7b oder .p7c. P7B-Zertifikate sind an den beiden Statements „—–BEGIN PKCS7—–“ und „—–END PKCS7—–“ zu erkennen. Eine P7B Datei beinhaltet nur das Zertifikat und das Zertifikat der signierenden CA, nicht den privaten Schlüssel. Viele Plattformen unterstützen dieses Format, z.B. Tomcat oder Microsoft Windows.
PKCS#12 bzw. PFX ist ein binärkodiertes Format. Das Server-Zertifikat, jedes Zwischenzertifikat und der private Schlüssel werden in einer Datei abgelgt. PFX-Dateien werden typischerweise auf Windows-Plattformen zum im- bzw. exportieren verwendet und enden üblicherweise auf .pfx oder .p12.
Konvertierung mit OpenSSL
PEM -> PKCS12: openssl pkcs12 -export -out certificate.pfx -inkey private.key -in certificate.crt -certfile CACert.crt
PEM -> DER: openssl x509 -outform der -in certificate.pem -out certificate.der
PEM -> P7B: openssl crl2pkcs7 –nocrl -in certificate.cer -out certificate.p7b -certfile CACert.cer
DER -> PEM: openssl x509 -inform der -in certificate.cer -out certificate.pem
P7B -> PEM: openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
P7B -> PFX: openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer; openssl pkcs12 -export -in certificate.cer -inkey private.key -out certificate.pfx -certfile CACert.cer
PFX -> PEM: openssl pkcs12 -in certificate.pfx -out certifikate.cer -nodes
Bei der Konvertierung von PFX nach PEM packt openssl alle Zertifikate und den privaten Schlüssel in eine Datei. Es ist jedoch leicht möglich die jeweiligen Zertifikate, sowie den privaten Schlüssel mit den BEGIN- und END-Statements per Copy’n’Paste in eigene Datei zu kopieren und zu speichern.

Lennart Betz
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Lies mehr von Lennart und triff unser Team

Trainings

Web Services

Events