SSL-Zertifikate

Aus DebianforumWiki

Wechseln zu: Navigation, Suche
Wiki ‹ Sicherheit ‹ 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.

Inhaltsverzeichnis

Grundlagen

Wenn jemand eine Verbindung über ein SSL-Protokoll (zb https) aufbaut, wird zunächst die Identität des Servers überprüft. Dabei kommt SSL/TLS zum Einsatz (praktisch dasselbe, TLS ist der Name für SSL ab SSL 3.0). Hier wird das eingesetzt, was in diesem Artikel erklärt wird. Das Clientprogramm erhält das von der CA signierte Zertifikat, in welchem unter anderem der Hostname (bzw mehrere) und die ausgebende Stelle (CA) steht. Wird der CA vertraut und der Hostname stimmt überein, können Server und Client eine symmetrische Verschlüsselung aushandeln und die Verbindung wird fortgesetzt.

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
CSR
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
Von „http://wiki.debianforum.de/wiki/?title=SSL-Zertifikate&oldid=9659“
Meine Werkzeuge