Machen wir das Internet sicherer: Zertifikatsanfragen mit OpenSSL

Gepriesen sei Let’s Encrypt! Dank der freien, automatisierten und offenen Initiative ist es möglich, für seine Webprojekte kostenlose TLS-Zertifikate zu erhalten, die auch in allen gängigen Browsern funktionieren. Dahinter stecken Branchengrößen, wie Mozilla, Cisco und Facebook.

Kürzlich veröffentlichte die Certificate Authority (CA) einen spannenden Artikel über ihre Kosten. Jetzt ist klar, was bereits viele vermutet haben: Symantec und Co haben sich eine goldene Nase mit den einfachen domain-validierten Zertifikaten verdient. All unseren Kunden empfehlen wir daher TLS-Zertifikate von Let's Encrypt.

Trotz Let’s Encrypt macht es jedoch in einigen Fällen Sinn auf kostenpflichtige Zertifikate zu setzen. Ob ein Wildcard-Zertifikat, welches für beliebig viele Subdomains gilt und auch in der Administration schnell von Server A auf Server B transferiert ist, oder ein unternehmensvalidiertes Zertifikat, das durch seine manuelle Prüfung eine Bestätigung für die Existenz des Unternehmens liefert. Beides wird bisher von Let's Encrypt nicht angeboten.

Häufig wird sogar die Ausstellung eines Extended-Validation-Zertifikats (EV) gewünscht. Damit erscheint nach einer Prüfung in Branchenbüchern und eines Telefonanrufs der Firmenname inklusive Rechtsform in der Adressleiste, was für zusätzliches Vertrauen sorgt. Auch eine besonders hohe Browser-Kompatiblität zu älteren Geräten oder der Wunsch nach einem Malware-Scan der eigenen Website, mit Siegel, sind gute Gründe für ein kostenpflichtiges TLS-Zertifikat.

Bei Let’s Encrypt hilft bei der Ausstellung des TLS-Zertifikats der CertBot. Für die anderen Anbieter muss man hier meist selbst Hand anlegen. Von Diensten, die einem das Generieren des Private Keys auf ihrer eigenen Website abnehmen, ist abzuraten. Es folgen die notwendigen Schritte für die Ausstellung eines TLS-Zertifikats.

Private Key

Zu Beginn benötigen wir OpenSSL. Das Paket stellt die für diese Zwecke am häufigsten verwendete Implementierung der Protokolle SSL und TLS dar. TLS ist der Nachfolger von SSL. Dennoch wird meist noch immer von SSL-Zertifikaten gesprochen.

Auf einem Debian-basierten System gibt es für OpenSSL natürlich ein Paket, welches wir uns ganz einfach auf die Maschine holen. Anschließend machen wir uns direkt an die Generierung des Private Keys.

apt-get update
apt-get install openssl
openssl genrsa -out privatekey.pem 2048

Der Schlüssel landet in der Datei „private.key“. Wir generieren den RSA-Key mit einer Zeichenlänge von 2048 bit, was dem Standard und Minimum der meisten CAs entspricht. Wer nun denkt „Viel hilft viel“ und warum nutzen wir keine 4096 bit, dem sei gesagt, dass die Kosten für die Verschlüsselung nicht linear mit der Länge steigen. Das Mehr an Sicherheit geht hier zulasten der Performance. Elliptische Kurven bringen jedoch Besserung. Dieser Private Key stellt unser Geheimnis dar, was es zu schützen gilt. Idealerweise verlässt der Private Key also nicht einmal den Server.

Certificate Signing Request (CSR)

Da wir den Private-Key nicht weiterreichen, braucht es für die Anfrage bei einer CA noch einen weiteren Baustein. Die Certificate Signing Request, kurz CSR. Bei einem selbstsignierten Zertifikat, würde man diesen Schritt daher auch überspringen.

Um mittels Private Key einen CSR zu generieren, hilft folgender Befehl.

openssl req -new -sha256 -key privatekey.pem -out csr.pem

Ich nutze jedoch auch ganz gern diesen kombinierten Befehl, der Private Key und CSR in einem Rutsch generiert.

openssl req -nodes -sha256 -newkey rsa:2048 -keyout privatekey.pem -out csr.pem

In beiden Fällen muss der CSR noch mit weiteren Metainformationen angereichert werden, die OpenSSL anschließend interaktiv abfragt. Felder, die mit einem Punkt versehen werden, gelten als leer gelassen. Hier ein Beispiel für eine Berliner Firma, die nicht namentlich genannt werden möchte.

Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Berlin
Locality Name (eg, city) []: Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]: überdosis GbR
Organizational Unit Name (eg, section) []: .
Common Name (e.g. server FQDN or YOUR name) []: www.ueberdosis.io
Email Address []: mail@ueberdosis.io

Besondere Aufmerksamkeit sollte man dem Feld „Common Name“ widmen. Darin wird definiert für welche Domain man ein Zertifikat ausgestellt bekommen möchte. Die meisten TLS-Produkte ermöglichen mit einem Zertifikat eine Domain inkl. der Subdomain „www.“ zu verschlüsseln (example.com/www.example.com). Dafür sollte man im Feld Common Name des CSR die Variante mit „www.“, also „www.example.com“ wählen, nachdem man sich bei der CA darüber informiert hat.

Bei einem Wildcard-Zertifikat (*.example.com) sollte man den Common-Name entsprechend eintragen. Unternehmensvalidierte Zertifikat unterscheiden sich an dieser Stelle nicht von domain-validierten.

Nun wendet man sich an die CA und übermittelt ihr die CSR, zusammen mit weiteren Informationen. Dabei handelt es sich meist um Informationen zum Ansprechpartner in der Firma für administrative oder technische Belange.

Für die Überprüfung der Domain stehen meist mehrere Verfahren zur Auswahl: DNS-Eintrag, Datei oder E-Mail. Meiner Erfahrung nach ist der DNS-Eintrag meist das unkomplizierteste, da eine Datei unter Umständen durch ein Rewriting blockiert sein kann und keiner weiß, bei wem E-Mails an admin@ aufschlagen.

Zertifikat

Abhängig vom Produkt erhält man das TLS-Zertifikat in wenigen Minuten (Domain Validation) oder mehreren Werktagen (Organisation Validation/Extended Validation). Das Zertifikat enthält keine brisanten Informationen und wird daher meist per E-Mail oder Download-Link bereitgestellt. Für die einwandfreie Funktion eines TLS-Zertifikats werden nötige Zwischenzertifikate mitgeliefert.

In der nginx-Konfiguration hinterlegt man anschließend folgende Zeilen und startet den Dienst neu:

server {
        listen 443 ssl;
        server_name example.com www.example.com

        [...]

        # TLS certificate
        ssl_certificate /etc/ssl/cert/certificateWithIntermediate.pem;
        ssl_certificate_key /etc/private/privatekey.pem;
}

Fazit

Let's Encrypt hat mit seinem Dienst Bewegung in den Markt der CAs gebracht. Die Gründe auf ein kostenpflichtiges Zertifikat zu setzen, werden immer weniger, aber dennoch macht es Sinn, sich mit den notwendigen Schritt vertraut zu machen. Angemerkt sei an dieser Stelle, dass mit der Einbindung des Zertifikats der Job noch lange nicht erledigt ist. Das kürzlich von Mozilla veröffentlichte Tool Observatory hilft bei der Härtung der TLS-Verbindung.

Bild von Hans Pagel