verify openssl certificate: Zertifikat mit OpenSSL schnell und sauber prüfen

verify openssl certificate: Warum ich Zertifikate immer selbst prüfe

Wenn ein HTTPS-Problem auftaucht, verlasse ich mich nicht auf Vermutungen. Ich prüfe das Zertifikat direkt. Das spart Zeit und zeigt mir sofort, ob das Problem an der Laufzeit, der Kette oder dem Hostname liegt. Genau dafür ist verify openssl certificate so nützlich.

OpenSSL ist mein Standardwerkzeug, wenn ich ein Zertifikat kontrollieren will. Es ist schnell, überall verfügbar und sagt mir klar, was stimmt und was nicht. Kein Dashboard, kein Blabla. Nur Fakten.

verify openssl certificate: Die wichtigsten Prüfungen

Bevor ich irgendetwas ändere, prüfe ich drei Dinge:

• Gültigkeit – ist das Zertifikat noch aktiv?
• Hostnamen – passt das Zertifikat zur Domain?
• Zertifikatskette – sind Zwischenzertifikate korrekt eingebunden?

Diese drei Punkte lösen die meisten SSL-Probleme. Wenn einer davon fehlschlägt, ist die Ursache meist schon gefunden.

verify openssl certificate mit dem richtigen Befehl

Der einfachste Weg ist dieser:

openssl s_client -connect example.com:443 -servername example.com

Damit hole ich mir das Zertifikat direkt vom Server. Wichtig ist -servername, weil viele Server SNI nutzen. Ohne diesen Parameter kann ich das falsche Zertifikat sehen.

Wenn ich die Kette sauber prüfen will, ergänze ich oft:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Dann sehe ich alle Zertifikate, die der Server ausliefert. Das hilft mir sofort, wenn ein Intermediate fehlt.

verify openssl certificate: Ablaufdatum prüfen

Ein abgelaufenes Zertifikat ist der Klassiker. Ich lese das Ablaufdatum direkt aus dem Zertifikat:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Die Ausgabe zeigt notBefore und notAfter. Für mich ist vor allem notAfter wichtig. Wenn das Datum nah ist, plane ich die Erneuerung sofort ein.

verify openssl certificate: Hostname und Subject Alternative Names

Heute reicht es nicht mehr, nur den Common Name zu prüfen. Ich schaue auf die Subject Alternative Names, weil dort die echten gültigen Domains stehen.

Mit diesem Befehl sehe ich die Zertifikatsdetails:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text

Dann suche ich nach X509v3 Subject Alternative Name. Wenn die gewünschte Domain dort nicht auftaucht, ist das Zertifikat für den Host falsch ausgestellt.

verify openssl certificate: Kette und Trust prüfen

Ein Zertifikat kann gültig sein und trotzdem im Browser Fehler werfen. Der Grund ist oft die Kette. Der Server liefert nicht alle Zwischenzertifikate aus oder ein falsches Intermediate ist eingebaut.

So prüfe ich die Vertrauenskette:

openssl s_client -connect example.com:443 -servername example.com -verify_return_error

Am Ende der Ausgabe achte ich auf Meldungen wie Verify return code: 0 (ok). Alles andere bedeutet: Ich muss genauer hinschauen.

Wenn ich eine lokale CA-Datei testen will, nutze ich:

openssl s_client -connect example.com:443 -servername example.com -CAfile ca-bundle.crt

verify openssl certificate: Typische Fehler und was ich daraus lese

Die meisten Fehler sind eindeutig. Ich lese sie nicht als Drama, sondern als Hinweis.

• self signed certificate – das Zertifikat ist nicht von einer vertrauenswürdigen CA signiert.
• certificate has expired – Zertifikat erneuern, sofort.
• hostname mismatch – Zertifikat passt nicht zur Domain.
• unable to get local issuer certificate – Kette fehlt oder ist falsch.

Mein Ansatz ist simpel: Erst den Fehler genau lesen, dann gezielt lösen. Nicht raten, nicht rumprobieren.

verify openssl certificate: Praktische Workflows für den Alltag

Wenn ich schnell arbeiten will, nutze ich diesen Ablauf:

1. Ich verbinde mich mit openssl s_client.
2. Ich prüfe die Zertifikatsdaten mit openssl x509.
3. Ich kontrolliere Hostname, SAN und Ablaufdatum.
4. Ich prüfe die Kette mit -verify_return_error.
5. Ich vergleiche Serverausgabe und erwartete Domain.

Das dauert meist nur wenige Minuten. Genau deshalb bleibt OpenSSL für mich so wertvoll.

verify openssl certificate: Nützliche Befehle zum Kopieren

Hier sind die Befehle, die ich am häufigsten nutze:

• openssl s_client -connect example.com:443 -servername example.com
• openssl s_client -connect example.com:443 -servername example.com -showcerts
• echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
• echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text
• openssl s_client -connect example.com:443 -servername example.com -verify_return_error

Wenn du tiefer einsteigen willst, ist die offizielle Dokumentation der beste Startpunkt: OpenSSL Documentation.

Für Hintergrundwissen zu TLS hilft auch die Cloudflare-Erklärung zu SSL/TLS: Cloudflare SSL/TLS Guide.

Wenn du Zertifikate im Browser besser verstehen willst, ist Mozilla eine gute Quelle: Mozilla Server Side TLS.

verify openssl certificate: Mein Fazit

Ich prüfe Zertifikate nicht, weil es technisch klingt. Ich prüfe sie, weil es Probleme schneller löst als fast jedes andere Tool. Wenn ich verify openssl certificate sauber anwende, finde ich Ablaufdatum, Hostname und Kette sofort. Das spart Zeit, reduziert Fehler und macht HTTPS wieder berechenbar.

Wenn du mit Zertifikaten arbeitest, lern diese Befehle. Sie zahlen sich jedes Mal aus, wenn etwas bricht. verify openssl certificate ist der schnellste Weg, um ein SSL-Problem klar zu sehen.