Überprüfen und Testen der neu ausgestellten Zertifikate
Nichts ist peinlicher, wenn ein SSL/TSL-Zertifikat nicht die richtigen Werte hat oder nicht richtig ausgeliefert wird, und sich infolgedessen die Benutzer - vor allem bei Mailservern und Mailclients - anfangen zu beschweren. Deshalb kann man bereits nach der Erstellung des Zertifikats es überprüfen. Dazu dient hauptsächlich der Befehl openssl.
Lokale Prüfungen
Alle Zertifikatsdetails werden hiermit angezeigt.
~# openssl x509 -in /etc/letsencrypt/live/mail.example.com/fullchain.pem -text -noout
Das zeigt für welche Domain (Subject), welchen Herausgeber (Issuer) - z. B. Let's Encrypt - das Zertifikat ausgestellt wurde. Und welche Gültigkeit (Validity) es besitzt und für welche alternative Domainnamen es gültig ist - SAN (Subject Alternative Names). Des Weiteren liefert der Befehl Informationen über den Public Key und die verwendeten Extensions.
Ist nur das Ablaufdatum von Interesse, dann hilft diese Variante
~# openssl x509 -enddate -noout -in /etc/letsencrypt/live/mail.example.com/fullchain.pem
Die Chain überprüfen, also ob alle Zertifikate in der Datei enthalten sind, erfolgt mit
~# awk 'BEGIN {c=0;} /BEGIN CERT/{c++} END{print c}' /etc/letsencrypt/live/mail.example.com/fullchain.pem
~# 2
Dann kann man mit den folgenden Befehl sicherstellen, dass das Zertifikat und der private Key zusammenpassen
~# openssl x509 -noout -pubkey -in /etc/letsencrypt/live/mail.example.com/fullchain.pem | openssl pkey -pubin -outform DER | sha256sum
~# openssl pkey -in /etc/letsencrypt/live/mail.example.com/privkey.pem -pubout -outform DER | sha256sum
Es muss beide Male ein identischer Wert herauskommen. Und da Let's Encrypt ECDSA-Zertifikate verwendet, ist das der richtige Befehl bei diesen Zertifikaten.
Testen aus der Client-Perspektive
Es hilft nichts, man will ja auch wissen, wie die Clients (Mailclients, Webbrowser) das Zertifikat erhalten. Das testet über STARTTLS, ob der Mailserver das richtige Zertifikat ausliefert und eine Verbindung aufbaut.
~# openssl s_client -connect mail.example.com:25 -starttls smtp
Für den IMAPs-Server Dovecot testet man wie folgt.
~# openssl s_client -connect mail.example.com:993
Für POP3S (POP3 Secure) testet man wie folgt.
~# openssl s_client -connect mail.example.com:995
Interessiert einen die Ausgabe des Webservers über HTTPs, dann ist das die richtige Variante.
~# openssl s_client -connect mail.example.com:443
In beiden Fällen wird geprüft
- ob der TLS-Handshake erfolgreich ist.
- welches Zertifikat der Server sendet.
- ob die Zertifikatskette vollständig ist.
- auf eventuelle Fehler (z. B. self-signed, untrusted, expired).
Validierung von Zertifikat und Hostname
Hiermit kann das Zertifikat gegen den Hostnamen validiert werden.
~# openssl s_client -connect mail.example.com:443 -servername mail.example.com
Dabei ist -servername bei Servern mit SNI (Server Name Indication), also bei Webservern mit mehreren Domains auf derselben IP, wichtig. Ein positives Ergebnis liegt vor, wenn die Meldung “Verify return code: 0 (ok)” in der Ausgabe auftaucht.
Nachweis der vollständigen Kette (CA Chain)
Um zu prüfen, ob alle Intermediate-Zertifikate mitgeschickt werden, kann man diesen Befehl einsetzen.
~# openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts
Dabei sollten mindestens zwei Zertifikate angezeigt werden:
- Das Domain-Zertifikat selber.
- Und das Let's Encrypt Intermediate-Zertifikat.
Ablaufdatum eines Zertifikats remote anzeigen
Wenn man nur wissen will, wann das HTTPS-Zertifikat ablaufen wird, dann hilft dieses hier.
~# echo | openssl s_client -connect mail.example.com:443 -servername mail.example.com 2>/dev/null | openssl x509 -noout -dates
Es macht in jedem Fall Sinn, auf diese Art und Weise Clients zu testen, da die Software-Produkte der unterschiedlichen Anbieter sich auch unterschiedlich verhalten können und dabei meistens nichtssagende Fehlermeldungen ausspucken.
