SSL-Zertifikate

Aus DebianforumWiki
Wechseln zu: Navigation, Suche
WikiSicherheit ‹ SSL-Zertifikate


Dieser Artikel soll erläutern, welchen Sinn und Zweck SSL-Zertifikate haben, wie man sie erzeugt (self-signed als auch mit einer bekannten CA, Certificate Authority) und wie man sie in die gängigen Serverdienste einfügt. Zuletzt werden auch SSL-Clientzertifikate erklärt und erzeugt. TLS ist nicht zu verwechseln mit GPG.

Grundlagen

Zertifikate kommen beim Aufbauen einer verschlüsselten Verbindung - beispielsweise über https - zum Einsatz. Sie sind Bestandteil einer sogenannten Public Key Infrastruktur (PKI).

Eine PKI benutzt asymmetrische Verschlüsselung. Der Name rührt daher, dass im Gegensatz zur symmetrischen Verschlüsselung für das Verschlüsseln ein anderer Schlüssel genutzt wird, als beim Entschlüsseln. Man hat es also immer mit einem Schlüsselpaar zu tun. Einer dieser beiden Schlüssel ist geheim, und sollte entsprechend aufbewahrt werden, der andere ist öffentlich. Beide Schlüssel können sowohl zur Verschlüsselung als auch zur Entschlüsselung genutzt werden. Daraus ergeben sich 2 wesentliche Anwendungsfälle:

  • Verschlüsselung mit dem öffentlichen Schlüssel - entschlüsseln mit dem privaten Schlüssel.

Dies wird benutzt, um mit dem Besitzer des privaten Schlüssels zu kommunizieren, ohne das jemand anders die Nachrichten mitlesen kann.

  • Verschlüsselung mit dem privaten Schlüssel - entschlüsseln mit dem öffentlichen Schlüssel

Dies wird - zusammen mit Einweg-Funktionen/Prüfsummen (z.B. SHA-256) - benutzt, um digital zu signieren. Der Besitzer des privaten Schlüssels berechnet für einen Text eine Prüfsumme und verschlüsselt diese mit seinem Privaten Schlüssel. Der Empfänger kann diese entschlüsseln und mit der Prüfsumme, die er selbst berechnet hat, vergleichen.

Beim Aufbau der verschlüsselten Verbindung haben Zertifikate 2 Funktionen:

  • sie dienen dem Client dazu, den Server zu identifizieren - damit man sicher ist, dass man z.B. mit seiner Bank kommuniziert
  • sie enthalten den öffentlichen Schlüssel des Inhabers, mit dessen Hilfe der Client bereits verschlüsselt mit dem Server kommunizieren kann.

Zum Nachweis der Identität enthält ein Zertifikat - neben einigen anderen Informationen - den Namen des Zertifikats-Inhabers (das kann auch ein Servername sein), den Namen des Ausstellers und die digitale Unterschrift des Ausstellers. Wenn man dem Aussteller bereits vertraut - und damit auch dessen digitaler Unterschrift - kann man dem Inhaber des ursprünglichen Zertifikats vertrauen. Andernfalls versucht man diese Vertrauens-Kette über die Aussteller soweit fortzusetzen, bis man einen Aussteller findet, dem man bereits vertraut.

Die Zertifikate, denen man bereits vertraut, bilden einen sogenannten Vertrauensraum. Unter Debian sind diese im Verzeichnis /etc/ssl/certs abgespeichert. Hier findet man vorinstallierte (häufig) "selbst-signierte" Zertifikate von sogenannten Certifying Authorities (CA). CAs sind in der Regel Unternehmen, die von den Staaten, in denen sich deren Sitz befindet, für die Ausstellung von Zertifikaten authorisiert wurden.


Hinweis.png Hinweis: Sämtliche Key-Erzeugungen im Artikel erfolgen ohne Passwort; um dies zu ändern, bitte noch den Parameter --des3 anfügen für eine zusätzliche symmetrische Verschlüsselung mittels DES. client.pem/server.pem usw. können natürlich auch hostname.pem benannt werden, um sie anschließend einfacher zu organisieren.


Kürzel im Artikel

SSL
Secure Socket Layer
TLS
Transport Layer Security, der Name für SSL ab SSL 3.0 (TLS 1.0 == SSL 3.1)
CA
Certificate Authority, eine Stelle, welche Zertifikate ausgibt
PEM
Dateiendung für ein Base64-kodiertes X.509-Zertifikat (manchmal auch CRT für CeRTificate) und CSR's
CSR
Certificate Signing Request, eine Anfrage an die CA, die eingegebenen Serverdaten wie Hostname und Betreiber zu beglaubigen)
RSA
Ein asymmetrisches Schlüsselverfahren [1]
DES
Ein symmetrischer Verschlüsselungsalgorithmus
CRL
Certificate Revocation List, damit werden Zertifikate als ungültig markiert.

Ablauf zum Erhalt eines Server-Zertifikats

Das ist die Kurzfassung, wie man sie mit meist korrekten Befehlen in den meisten How-To's findet.

Eigene CA erzeugen

Nur wichtig ohne externen Anbieter und für Clientzertifikate.

1. Erzeugen eines Keys für die CA

openssl genrsa -out ca.key 4096

2a. Erzeugen eines Zertifikats für die CA, ein Jahr gültig. Wichtig: common name ist der hostname, zb debianforum.de, mehrere Hosts siehe SNI

openssl req -new -x509 -days 365 -key ca.key -out ca.pem

2b. Erzeugen einer (leeren) CRL für das Zertifikat

Zunächst eine Konfiguration anlegen, hier in /etc/ssl/crl.config: (entnommen und angepasst von [2])

[ ca ]
default_ca       = CA_default                   # the default ca section

[ CA_default ]
dir              = /etc/ssl                     # where everything is kept
database         = $dir/index.txt               # database index file.
certificate      = $dir/certs/ca.pem            # the CA certificate
crl              = $dir/ca.crl                  # the current CRL
private_key      = $dir/private/ca.key          # the private key
default_crl_days = 183                          # how long before next CRL 
default_md       = md5

Danach die CRL erzeugen und an das CA-Zertifikat anhängen:

openssl ca -gencrl -config crl.config -out ca.crl
cat ca.pem ca.crl > /etc/ssl/certs/ca.pem

Eigenes Zertifikat erzeugen und signieren (lassen)

3. Erzeugen eines Keys für den (eigenen) Server

openssl genrsa -out server.key 1024

4. Erzeugen eines CSR (unterschrieben mit dem Server-Key)

openssl req -new -key server.key -out server.csr

5. Signieren des CSR durch die eigene CA, als Produkt erhält man das Zertifikat. Mit externer CA macht man das dann auf der jeweiligen Webseite des Anbieters (CSR rein, neues Zertifikat raus)

openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca.key -out server.pem

Client-Zertifikate

Als passabler Ersatz für basic auth (htaccess) können auch Client-Zertifikate verwendet werden. Dies ist nicht besonders weit verbreitet, vermutlich wegen des leicht erhöhten Aufwands bei der Einrichtung. Die Zertifikate werden wie folgt erzeugt:

1. Erzeugen einer CA (nicht optional!), siehe oben 2. Erzeugen eines Client-Keys

openssl genrsa -out client.key 1024

3. Erzeugen eines Client-CSR

openssl req -new -key client.key -out client.csr

4. Signieren des CSR, Endprodukt ist wieder ein Zertifikat.

openssl x509 -req -days 365 -in client.csr -CA ca.pem -CAkey ca.key -out client.pem

5. Export als PKCS#12 Zertifikat

openssl pkcs12 -export -inkey client.key -in client.pem -out client.pfx

Der Serverdienst erhält als Parameter das Zertifikat der CA, um die Clientzertifikate zu überprüfen. Im Client wird dann an passender Stelle das Clientzertifikat (im PKCS#12 Format) hinterlegt.

SNI

Um mehrere Hosts in einem Zertifikat einzubinden, ist SNI vorgesehen. SNI steht für Server Name Indication. Durch SNI wird der Hostname mit dem TLS Handshake übergeben. Damit kann der Dienst das korrekte Zertifikat ausliefern.

Aktuelle Browser unterstützen darüber hinaus das Attribut subjectAltName (definiert im Standard x.509 v3) im Zertifikat, wo auch wildcards erlaubt sind (ebenso im common name, was dann aber nicht mehr abwärtskompatibel ist). Konfiguiert wird dies am besten in der /etc/ssl/openssl.cnf, Beispiel:

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName  =       DNS:planet.debianforum.de, DNS:nopaste.debianforum.de

Bei der Generierung des CSR wird dies dann miteingebunden.

Konfiguration verschiedener Serverdienste und Clients

Im Folgenden wird beschrieben, wie verschiedene Dienste wie https/imaps mit dem erzeugten Zertifikat konfiguriert werden.

Apache

Serverzertifikat

Der entsprechende VirtualHost muss wie folgt konfiguiert werden:

SSLEngine On
SSLCertificateFile /etc/ssl/certs/server.pem
SSLCertificateKeyFile /etc/ssl/private/server.key

Es gibt auch die Möglichkeit, den Key und das Zertifikat in eine Datei zu kopieren und als SSLCertificateFile anzugeben.

Clientzertifikat

Für Logins mit Clientzertifikaten gibt man im betreffenden VirtualHost bzw. einer Verzeichnisdirektive folgendes an:

SSLVerifyClient require
SSLCACertificateFile /etc/ssl/certs/ca.pem

An der Stelle sei noch angemerkt, dass auch pro Benutzer mit Zertifikaten (anhand des Email-Felds) gearbeitet werden kann. Dies ist jedoch etwas komplizierter und basiert auf zwei unterschiedlichen Methoden, siehe [3] [4]

ToDo

Nginx

Serverzertifikat

In die Konfigurationsdatei des VirtualHost wird eingetragen:

ssl on;
ssl_certificate      /etc/ssl/certs/server.pem;
ssl_certificate_key  /etc/ssl/private/server.key;

Clientzertifikat

ssl_client_certificate /etc/ssl/certs/ca.pem;
ssl_verify_client on;

Dovecot

Hinweis.png Hinweis: Die von debian mitgegebene Konfiguration enthält bereits die meisten Parameter in auskommentierter Form. Es bietet sich an, diese zu suchen und anzupassen anstatt selbst einzufügen, sofern vorhanden.


Serverzertifikat

Vorab: Das Serverzertifikat kann mittels dpkg-reconfigure dovecot-common auch automatisch erzeugt werden (self signed). Wer sich also Arbeit sparen will, ist damit gut bedient. Wer es mit dem bereits oben angelegten Zertifikat machen will, hier die Konfiguration:

Für "reines SSL" muss imaps zur protocols-Zeile hinzugefügt und im Abschnitt protokoll imap ssl_listen mit IP:Port angegeben werden (analog für pop3 mit pop3s).

protocol imap {
  listen = *:143
  ssl_listen = *:993
}

Es gibt jedoch praktisch keinen Unterschied zwischen IMAP mit TLS und IMAPS außer dem zusätzlichen Port und einem Zwischenschritt mit STARTTLS.

Das Zertifikat wird wie folgt angegeben:

ssl_cert_file = /etc/ssl/certs/server.pem
ssl_key_file = /etc/ssl/private/server.key

dovecot kann auch mit DES-geschützten Zertifikaten umgehen, dann muss/kann

ssl_key_password = passwort

gesetzt werden (alternativ wie bei anderen Diensten beim Start). Außerdem sollte dann der Zugriff auf die Datei /etc/dovecot/dovecot.conf limitiert werden:

chmod 600 /etc/dovecot.conf

Clientzertifikat

Um dovecot für Zertifikate fit zu machen, benötigt dovecot das Zertifikat der (eigenen) CA. Setzt man ssl_verify_client_cert auf yes, wird der Client nach einem Zertifikat gefragt, mit gesetztem ssl_require_client_cert=yes im Bereich auth kann man sich via IMAP/POP3 nur noch mit Zertifikat anmelden.

ssl_ca_file = /etc/ssl/certs/ca.pem
ssl_verify_client_cert = yes
ssl_require_client_cert= no

Das Clientzertifikat ersetzt jedoch nicht den Login-Mechanismus!

Postfix

Serverzertifikat

Um Postfix TLS beizubringen, benötigt es folgendes in der /etc/postfix/main.cf:

smtpd_tls_cert_file=/etc/ssl/certs/server.pem
smtpd_tls_key_file=/etc/ssl/private/server.key
smtpd_use_tls=yes

Clientzertifikat

Auch über SMTP sind Zertifikate möglich und können wahlweise optional oder erforderlich sein.

smtpd_tls_ask_ccert = yes # Um die Funktionalität grundsätzlich zu aktivieren
smtpd_tls_req_ccert = yes # Um Zertifikate erforderlich zu machen, impliziert die vorige Direktive
smtpd_tls_security_level = encrypt # Keine Authentifikation ohne TLS, empfohlen
smtpd_tls_CAfile = /etc/ssl/certs/ca.pem

Firefox/Iceweasel

ToDo

Chromium

ToDo

Opera

ToDo

Thunderbird/Icedove

ToDo

Quellen

http://www.openssl.org/docs/HOWTO/keys.txt
http://www.postfix.org/TLS_README.html
http://pilif.github.com/2008/05/why-is-nobody-using-ssl-client-certificates/
http://www.tc.umn.edu/~brams006/selfsign.html
http://www.lwithers.me.uk/articles/cacert.html
http://wiki.dovecot.org/SSL/DovecotConfiguration