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: 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: 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
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