SSL-Zertifikate von Let's Encrypt

Genauer untersucht

Das OpenSSL-Toolkit gilt als das Schweizer Taschenmesser im Kryptobereich. Der Open-Source-Tipp in diesem Monat zeigt, wie sich das Tool dazu einsetzen lässt, um X.509-Zertifikate näher zu untersuchen, zum Beispiel die kostenlosen Schlüssel von Let's Encrypt.
Täglich prasseln verschiedenste Angriffe auf die IT-Systeme von Unternehmen ein. Die breite Masse lässt sich zwar mit Standardmitteln wie Virenscannern ... (mehr)

Das OpenSSL-Toolkit stellt neben der freien Implementierung des SSL/TLS-Protokolls auch eine Vielzahl kryptografischer Bibliotheken zur Verfügung. Daneben enthält es diverse Tools zur Verwaltung von X.509-Zertifikaten und anderen kryptografischen Schlüsseln. Ein einfacher SSL-/TLS-Server sowie ein entsprechender Client gehören ebenfalls mit zum Lieferumfang.

Let's Encrypt bietet Zertifikate für alle

X.509-Zertifikate kommen heutzutage glücklicherweise immer häufiger zum Einsatz, um die Kommunikation zwischen einem Client und Server abzusichern. Allerdings gilt die Konfiguration der zu schützenden Dienste und Clients als recht komplex und fehleranfällig. Seit Ende 2015 existiert mit Let's Encrypt [1] ein Projekt, das den Einsatz von X.509-Zertifikaten für jedermann ohne großen Konfigurationsaufwand ermöglichen möchte, siehe " Zertifikate von Let's Encrypt in Apache, Nginx und HAProxy ".

So bekommt jeder Benutzer bei Bedarf ein kostenfreies X.509-Zertifikat für seine Domäne ausgestellt. Auf Wunsch wird die Konfiguration des eigenen Webservers angepasst, sodass dieser das neu ausgestellte Zertifikat direkt verwenden kann. Da dieser Vorgang nicht ganz unumstritten ist, besteht mittlerweile auch die Möglichkeit, sich lediglich ein Zertifikat ausstellen zu lassen, ohne die eigene Server-Konfiguration anpassen zu lassen. In jedem Fall ist es aber notwendig, einen Python basierten Client [2][3] auf den entsprechenden Systemen zu installieren.

Die von Let's Encrypt ausgestellten Zertifikate werden in Browsern als gültige Zertifikate anerkannt, da die von Let's Encrypt eingesetzte Certificate Authority (CA) eine Cross-Signatur mit der CA von IdenTrust besitzt. Deren Zertifikate sind in allen gängigen Browsern installiert, sodass automatisch eine Verifikation der Let's-Encrypt-Zertifikate stattfinden kann. Die Aufnahme der Let's Encrypt eigenen Root-CA-Zertifikate wird wohl hingegen noch einige Zeit in Anspruch nehmen.

Im Folgenden stellen wir noch einmal sehr vereinfacht dar, wie ein Zertifikat die Kommunikation absichert und wie die OpenSSL-Tools dabei helfen, diesen Ablauf besser zu verstehen. Absicherung heißt beispielsweise, dass die übertragenen Daten verschlüsselt werden. Hierzu kommt ein symmetrischer Schlüssel zum Einsatz, der zu Beginn der Kommunikation im SSL-/TLS-Handshake zwischen den Kommunikationspartnern ausgehandelt wird. Teil eines X.509-­Zertifikats ist unter anderem ein asymmetrisches Schlüsselpaar, das zum einen dazu dient, die Integrität der übertragenden Daten sicherzustellen, als auch die Gegenseite (meistens den Server) zu authentifizieren. Damit ist sichergestellt, dass man sich auch tatsächlich mit dem richtigen Server unterhält.

Natürlich funktioniert das auch andersrum. Hierzu ist es notwendig, dass eine dritte Instanz die Authentizität dieses Schlüsselpaars verifiziert und durch eine Signatur bestätigt. Diese fließt dann ebenfalls mit in das Zertifikat ein. Vertraut man dieser dritten Instanz, üblicherweise spricht man hier von einer sogenannten Root-CA, so kann man davon ausgehen, dass das Zertifikat des Servers echt ist. Oft ist es so, dass eine Root-CA lediglich die Zertifikate von anderen Certificate Authorities (CA) signiert, die dann dafür zuständig sind, die Zertifikate für die Endkunden zu erzeugen. Bei diesen CAs spricht man dann von Intermediate-CAs.

Komplette Kette prüfen

Damit ein Client ein Zertifikat verifizieren kann, das von einer Intermediate-CA ausgestellt wurde, ist allerdings die komplette CA-Hierarchie bis zur Root-CA zu überprüfen. Diese CA-Hierarchie wird als Certificate-Chain bezeichnet. Im Klartext heißt das, dass der Client nicht nur das Zertifikat seines Kommunikationspartners, beispielsweise eines Webservers, benötigt, sondern auch die Zertifikate der darüber liegenden Intermediate- und Root-CA.

Das folgende Beispiel basiert auf einem Webserver, der ein von Let's Encrypt ausgestelltes Zertifikat verwendet. Zur Analyse der Verbindung stellt der im OpenSSL-Toolkit enthaltene SSL-/TLS-Client eine Verbindung zum Server her (Listing 1).

Listing 1: OpenSSL-Client zeigt Certificate-Chain an



$ openssl s_client -connect batmanbutiken.se:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X1
verify return:1
depth=0 CN = batmanbutiken.se
verify return:1
---
Certificate chain
    0 s:/CN=batmanbutiken.se
       i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
    1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
      i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server certificate
-----BEGIN CERTIFICATE-----
MIIFMDCCBBigAwIBAgISAUgY8vKBnPRvVNVLuysjYBupMA0GCSqGSIb3DQEBCwUA
MeoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
[…]
-----END CERTIFICATE-----
[…]
SSL-Session:
       Protocol : TLSv1.2
       Cipher : ECDHE-RSA-AES128-GCM-SHA256
[…]
      Verify return code: 0 (ok)

Das Tool zeigt nun jede Menge Informationen zu der aufgebauten TLS-Verbindung an. So ist beispielsweise zu erkennen, dass TLS in der Version 1.2 zum Einsatz kommt und welche Krypto-Algorithmen verwendet werden. Desweiteren ist zu erkennen, dass die komplette Certificate-Chain aus drei Zertifikaten besteht. Auf der untersten Ebene ("depth=0") befindet sich das Zertifikat des Webservers. Es wurde von der Let's-Encrypt-Intermediate-CA ("depth=1") signiert, die wiederum von der IdenTrust-Root-CA signiert wurde ("depth=2").

Ähnliche Artikel

comments powered by Disqus
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

Ausgabe /2023