Beschreibung

Diese Dokumentation beschreibt die Verwendung von SSL unter Gentoo/Linux.

Aktuell kommen Zertifikate von StartSSL zum Einsatz.

In früheren Versionen der Seite (über die Historie einsehbar), ist auch die Verwendung von GoDaddy Zertifikaten beschrieben:

Von CA's aus den USA und Großbritannien kann ich nach den Enthüllungen des Guardian in diesem Artikel zur abraten:

Wenn die Gefahr besteht, dass CA's mit den Geheimdiensten zusammenarbeiten, sollte man diese meiden. StartSSL ist auch nur die zweite Wahl, da das Unternehmen aus Israel kommt. Bevorzugen würde ich CA's aus der EU, aus Kostengründen ist das aktuell jedoch keine Alternative.

Das höchste Vertrauen hat bei mir CAcert:

Da das Root-Zertifikat jedoch weder in Browsern, noch E-Mail-Clients vorhanden ist, nutze ich diese CA (noch) nicht.

Grundsätzlich gilt, auch wenn es Geheimdienste teilweise möglich ist, SSL geschützten Traffic zu entschlüsselt oder anderweitig zu kompromittieren, sollte man nicht darauf verzichten und die Implementierung nach aktuellem Stand der Technik und den Erkenntissen der Arbeitsweise von Geheimdiensten anpassen.

OpenSSL

CSR

# openssl genrsa -out bknaus.de.key 4096
# chmod 400 bknaus.de.key
# openssl req -new -sha256 -nodes -key bknaus.de.key -out bknaus.de.csr
...
Common Name (eg, YOUR name) []:bknaus.de
...

Verify

// CSR
# openssl req -in bknaus.de.csr -noout -text

// Key
# openssl rsa -in bknaus.de.key -noout -text

// Cert
# openssl x509 -in bknaus.de.crt -noout -text

// Remote
# openssl s_client -CApath /etc/ssl/certs -connect bknaus.de:636

// SMTP
# openssl s_client -CApath /etc/ssl/certs -starttls smtp -connect bknaus.de:25

// FTP
# openssl s_client -CApath /etc/ssl/certs -starttls ftp -connect bknaus.de:21

Anbieter

StartSSL

Will man StartSSL auch zur internen Verschlüsselung der Kommunikation verwenden, muss man die CA bekannt machen:

# wget https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem
# wget https://www.startssl.com/certs/ca-sha2.pem
# cp /path/ca-sha2.pem /etc/ssl/certs/StartCom_Certification_Authority.pem
# cp /path/sub.class1.server.sha2.ca.pem /etc/ssl/certs/
# update-ca-certificates

Apache

# vi /etc/apache2/vhosts.d/00_default.conf

SSLEngine On
SSLHonorCipherOrder On
SSLCompression Off
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:!MD5:!aNULL:!EDH
SSLCertificateFile /path/bknaus.de.crt
SSLCertificateKeyFile /path/bknaus.de.key
SSLCertificateChainFile /path/sub.class1.server.sha2.ca.pem
SSLCACertificateFile /path/ca-sha2.pem

# /etc/init.d/apache2 restart

Dovecot

# cd /path/
# cat bknaus.de.crt sub.class1.server.sha2.ca.pem > bknaus.de.bundle.crt

# vi /etc/dovecot/dovecot.conf

ssl = yes
ssl_cert_file = /path/bknaus.de.bundle.crt
ssl_key_file = /path/bknaus.de.key
ssl_ca_file = /path/ca.pem
ssl_verify_client_cert = yes
ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = -ALL:AES:DES-CBC3-SHA:DES-CBC3-MD5:ADH-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA
verbose_ssl = yes

# /etc/init.d/dovecot restart

Qmail

# cd /path/
# cat bknaus.de.key bknaus.de.crt sub.class1.server.sha2.ca.pem > bknaus.de.pem
# openssl gendh >> bknaus.de.pem
# mv /var/qmail/control/servercert.pem /var/qmail/control/servercert.pem_back
# cp bknaus.de.pem /var/qmail/control/servercert.pem
# vi /var/qmail/control/tlsserverciphers
HIGH:!MD5:!aNULL:!EDH:!SSLv2:!SSLv3
# vi /var/qmail/control/tlsclientciphers
HIGH:!MD5:!aNULL:!EDH:!SSLv2:!SSLv3
# /etc/init.d/svscan restart

ProFTPd

# vi /etc/proftpd/proftpd.conf

<IfModule mod_tls.c>
        TLSEngine on
        TLSLog /var/log/proftpd/tls.log
        TLSProtocol TLSv1
        TLSRSACertificateFile /path/bknaus.de.crt
        TLSRSACertificateKeyFile /path/bknaus.de.key
        TLSVerifyClient off
        TLSRenegotiate required off
</IfModule>

# /etc/init.d/proftpd restart

Java

Zuerst prüft man, ob bereits ein altes Zertifikat mit dem Alias vorhanden ist:

# keytool -list -alias bknaus.de -keystore $JAVA_HOME/jre/lib/security/cacerts                      

bknaus.de, Jul 3, 2013, trustedCertEntry, 
Certificate fingerprint (SHA1): 3B:35:AB:0E:2F:00:A3:08:6B:2D:F9:E3:39:C9:FA:69:0D:32:CD:70

Das Default Passwort für den Keystore lautet "changeit" und sollte geändert werden!

Möchte man jetzt ein Zertifikat mit dem selben Namen importieren, wird zuerst das alte Zertifikat entfernt:

# keytool -delete -alias bknaus.de -keystore $JAVA_HOME/jre/lib/security/cacerts

Jetzt kann das neue Zertifikat importiert werden:

# keytool -import -alias bknaus.de -keystore $JAVA_HOME/jre/lib/security/cacerts -file /path/bknaus.de.crt

Trust this certificate? [no]:  yes
Certificate was added to keystore

Je nachdem, welche Anwendungen den Keystore verwenden, müssen diese neugestartet werden (z.B. JIRA und Confluence auf einem Tomcat).

OpenLDAP

Da der LDAP Daemon als User LDAP gestartet wird und dann in der Regel keinen Zugriff auf die Key Datei hat, kopiert man einfach alle notwendigen Dateien in das OpenLDAP Verzeichnis und setzt die Rechte:

# cp /path/bknaus.de.pem /etc/openldap/ssl
# cp /path/bknaus.de.key /etc/openldap/ssl
# cp /path/ca-sha2.pem /etc/openldap/ssl
# cp /path/sub.class1.server.sha2.ca.pem /etc/openldap/ssl
# chown ldap:ldap /etc/openldap/ssl/*

Wichtig ist hier, dass die Key Datei auch nur von diesem Benutzer gelesen werden kann:

-r-------- 1 ldap ldap 1679 Aug 17 09:30 bknaus.de.key

Details zur Konfiguration von OpenLDAP findet man im Artikel OpenLDAP.

Probleme

OCSP

Will man ein signiertes Zertifikat verwenden und bekommt folgenden Fehler ...

sec_error_ocsp_unknown_cert

... ist die Ursache eine langsame CA. StartSSL hat in diesem Fall das Zertifikat noch nicht im "Online Certificate Status Protocol" registriert.

Dann hilft es nur, die Füße still zu halten und es später nochmal zu versuchen.

In der Regel dauert es zwischen 22 bis 24 Stunden bis nach dem signieren das Zertifikat auch registriert ist. Hat man rechtzeitig ein neues beantragt, kann man sich solange noch mit dem alten Zertifikat aushelfen.

Ob das Zertifikat registriert ist, kann auch über openssl ermittelt werden:

# openssl x509 -in bknaus.de.crt -noout -serial                                                                                                                   
serial=078067

# openssl ocsp -nonce -issuer sub.class1.server.sha2.ca.pem \
  -url http://ocsp.startssl.com/sub/class1/server/ca/ -header "HOST" "ocsp.startssl.com" \
  -serial 0x78067 -text

Response verify OK
0x78067: good

Ist die List nicht aktuell, bekommt man folgende Meldung:

Response verify OK
0x78067: unknown
  • No labels

3 Comments

  1. Nach dem Heartbleed-Bug habe ich alle Systeme auf die aktuelle OpenSSL Version 1.0.1g aktualisiert und alle Dienste neugestartet. Da durch den Bug auch der private Key ausgelesen werden konnte, müssen alle Zertifikate ausgetauscht werden. Bei StartSSL muss dazu das alte Zertifikat revoked werden (US $24.90). Erst danach kann man ein neues erstellen (thumbs down)

  2. Anonymous

    Ich hab das bei ProFTPd probiert, leider sagt FileZilla immer "Unbekanntes Zertifikat" und fragt ob es dem unbekannten Zertifikat trotzdem vertrauen soll. Ich blick da leider noch nicht so ganz durch, hab es auch versucht mit dem sub.class2....pem file als TLSCACertificateFile. Hat aber nichts geändert. Weiß jemand woran das liegt?

  3. Da gibt es mehrere mögliche Ursachen:

    1) Dein Client akzeptiert die verwendete CA nicht. Welche verwendest du denn? StartSSL?

    2) Die Zertifikatskette stimmt nicht. Das kannst du mit OpenSSL prüfen:

    $ openssl s_client -connect bknaus.de:21 -starttls ftp

    3) Deine Konfiguration ist noch nicht vollständig. Manche CA's verwendet Sub-CA's, die ebenfallst eingebunden werden müssen.

    Wenn du mir verrätst, unter welcher Adresse dein FTP Server mit SSL erreichbar ist, kann ich mehr sagen.