Täglich prasseln verschiedenste Angriffe auf die IT-Systeme von Unternehmen ein. Die breite Masse lässt sich zwar mit Standardmitteln wie Virenscannern ... (mehr)

Webserver schickt lückenhafte Kette

Der Webserver sendet in seiner Zertifikats-Chain allerdings nur die Zertifikate des Webservers ("depth=0") und der Intermediate-CA (depth=1). Mit Hilfe des OpenSSL-Tools s_client lässt sich dies bestätigen. Zuerst ist dem Tool mitzuteilen, dass die empfangene Certificate-Chain angezeigt werden soll ("-showcerts") und dass diese dann in einer Datei zu speichern ist:

$ echo -n | openssl s_client -connect www.batmanbutiken.se:443 -showcerts | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ca-chain.crt

Das Skript in Listing 2 zeigt den Eigentümer und den Herausgeber der PEM-codierten Zertifikate.

Listing 2: Eigentümer und Herausgeber anzeigen



$ cat ca-chain.crt | while read line; do cert=$cert$line$'\n'
      if [ "$line" != "${line/END CERTIFICATE/}" ]; then
           echo "$cert" | openssl x509 -subject -issuer -noout
           echo "-------"
           cert=""
      fi
done
subject= /CN=batmanbutiken.se
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
-------
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
-------

Um nun noch die Intermediate-CA von Let's Encrypt (CN=Let's Encrypt Authority X1) zu verifizieren, ist auch noch das Zertifikat der Root-CA (CN=DST Root CA X3) notwendig. Es ist jedoch nicht in der übertragenen Certificate-Chain enthalten. Zu finden ist es in einer vom Mozilla-Projekt herausgegebenen Liste, in der alle offiziellen Root-CAs aufgeführt sind [4]. Diese Liste ist in allen gängigen Webbrowsern enthalten und außerdem oft als CA-bundle-Datei innerhalb des Betriebssystems verfügbar. Auf einem Fedora-System ist das Zertifikat beispielsweise in der Datei "/etc/ pki/tls/cert.pem" enthalten. Bei einem näheren Blick auf das Zertifikat stellt man fest, dass Herausgeber und Eigentümer identisch sind:

subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

Konfiguration herausfinden

Da OpenSSL auf einem Fedora-System automatisch im Order "/etc/pki/tls" nach dieser CA-bundle-Datei sucht, muss der Speicherort beim Aufruf nicht explizit mit angegeben werden. Welches Standardverzeichnis OpenSSL bei der eingesetzten Linux-Distribution verwendet, zeigt der Aufruf

$ openssl version -a | grep -i openssldir
OPENSSLDIR: "/etc/pki/tls"

Alternativ besteht die Möglichkeit, die Datei mit den hinterlegten Root-CA-Zertifikaten beim Aufruf des OpenSSL-Kommandos s_client mit anzugeben ("-CA-file"). Wie in Listing 1 zu erkennen ist, hat die Verifizierung der kompletten Certificate-Chain reibungslos funktioniert, sodass das OpenSSL-Tool mit dem Verify Return Code 0 beendet wird.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019