Haken dran

von Markus Stubbig

In aller Regel surfen wir täglich ohne Probleme durch das Netz. Doch wenn der Webbrowser beim Aufrufen einer HTTPS-Seite meckert, dann stimmt meist etwas mit den Zertifikaten nicht. Besonders ungünstig ist das, wenn es Ihren eigenen Webserver betrifft. Mit "certigo" prüfen Sie die angebotene Zertifikatskette mit einem einzigen Befehl und erfahren in der Kommandozeile, wer was wann ausgestellt hat – und wo Unklarheiten liegen.

Die meisten Webseiten liefern ihre Inhalte verschlüsselt aus. Dies ist bei HTTPS am Anfang der URL erkennbar. Der Webbrowser akzeptiert die Daten vom aufgerufenen Server erst, nachdem dieser sich mit einem gültigen Zertifikat ausgewiesen hat. Danach erscheinen die Webinhalte im Browser und das Surfvergnügen kann beginnen. Bei Sicherheitsproblemen warnt der Browser seine Anwender. Die Gründe für eine Zertifikatswarnung sind vielfältig: Das Ablaufdatum ist überschritten, das Zertifikat ist selbstsigniert, der Aussteller ist unbekannt oder es fehlt ein Zwischenzertifikat.

Legt der Webbrowser dabei die Ursache nicht verständlich dar oder besteht Interesse an der Zertifikatskette, kann das Kommandozeilentool certigo [1] weiterhelfen. certigo greift wie ein Browser auf den Webserver zu, berichtet über die erhaltenen Zertifikate und liefert weitere Infos zur verwendeten Verschlüsselung. Im Bild sehen Sie, wie certigo eine Webseite prüft und in grün bestätigt, dass alle Zertifikate gültig sind und kein Zwischenzertifikat fehlt.

Installation per Build oder Binaries

certigo ist Open Source und steht unter der Apache-2-Lizenz auf GitHub bereit. Die in Go verfasste Software lässt sich mit den üblichen Build-Tools übersetzen. Einfacher gelingt der Start mit den angebotenen Binaries für Windows, Linux und macOS. Ein offizielles Docker-Image gibt es nicht.

Unter Linux laden Sie die Binärdatei auf den lokalen Rechner herunter und speichern sie in einem Verzeichnis, in dem üblicherweise die Linux-Befehle wohnen:

Bei Windows ist die Installation ebenfalls auf der Kommandoebene möglich, da curl mittlerweile zum Standardumfang gehört:

Das vorkompilierte Angebot ist zwar bequem, aber nicht die einzige Möglichkeit. Wer aus Prinzip selbst übersetzen möchte, Modifikationen am Quellcode plant oder auf einer Intel-fernen Architektur arbeitet, kann damit loslegen. Bewaffnen Sie sich mit einem Compiler für die Programmiersprache Go und nutzen das Build-Skript aus dem GitHub-Repository. Eine aktuelle Linux-Distribution führt mit wenigen Befehlen zum fertigen Executable, am Beispiel von Rocky Linux 9. Das kompilierte Ergebnis liegt im bin-Verzeichnis. Ein make install gibt es leider nicht.

Zuletzt rufen Sie certigo in einem Kommandozeilenfenster auf. Ohne Angabe von Optionen präsentiert die Software alle möglichen Parameter, was ungefähr zwei Bildschirmseiten füllt.

Analysieren, informieren, validieren

certigo kennt drei Betriebsmodi: dump, connect und verify. Connect erwartet den Namen des Webservers ohne HTTPS und beginnt sogleich mit seiner Zertifikatsanalyse. Dump ist so freundlich und zeigt die Informationen einer Zertifikatsdatei an, ohne diese zu überprüfen. Verify akzeptiert eine Zertifikatskette in Dateiform sowie einen Servernamen und validiert anschließend, ob beide zusammenpassen. Das funktioniert wie connect, allerdings offline ohne Webzugriff.

certigo ist kein Pen-Testing-Tool und fügt der Zieldomäne keinen Schaden zu. Ein Blick auf die Webpräsenz von it-administrator.de zeigt eine einwandfreie Kette von Zertifikaten bis hin zur Root-CA von DigiCert (siehe Bild). Wer certigo auf eine Webseite mit ungültigen Zertifikaten loslassen möchte, dem sei "https://badssl.com" empfohlen. Der Anbieter spezialisiert sich darauf, absichtlich verschiedenste Fehler in TLS-Webseiten einzubauen. Dahinter steckt zwar kein sinnvoller Inhalt, aber für ein paar negative Beispiele reicht es.

Zertifikate dazwischen

Webserver präsentieren ihren Clients in der Regel ein von einer ordentlichen CA ausgestelltes Zertifikat. In den meisten Fällen ist das jedoch keine Root-CA, sondern eine untergeordnete Zertifizierungsstelle. Das tut der Sicherheit keinen Abbruch, aber der Webserver muss so konfiguriert sein, dass er dem Webbrowser sein Zertifikat und alle Zwischenzertifikate vorzeigt. Fehlt ein Zertifikat in der Kette, dann liegt es im Ermessen des Browsers, die Verbindung zu akzeptieren oder dem Benutzer die übliche Warnung anzuzeigen.

Das Zertifikat der Root-CA muss der Webserver wiederum nicht mitliefern. Denn es ist im Zertifikatsspeicher des Browsers oder des Betriebssystems verankert und schließt die Vertrauenskette zwischen Server und Client. In unserem Beispiel im Bild präsentiert der Webserver das Serverzertifikat und das Zwischenzertifikat "Thawte TLS RSA CA G1". Auch das Root-Zertifikat von DigiCert taucht auf, obwohl es im TLS-Handshake nicht enthalten ist. Der Hinweis "self-signed" hat möglicherweise den Beigeschmack von Eigenbau. Allerdings sind alle Root-CAs selbstsigniert – vom Cross-signing mal abgesehen. Das Ergebnis ist eine Zertifikatskette vom Serverzertifikat bis hinauf zur Wurzel, was certigo lobend in Grün erwähnt.

Abläufe scripten

Mit dem Schalter "--json" spricht certigo JSON. Zusammen mit dem Helferlein jq [2] lassen sich Informationen von certigo bequem in Skripten, beim Monitoring oder in CI-Pipelines verwerten, ohne dass unschöner Shell-Code mit awk, sed oder grep entsteht. Beispielsweise ermittelt der folgende Aufruf die ausstellende CA der Webseite "www.example.net":

Wer die Ablaufdaten seiner Webzertifikate nicht im Blick hat, kann sein Monitoringsystem damit beauftragen. Der Klassiker Nagios greift auf das Skript "check_ssl_certificate" [3] zurück und erhält nach 140 Zeilen Perl-Code ein Ergebnis. certigo und die Bash erledigen den Job im Listing-Kasten dagegen in nur elf Zeilen Code.

Nicht nur HTTPS

Certigo beschränkt sich nicht auf HTTPS. Auch andere Protokolle sichern ihre Nutzdaten ebenfalls per TLS, darunter SMTP, LDAP, IMAP, FTP, MySQL und PostgreSQL. So lässt sich beispielsweise schnell prüfen, ob der verschlüsselte LDAP-Zugriff auf das Active Directory mit einem gültigen Zertifikat abgesichert ist. In den meisten Fällen spendieren Admins ihren Domänencontrollern kein kostenpflichtiges Zertifikat, sondern nutzen die CA von Windows Server. Solange die Clients dieser Root-CA vertrauen, sollte certigo sein Audit erfolgreich abschließen.

Beim E-Mail-Protokoll SMTP kam die Verschlüsselung erst nachträglich auf die Wunschliste. Der Kompromiss StartTLS ermöglicht es dem Client, zunächst unverschlüsselt den Server zu kontaktieren und beim anfänglichen Smalltalk auf eine chiffrierte Verbindung umzuschalten. certigo macht bei der Prüfung eines StartTLS-Servers genau dasselbe. Sobald der Server seine Zertifikate vorzeigt, bricht certigo die Verbindung ab und beginnt mit seiner Inspektion.

Beim Aufruf des Befehls benötigt certigo noch einen Hinweis darauf, welches Protokoll es per StartTLS abhorchen soll. Neben SMTP haben sich noch andere Protokolle wie IMAP und LDAP für die explizite TLS-Ertüchtigung entschieden:

Wer seinen Server dagegen im TLS-Modus auf dem jeweiligen TCP-Port betreibt, kann auf den gezeigten Umweg über StartTLS verzichten.

Verschlüsselung ist nicht gleich Verschlüsselung

Abgesehen von den Zertifikaten wirft certigo auch einen kurzen Blick auf die verwendeten Kryptoalgorithmen und auf die TLS-Version. Solide Werte erscheinen in Grün, wackelige zeigen sich in Gelb und bedenkliche Settings bekommen einen roten Schriftzug. Beispielsweise tadelt certigo die erste GlobalSign-Root-CA in Rot, da sie noch den älteren SHA1-Algorithmus nutzt. Und das zu Recht, denn die CA stammt noch aus den neunziger Jahren und erreicht ihr Ablaufdatum bereits im nächsten Jahr.

Wenn Zertifizierungsstellen einen Statuscheck im Sinne von OCSP anbieten, macht certigo auch dort einen kurzen Besuch und berichtet über zurückgerufene Zertifikate. Darüber hinaus hat das Tool Beziehungsprobleme zu Zertifikaten, die in verschlüsselten PKCS#12-Containern daherkommen und unbekannte Attribute enthalten. Die Ursache liegt in den Bibliotheken der Programmiersprache Go, die einen Abbruch bevorzugen, anstatt einen Informationsschnipsel zu ignorieren.

Mehr Funktionalität bietet certigo nicht. Wer seine Webserver einer tieferen Prüfung unterziehen möchte, sollte bei Qualys vorbeischauen [4]. Die Begutachtung endet mit einer Note von A bis F und liefert Hinweise, wie das Rating zustande kommt. Kleiner Tipp: Setzen Sie das Häkchen bei "Do not show the results on the boards", damit das Testergebnis nicht öffentlich wird. Für interne Server eignen sich schlanke Audit-Tools wie testssl.sh, Wapiti oder SSLyze.

Best Practices für Webserver

Wie sollte ein Webserver ausgestattet sein, damit Webbrowser nicht warnen und certigo alle Checks grün bewertet? Grundsätzlich benötigt der Webserver den privaten Schlüssel und das Zertifikat in Dateiform. Setzt die ausstellende Zertifizierungsstelle eine oder mehrere Intermediate-CAs ein (und das dürften fast alle sein), sollte der Webserver diese Zertifikate auch im TLS-Handshake anbieten. Vertrauen Sie nicht der Laune eines Webbrowsers und statten Ihren Server mit den benötigten Zwischenzertifikaten aus.

Ein konkretes Beispiel: Der Apache-HTTP-Server verfügt über drei Schlüsselwörter für das Zertifikate-Handling. Diese können Sie im Kontext des Servers aber auch für jeden virtuellen Host festlegen. Die Datei bei SSLCertificateChainFile sollte die Zertifikate der Zwischen-CA enthalten, nicht jedoch die Root-CA.

Bei Nginx funktioniert die Welt ähnlich. Dieser Webserver erwartet alle Zertifikate in einer einzigen Datei. Dabei ist die Reihenfolge wichtig – zunächst das Serverzertifikat, dann die Zwischen-CA(s):

Beim Webserver Caddy läuft vieles automatisch ab. So bestellt Caddy beispielsweise ohne Angabe von Zertifikatsdateien gültiges Material bei Let's Encrypt und stattet die laufende Instanz seines Webdienstes damit aus. Ohne diesen Automatismus erwartet Caddy alle Zertifikate in derselben Datei. Genau wie bei nginx ist dabei die Reihenfolge entscheidend:

Die Liste lässt sich fortsetzen, doch das Prinzip bleibt stets dasselbe. Das gilt auch für einen Reverse-Proxy, ein API-Gateway, einen TLS-Inspektor und einen Lastverteiler, der als Webdienst auf Ebene 7 des OSI-Protokolls arbeitet.

Wie verhalten sich Zertifikate von Let's Encrypt? Der Certbot-Automatismus beschafft sich das Kryptomaterial und legt es im Dateisystem ab. Idealerweise frisiert dieser auch die Konfigurationsdateien, was jedoch fehlerhaft sein kann oder nicht gewünscht ist. Richten Sie sich bei den Settings im Apache-Webserver nach der Verzeichnisstruktur des Certbots, am Beispiel von Rocky Linux:

Ob die Zertifikatsdateien miteinander harmonieren und zum DNS-Namen des Servers passen, analysiert certigo im verify-Modus:

Alternativen zu certigo

Jeder Webbrowser prüft die Zertifikate der angesurften HTTPS-Seite anhand der Signatur der CA. Das gilt auch für kommandobasierte Browser wie curl und wget. Beide Tools legen die Ursache nicht ganz so eindeutig auf den Tisch, wobei wget die deutlichere Sprache spricht. Erst durch die Zugabe von "--verbose" informiert curl über Details des angebotenen Zertifikats.

Kleiner Tipp: Wer die Ausgabe von curl per Skript weiterverarbeiten möchte, kann über den Hilfsbefehl "jc" [5] den Output ins JSON-Format bringen. Anschließend lassen sich die gewünschten Werte mit jq gezielt rauspicken. Leider funktioniert diese Magie nicht bei Zertifikatsfehlern. Die Allzweckwaffe "openssl" ist ebenfalls in der Lage, Zertifikate von Webseiten zu erfragen und anschließend zu prüfen.

Respekt an jeden Administrator, der die passende Syntax im Kopf hat. Alle anderen holen den Befehlssatz per Google oder ChatGPT ins Shell-Fenster, was nicht für die Usability des openssl-Befehls spricht. Schließlich bietet auch das "certtool" aus der GnuTLS-Sammlung seine Hilfe bei der Zertifikatskontrolle an. Die Prüfung erfolgt in zwei Stufen: Zuerst erfolgt das Herunterladen der Zertifikatskette und anschließend deren Validierung:

Der mittlere Befehl gibt lediglich die Inhalte wortreich auf dem Bildschirm aus. Auf Wunsch kann jc die Zertifikate auch im JSON-Format aufbereiten.

Fazit

Bleibt der Zugriff auf einen Webserver an einer Zertifikatswarnung hängen, liegt die Ursache nicht automatisch an einem überschrittenen Ablaufdatum. Das CLI-Tool certigo schlüsselt die Zertifikatskette auf und erkennt fehlende Zwischenzertifikate oder eine unbekannte Root-CA. certigo schaut TLS-Fehlern auf die Finger und macht die Tuschelei der Zertifikate ein wenig transparenter. Auf Wunsch liefert certigo die Ausgabe im JSON-Format und lässt sich ideal in Skripten weiterverarbeiten oder in einem Monitoringsystem auswerten.

TLS-Zertifikate prüfen mit certigo

Haken dran

Installation per Build oder Binaries

Installation per Build oder Binaries

Analysieren, informieren, validieren

Zertifikate dazwischen

Abläufe scripten

Nicht nur HTTPS

Verschlüsselung ist nicht gleich Verschlüsselung

Best Practices für Webserver

Alternativen zu certigo

Fazit