TLS-Verbindungen, verschlüsselte Kommunikation für Postfix 2.11 unter CentOS 7
Dass das Internet systembedingt unsicher ist, hat sich in aller Regel herumgesprochen. Daten durchlaufen von der Quelle bis zum Ziel zahlreiche Server und Systeme, an denen die Daten, abgegriffen und/oder manipuliert werden können. Persönliche und vertrauliche Daten können so einfach Dritten in die Hände fallen, die mit grosser krimineller Energie versuchen an diese Daten zu kommen.
Inwieweit staatliche Stellen den Datenverkehr abhören, protokollieren und abgreifen und zu manipulieren bzw. zensieren versuchen, weiss
- keiner so genau und
- was mit den gewonnen Daten angestellt wird, wird sich niemand öffentlich sagen trauen.
Tja, das war Stand der Dinge vor 2013, denn was bisher in den Bereich der Spekulation fiel, findet nun Bestätigung durch die Erkenntnisse des Whistleblowers Edward Snowden zu den Projekten PRISM aus den USA und TEMPORA aus England. Seit Jahren werden unschuldige Bürgerinnen und Bürger von staatlichen Institutionen unter Generalverdacht gestellt und überwacht! Regierungen scheuen keinen Aufwand um in die Privatsphäre unschuldiger Bürgerinnen und Bürger einzudringen, Daten auszulesen und auszuwerten!
Was lernen wir aus dieser Tatsache? Unsere Kommunikation ist nach besten Wissen und Gewissen, so zu gestalten, damit andere unsere Daten nicht mitlesen und manipulieren können. Ferner ist sicherzustellen, dass Empfänger vertrauen können, dass Informationen tatsächlich von dem versandt wurden, von dem wir glauben, diese zu bekommen.
Nicht nur auf Seiten der Endkunden, die mit Hilfe von OpenPGP oder S/MIME vertraulich kommunizieren, sondern auch serverseitig kann der Übertragungsweg mit einfachen Mitteln entsprechend verschlüsselt werden. Für die vertrauliche Kommunikation zwischen unseren Usern und unserm Postfix-Mailserver, wie auch zwischen fremden Postfix bietet sich eine verschlüsselte Kommunikation mit Hilfe von SSL/TLS an.
Mit Hilfe von PFS1) können wir leicht und einfach sicherstellen, dass aufgezeichnete Datenströme im nachhinein nicht entschlüsselt werden können. Dies wird erreicht, da die beiden Kommunikationspartner, einen separaten und individuellen temporären Schlüssel zur Datensicherung verwenden. Dieser Schlüssel ist dabei nicht fix, sondern wird bei jeder Verbindung neu ausgehandelt. Da aber der Schlüssel an sich nicht ausgetauscht werden muss, ist es auch nicht möglich, den eventuell aufgezeichneten Datenstrom zu entschlüsseln, da der dazu benötigte Schlüssel nicht im Datenstrom enthalten war.
Perfect Forward Secrecy (PFS) basiert auf der Idee, dass Client und Server ihre Kommunikation über einen zusätzlichen temporären Schlüssel absichern, der wechselt. Da der Verbindungsaufbau so gestrickt ist, dass der Schlüssel selbst gar nicht ausgetauscht werden muss, kann der jeweils benutzte Sitzungsschlüssel selbst auch nicht aufgezeichnet werden. Eine nachträgliche Entschlüsselung einer früher aufgezeichneten Session ist damit nicht mehr möglich.
Die für die Verschlüsselung notwendigen Schlüssel und Zertifikate erstellen wir mittels OpenSSL, einer freien Implementierung von SSL2). SSL oder TLS3) ist ein hybrides Verschlüsselungsprotokoll zur Datenübertragung im Internet. Unter TLS 1.0, 1.1 und 1.2 versteht man die standardisierten Weiterentwicklungen von SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). Dies bedeutet also, SSL wird nun unter dem Namen TLS weiterentwickelt.
OpenSSL
Bei der Standardinstallation unseres Systems wurde in der Regel bereits das Paket openssl installiert. Ein kurzer Blick in die RPMdatenbank schafft hierzu Gewissheit.
# yum list openssl
Installed Packages openssl.x86_64 1:1.0.1e-34.el7_0.6
Sollte das Paket noch fehlen, installieren wir dies einfach via:
# yum install openssl
Was uns das Paket openssl alles mitbringt und wohin die Programme und Konfigurationsdateien kopiert werden, offenbart uns das System wie folgt.
# rpm -qil openssl
Name : openssl Epoch : 1 Version : 1.0.1e Release : 34.el7_0.6 Architecture: x86_64 Install Date: Sat 18 Oct 2014 09:55:41 AM CEST Group : System Environment/Libraries Size : 1610001 License : OpenSSL Signature : RSA/SHA256, Thu 16 Oct 2014 06:06:46 PM CEST, Key ID 24c6a8a7f4a80eb5 Source RPM : openssl-1.0.1e-34.el7_0.6.src.rpm Build Date : Thu 16 Oct 2014 05:42:42 PM CEST Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.openssl.org/ Summary : Utilities from the general purpose cryptography library with TLS implementation Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. /etc/pki/CA /etc/pki/CA/certs /etc/pki/CA/crl /etc/pki/CA/newcerts /etc/pki/CA/private /etc/pki/tls/certs/Makefile /etc/pki/tls/certs/make-dummy-cert /etc/pki/tls/certs/renew-dummy-cert /etc/pki/tls/misc/CA /etc/pki/tls/misc/c_hash /etc/pki/tls/misc/c_info /etc/pki/tls/misc/c_issuer /etc/pki/tls/misc/c_name /usr/bin/openssl /usr/share/doc/openssl-1.0.1e /usr/share/doc/openssl-1.0.1e/CHANGES /usr/share/doc/openssl-1.0.1e/FAQ /usr/share/doc/openssl-1.0.1e/INSTALL /usr/share/doc/openssl-1.0.1e/LICENSE /usr/share/doc/openssl-1.0.1e/NEWS /usr/share/doc/openssl-1.0.1e/README /usr/share/doc/openssl-1.0.1e/README.FIPS /usr/share/doc/openssl-1.0.1e/c-indentation.el /usr/share/doc/openssl-1.0.1e/openssl.txt /usr/share/doc/openssl-1.0.1e/openssl_button.gif /usr/share/doc/openssl-1.0.1e/openssl_button.html /usr/share/doc/openssl-1.0.1e/ssleay.txt /usr/share/man/man1/asn1parse.1ssl.gz /usr/share/man/man1/ca.1ssl.gz /usr/share/man/man1/ciphers.1ssl.gz /usr/share/man/man1/cms.1ssl.gz /usr/share/man/man1/crl.1ssl.gz /usr/share/man/man1/crl2pkcs7.1ssl.gz /usr/share/man/man1/dgst.1ssl.gz /usr/share/man/man1/dhparam.1ssl.gz /usr/share/man/man1/dsa.1ssl.gz /usr/share/man/man1/dsaparam.1ssl.gz /usr/share/man/man1/ec.1ssl.gz /usr/share/man/man1/ecparam.1ssl.gz /usr/share/man/man1/enc.1ssl.gz /usr/share/man/man1/errstr.1ssl.gz /usr/share/man/man1/gendsa.1ssl.gz /usr/share/man/man1/genpkey.1ssl.gz /usr/share/man/man1/genrsa.1ssl.gz /usr/share/man/man1/md2.1ssl.gz /usr/share/man/man1/md4.1ssl.gz /usr/share/man/man1/md5.1ssl.gz /usr/share/man/man1/mdc2.1ssl.gz /usr/share/man/man1/nseq.1ssl.gz /usr/share/man/man1/ocsp.1ssl.gz /usr/share/man/man1/openssl.1ssl.gz /usr/share/man/man1/pkcs12.1ssl.gz /usr/share/man/man1/pkcs7.1ssl.gz /usr/share/man/man1/pkcs8.1ssl.gz /usr/share/man/man1/pkey.1ssl.gz /usr/share/man/man1/pkeyparam.1ssl.gz /usr/share/man/man1/pkeyutl.1ssl.gz /usr/share/man/man1/req.1ssl.gz /usr/share/man/man1/ripemd160.1ssl.gz /usr/share/man/man1/rsa.1ssl.gz /usr/share/man/man1/rsautl.1ssl.gz /usr/share/man/man1/s_client.1ssl.gz /usr/share/man/man1/s_server.1ssl.gz /usr/share/man/man1/s_time.1ssl.gz /usr/share/man/man1/sess_id.1ssl.gz /usr/share/man/man1/sha.1ssl.gz /usr/share/man/man1/sha1.1ssl.gz /usr/share/man/man1/smime.1ssl.gz /usr/share/man/man1/speed.1ssl.gz /usr/share/man/man1/spkac.1ssl.gz /usr/share/man/man1/sslpasswd.1ssl.gz /usr/share/man/man1/sslrand.1ssl.gz /usr/share/man/man1/ts.1ssl.gz /usr/share/man/man1/tsget.1ssl.gz /usr/share/man/man1/verify.1ssl.gz /usr/share/man/man1/version.1ssl.gz /usr/share/man/man1/x509.1ssl.gz /usr/share/man/man5/config.5ssl.gz /usr/share/man/man5/openssl.cnf.5ssl.gz /usr/share/man/man5/x509v3_config.5ssl.gz /usr/share/man/man7/des_modes.7ssl.gz
Cipher-Suites und Diffie-Hellmann
Möchte man in Erfahrung bringen, welche Cipher-Suites4) (Chiffrensammlung) unser installiertes OpenSSL-Paket mitbringt, können wir wie folgt abfragen5).
# openssl ciphers -v
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1 KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1 KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1 KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5 KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
Wir haben also mit der aktuellen Version von OpenSSL, den für Perfect Forward Secrecy benötigten kryptographischen Algorithmus DH6) sowie den weiterentwickelten ECDH7).
Enhanced Diffie Hellman Keys
Bei der Postfix-Installation wurden vordefinierte Schlüssel mitgeliefert, die jedoch bei den RPM-Installation mit diesem Paket gleich sind. Also werden wir uns nun erst einmal passende Diffie-Hellmann-Schlüsselparameterdatei generieren. Als erstes einen 512-bit Schlüssel (export ciphers), der jedoch „nur“ noch für die obsoleten „Export“-Ciphers verwendet wird. Des weiteren generieren wir noch einen 1024-bit und einen 2048-bit (non export ciphers) Schlüssel, die für all die anderen EDH Cipher Suits verwendet werden.
# openssl dhparam -out /etc/pki/postfix/private/dh_512.pem -2 512
Generating DH parameters, 512 bit long safe prime, generator 2 This is going to take a long time ......+...........+.......+.........................+......+.+........+.....+.........+......................................++*++*++*++*++*++*
# openssl dhparam -out /etc/pki/postfix/private/dh_1024.pem -2 1024
Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time ...............................+............+............................................................+........+.......+.................+.........................+........+......+.......+.........................................+...................+............................+...............................+...............+.............+.+.........+....+............+............+................................+.........+....+.+..+.................+......................................................+.............+.+..................+.............................................................................................................+......+........+.........................................................................................................................................................+...........+........................+..............+.................................+.......+........+................................+...............+..................+.........................................+..........................+............+..........................+..............................+............................+...+................+.....+.................+.++*++*++*++*++*++*
# openssl dhparam -out /etc/pki/postfix/private/dh_2048.pem -2 2048
Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time ...........+..............................................................+.................+........................................................................................................................................................................................................................+...................................................................+..................................................................+...........................+....................................................................................................................+........+.................+.................................................................................................+...........+...................+.......................................................................................................+++...................................+....+................................................+.....................................+...............+.....+.............................+.+.........................+.........................+....................................+...................................................................................+..................+............+...............................+.........................................................................................+..............+.................................+.............+................................................................+.....+..............+.........+.............+..............................................+..............+................................++*++*++*
Um nun nicht jeden Schlüssel einzeln generieren zu müssen, legen wir uns kurzer Hand einfach ein passendes Shell-Script an. Zuvor legen wir aber noch ein Verzeichnis an, in dem die Schlüssel vorübergehend abgelegt werden können.
# mkdir /etc/pki/tls/tmp
# vim edh_keygen
- edh_keygen
#!/bin/bash # Script zum Erstellen der Diffie Hellman Schlüssel # Django <django@mailserver.guru> (c) 2015 cd /etc/pki/tls/tmp umask 022 openssl dhparam -out dh_512.pem 512 openssl dhparam -out dh_1024.pem 1024 openssl dhparam -out dh_2048.pem 2048 openssl dhparam -out dh_4096.pem 4096 chmod 640 dh_512.pem dh_1024.pem dh_2048.pem dh_4096.pem /usr/bin/rsync /etc/pki/tls/tmp/*.pem /etc/pki/tls/private/ rm *.pem -f systemctl condrestart postfix
Damit das Script auch ausgeführt werden kann, versehen wir es noch mit den benötigten Rechten.
# chmod +x edh_keygen
Warum das ganze in ein Shellsript packen, wird nun sich der ein oder andere gefragt haben. Ganz einfach: Wenn wir das Script nun nach /etc/cron.daily verschieben, können wir einfach einmal am Tag neu generierte Schlüssel generieren und auch verwenden!
# mv edh_keygen /etc/cron.daily/
Zum Testen welche Schlüssel vom Server verwendet werden, können wir folgenden Befehl verwenden:
$ echo | openssl s_client -starttls smtp -connect smtp.nausch.org:25 -cipher "EDH" 2>/dev/null | grep -ie "Server .* key"
Als Antwort erhalten wie zwei Zeilen mit Angabe zu den Schlüssellängen. Die erste Zeile beschreibt den temporären Diffie Hellman, die zweite Zeile den RSA-Schlüssel des TLS-Zertifikats.
Server Temp Key: DH, 4096 bits Server public key is 4096 bit
Zertifikatserstellung
Technisch gesehen unterscheiden sich Zertifikate einer „offiziellen“ oder besser gesagt einer kommerziellen CA nicht von Zertifikaten einer eigenen „self signed“ Zertifikaten. In aller Regel wird dies abhängig davon sein, ob die verwendeten Zertifikate anstandslos von den Clientprogrammen (Mailclients und ggf. Browser) beim Endnutzer akzeptiert werden, also von einer vertrauenswürdigen CA stammen.
Egal welchen Weg wir hier gehen können oder müssen, zur Absicherung unserer Kommunikation benötigen wir drei Dinge:
- unseren Private Key, den wir hüten wie unseren Augapfel
- unseren Public Key mit zusätzlichen Daten , auch bekannt als CSR8), den wir von einer CA9) signieren lassen. Dies ist das Zertifikat, welches wir von unserer eigenen CA oder auch eine der vielen kommerziellen erhalten, und
- den Public Key der unterschreibenden CA, um deren Unterschrift zu prüfen, auch als Root-Zertifikat bekannt.
Nutzt man ein kommerzielle CA können wir die nächsten Kapitel getrost überspringen und gleich damit starten, den nötigen Schlüssel für unser Zertifikat/CSR zu erstellen.
Scriptgesteuert erstellen
Dem Paket openssl liegt zwar ein Bash-Script bei, mit dessen Hilfe die nachfolgenden Installationsschritte automatisiert ablaufen sollen, aber zum besseren Verständnis, gehen wir die Schritte kurz manuell durch. Das vorgenante Script aus dem Jahre '96 findet man im Übrigen sonderbarer Weise unter /etc/pki/tls/misc/CA.
# cat /etc/pki/tls/misc/CA
- /etc/pki/tls/misc/CA
#!/bin/sh # # CA - wrapper around ca to make it easier to use ... basically ca requires # some setup stuff to be done before you can use it and this makes # things easier between now and when Eric is convinced to fix it :-) # # CA -newca ... will setup the right stuff # CA -newreq ... will generate a certificate request # CA -sign ... will sign the generated request and output # # At the end of that grab newreq.pem and newcert.pem (one has the key # and the other the certificate) and cat them together and that is what # you want/need ... I'll make even this a little cleaner later. # # # 12-Jan-96 tjh Added more things ... including CA -signcert which # converts a certificate to a request and then signs it. # 10-Jan-96 eay Fixed a few more bugs and added the SSLEAY_CONFIG # environment variable so this can be driven from # a script. # 25-Jul-96 eay Cleaned up filenames some more. # 11-Jun-96 eay Fixed a few filename missmatches. # 03-May-96 eay Modified to use 'ssleay cmd' instead of 'cmd'. # 18-Apr-96 tjh Original hacking # # Tim Hudson # tjh@cryptsoft.com # # default openssl.cnf file has setup as per the following # demoCA ... where everything is stored cp_pem() { infile=$1 outfile=$2 bound=$3 flag=0 exec <$infile; while read line; do if [ $flag -eq 1 ]; then echo $line|grep "^-----END.*$bound" 2>/dev/null 1>/dev/null if [ $? -eq 0 ] ; then echo $line >>$outfile break else echo $line >>$outfile fi fi echo $line|grep "^-----BEGIN.*$bound" 2>/dev/null 1>/dev/null if [ $? -eq 0 ]; then echo $line >$outfile flag=1 fi done } usage() { echo "usage: $0 -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify" >&2 } if [ -z "$OPENSSL" ]; then OPENSSL=openssl; fi if [ -z "$DAYS" ] ; then DAYS="-days 365" ; fi # 1 year CADAYS="-days 1095" # 3 years REQ="$OPENSSL req $SSLEAY_CONFIG" CA="$OPENSSL ca $SSLEAY_CONFIG" VERIFY="$OPENSSL verify" X509="$OPENSSL x509" PKCS12="openssl pkcs12" if [ -z "$CATOP" ] ; then CATOP=/etc/pki/CA ; fi CAKEY=./cakey.pem CAREQ=./careq.pem CACERT=./cacert.pem RET=0 while [ "$1" != "" ] ; do case $1 in -\?|-h|-help) usage exit 0 ;; -newcert) # create a certificate $REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS RET=$? echo "Certificate is in newcert.pem, private key is in newkey.pem" ;; -newreq) # create a certificate request $REQ -new -keyout newkey.pem -out newreq.pem $DAYS RET=$? echo "Request is in newreq.pem, private key is in newkey.pem" ;; -newreq-nodes) # create a certificate request $REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS RET=$? echo "Request (and private key) is in newreq.pem" ;; -newca) # if explicitly asked for or it doesn't exist then setup the directory # structure that Eric likes to manage things NEW="1" if [ "$NEW" -o ! -f ${CATOP}/serial ]; then # create the directory hierarchy mkdir -p ${CATOP} mkdir -p ${CATOP}/certs mkdir -p ${CATOP}/crl mkdir -p ${CATOP}/newcerts mkdir -p ${CATOP}/private touch ${CATOP}/index.txt fi if [ ! -f ${CATOP}/private/$CAKEY ]; then echo "CA certificate filename (or enter to create)" read FILE # ask user for existing CA certificate if [ "$FILE" ]; then cp_pem $FILE ${CATOP}/private/$CAKEY PRIVATE cp_pem $FILE ${CATOP}/$CACERT CERTIFICATE RET=$? if [ ! -f "${CATOP}/serial" ]; then $X509 -in ${CATOP}/$CACERT -noout -next_serial \ -out ${CATOP}/serial fi else echo "Making CA certificate ..." $REQ -new -keyout ${CATOP}/private/$CAKEY \ -out ${CATOP}/$CAREQ $CA -create_serial -out ${CATOP}/$CACERT $CADAYS -batch \ -keyfile ${CATOP}/private/$CAKEY -selfsign \ -extensions v3_ca \ -infiles ${CATOP}/$CAREQ RET=$? fi fi ;; -xsign) $CA -policy policy_anything -infiles newreq.pem RET=$? ;; -pkcs12) if [ -z "$2" ] ; then CNAME="My Certificate" else CNAME="$2" fi $PKCS12 -in newcert.pem -inkey newreq.pem -certfile ${CATOP}/$CACERT \ -out newcert.p12 -export -name "$CNAME" RET=$? exit $RET ;; -sign|-signreq) $CA -policy policy_anything -out newcert.pem -infiles newreq.pem RET=$? cat newcert.pem echo "Signed certificate is in newcert.pem" ;; -signCA) $CA -policy policy_anything -out newcert.pem -extensions v3_ca -infiles newreq.pem RET=$? echo "Signed CA certificate is in newcert.pem" ;; -signcert) echo "Cert passphrase will be requested twice - bug?" $X509 -x509toreq -in newreq.pem -signkey newreq.pem -out tmp.pem $CA -policy policy_anything -out newcert.pem -infiles tmp.pem RET=$? cat newcert.pem echo "Signed certificate is in newcert.pem" ;; -verify) shift if [ -z "$1" ]; then $VERIFY -CAfile $CATOP/$CACERT newcert.pem RET=$? else for j do $VERIFY -CAfile $CATOP/$CACERT $j if [ $? != 0 ]; then RET=$? fi done fi exit $RET ;; *) echo "Unknown arg $i" >&2 usage exit 1 ;; esac shift done exit $RET
Wichtig:
Zum besseren Verständnis der Zertifikatsthematik, gehen wir die Schritte kurz manuell durch und nutzen nicht das fast 20 jahre alte Script.
manuelle Erstellung unserer eigenen CA
fehlende Dateien anlegen
Als erstes legen wir die noch fehlenden Dateien an.
# echo "00" > /etc/pki/CA/serial
# touch /etc/pki/CA/index.txt
Somit befindet sich in unserem Pfad /etc/pki/CA nun folgender Inhalt:
# ll /etc/pki/CA
total 4 drwxr-xr-x 2 root root 6 Jun 24 14:57 certs drwxr-xr-x 2 root root 6 Jun 24 14:57 crl -rw-r--r-- 1 root root 0 Jul 23 14:03 index.txt drwxr-xr-x 2 root root 6 Jun 24 14:57 newcerts drwx------ 2 root root 6 Jun 24 14:57 private -rw-r--r-- 1 root root 3 Jul 23 14:03 serial
CA-Erstellung mit Hilfe von openssl
Die Gültigkeit setzen wir mit 25 Jahren bewusst sehr hoch an. Nach dem Ablauf der Gültigkeit der CA werden nämlich auch alle damit signierten Serverzertifikate ungültig! Bei der nun folgenden Generierung unserer CA wird automatisch ein Schlüssel (private key), mit einer Länge von 2048 Bit, erzeugt und in der Datei cakey.pem abgespeichert. Das CA-Zertifikat selbst wird nach cacert.pem geschrieben.
Zur Sicherheit schützen wir den private key unserer CA mit einer Passphrase! Denn wer den geheimen Schlüssel der CA hat/kennt, könnte damit beliebige Serverzertifikate signieren. Daher legen wir dieses Keyfile nicht im Klartext auf der Festplatte ab, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigen wir immer dann, wenn wir mit unser eigenen CA neue Zertifikate ausstellen wollen. Im nachfolgenden Dialog akzetieren wir die Vorgaben in eckigen Klammern, geben unsere individuellen Daten an, oder quittieren ein leeres Feld mittels eines Punktes .. Beim Feld Common Name (CN) geben wir den Domain-Namen unserer Zertifizierungsstelle ein.
Diese Daten werden dem Client angezeigt, sobald dieser aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen.
Die Eingaben sind in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl req -new -x509 -newkey rsa:4096 -keyout cakey.pem -out cacert.pem -days 9125
Generating a 4096 bit RSA private key ..................................................++ ....................++ writing new private key to 'cakey.pem' Enter PEM pass phrase: des-woas-blos-I-und-sundst-koana Verifying - Enter PEM pass phrase: des-woas-blos-I-und-sundst-koana ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:DE State or Province Name (full name) []:Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:Zertifizierungsstelle Common Name (eg, your name or your server's hostname) []:nausch.org Email Address []:ca-support@nausch.org
Als Ergebnis erhalten wir zwei Dateien:
- cakey.pem den private key unserer CA und
- cacert.pem das CA-Certifikat unserer CA.
# ll *.pem
- rw-r–r– 1 root root 2171 Jul 23 14:07 cacert.pem
- rw-r–r– 1 root root 3394 Jul 23 14:07 cakey.pem
Sicherheitshalber ändern wir die Rechte so, dass die Schlüsseldateien nur für root lesbar sind:
# chmod 400 *.pem
Bei Bedarf kann man mit openssl rsa -in <keyfile> -noout -text die Schlüsseldatei öffnen und ausgeben lassen.
# openssl rsa -in cakey.pem -noout -text
Enter pass phrase for cakey.pem: des-woas-blos-I-und-sundst-koana Private-Key: (4096 bit) modulus: 00:a6:c0:e4:4a:c5:be:6c:c7:fe:8d:20:34:3d:58: f5:40:3c:4b:b6:8a:df:3f:2b:cf:c2:9a:d6:0e:1e: 78:25:93:b1:6e:d4:fe:c4:41:0a:3a:f4:7e:f9:f1: f1:a3:2a:b9:c2:b7:86:39:94:4a:16:be:97:e6:92: 4a:3d:e7:f3:63:46:d4:fb:66:b1:cb:f6:d0:0a:9e: 04:fd:cc:d0:7f:bd:af:40:01:cb:86:ab:c7:e8:25: d8:58:72:66:a7:6e:ab:af:70:a6:07:06:df:a8:86: d9:53:75:74:d5:55:a7:4c:7e:4a:55:96:39:0a:97: 98:eb:b3:58:57:bc:5d:ef:7b:6c:8c:a0:ba:9f:10: 67:14:f0:4f:2b:7b:b9:72:b9:ff:e2:99:3f:a7:d2: 91:2c:a2:db:94:e9:bb:90:06:e2:91:06:c7:26:fb: 23:06:83:b0:60:30:a2:d5:7d:22:95:62:99:42:c3: 8e:58:44:32:52:29:ad:68:27:bb:ae:5d:99:67:0e: 10:a0:3c:c0:a6:d4:d5:44:a8:c9:c4:a4:45:12:19: 46:c3:aa:dc:e5:61:a2:0c:cf:2f:38:f3:6f:5c:13: f9:fe:86:c0:4a:ba:2a:9a:4f:25:4d:63:85:e4:6a: 9d:f1:53:a0:31:64:aa:77:98:b9:0e:63:5c:de:d9: 04:ed:d0:b7:fa:5b:5d:cc:e4:1e:c4:5b:e3:05:dd: 79:21:ae:e1:a3:6d:0b:9e:78:fb:d7:67:cc:a4:b2: 21:44:e1:0a:bc:e1:e9:ab:1d:f2:c8:a9:59:51:3c: dd:d9:e4:de:e5:a3:c7:95:83:5a:f5:c1:b1:cb:69: f5:fe:a6:8d:91:11:c4:5d:cd:b5:cc:fc:77:60:68: aa:3e:92:dc:6f:ac:55:03:82:7a:7d:77:17:00:14: 4f:e2:b9:d8:87:bc:30:f1:b7:28:1d:a9:6b:25:2c: 22:28:29:6b:9e:ba:ad:2f:12:77:be:e4:43:69:0f: fd:a7:f9:03:21:05:df:f4:eb:90:1c:8e:1e:82:d2: 81:0d:a1:a9:00:cb:3e:b8:73:39:19:4f:32:cc:dc: 4e:ea:ab:1c:1b:a1:6d:63:68:a8:3a:67:65:22:ec: 0c:ea:f7:e6:38:9c:5e:0c:8c:e7:d1:30:fa:53:2d: 80:2f:19:84:d2:49:17:7f:6d:d5:63:d2:20:3d:ec: e6:d7:74:65:e6:cc:be:cb:1b:07:76:96:aa:05:16: 4e:26:89:ab:42:f1:39:58:2c:af:44:fb:e6:c9:ea: 46:34:19:8f:6a:d4:59:55:d8:40:d5:a2:39:8e:80: ce:9b:6e:42:8f:2f:49:93:24:b5:6c:a5:07:b0:9c: f9:25:eb publicExponent: 65537 (0x10001) privateExponent: 45:42:50:8f:8d:da:2d:ac:53:59:a2:4a:90:40:66: 7c:ab:8e:76:de:ef:22:79:bb:ed:04:0a:6c:0a:d3: b4:27:c7:c6:54:c9:0c:12:47:81:7d:13:50:14:e1: 5b:f7:de:f7:b4:ea:16:f8:34:5d:86:03:e9:4c:51: 71:ac:e9:36:0e:b1:5f:49:a4:07:27:17:f9:90:f0: 59:c9:bb:bf:92:b5:3b:4c:83:90:07:c1:1b:f6:bc: 08:e0:5b:2a:a7:98:bf:61:76:53:ec:d2:f0:58:31: e3:ac:21:3e:8a:38:d6:58:8d:df:46:69:a2:b0:9c: 5f:29:3a:44:16:84:9d:77:11:fa:c6:b7:3c:61:bf: ae:be:b0:e3:4a:9c:17:be:91:3d:38:91:6b:ce:d5: 65:48:af:13:06:91:54:9c:c7:75:9c:ef:12:8d:b4: 5a:7c:4f:c1:63:f1:fd:e1:df:7f:54:58:7b:96:65: 84:db:ae:5a:d9:dc:a0:2a:00:95:c7:62:73:9f:2f: e0:9d:db:16:6f:c7:b4:a0:b6:4c:ea:3d:95:ea:d1: ad:6b:46:1c:2f:94:f2:e5:0a:a4:08:d7:f3:d2:88: 3e:e3:10:f2:f8:a7:c1:37:a6:32:a2:67:76:1b:a2: 46:1d:89:a7:7a:3c:23:38:57:84:56:58:b8:66:42: d9:27:95:61:cb:1b:39:61:a4:f1:cb:c1:71:ea:3f: 3b:a3:44:ea:84:77:eb:f6:bb:3e:9e:08:1d:27:91: b5:89:cd:ba:97:fc:6a:de:f9:43:9d:e4:a0:b2:b5: bd:b7:ea:d7:84:2e:9e:78:5b:fc:27:73:6c:51:40: c0:bd:0c:69:3e:4a:c5:ac:15:cb:a8:7c:4a:fa:ee: bc:64:94:02:af:da:56:e5:56:9f:79:93:8d:f1:42: f7:39:99:dc:82:ab:4b:20:e9:10:da:01:2c:94:be: fa:d6:9d:59:e9:fb:b9:b8:af:79:10:25:f9:a4:22: 1e:4b:03:ac:e7:a1:57:35:d8:e4:49:1b:78:c5:b9: 1c:3f:30:1c:19:20:2a:b9:0f:90:aa:c1:60:19:ba: b5:de:98:c4:68:81:ef:8a:c7:fc:c7:64:85:3a:47: a7:97:b7:ec:4d:fe:f9:ce:e9:9a:2f:76:ea:77:0e: 3e:ac:48:f9:f2:c4:c0:fa:af:f7:09:a6:cb:35:14: c6:30:fe:ba:7d:b2:d9:ba:50:9a:84:5c:17:11:65: c4:b9:86:c7:db:52:05:b6:66:df:05:e9:17:03:c1: 02:5b:77:06:0b:7f:5a:a9:f9:01:b7:8d:4a:c3:42: d7:cd:80:f3:12:c1:36:e2:bf:08:36:52:d8:c6:79: 6d:a1 prime1: 00:dd:13:5d:14:12:93:0e:aa:0b:5f:b2:a7:a8:10: 5b:0c:cc:41:46:bb:ac:3a:d1:e1:e8:76:4b:1a:49: 0e:d4:0c:5e:51:75:c4:77:f5:68:dd:26:f2:d1:b6: 02:77:e2:cf:53:37:a6:f4:a5:b3:dc:26:56:bd:8f: 3e:b2:22:67:67:dc:a1:70:40:6b:57:33:b4:08:e6: d0:f3:a4:dd:b3:0c:17:bc:57:2a:47:9a:fc:c8:0d: 03:41:b7:56:d6:ce:69:bf:7a:45:5a:72:6c:02:b3: 70:a7:fa:62:ac:a4:5d:5a:c6:92:5d:84:f4:8f:90: 3a:d2:4a:79:89:d7:6a:50:41:12:ea:b9:24:e0:96: e5:70:62:0a:50:3e:82:cf:56:08:99:47:ba:bf:7b: 8f:b7:b0:89:b6:06:ea:0e:78:86:5b:e1:32:2f:49: 61:88:62:29:c3:db:c0:a1:89:1a:66:48:c4:c1:07: 12:11:2a:ad:73:0a:c2:f3:fa:75:66:88:87:c0:66: cc:70:7c:29:96:e1:4b:36:36:7e:73:4c:ba:65:5b: c6:07:c1:e1:d0:43:e6:c8:6e:83:ed:67:c2:ce:b4: 2c:a9:e2:5c:87:24:bb:ad:f0:3c:d7:7a:c7:86:aa: d3:e3:f1:24:12:8b:b1:55:3e:a7:77:65:80:75:fe: b6:37 prime2: 00:c1:18:a8:42:3e:47:be:ac:a1:5a:82:06:24:ff: 15:d6:07:dc:79:94:25:6a:f9:de:63:18:d9:93:ca: d8:88:94:8a:d3:7f:f3:2e:6f:1c:64:40:86:e7:3d: 34:8e:45:c9:f4:dd:1a:17:bb:7f:55:9d:ed:d6:d3: 73:7e:c5:9d:a8:0f:cd:00:eb:78:9c:0c:4d:77:b5: f7:80:e4:5c:ee:84:1b:aa:9f:b9:82:24:b3:e9:cd: 7e:ee:bb:bf:ce:a0:82:cf:cc:fa:2c:b8:07:fe:79: ab:00:41:6a:55:3b:88:6e:5c:53:64:07:c2:2a:78: 29:a6:c2:5c:5d:77:1d:a1:83:d5:d1:4b:3d:ce:88: e4:6f:e8:ff:0b:cb:9e:79:51:63:00:02:5e:2f:fc: 2d:14:9d:02:e0:eb:88:8b:35:76:94:a9:da:da:a9: b6:5b:eb:b2:ff:ad:72:a6:4e:6a:1d:08:36:99:fc: 63:8b:92:66:c9:0b:af:6d:64:f0:d0:0e:8b:10:2c: 45:7f:2e:e3:6d:7d:e0:60:69:65:30:0e:25:5b:d8: 06:00:77:cb:1e:d5:9b:72:34:49:e8:9c:c6:a8:61: 2d:e0:f8:fe:c7:57:ae:47:79:14:07:22:38:9e:bf: 44:ec:28:b5:73:73:a4:c1:26:89:b0:71:ee:4e:4e: b3:ed exponent1: 69:79:e7:9a:c0:11:f1:99:27:bc:0c:dc:f8:ce:74: e2:72:41:62:a1:ff:d6:40:74:ec:18:24:54:f2:2e: 64:f5:51:ba:c3:d9:6c:f2:65:89:be:1f:73:f6:c6: ce:b4:23:fe:ac:3a:b7:d6:a7:2d:8e:0d:2c:7b:bf: 89:f5:e8:28:21:97:d4:9a:a7:9b:ff:4b:12:44:2d: c5:51:0f:85:71:6b:91:ac:74:bb:9d:32:a5:af:af: b2:16:eb:13:a9:7f:c2:9f:6f:9f:6b:a0:24:d9:c0: 12:24:e0:17:46:84:53:df:11:ce:14:b5:2a:19:c2: 36:ba:d9:a9:ee:61:06:d1:45:59:3f:e4:5c:53:22: 3c:b0:4a:03:67:0f:ba:24:6e:0d:d3:af:41:d4:8e: 09:31:ed:42:2f:a2:54:2d:24:cd:89:70:0c:27:92: a5:23:50:91:e5:b2:ce:5f:3f:7d:35:92:ca:15:b9: 84:ff:3b:a9:fb:a4:70:0b:3b:20:24:5b:c0:6c:4b: 76:0f:87:38:39:5d:4d:0c:4a:e0:6f:e7:2e:9c:ce: aa:bc:d2:24:2f:81:58:77:81:f2:2e:e3:3f:03:af: 9b:8e:28:5f:42:23:59:25:99:a1:a5:2e:b5:0d:a3: f2:c9:06:50:e2:dd:44:b2:93:eb:df:3d:9f:0e:5b: 99 exponent2: 0f:3d:16:ea:43:67:fe:10:39:9b:9e:ef:45:34:2c: 50:fb:c5:d6:82:6e:81:86:be:9a:2b:77:e0:45:fd: d8:a9:80:5b:38:99:c4:6c:58:5d:41:0a:64:6d:5c: 1c:6e:3d:85:e9:7d:09:aa:6e:5e:1f:5c:89:bb:9e: 3d:be:f2:b6:34:a9:05:0d:90:33:20:75:6c:a1:1b: ab:3c:5a:69:28:5b:d6:97:4c:58:8c:f4:f5:da:95: cd:d9:5b:45:bf:3d:13:91:25:9d:29:d8:d7:a8:5a: 6a:66:bf:31:82:c5:3d:90:63:b4:5d:38:61:89:a2: 1f:da:ee:d7:21:73:61:2f:ba:4c:0e:18:0e:98:97: 0e:8d:e0:b2:d9:9a:e4:10:1c:33:ff:fb:d6:e5:9b: d9:28:9a:f5:8d:20:f5:7b:7e:a4:34:d3:64:b6:48: 01:f1:13:eb:41:90:ee:b6:f9:80:d9:09:16:15:e8: f5:36:d4:8d:c1:32:52:fb:c8:55:63:10:6e:72:4f: f9:bd:85:8d:3a:85:de:95:f2:ba:5c:23:6e:a0:19: b9:27:bb:0b:ef:e7:98:97:af:cd:7f:b1:dd:cf:ed: 82:f7:a3:83:af:d3:bd:28:3d:00:63:1e:fc:c8:33: 74:3f:b2:32:2e:4a:2e:44:10:51:b0:6c:12:19:fb: f1 coefficient: 00:a6:96:2f:62:1b:35:35:c6:20:ef:a9:8e:66:ac: 5b:2c:a4:cc:ff:ed:a6:53:ad:9d:e1:cb:73:4e:3c: df:08:f8:7a:10:ee:f1:3b:51:52:6a:ba:eb:60:3a: 72:ee:89:d5:ce:f3:64:bb:44:97:0a:94:25:7f:ce: 0e:f5:13:33:1e:2c:ba:7e:7e:ec:39:4a:ea:8c:05: 76:48:59:f2:19:e5:16:37:1f:1d:dc:9e:06:cb:20: 31:9c:00:61:40:ba:8b:94:c2:68:2c:54:04:a4:5b: 36:d5:36:dd:cc:64:d8:15:d1:14:0e:de:23:9a:59: c3:b3:1d:7c:6d:29:98:6d:b3:11:71:d1:6e:d2:9d: 01:9a:12:aa:f9:1f:54:f1:d6:0a:b3:ea:1c:b4:cb: fb:91:f3:dd:e4:a7:3c:f0:74:f1:c9:e5:42:f2:2d: 03:b6:a4:ba:34:92:f5:70:f0:ae:34:b3:6f:c4:69: 3d:14:76:ec:a6:e6:c6:d2:a4:d3:05:30:0e:f8:de: 46:f1:f6:bc:4d:ba:7c:fe:fa:5d:fa:35:54:df:be: b5:08:92:ea:ba:b6:9c:cc:06:77:40:1e:c3:cc:f7: 6a:4f:56:a7:b3:a9:9a:55:91:55:e0:aa:8e:f7:8d: 6e:59:26:d7:8e:ea:c8:e1:19:a9:12:c0:43:f7:7d: 82:f5
Will man die Passphrase eines Schlüssels entfernen, geht man wie folgt vor:
# openssl rsacakey_ohne_passphrase.pem
Enter pass phrase: des-woas-blos-I-und-sundst-koana writing RSA key
Auch hier sind die Eingaben sind in der Farbe blau, sowie die Rückmeldungen in der Farbe grün gekennzeichnet.
Laufzeit der Zertifikate anpassen
Da wir die Laufzeit der erzeugten Zertifikate nicht auf der Kommandozeile beim Aufruf von openssl angeben können, passen wir in der OpenSSL-Konfigurationsdatei die Laufzeit default_days an.
# vim /etc/pki/tls/openssl.cnf
- /etc/pki/tls/openssl.cnf
# # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. # # This definition stops the following lines choking if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) [ new_oids ] # We can add new OIDs in here for use by 'ca', 'req' and 'ts'. # Add a simple OID like this: # testoid1=1.2.3.4 # Or use config file substitution like this: # testoid2=${testoid1}.5.6 # Policies used by the TSA examples. tsa_policy1 = 1.2.3.4.1 tsa_policy2 = 1.2.3.4.5.6 tsa_policy3 = 1.2.3.4.5.7 #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir = /etc/pki/CA # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. #unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = usr_cert # The extentions to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options # Extension copying option: use with caution. # copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # crlnumber must also be commented out to leave a V1 CRL. # crl_extensions = crl_ext # Django : 2014-07-23 # default: default_days = 365 # how long to certify for (one year) default_days = 730 # how long to certify for (two years) default_crl_days= 30 # how long before next CRL default_md = sha256 # use SHA-256 by default preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### [ req ] default_bits = 2048 default_md = sha256 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert # Passwords for private keys if not present they will be prompted for # input_password = secret # output_password = secret # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK:XXXX a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only # req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = XX countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) #stateOrProvinceName_default = Default Province localityName = Locality Name (eg, city) localityName_default = Default City 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Default Company Ltd # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = Organizational Unit Name (eg, section) #organizationalUnitName_default = commonName = Common Name (eg, your name or your server\'s hostname) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 # SET-ex3 = SET extension number 3 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name [ usr_cert ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. # nsCertType = server # For an object signing certificate this would be used. # nsCertType = objsign # For normal client use this is typical # nsCertType = client, email # and for everything including object signing: # nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectAltName=email:move # Copy subject details # issuerAltName=issuer:copy #nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName # This is required for TSA certificates. # extendedKeyUsage = critical,timeStamping [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer # This is what PKIX recommends but some broken software chokes on critical # extensions. #basicConstraints = critical,CA:true # So we do this instead. basicConstraints = CA:true # Key usage: this is typical for a CA certificate. However since it will # prevent it being used as an test self-signed certificate it is best # left out by default. # keyUsage = cRLSign, keyCertSign # Some might want this also # nsCertType = sslCA, emailCA # Include email address in subject alt name: another PKIX recommendation # subjectAltName=email:copy # Copy issuer details # issuerAltName=issuer:copy # DER hex encoding of an extension: beware experts only! # obj=DER:02:03 # Where 'obj' is a standard or added object # You can even override a supported extension: # basicConstraints= critical, DER:30:03:01:01:FF [ crl_ext ] # CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. # issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always [ proxy_cert_ext ] # These extensions should be added when creating a proxy certificate # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. # nsCertType = server # For an object signing certificate this would be used. # nsCertType = objsign # For normal client use this is typical # nsCertType = client, email # and for everything including object signing: # nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectAltName=email:move # Copy subject details # issuerAltName=issuer:copy #nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName # This really needs to be in place for it to be a proxy certificate. proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo #################################################################### [ tsa ] default_tsa = tsa_config1 # the default TSA section [ tsa_config1 ] # These are used by the TSA reply generation only. dir = ./demoCA # TSA root directory serial = $dir/tsaserial # The current serial number (mandatory) crypto_device = builtin # OpenSSL engine to use for signing signer_cert = $dir/tsacert.pem # The TSA signing certificate # (optional) certs = $dir/cacert.pem # Certificate chain to include in reply # (optional) signer_key = $dir/private/tsakey.pem # The TSA private key (optional) default_policy = tsa_policy1 # Policy if request did not specify it # (optional) other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional) digests = sha1, sha256, sha384, sha512 # Acceptable message digests (mandatory) accuracy = secs:1, millisecs:500, microsecs:100 # (optional) clock_precision_digits = 0 # number of digits after dot. (optional) ordering = yes # Is ordering defined for timestamps? # (optional, default: no) tsa_name = yes # Must the TSA name be included in the reply? # (optional, default: no) ess_cert_id_chain = no # Must the ESS cert id chain be included? # (optional, default: no)
Schlüssel für das Serverzertifikat erzeugen
Nachdem wir nun unsere eigene CA erstellt haben, machen wir uns daran, endlich für unseren Server ein Zertifikat herausgeben. Hierzu erzeugen wir als erstes einen 4096 Bit langen RSA Schlüssel, den wir mit AES 256 verschlüsselt auf der Platte abgelegt lassen. Da OpenSSL keine leere Passphrase zulässt braucht die Passphrase diesmal nicht sonderlich geheim sein, da wir diese im Anschluss ohnehin sofort wieder entfernen werden.
Die Eingaben sind in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl genrsa -out serverkey.pem -aes256 4096
Generating RSA private key, 4096 bit long modulus .......................................................................................................................................................................................................................++ ........................................................................................................................................................................................++ e is 65537 (0x10001) Enter pass phrase for serverkey.pem: 12qwasyx Verifying - Enter pass phrase for serverkey.pem: 12qwasyx
Wie schon erwähnt, entfernen wir die Passphrase nun wieder, in dem wir bei der Frage Enter pass phrase: einfach die Taste [ENTER] drücken.
# openssl rsa -in serverkey.pem -out serverkey_2.pem
Enter pass phrase: writing RSA key
Wie schon zuvor schützen wir auch hier den Serverschlüssel über die Dateirechte, nachdem wir diesen umbenannt haben.
# mv serverkey_2.pem serverkey.pem -f
# chmod 400 serverkey.pem
Certificate Signing Request erzeugen
Im folgenden Schritt zu unserem eigenen Zertifikat erzeugen wir einen CSR10), den wir dann in einem weiteren Schritt von unserer eigenen CA signieren lassen werden, oder bei der ausgewählten kommerziellen CA einkippen.
Wichtig: Bei unserem Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name unseres Postfix-Servers eingetragen werden, unter dem der Mailserver angesprochen wird!
Auch hier sind die Eingaben in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl req -new -key serverkey.pem -out csr.pem -nodes
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:DE State or Province Name (full name) []Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:Postoffice Common Name (eg, your name or your server's hostname) []:mx01.nausch.org Email Address []:postmaster@nausch.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Wollen oder müssen wir ein kommerzielles Zertifikat, also von einer in den Browsern und mailclients von Haus aus installierten CAs, nutzen, so lassen wir den CSR der CA zukommen.
# cat csr.pem
-----BEGIN CERTIFICATE REQUEST----- MIIC4TCCAckCAQAwgZsxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRMwEQYDVQQLDApQ b3N0b2ZmaWNlMRgwFgYDVQQDDA9teDAxLm5hdXNjaC5vcmcxJDAiBgkqhkiG9w0B CQEWFXBvc3RtYXN0ZXJAbmF1c2NoLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANGHFR6fvj33ISUmvZw4g92Di78T3euAXDcOF+VpXnivwbegDVT5 utTtc2mdFUD5AeTVpdOdE7AZfjqaXFpwo5A8TRT11cxEWtZ+cJw4KBSqSNi9B2K/ ApQ4mp8l95/Rm6fgLstpt8/8ZvlOQVQLv4erePOhmeJ+V5G4r7YxldfTn8T5PmMq tWxqd+HZs3pYqDPC+Y9q6ul6UDV/lyKJpZy5e1NzweuyHKSjfQh7IjEAnYlqPfMc oSO5Mw2f9+ww44U7QsbZPrxZz2AVFrR2zUtcVu7A7GLWL90tFYMWEZm2mWkc4GVg GTCcRrCmwdL6dBURzZ3sIUIFavYwJJAtBC8CAwEAAaAAMA0GCSqGSIb3DQEBCwUA A4IBAQCY7ZrJ6i/T/iK3bMVNoe8q9ZaoXGcKa33tZnae1WMfoS2NBWZJHI6/i4m4 xc2iMdoH8rElmc1cC7nk6vV61mF3Fxx20+ItXVdciSGPGqOlh+kiKbGbjtJCC+r+ 0Xa1HvRnoHGHPA3ZOCBvxutNS4JC6OmaSLOkGMU1p5aSryyrpPEWg921Qt47YaEz cirOHxaeH5aQ/RSugeGuRmAeo0KUPIM8//eL80Xmd4Wxjan58dkuat7FEdp6MIFE J//aMh6n6scA+UgfzY9c4Ep6Mq4GP6ID7DWZC7AT6LldXMS+FvCH1GQBPGImM14B 01quu+iQHkbA00jyDB0SL4tIlQSD -----END CERTIFICATE REQUEST-----
Bei Interesse können wir uns unseren CSR auch ansehen, dazu benutzen wir folgenden Befehl:
# openssl req -noout -text -in csr.pem
Certificate Request: Data: Version: 0 (0x0) Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Postoffice, CN=mx01.nausch.org/emailAddress=postmaster@nausch.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d1:87:15:1e:9f:be:3d:f7:21:25:26:bd:9c:38: 83:dd:83:8b:bf:13:dd:eb:80:5c:37:0e:17:e5:69: 5e:78:af:c1:b7:a0:0d:54:f9:ba:d4:ed:73:69:9d: 15:40:f9:01:e4:d5:a5:d3:9d:13:b0:19:7e:3a:9a: 5c:5a:70:a3:90:3c:4d:14:f5:d5:cc:44:5a:d6:7e: 70:9c:38:28:14:aa:48:d8:bd:07:62:bf:02:94:38: 9a:9f:25:f7:9f:d1:9b:a7:e0:2e:cb:69:b7:cf:fc: 66:f9:4e:41:54:0b:bf:87:ab:78:f3:a1:99:e2:7e: 57:91:b8:af:b6:31:95:d7:d3:9f:c4:f9:3e:63:2a: b5:6c:6a:77:e1:d9:b3:7a:58:a8:33:c2:f9:8f:6a: ea:e9:7a:50:35:7f:97:22:89:a5:9c:b9:7b:53:73: c1:eb:b2:1c:a4:a3:7d:08:7b:22:31:00:9d:89:6a: 3d:f3:1c:a1:23:b9:33:0d:9f:f7:ec:30:e3:85:3b: 42:c6:d9:3e:bc:59:cf:60:15:16:b4:76:cd:4b:5c: 56:ee:c0:ec:62:d6:2f:dd:2d:15:83:16:11:99:b6: 99:69:1c:e0:65:60:19:30:9c:46:b0:a6:c1:d2:fa: 74:15:11:cd:9d:ec:21:42:05:6a:f6:30:24:90:2d: 04:2f Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption 98:ed:9a:c9:ea:2f:d3:fe:22:b7:6c:c5:4d:a1:ef:2a:f5:96: a8:5c:67:0a:6b:7d:ed:66:76:9e:d5:63:1f:a1:2d:8d:05:66: 49:1c:8e:bf:8b:89:b8:c5:cd:a2:31:da:07:f2:b1:25:99:cd: 5c:0b:b9:e4:ea:f5:7a:d6:61:77:17:1c:76:d3:e2:2d:5d:57: 5c:89:21:8f:1a:a3:a5:87:e9:22:29:b1:9b:8e:d2:42:0b:ea: fe:d1:76:b5:1e:f4:67:a0:71:87:3c:0d:d9:38:20:6f:c6:eb: 4d:4b:82:42:e8:e9:9a:48:b3:a4:18:c5:35:a7:96:92:af:2c: ab:a4:f1:16:83:dd:b5:42:de:3b:61:a1:33:72:2a:ce:1f:16: 9e:1f:96:90:fd:14:ae:81:e1:ae:46:60:1e:a3:42:94:3c:83: 3c:ff:f7:8b:f3:45:e6:77:85:b1:8d:a9:f9:f1:d9:2e:6a:de: c5:11:da:7a:30:81:44:27:ff:da:32:1e:a7:ea:c7:00:f9:48: 1f:cd:8f:5c:e0:4a:7a:32:ae:06:3f:a2:03:ec:35:99:0b:b0: 13:e8:b9:5d:5c:c4:be:16:f0:87:d4:64:01:3c:62:26:33:5e: 01:d3:5a:ae:bb:e8:90:1e:46:c0:d3:48:f2:0c:1d:12:2f:8b: 48:95:04:83
Diesen CSR kippen wir nun entweder bei der hauseigenen CA ein oder entsprechend bei einer kommerziellen CA.
eigene CA: CSR beabeiten - Zertifikat erstellen
Kommen wir zum krönenden Abschluss - wir signieren nun das Server-Zertifikat durch unsere CA, oder anders ausgedrückt, wir erstellen das benötigte X.509-Serverzertifikat.
Wie schon bereits bei den anderen Konfigurationsbeispielen, sind auch hier die Eingaben in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl ca -in csr.pem -notext -out servercert.pem
Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase for /etc/pki/CA/private/cakey.pem: des-woas-blos-I-und-sundst-koana Check that the request matches the signature Signature ok Certificate Details: Serial Number: 0 (0x0) Validity Not Before: Oct 19 13:23:33 2014 GMT Not After : Jul 22 13:23:33 2016 GMT Subject: countryName = DE stateOrProvinceName = Bayern organizationName = nausch.org organizationalUnitName = Postoffice commonName = mx01.nausch.org emailAddress = postmaster@nausch.org X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 43:98:32:9B:BA:65:AD:14:08:67:FB:B0:B1:BD:BD:57:A8:B4:3D:C9 X509v3 Authority Key Identifier: keyid:19:F5:FD:B1:D1:98:4B:E3:E8:26:CD:55:CB:14:08:19:67:9E:78:16 Certificate is to be certified until Oct 19 13:23:33 2016 GMT (730 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
Speicherort
Bei der Installation von Postfix wurden noch keine speziellen Ordner im Verzeichnis /etc/pki angelegt. Dies holen wir nun kurz nach.
# mkdir -p /etc/pki/postfix/certs /etc/pki/postfix/private
/etc/pki/postfix/ ├── certs └── private
Anschließend legen wir dort die drei benötigten Dateien ab:
Die Dateinamen passen wir natürlich den lokalen Gegebenheiten nach an!
- unseren Serverzertifikat : servercert.pem
# mv /etc/pki/CA/servercert.pem /etc/pki/postfix/certs/servercert.pem
- unseren Serverschlüssel : serverkey.pem
# mv /etc/pki/CA/serverkey.pem /etc/pki/postfix/private/serverkey.pem
- das CA-Zertifikat : cacert.pem
# cp /etc/pki/CA/cacert.pem /etc/pki/postfix/certs/
- und schützen diese Dateien mit den Dateirechten 400:
# chmod 400 /etc/pki/postfix/private/*.pem # chmod 400 /etc/pki/postfix/certs/*.pem
CA Trust
Zertifizierungspfad beim SSL Zertificate (trusted chain)
Bei der asymmetrischen Verschlüsselung, wie sie bei SSL/TLS gesicherter Kommunikation zum Einsatz kommt, benötigt der sendende Kommunikationspartner den öffentlichen Schlüssel (public key) des Empfängers. Bei dieser Kommunikation ist es äußerst wichtig, dass die Echtheit des Schlüssels gewährleistet, sprich auch überprüft werden kann. Diese Überprüfung erfolgt mit digitalen Zertifikaten, die die Echtheit eines öffentlichen Schlüssels sowie den Geltungsbereich und die Anwendungsbereich für das Zertifikat bestätigen.
Bei einer reinen 1:1 Kommunikation können sich beide Kommunikationspartner, oder der Client mit dem Server dieses Vertrauen selbst gegenseitig aussprechen. In den allermeisten Fällen wird es aber bei der verschlüsselten und vertraulichen Kommunikation um eine 1:n Kommunikation handeln; d.h. ein Server wird mit unter sehr vielen Clients Daten austauschen. Eine gegenseitige Vertrauensbildung ist hier in den allermeisten Fällen nicht realistisch und praktikabel durchführbar.
Für die Überprüfung der Echtheit der zur Verschlüsselung verwendeten X.509-Zertifikates wird wiederum ein digitales Zertifikat einer CA11) oder kurz Zertifizierungsstelle verwendet. Diese CA bestätigt somit die Echtheit des Zertifikates. Eine Zertifikat (Root Zertifikat) einer CA selbst kann wiederum durch eine weitere CA beglaubigt worden sein. Somit ergibt sich eine Kette von Zertifikaten, bei der jedes Zertifikat mit dem Zertifikat der übergeordneten Stelle authentifiziert werden kann. Diese Vertrauenskette wird auch Zertifizierungspfad oder trusted chain bezeichnet.
Die nachfolgende Graphik zeigt den Zertifizierungspfad eines Zertifikats mit dem CN12) dokuwiki.nausch.org.
Der Publickey in dem Zertifikat dokuwiki.nausch.org wurde mit dem Zertifikat CAcert Class 3 Root unterschrieben. Der Publickey dieses Root-Zertifikates CAcert Class 3 Root wurde wiederum mit dem Root-Zertifikat CA Cert Signing Authority unterschrieben.
Damit ein Client die Vertrauenskette (trusted chain) überprüfen kann, muss der Server diese beim TLS-Verbindungshandshake mit ausliefern! Normaler Weise wird die ausstellende CA von sich aus immer die benötigten Zwischen- und Root-Zertifikate der (Sub)CAs zur Verfügung stellen. Nutzt man einen sehr preisgünstigen Anbieter von Zertifikaten kann, die Suche nach den richtigen und passenden Zertifikaten zuweilen doch recht aufwändig werden.
Wir werden nun darauf eingehen, wie wir die trusted chain ermitteln, die Zertifikate besorgen und überprüfen können.
Im folgenden Beispiel orientieren wir uns am vorliegendem Zertifikat des Mailservers mx1.nausch.org. Das Zertifikat haben wir von der CA unseres Vertrauens erhalten.
- Als erstes ermitteln wir, wer genau unser Zertifikat unterschrieben hat.
# openssl x509 -subject -issuer -noout -in mx1.nausch.org.servercert.pem
subject= /serialNumber=3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP/OU=GT49447951/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.nausch.org issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Der CN bei der Zeile issuer beschreibt nun das Zertifikat, mit dem unser Serverzertifikat unterschrieben wurde.
- Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat RapidSSL_CA.pem auf unseren Rechner.
- Auch bei diesem Root-Zertifikat RapidSSL_CA.pem ermitteln wir nun den issuer.
# openssl x509 -subject -issuer -noout -in RapidSSL_CA.pem
subject= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Das Root Zertifikat der RapidSSL CA wurde also mit dem Root-Zertifikat der GeoTrust Global CA signiert.
- Wir benötigen also ein weiteres Root-Zertifikat. Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat GeoTrust_Global_CA.pem auf unseren Rechner.
- Nun können wir ermitteln, wer dieses Zertifikat unterschrieben hat.
# openssl x509 -subject -issuer -noout -in GeoTrust_Global_CA.pem
subject= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Das Root Zertifikat der GeoTrust Global CA wurde also mit dem Root-Zertifikat der Equifax Secure Certificate Authority unterschrieben.
- Wir werden uns also auch dieses Root-Zertifikat besorgen müssen. Erneiut gehen wir auf die Suche nach dem Root-Zertifikat und laden uns das betreffende Zertifikat Equifax_Secure_Certificate_Authority.pem auf unseren Rechner.
- Auch hier überprüfen wir nun, wer dieses Zertifikat nun unterschrieben hat.
# openssl x509 -subject -issuer -noout -in Equifax_Secure_Certificate_Authority.pem
subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Hier sehen wir nun, dass das subject und der issuer identisch sind, das Zertifikat wurde also selbst signiert (self signed certificate). Wir haben hier also das Wurzelzertifikat unserer Zertifizierungskette.
Somit ergibt sich für unser Zertifikat folgende komplette Zertifizierungskette.
── (1) Equifax Secure Certificate Authority │ └── (2) GeoTrust Global CA │ └── (3) RapidSSL CA │ └── (4) mx1.nausch.org.servercert.pem
Aus Interoperabilitätsgründen sollte vom Server immer die komplette Zertifikatskette zur Verfügung gestellt werden!
- Wir erstellen uns nun eine Datei in der die Root-Zertifikaten vom Serverzertifikat beginnend zum ersten Rootzertifikat beinhaltet, also in unserem Beispiel in der Reihenfolge (3) → (2) → (1).
# cat RapidSSL_CA.pem GeoTrust_Global_CA.pem Equifax_Secure_Certificate_Authority.pem > rapid_geotrust_equifax_bundle.pem
- Zum Schluss überprüfen wir noch ob nun alle benötigten Zertifikate in der richtigen Reihenfolge vorliegen.
# openssl verify -verbose -purpose sslserver -CAfile rapid_geotrust_equifax_bundle.pem mx1.nausch.org.servercert.pem
mx01.nausch.org.servercert.pem: OK
Wir haben also bei diesem Konfigurationsbeispiel nun neben unserem Zertifikat mx1.nausch.org.servercert.pem die zugehörige Zertifikatskette rapid_geotrust_equifax_bundle.pem vorliegen!
Postfix konfigurieren
Die Konfiguration der TLS-Optionen erfolgt in der Hauptkonfigurationsdatei /etc/postfix/main.cf unseres Postfix Mailservers.
Zertifikate und Key(s)
Postfix kennt grundsätzlich zwei verschiedene Transportrichtungen bei der Verarbeitung von eMails:
- ankommend: Für den Empfang der eMails ist unser SMTP-Daemon zuständig.
- abgehend: Der Versand bzw. Weiterleitung erfolgt durch den SMTP-Client.
In aller Regel werden wir unseren SMTP-Daemon mit einem Zertifikat für die TLS-Transportverschlüsselung ausstatten. Aber auch der SMTP-Client kann mit Zertifikat und zugehörigen Schlüssel ausgestattet werden, wenn z.B. der empfangene SMTP-Server unseres Kommunikationspartners an Hand unseres Clientzertifikats überprüfen will/muss ob es sich um einen legitimen Sender handelt.
SMTP-Daemon (Empfang von eMails)
Zunächst definieren wir unseren SMTP-Daemon, also die Empfangsrichtung von unserem Mailserver aus gesehen. Für die (asynchrone] Verschlüsselung benötigen wir drei Dinge:
- privaten Schlüssel/Serverkey, den wir auf unserem Server erstellt haben.
- Zertifikat, welches die CA13) an Hand unseres CSR14) erstellt und mit dem Root- bzw. intermediate Zertifikat signiert hat.
- CA-Zertifikate: Das Root- und alle Zwischenzertifikate der CA, von der wir unser Serverzertifikat erhalten haben.
Diese drei Teilen weisen wir nun den zugehörigen Postfixparametern smtpd_tls_key_file, smtpd_tls_cert_file und smtpd_tls_CAfile zu:
- privaten Schlüssel/Serverkey:
Unseren privaten Schlüssel/Serverkey haben wir in der Datei mx01.nausch.org.serverkey_151015.pem im Verzeichnis /etc/pki/postfix/private/ abgelegt.
# vim /etc/pki/postfix/private/mx01.nausch.org.serverkey_151015.pem
-----BEGIN RSA PRIVATE KEY----- MIIJKQIBAAKCAgEA148Cwr3Z9vK9I2uc1iYZK9hbcRoqR/9/6fNRXHAJRYB14OGv q9tpf43ypjKpZBCL+OE3SCrG3W6/paGQBcNeR2lIqhbD1sPvjv09fTmSiY3qf1v8 FhRUpLk1eXjAShxGpyH6Xrb9xK7tishirSHuCIhXhtjSzNZQeMg+8yfbrQpzRK/z vxonHNX1EWC0DS54+5UUT6Eb6Q8kK545+8/Xu5V4INsl+PO3SHnWGdoFGrG7sfbV gfIhFwnfsyh+9trp5WTeVFu40mzs7WZRHATbrwFZqJ4F/UKpvIuDHsAdZQpvZy8U H74Mm4xyU8IkU8R1lh1TVGyeUarMRef9xuCjxioqwbw6kHcjfkmY4OI+XlAO7BIJ EVe2RVocvjqIAeQpFr3pOXCg390/dtWTcdKYq9JUBJLVsvI+iZ1btHH2Do3lsI1O oBmpvc7tswRVp501ZCPgOv5dkFbPyM+brUF3QZHv6mHAgleTQnUaTRGfBfcEzki/ TCtZlf66IBEFI7o4I3weD+u+DRfVy5S2mAXwCqL9QTyqf/sasNGlshlDvhrdp/zH r3m1EID4UpusuSdZ2oqFWztU+ZnKQDRhqjNH1YhEZJu66og4X3hzjL2y8OkCAwEA AQKCAgEAoKt/IkrCeXhLFGi02UZCgtTcq7wWAd5mqKntXhpAPubWdk2iMLh6W9qi +PoybwaC8WaI4GKEMh0wk1ehk5swPhqPaJ3vWM1r7O17Jbfh0zSIsBPxjkuYIjRa xhiC/Av9WP/95bPE0O4ouTtoj3MlBdNrDySyypT3LbyCpaFRIWh/fnjAuHBk+vb1 7dncciELZK5F4W1CT+UXN9fO/T+KHiAKJX/d+EJSbwTLLxDpg9yDOJJx+2Jx/uNX rKFI835NPTDMl+H9XMUlb8GbdJ9iLPbnOI5AioSWe9YciN5h6ZjKz4atdBNXKMX6 UJ8Bq9xWdN6vfW90npwEKZuXH2xblYHTip+BQD2yDDtGLRFPv70/pWUkoP6mlkcw D0ycFMD10sYo2tg69QHCwzdzgj6l/UUovu8N1QFgcwhykAEL/oCinDpQup8fuE3G vjMSmpcoCinDpQKGGUwpc65C5hWj7H3WO13fZGzIl33BBK9B0DG1GdJSAIlTh9hy cu0llaQ0bVWniXj42QeojGbUmAbB67rzgpN+rAfJilWNuNx0sEyyvDcjI04dJ9pN zWDpQKGGUwpc65C5hW91z2F1ckD1cHd0Ch53l6571n5Kn13UJ0oUCggEBAP/Q4Yo BiUpOphahwy7fz5mFWGCnpz5fmUpfNjzJlI+ibqggT7geRbiR8iZUp4+AW+W8u8L YnpWDErK8cQ+U08mLb3NBTHZETvwsmiAYdHoL/8PvgONmNtUzqD8aInbiQ7nPg95 uQZoYiFSbqfkj+Jcvu9ljrJTkpIoVsLp68040hdF9EbAIEMrPY8o9Dz6/DQpoq2p dzNHGyFBx62xyaDTMk20fLrPMqF/DxQOoWPSvmMWJs3fXs/33yU4zatnEMx3lDp8 9FlcVMhNEHSizmEvhAnK7vdHPFcvkfQVbK3f8ZCy7B76OmY6lPtkb3MJRGyVuP2B ljb+IGsa3/H3l0MCggEBANe2tvj7fV1vr3/yOslvnLSxTLR4iDPdUwdF3ujsPthI sJSB7KswFImUqNHSZ4NoDG+KtE+lYHAkMQMOhG9/U5389Ka/HRgC4wQwPX0jYhrZ e83S0uVn/aQPgDFhKxfQXqISJguRcraqNGsZAjCZImA1b+hIDNrTsnA/uP6wBATs mxh5REItS1amoBRdt2fjzJIhRbIdlRBjYPJQl6BWk07AIt4D52XphpuLrmCMUbSY oTvS/W6VoanymlK8arXLu9+STZDibGEk/H/IzMXJ3fp9tPasxFwrgN8PSaYZ9C3U 0LQXUYKXBfw6cKh98wUV5Yoo/5bhVjqp4oq0ymzKpmMCggEAbRN7l50jOaUivuOa wesQjmKoqzMuvnADXM8b1MWYiWjxAQp/EXhVKVTClt4JRD/cDOCoJRUNoGwgQaPX An4wt4bn6g4JMQAFQTGYYMac7wu5q1/i/VDa5Gp80FfPmzhocFpZM/AK3JiVfu/P Dvd+Al7Zauo6tf68eGWK2QE08gRQUGwbhC9XkkxVqz0jJv09nGBEZRflI5AmGUAb DAzKlDB5OnjC1kSSqhmrLDowxoeNdmJzmUStALAIDa7ywyrnFsfGBEpTRecAn4d8 hL8GkJnaCvLkgbt2FxbJfPHFrT3XmoMv+uVnET/ZVne0rbA95K7SegVPL5Ob7w8+ fcW8UQKCAQEAtZCLLcKwYIbzFyRRqt8Q7V4WjAivy8fMbOC4oSDIPM/iIP3CsMxF XRANkJ4ilo5reS8sWaV/KKStxD7h5d8sCFyzp+5QlLdJUWsxNjUkDClmdXWwIXuI GCEb63Q4C1FNdekEsNP51BorCMIB/9nE/2m7Ca4rc7ygAq8ADQ8mMubcHJtlgrYR JZwWPU4sY3tv4seynBseLq8XGJ4RIdn9H1nFf02V5UfMDvxhB87TrsiRXYNX4U58 xkj28BC7WM1lEudX9k0+n/27serXwNsKxh4sxTviAxpy3E1H1lEeH71y9UJzTxHC 7exaiteIR42IqOOdTefY5oO7tLg7cZqYtQKCAQA4Fpbl/101OWzNLqgeS0csmRwh o5xBcruthSFRVT+gbtB3HSa0ImW69YofutC1FNdekEsNP51BorCMIBtcXaGFHXx3 1aTxVTN1bWtcqzeV9zLvxQ39FWRZczKQzf2eSEQcO3MQJu3X+F1dbcpuWKHOg6S9 QKgUAh7HeTb9A+/WTzuHVUllNvRJtgk6lSDEBMHHrisLBav5AguBSl+Rbva0wvI7 wm+bdTNKhHvZ7tepw8wwD321Iv82me7afNMjlV2OLy0OZ5jjXLJIXcV1QTIikIUm MeXU1e4o7RXZ6IjxvjPObtcEJYy0etm3AkKo+Ql/PTn4QG+p7D3gWVKRbMXn -----END RSA PRIVATE KEY-----
- Zertifikat:
Das Serverzertifikat, welches wir von der ausstellenden CA erhalten haben, legen wir im Verzeichnis /etc/pki/postfix/certs/ ab. In unserem Konfigurationsbeispiel wäre das die Datei rapidssl_2015-10-15_mx01.nausch.org.certificate.pem.
# vim /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.certificate.pem
-----BEGIN CERTIFICATE----- MIIFoDCCBIigAwIBAgICKRAwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCVVMx FjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlkU1NMIFNIQTI1 NiBDQSAtIEc0MB4XDTE1MTAxNDIyMjA1M1oXDTE3MTAxNTE2MDkxMVowgZMxEzAR BgNVBAsTCkdUMjI2Njc5NDExMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29t L3Jlc291cmNlcy9jcHMgKGMpMTUxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZh bGlkYXRlZCAtIFJhcGlkU1NMKFIpMRgwFgYDVQQDEw9teDAxLm5hdXNjaC5vcmcw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXjwLCvdn28r0ja5zWJhkr 2FtxGipH/3/p81FccAlFgHXg4a98E11VEOfH7mjJqi3a6hx+MQDGD78aSxpqAE2c M5No3fONVr3cFoj/IVVUG+EwMOSr22l/jfKmMqlkEIv44TdIKsbdbr+loZAFw15H aUiqFsPWw++O/T19OZKJjep/W/wWFFSkuTV5eMBKHEanIfpetv3Eru2KyGKtIe4I iFeG2NLM1lB4yD7zJ9utCnNEr/O/Gicc1fURYLQNLnj7lRRPoRvpDyQrnjn7z9e7 lXgg2yX487dIedYZ2gUasbux9tWB8iEXCd+zKH722unlZN5UW7jSbOztZlEcBNuv AVmongX9Qqm8i4MewB1lCm9nLxQfvgybjHJTwiRTxHWWHVNUbJ5RqsxF5/3G4KPG KirBvDqQdyN+SZjg4j5eUA7sEgkRV7ZFWhy+OogB5CkWvek5cKDf3T921ZNx0pir 0lQEktWy8j6JnVu0cfYOjeWwjU6gGam9zu2zBFWnnTVkI+A6/l2QVs/Iz5utQXdB ke/qYcCCV5NCdRpNEZ8F9wTOSL9MK1mV/rogEQUjujgjfB4P674NF9XLlLaYBfAK ov1BPKp/+xqw0aWyGUO+Gt2n/MevebUQgPhSm6y5J1naioVbO1T5mcpANGGqM0fV iERkm7rqiDhfeHOMvbLw6QIDAQABo4IBRzCCAUMwHwYDVR0jBBgwFoAU87VWDMQJ sLTPH6r53SNW8HfoofkwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUFBzABhhNodHRw Oi8vZ3ouc3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vZ3ouc3ltY2IuY29t L2d6LmNydDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG AQUFBwMCMBoGA1UdEQQTMBGCD214MDEubmF1c2NoLm9yZzArBgNVHR8EJDAiMCCg HqAchhpodHRwOi8vZ3ouc3ltY2IuY29tL2d6LmNybDAMBgNVHRMBAf8EAjAAMEEG A1UdIAQ6MDgwNgYGZ4EMAQIBMCwwKgYIKwYBBQUHAgEWHmh0dHBzOi8vd3d3LnJh cGlkc3NsLmNvbS9sZWdhbDANBgkqhkiG9w0BAQsFAAOCAQEAI741GwJW1MPFpzn6 k0KavUzJp9uybjbRGrH1p1HbKX7nMj93qO7BcN6x3aXVxAe5bDPhK7flmlAwIAyn X+EVjC0uV10zY75uY8jfyQ2j7qi2FMMWsa98kWMPzxkU9k7DXDSNIXvhoPhfT9ep A0pY4peiKrrCDGvW6/G2Bx8KXpOjUlNC7GGZxK9ZOVvCe8l5fZFT/II4dEYiU/bJ Md2v5ayCTGAt8S5ITz/6o0MALtIB9M0/AyqqxFKLinIqOAoKxWE+4fO6J3t+YOGp eVH+n//PADBewKZZF43KSROsqM6fE4DeRdUk77Tp9LyCoKdPFHo04XHmE0iyBT6h x5L03w== -----END CERTIFICATE-----
- CA-Zertifikate:
Da wir nicht sicher sein können, dass der einliefernde SMTP-Client alle notwendigen Zwischenzertifikate in seinem trusted Root CA Store vorhält, müssen wir diese dem Postfix-SMTP-Daemon bekannt geben, damit der Daemon diese beim Aushandeln der TLS-Verschlüsselung auch diese Zertifikate dem SMTP-Client bekannt geben kann.
Alle nötigen CA-Zertifikate legen wir nun nacheinander in einer Datei ab und zwar in der Reihenfolge vom Serverzertifikat in Richtung des obersten Root-Zertifikates der CA ab. Wenn wir nicht sicher sind welche Zwischenzertifikate genau benötigt werden, ermitteln wir diese wie folgt. Als erstes ermitteln wir, mit welchem Zertifikat unser Serverzertifikat signiert wurde.
# openssl x509 -subject -issuer -dates -noout -in /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.certificate.pem
subject= /OU=GT22667941/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=mx01.nausch.org issuer= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 notBefore=Oct 14 22:20:53 2015 GMT notAfter=Oct 15 16:09:11 2017 GMT
Wir benötigen also das Zertifikat des CN=RapidSSL SHA256 CA - G4. Wir besorgen uns nun dieses Root-Zertifikat von der CA=GeoTrust Inc.. Auch bei diesem Zertifikat überprüfen wir nun, ob es sich um das selbstsignierte Root-Zertifikat der CA handelt, oder ob dieses Zertifikat von einem anderen Root-Zertifikat signiert wurde.
# openssl x509 -subject -issuer -dates -noout -in /etc/pki/postfix/certs/RapidSSL_SHA256_CA_-_G4.pem
subject= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 notBefore=Jun 30 00:00:00 2015 GMT notAfter=Jun 29 23:59:59 2025 GMT
Da sich subject und issuer unterscheiden, wissen wir nun, dass es sich bei dem Zertifikate RapidSSL_SHA256_CA_-_G4.pem um ein Intermediate-Zertifikat handelt und wir uns das Zertifikat GeoTrust_Primary_Certification_Authority_-_G3.pem besorgen müssen. Wir besorgen uns nun auch noch dieses Root-Zertifikat von der CA=GeoTrust Primary Certification Authority - G3. Haben wir dieses Zertifikat gefunden, ermitteln wir auch hier, ob es sich um das selbstsignierte Root-Zertifikat der CA handelt, oder ob dieses Zertifikat von einem anderen Root-Zertifikat signiert wurde.
# openssl x509 -subject -issuer -dates -noout -in /etc/pki/postfix/certs/GeoTrust_Primary_Certification_Authority_-_G3.pem
subject= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 notBefore=Apr 2 00:00:00 2008 GMT notAfter=Dec 1 23:59:59 2037 GMT
Da sich hier nun subject und issuer nicht unterscheiden, wissen wir, es handelt sich hier um das selbstsignierte Root-Zertifikat der CA!
Damit wir später leichter die Zertifikate zuordnen können, kopieren wir die Ausgaben der obigen openssl-Aufrufe in die jeweiligen Zertifikatsdateien und stellen den vier Zeilen jeweils eine Raute # voran!
Wir haben also nun drei Zertifikatsdateien mit folgendem Inhalt:
# vim /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.certificate.pem
- /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.certificate.pem
# subject= /OU=GT22667941/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=mx01.nausch.org # issuer= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 # notBefore=Oct 14 22:20:53 2015 GMT # notAfter=Oct 15 16:09:11 2017 GMT -----BEGIN CERTIFICATE----- MIIFoDCCBIigAwIBAgICKRAwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCVVMx FjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlkU1NMIFNIQTI1 NiBDQSAtIEc0MB4XDTE1MTAxNDIyMjA1M1oXDTE3MTAxNTE2MDkxMVowgZMxEzAR BgNVBAsTCkdUMjI2Njc5NDExMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29t L3Jlc291cmNlcy9jcHMgKGMpMTUxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZh bGlkYXRlZCAtIFJhcGlkU1NMKFIpMRgwFgYDVQQDEw9teDAxLm5hdXNjaC5vcmcw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXjwLCvdn28r0ja5zWJhkr 2FtxGipH/3/p81FccAlFgHXg4a98E11VEOfH7mjJqi3a6hx+MQDGD78aSxpqAE2c M5No3fONVr3cFoj/IVVUG+EwMOSr22l/jfKmMqlkEIv44TdIKsbdbr+loZAFw15H aUiqFsPWw++O/T19OZKJjep/W/wWFFSkuTV5eMBKHEanIfpetv3Eru2KyGKtIe4I iFeG2NLM1lB4yD7zJ9utCnNEr/O/Gicc1fURYLQNLnj7lRRPoRvpDyQrnjn7z9e7 lXgg2yX487dIedYZ2gUasbux9tWB8iEXCd+zKH722unlZN5UW7jSbOztZlEcBNuv AVmongX9Qqm8i4MewB1lCm9nLxQfvgybjHJTwiRTxHWWHVNUbJ5RqsxF5/3G4KPG KirBvDqQdyN+SZjg4j5eUA7sEgkRV7ZFWhy+OogB5CkWvek5cKDf3T921ZNx0pir 0lQEktWy8j6JnVu0cfYOjeWwjU6gGam9zu2zBFWnnTVkI+A6/l2QVs/Iz5utQXdB ke/qYcCCV5NCdRpNEZ8F9wTOSL9MK1mV/rogEQUjujgjfB4P674NF9XLlLaYBfAK ov1BPKp/+xqw0aWyGUO+Gt2n/MevebUQgPhSm6y5J1naioVbO1T5mcpANGGqM0fV iERkm7rqiDhfeHOMvbLw6QIDAQABo4IBRzCCAUMwHwYDVR0jBBgwFoAU87VWDMQJ sLTPH6r53SNW8HfoofkwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUFBzABhhNodHRw Oi8vZ3ouc3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vZ3ouc3ltY2IuY29t L2d6LmNydDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG AQUFBwMCMBoGA1UdEQQTMBGCD214MDEubmF1c2NoLm9yZzArBgNVHR8EJDAiMCCg HqAchhpodHRwOi8vZ3ouc3ltY2IuY29tL2d6LmNybDAMBgNVHRMBAf8EAjAAMEEG A1UdIAQ6MDgwNgYGZ4EMAQIBMCwwKgYIKwYBBQUHAgEWHmh0dHBzOi8vd3d3LnJh cGlkc3NsLmNvbS9sZWdhbDANBgkqhkiG9w0BAQsFAAOCAQEAI741GwJW1MPFpzn6 k0KavUzJp9uybjbRGrH1p1HbKX7nMj93qO7BcN6x3aXVxAe5bDPhK7flmlAwIAyn X+EVjC0uV10zY75uY8jfyQ2j7qi2FMMWsa98kWMPzxkU9k7DXDSNIXvhoPhfT9ep A0pY4peiKrrCDGvW6/G2Bx8KXpOjUlNC7GGZxK9ZOVvCe8l5fZFT/II4dEYiU/bJ Md2v5ayCTGAt8S5ITz/6o0MALtIB9M0/AyqqxFKLinIqOAoKxWE+4fO6J3t+YOGp eVH+n//PADBewKZZF43KSROsqM6fE4DeRdUk77Tp9LyCoKdPFHo04XHmE0iyBT6h x5L03w== -----END CERTIFICATE-----
# vim vim /etc/pki/postfix/certs/RapidSSL_SHA256_CA_-_G4.pem>
- /etc/pki/postfix/certs/RapidSSL_SHA256_CA_-_G4.pem
# subject= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 # issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # notBefore=Jun 30 00:00:00 2015 GMT # notAfter=Jun 29 23:59:59 2025 GMT -----BEGIN CERTIFICATE----- MIIEpjCCA46gAwIBAgIQKByJKWYUQ4BCY1U6MkCuszANBgkqhkiG9w0BAQsFADCB mDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xOTA3BgNVBAsT MChjKSAyMDA4IEdlb1RydXN0IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25s eTE2MDQGA1UEAxMtR2VvVHJ1c3QgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEczMB4XDTE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzNTk1OVowRzELMAkG A1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlk U1NMIFNIQTI1NiBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwJ46D5qyutPS3BXs0DBUWTBNQFGuQnFx0o1Tc4H+uODElsWOfsLxt2NKz6ce P6jnzlOg+i331ubOcBGm7uEDUtJo3j0IDYf9HNcLl2JtgjB2G0c6xPfO7R18jLcX jlOAHh0PXYz5kOQEHgJ+y7BJ79pSJfv7Z+3dhHRZhA7z3nBmjeRSOPdTWjcTZws+ u6hYty7t/7deEXO5d0VSZ0auxNwkgYl2CsqhbGZzBIKq9XBsXxuaAHlG1n96Jhcw zzlLLHTZiUR2ENDt94u7iQV1TQsNs9rpv/FqfSoR2x6fjOPEBmnhHYhFOdFuVdiq t5tv6vTerBcRkl1Am4N7muL3qQIDAQABo4IBOjCCATYwLgYIKwYBBQUHAQEEIjAg MB4GCCsGAQUFBzABhhJodHRwOi8vZy5zeW1jZC5jb20wEgYDVR0TAQH/BAgwBgEB /wIBADBJBgNVHSAEQjBAMD4GBmeBDAECATA0MDIGCCsGAQUFBwIBFiZodHRwczov L3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2VzL2NwczA2BgNVHR8ELzAtMCugKaAn hiVodHRwOi8vZy5zeW1jYi5jb20vR2VvVHJ1c3RQQ0EtRzMuY3JsMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FPO1VgzECbC0zx+q+d0jVvB36KH5MB8GA1UdIwQYMBaAFMR5yo6hTgMdHNxr2zFb lD4/MH8tMA0GCSqGSIb3DQEBCwUAA4IBAQDDftiDSwRMVSkqTxSdmm7ekHDBpCZM iI54SO+9nLCg9fBm/P5ZJuF578i3YGSoi0fqL+CDmdpBGdfFvgX68pAR8Ar/bNwF tNgGb6Rvjb4gK1Tb+aJFg5oepSGJNR18IFwX/QQuRdiyxvhCmfxUCE5LgF85N7qV TqY3Cp6TXodb6ZDWqLZlCI1hSeuDIKldGxZgYmsvVPtaAg16J+JL4QUUwuTp+XDA 2fc0ZQ6ikUusKPK3CA+Yytc+cLbIC/GLnFH4xhBs0lNPYowRAD6I37/m0sxwve0l nPvdJAq9WZFKQgM4EnEyiHagjny7Mu+IKhvUam9QuVJni6sw+h/94ySa -----END CERTIFICATE-----
# vim /etc/pki/postfix/certs/GeoTrust_Primary_Certification_Authority_-_G3.pem>
- /etc/pki/postfix/certs/GeoTrust_Primary_Certification_Authority_-_G3.pem
# subject= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # notBefore=Apr 2 00:00:00 2008 GMT # notAfter=Dec 1 23:59:59 2037 GMT -----BEGIN CERTIFICATE----- MIID/jCCAuagAwIBAgIQFaxulBmyeUtB9iepwxgPHzANBgkqhkiG9w0BAQsFADCB mDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xOTA3BgNVBAsT MChjKSAyMDA4IEdlb1RydXN0IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25s eTE2MDQGA1UEAxMtR2VvVHJ1c3QgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEczMB4XDTA4MDQwMjAwMDAwMFoXDTM3MTIwMTIzNTk1OVowgZgxCzAJ BgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMTkwNwYDVQQLEzAoYykg MjAwOCBHZW9UcnVzdCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxNjA0 BgNVBAMTLUdlb1RydXN0IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANziXmJYHTNXOTIz +uvLh4yn1ErdBojqZI4xmKU4kB6Yzy5jK/BGvESyiaHAKAxJcCGVn2TAppMSAmUm hsalifD614SgcK9PGpc/BkTVyetyEH3kMSj7HGHmKAdEc5IiaacDiGydY8hS2pgn 5whMcD60yRLBxWeDXTPzAxHsatBT4tG6NmCUgLthY2xbF37fQJQeqw3CIShwiP/W JmxsYAQlTlV+fe+/lEjetx3dcI0FX4ilm/LC7urRQEFtYjgdVgbFA0dRIBn8exAL DmKudlW/X3e+PkkBUz2YJQN2JFodtNuJ6nnltrM7P7pMKEF/BqxqjsHQ9gUdfeZC huOl1UcCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFMR5yo6hTgMdHNxr2zFblD4/MH8tMA0GCSqGSIb3DQEBCwUAA4IB AQAtxRPPVoB7eni9n64smefv2t+UXglpp+duaIy9cr5HqQ6XErhK8WTTOd8lNNTB zU6B8A8ExCSzNJbGpqow32hhc9f5joWJ7w5elShKKiePEI4ufIbEAp7aDHdlDkQN kv39sxY2+hENHYwOB4lqKVb3cvTdFZx3NWZXqxNT2I7BQMXXExZacse3aQHEerGD AWh9jUGhlBjBJVz88P6DAod8DQ3PLghcSkANPuyBYeYk28rgDi0Hsj5W3I31QYUH SJsMC8tJP33st/3LjWeJGqvtux6jAAgIFyqCXDFdRootD4abdNlF+9RAsXqqaC2G spki4cErx5z481+oghLrGREt -----END CERTIFICATE-----
Wir können nun die Root-Zertifikate unserem Postfix auf zwei Arten zur Verfügung stellen:
- certificate_chain: Hierzu kopieren wir die beiden Root-Zertifikate in eine Datei und weisen diese Datei dann später dem Postfix-Parameter smtpd_tls_CAfile zu.
# cat /etc/pki/postfix/certs/RapidSSL_SHA256_CA_-_G4.pem \ /etc/pki/postfix/certs/GeoTrust_Primary_Certification_Authority_-_G3.pem > \ /etc/pki/postfix/certs/RapidSSL_ca_certificate_chain.pem
Als Ergebnis erhalten wir nun:
# vim /etc/pki/postfix/certs/RapidSSL_ca_certificate_chain.pem
- /etc/pki/postfix/certs/RapidSSL_ca_certificate_chain.pem
# subject= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 # issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # notBefore=Jun 30 00:00:00 2015 GMT # notAfter=Jun 29 23:59:59 2025 GMT -----BEGIN CERTIFICATE----- MIIEpjCCA46gAwIBAgIQKByJKWYUQ4BCY1U6MkCuszANBgkqhkiG9w0BAQsFADCB mDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xOTA3BgNVBAsT MChjKSAyMDA4IEdlb1RydXN0IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25s eTE2MDQGA1UEAxMtR2VvVHJ1c3QgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEczMB4XDTE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzNTk1OVowRzELMAkG A1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlk U1NMIFNIQTI1NiBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwJ46D5qyutPS3BXs0DBUWTBNQFGuQnFx0o1Tc4H+uODElsWOfsLxt2NKz6ce P6jnzlOg+i331ubOcBGm7uEDUtJo3j0IDYf9HNcLl2JtgjB2G0c6xPfO7R18jLcX jlOAHh0PXYz5kOQEHgJ+y7BJ79pSJfv7Z+3dhHRZhA7z3nBmjeRSOPdTWjcTZws+ u6hYty7t/7deEXO5d0VSZ0auxNwkgYl2CsqhbGZzBIKq9XBsXxuaAHlG1n96Jhcw zzlLLHTZiUR2ENDt94u7iQV1TQsNs9rpv/FqfSoR2x6fjOPEBmnhHYhFOdFuVdiq t5tv6vTerBcRkl1Am4N7muL3qQIDAQABo4IBOjCCATYwLgYIKwYBBQUHAQEEIjAg MB4GCCsGAQUFBzABhhJodHRwOi8vZy5zeW1jZC5jb20wEgYDVR0TAQH/BAgwBgEB /wIBADBJBgNVHSAEQjBAMD4GBmeBDAECATA0MDIGCCsGAQUFBwIBFiZodHRwczov L3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2VzL2NwczA2BgNVHR8ELzAtMCugKaAn hiVodHRwOi8vZy5zeW1jYi5jb20vR2VvVHJ1c3RQQ0EtRzMuY3JsMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FPO1VgzECbC0zx+q+d0jVvB36KH5MB8GA1UdIwQYMBaAFMR5yo6hTgMdHNxr2zFb lD4/MH8tMA0GCSqGSIb3DQEBCwUAA4IBAQDDftiDSwRMVSkqTxSdmm7ekHDBpCZM iI54SO+9nLCg9fBm/P5ZJuF578i3YGSoi0fqL+CDmdpBGdfFvgX68pAR8Ar/bNwF tNgGb6Rvjb4gK1Tb+aJFg5oepSGJNR18IFwX/QQuRdiyxvhCmfxUCE5LgF85N7qV TqY3Cp6TXodb6ZDWqLZlCI1hSeuDIKldGxZgYmsvVPtaAg16J+JL4QUUwuTp+XDA 2fc0ZQ6ikUusKPK3CA+Yytc+cLbIC/GLnFH4xhBs0lNPYowRAD6I37/m0sxwve0l nPvdJAq9WZFKQgM4EnEyiHagjny7Mu+IKhvUam9QuVJni6sw+h/94ySa -----END CERTIFICATE----- # subject= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # notBefore=Apr 2 00:00:00 2008 GMT # notAfter=Dec 1 23:59:59 2037 GMT -----BEGIN CERTIFICATE----- MIID/jCCAuagAwIBAgIQFaxulBmyeUtB9iepwxgPHzANBgkqhkiG9w0BAQsFADCB mDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xOTA3BgNVBAsT MChjKSAyMDA4IEdlb1RydXN0IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25s eTE2MDQGA1UEAxMtR2VvVHJ1c3QgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEczMB4XDTA4MDQwMjAwMDAwMFoXDTM3MTIwMTIzNTk1OVowgZgxCzAJ BgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMTkwNwYDVQQLEzAoYykg MjAwOCBHZW9UcnVzdCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxNjA0 BgNVBAMTLUdlb1RydXN0IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANziXmJYHTNXOTIz +uvLh4yn1ErdBojqZI4xmKU4kB6Yzy5jK/BGvESyiaHAKAxJcCGVn2TAppMSAmUm hsalifD614SgcK9PGpc/BkTVyetyEH3kMSj7HGHmKAdEc5IiaacDiGydY8hS2pgn 5whMcD60yRLBxWeDXTPzAxHsatBT4tG6NmCUgLthY2xbF37fQJQeqw3CIShwiP/W JmxsYAQlTlV+fe+/lEjetx3dcI0FX4ilm/LC7urRQEFtYjgdVgbFA0dRIBn8exAL DmKudlW/X3e+PkkBUz2YJQN2JFodtNuJ6nnltrM7P7pMKEF/BqxqjsHQ9gUdfeZC huOl1UcCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFMR5yo6hTgMdHNxr2zFblD4/MH8tMA0GCSqGSIb3DQEBCwUAA4IB AQAtxRPPVoB7eni9n64smefv2t+UXglpp+duaIy9cr5HqQ6XErhK8WTTOd8lNNTB zU6B8A8ExCSzNJbGpqow32hhc9f5joWJ7w5elShKKiePEI4ufIbEAp7aDHdlDkQN kv39sxY2+hENHYwOB4lqKVb3cvTdFZx3NWZXqxNT2I7BQMXXExZacse3aQHEerGD AWh9jUGhlBjBJVz88P6DAod8DQ3PLghcSkANPuyBYeYk28rgDi0Hsj5W3I31QYUH SJsMC8tJP33st/3LjWeJGqvtux6jAAgIFyqCXDFdRootD4abdNlF+9RAsXqqaC2G spki4cErx5z481+oghLrGREt -----END CERTIFICATE-----
- full_certificate_chain: Hier kopieren wir nun unser Serverzertifikat, gefolgt vom Intermediate Zertifikat und dem Root-CA Zertifikat in eine Datei. Diese Datei weisen wir dann dem Postfix Parameter smtpd_tls_cert_file zu.
# cat /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.certificate.pem \ /etc/pki/postfix/certs/RapidSSL_SHA256_CA_-_G4.pem \ /etc/pki/postfix/certs/GeoTrust_Primary_Certification_Authority_-_G3.pem > \ /etc/pki/postfix/rapidssl_2015-10-15_mx01.nausch.org.full_certificate_chain.pem
Als Ergebnis erhalten wir nun:
# vim /etc/pki/postfix/rapidssl_2015-10-15_mx01.nausch.org.full_certificate_chain.pem
- /etc/pki/postfix/rapidssl_2015-10-15_mx01.nausch.org.full_certificate_chain.pem
# subject= /OU=GT22667941/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=mx01.nausch.org # issuer= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 # notBefore=Oct 14 22:20:53 2015 GMT # notAfter=Oct 15 16:09:11 2017 GMT -----BEGIN CERTIFICATE----- MIIFoDCCBIigAwIBAgICKRAwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCVVMx FjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlkU1NMIFNIQTI1 NiBDQSAtIEc0MB4XDTE1MTAxNDIyMjA1M1oXDTE3MTAxNTE2MDkxMVowgZMxEzAR BgNVBAsTCkdUMjI2Njc5NDExMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29t L3Jlc291cmNlcy9jcHMgKGMpMTUxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZh bGlkYXRlZCAtIFJhcGlkU1NMKFIpMRgwFgYDVQQDEw9teDAxLm5hdXNjaC5vcmcw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXjwLCvdn28r0ja5zWJhkr 2FtxGipH/3/p81FccAlFgHXg4a98E11VEOfH7mjJqi3a6hx+MQDGD78aSxpqAE2c M5No3fONVr3cFoj/IVVUG+EwMOSr22l/jfKmMqlkEIv44TdIKsbdbr+loZAFw15H aUiqFsPWw++O/T19OZKJjep/W/wWFFSkuTV5eMBKHEanIfpetv3Eru2KyGKtIe4I iFeG2NLM1lB4yD7zJ9utCnNEr/O/Gicc1fURYLQNLnj7lRRPoRvpDyQrnjn7z9e7 lXgg2yX487dIedYZ2gUasbux9tWB8iEXCd+zKH722unlZN5UW7jSbOztZlEcBNuv AVmongX9Qqm8i4MewB1lCm9nLxQfvgybjHJTwiRTxHWWHVNUbJ5RqsxF5/3G4KPG KirBvDqQdyN+SZjg4j5eUA7sEgkRV7ZFWhy+OogB5CkWvek5cKDf3T921ZNx0pir 0lQEktWy8j6JnVu0cfYOjeWwjU6gGam9zu2zBFWnnTVkI+A6/l2QVs/Iz5utQXdB ke/qYcCCV5NCdRpNEZ8F9wTOSL9MK1mV/rogEQUjujgjfB4P674NF9XLlLaYBfAK ov1BPKp/+xqw0aWyGUO+Gt2n/MevebUQgPhSm6y5J1naioVbO1T5mcpANGGqM0fV iERkm7rqiDhfeHOMvbLw6QIDAQABo4IBRzCCAUMwHwYDVR0jBBgwFoAU87VWDMQJ sLTPH6r53SNW8HfoofkwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUFBzABhhNodHRw Oi8vZ3ouc3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vZ3ouc3ltY2IuY29t L2d6LmNydDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG AQUFBwMCMBoGA1UdEQQTMBGCD214MDEubmF1c2NoLm9yZzArBgNVHR8EJDAiMCCg HqAchhpodHRwOi8vZ3ouc3ltY2IuY29tL2d6LmNybDAMBgNVHRMBAf8EAjAAMEEG A1UdIAQ6MDgwNgYGZ4EMAQIBMCwwKgYIKwYBBQUHAgEWHmh0dHBzOi8vd3d3LnJh cGlkc3NsLmNvbS9sZWdhbDANBgkqhkiG9w0BAQsFAAOCAQEAI741GwJW1MPFpzn6 k0KavUzJp9uybjbRGrH1p1HbKX7nMj93qO7BcN6x3aXVxAe5bDPhK7flmlAwIAyn X+EVjC0uV10zY75uY8jfyQ2j7qi2FMMWsa98kWMPzxkU9k7DXDSNIXvhoPhfT9ep A0pY4peiKrrCDGvW6/G2Bx8KXpOjUlNC7GGZxK9ZOVvCe8l5fZFT/II4dEYiU/bJ Md2v5ayCTGAt8S5ITz/6o0MALtIB9M0/AyqqxFKLinIqOAoKxWE+4fO6J3t+YOGp eVH+n//PADBewKZZF43KSROsqM6fE4DeRdUk77Tp9LyCoKdPFHo04XHmE0iyBT6h x5L03w== -----END CERTIFICATE----- # subject= /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G4 # issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # notBefore=Jun 30 00:00:00 2015 GMT # notAfter=Jun 29 23:59:59 2025 GMT -----BEGIN CERTIFICATE----- MIIEpjCCA46gAwIBAgIQKByJKWYUQ4BCY1U6MkCuszANBgkqhkiG9w0BAQsFADCB mDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xOTA3BgNVBAsT MChjKSAyMDA4IEdlb1RydXN0IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25s eTE2MDQGA1UEAxMtR2VvVHJ1c3QgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEczMB4XDTE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzNTk1OVowRzELMAkG A1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlk U1NMIFNIQTI1NiBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwJ46D5qyutPS3BXs0DBUWTBNQFGuQnFx0o1Tc4H+uODElsWOfsLxt2NKz6ce P6jnzlOg+i331ubOcBGm7uEDUtJo3j0IDYf9HNcLl2JtgjB2G0c6xPfO7R18jLcX jlOAHh0PXYz5kOQEHgJ+y7BJ79pSJfv7Z+3dhHRZhA7z3nBmjeRSOPdTWjcTZws+ u6hYty7t/7deEXO5d0VSZ0auxNwkgYl2CsqhbGZzBIKq9XBsXxuaAHlG1n96Jhcw zzlLLHTZiUR2ENDt94u7iQV1TQsNs9rpv/FqfSoR2x6fjOPEBmnhHYhFOdFuVdiq t5tv6vTerBcRkl1Am4N7muL3qQIDAQABo4IBOjCCATYwLgYIKwYBBQUHAQEEIjAg MB4GCCsGAQUFBzABhhJodHRwOi8vZy5zeW1jZC5jb20wEgYDVR0TAQH/BAgwBgEB /wIBADBJBgNVHSAEQjBAMD4GBmeBDAECATA0MDIGCCsGAQUFBwIBFiZodHRwczov L3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2VzL2NwczA2BgNVHR8ELzAtMCugKaAn hiVodHRwOi8vZy5zeW1jYi5jb20vR2VvVHJ1c3RQQ0EtRzMuY3JsMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FPO1VgzECbC0zx+q+d0jVvB36KH5MB8GA1UdIwQYMBaAFMR5yo6hTgMdHNxr2zFb lD4/MH8tMA0GCSqGSIb3DQEBCwUAA4IBAQDDftiDSwRMVSkqTxSdmm7ekHDBpCZM iI54SO+9nLCg9fBm/P5ZJuF578i3YGSoi0fqL+CDmdpBGdfFvgX68pAR8Ar/bNwF tNgGb6Rvjb4gK1Tb+aJFg5oepSGJNR18IFwX/QQuRdiyxvhCmfxUCE5LgF85N7qV TqY3Cp6TXodb6ZDWqLZlCI1hSeuDIKldGxZgYmsvVPtaAg16J+JL4QUUwuTp+XDA 2fc0ZQ6ikUusKPK3CA+Yytc+cLbIC/GLnFH4xhBs0lNPYowRAD6I37/m0sxwve0l nPvdJAq9WZFKQgM4EnEyiHagjny7Mu+IKhvUam9QuVJni6sw+h/94ySa -----END CERTIFICATE----- # subject= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # issuer= /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 # notBefore=Apr 2 00:00:00 2008 GMT # notAfter=Dec 1 23:59:59 2037 GMT -----BEGIN CERTIFICATE----- MIID/jCCAuagAwIBAgIQFaxulBmyeUtB9iepwxgPHzANBgkqhkiG9w0BAQsFADCB mDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xOTA3BgNVBAsT MChjKSAyMDA4IEdlb1RydXN0IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25s eTE2MDQGA1UEAxMtR2VvVHJ1c3QgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEczMB4XDTA4MDQwMjAwMDAwMFoXDTM3MTIwMTIzNTk1OVowgZgxCzAJ BgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMTkwNwYDVQQLEzAoYykg MjAwOCBHZW9UcnVzdCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxNjA0 BgNVBAMTLUdlb1RydXN0IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANziXmJYHTNXOTIz +uvLh4yn1ErdBojqZI4xmKU4kB6Yzy5jK/BGvESyiaHAKAxJcCGVn2TAppMSAmUm hsalifD614SgcK9PGpc/BkTVyetyEH3kMSj7HGHmKAdEc5IiaacDiGydY8hS2pgn 5whMcD60yRLBxWeDXTPzAxHsatBT4tG6NmCUgLthY2xbF37fQJQeqw3CIShwiP/W JmxsYAQlTlV+fe+/lEjetx3dcI0FX4ilm/LC7urRQEFtYjgdVgbFA0dRIBn8exAL DmKudlW/X3e+PkkBUz2YJQN2JFodtNuJ6nnltrM7P7pMKEF/BqxqjsHQ9gUdfeZC huOl1UcCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFMR5yo6hTgMdHNxr2zFblD4/MH8tMA0GCSqGSIb3DQEBCwUAA4IB AQAtxRPPVoB7eni9n64smefv2t+UXglpp+duaIy9cr5HqQ6XErhK8WTTOd8lNNTB zU6B8A8ExCSzNJbGpqow32hhc9f5joWJ7w5elShKKiePEI4ufIbEAp7aDHdlDkQN kv39sxY2+hENHYwOB4lqKVb3cvTdFZx3NWZXqxNT2I7BQMXXExZacse3aQHEerGD AWh9jUGhlBjBJVz88P6DAod8DQ3PLghcSkANPuyBYeYk28rgDi0Hsj5W3I31QYUH SJsMC8tJP33st/3LjWeJGqvtux6jAAgIFyqCXDFdRootD4abdNlF+9RAsXqqaC2G spki4cErx5z481+oghLrGREt -----END CERTIFICATE-----
- Variante a: Hier weisen wir dem Postfix-Parameter smtpd_tls_cert_file der Datei zu, in dem sich „nur“ das Serverzertifikat befindet. Beim Parameter smtpd_tls_CAfile verweisen wir auf die Datei mit den beiden Root-Zertifikats-Kette zu.
# Django : 2014-10-19 - SSL/TLS - Schutz durch verschlüsselte Verbindungen # (Postfixbuch: Kapitel 20.2) # Pfade für die Key- und Zertifikatsdateien für den SMTP-Daemon # Konfigurationsbeispiel "a" bei dem das Serverzertifikat und die beiden # Root-Zertifikate der CA in getrennten Dateien vorliegen. # default: smtpd_tls_key_file = $smtpd_tls_cert_file # smtpd_tls_cert_file = # smtpd_tls_CAfile = smtpd_tls_key_file = /etc/pki/postfix/private/mx01.nausch.org.serverkey_151015.pem smtpd_tls_cert_file = /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.certificate.pem smtpd_tls_CAfile = /etc/pki/postfix/certs/RapidSSL_ca_certificate_chain.pem
- Variante b: Hier weisen wir dem Postfix-Parameter smtpd_tls_cert_file diejenige Datei zu, in der, angefangen vom Serverzertifikat bis hin zum selbstsignierten Root-Zertifikat der CA, alle benötigten Zertifikate vorfinden. Den Parameter smtpd_tls_CAfile lassen wir erst einmal unbesetzt!
# Django : 2014-10-19 - SSL/TLS - Schutz durch verschlüsselte Verbindungen # (Postfixbuch: Kapitel 20.2) # Pfade für die Key- und Zertifikatsdateien für den SMTP-Daemon # Konfigurationsbeispiel "b" bei dem das Serverzertifikat und die beiden # Root-Zertifikate der CA in einer gemainsamen Dateien vorliegen. # default: smtpd_tls_key_file = $smtpd_tls_cert_file # smtpd_tls_cert_file = # smtpd_tls_CAfile = smtpd_tls_key_file = /etc/pki/postfix/private/mx01.nausch.org.serverkey_151015.pem smtpd_tls_cert_file = /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.full_certificate_chain.pem smtpd_tls_CAfile =
Haben die Konfiguration werden Informationen zur TLS-Verschlüsselung im Mailheader der angenommenen Nachrichten eingefügt, vorausgesetzt wir haben den Parameter smtpd_tls_received_header = yes gesetzt. Nachfolgendes Beispiel zeigt einen solchen Eintrag:
Received: from mx1.piratenpartei-bayern.de (mx1.piratenpartei-bayern.de [88.198.212.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.nausch.org (Postfix) with ESMTPS id 3F887C00088 for; Thu, 22 Oct 2015 12:01:32 +0200 (CEST)
Der Zusatz (No client certificate requested) weisst darauf hin, dass der SMTP-Daemon nicht nach einem Zertifikat gefragt hatte. Ein Klient wird nur dann sein Client-Zertifikat zum Server schicken, wenn dieser explizit danach frägt. Diese Funktion können wir jedoch aktivieren, in dem wir den Postfix Parameter smtpd_tls_ask_ccert = yes setzen.
# Django : 2015-02-23 - Remote Client nach einem Zertifikat fragen # http://www.postfix.org/postconf.5.html#smtpd_tls_ask_ccert # default: smtpd_tls_ask_ccert = no smtpd_tls_ask_ccert = yes
Haben wir diese Funktion gesetzt, werden wir nun Informationen zum CN des Zertifikats und eine Bewertung des Vertrauensstatuses zu dem Zertifikat vorfinden, wie nachfolgender Ausschnitt aufzeigt.
Received: from mx1.piratenpartei-bayern.de (mx1.piratenpartei-bayern.de [88.198.212.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.piratenpartei-bayern.de", Issuer "PositiveSSL CA 2" (not verified)) by mx01.nausch.org (Postfix) with ESMTPS id 57BD3C00088 for; Thu, 22 Oct 2015 12:28:30 +0200 (CEST)
Im Mailheader sehen wir nun, dass sich der Client mit einem Zertifikat von Client CN "*.piratenpartei-bayern.de", Issuer "PositiveSSL CA 2" ausgewiesen hatte. Der Zusatz (not verified)wird noch angezeigt, da wir (noch) nicht die benötigten Rootzertifikate in unserem Truststore verankert haben. Sobald wir die Zertifikate unserer wichtigsten Kommunikationspartner zu den vertrauenswürdigen Root-Zertifikaten hinzugefügt und die CAcert-Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem erstellt haben, müssen wir dem SMTP-Daemon noch sagen, das er zur Verifizierung diese Datei verwenden soll. Hier zeigt es sich dann auch als Vorteil, wenn wir unser Serverzertifikat zusammen mit den CA-Root-Zertifikaten in einer Datei angelegt und dem Postfix-Parameter smtpd_tls_cert_file übergeben haben.
# Django : 2014-10-19 - SSL/TLS - Schutz durch verschlüsselte Verbindungen # (Postfixbuch: Kapitel 20.2) # Pfade für die Key- und Zertifikatsdateien für den SMTP-Daemon # Konfigurationsbeispiel "a" bei dem das Serverzertifikat und die beiden # Root-Zertifikate der CA in einer gemainsamen Dateien vorliegen. # default: smtpd_tls_key_file = $smtpd_tls_cert_file # smtpd_tls_cert_file = # smtpd_tls_CAfile = smtpd_tls_key_file = /etc/pki/postfix/private/mx01.nausch.org.serverkey_151015.pem smtpd_tls_cert_file = /etc/pki/postfix/certs/rapidssl_2015-10-15_mx01.nausch.org.full_certificate_chain.pem smtpd_tls_CAfile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
Nimmt unser Mailserver nun Nachrichten über einen TLS-verschlüsselten Transportweg entgegen, frägt er den Klient nach seinem Clientzertifikat und Überprüft an Hand der Zertifikatskette, ob die Zertifikatskette lückenlos und vertrauenswürdig ist.
Received: from mx1.piratenpartei-bayern.de (mx1.piratenpartei-bayern.de [88.198.212.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.piratenpartei-bayern.de", Issuer "PositiveSSL CA 2" (verified OK)) by mx01.nausch.org (Postfix) with ESMTPS id A490AC00088 for; Thu, 22 Oct 2015 13:48:13 +0200 (CEST)
Nachdem nun sowohl das Zertifikat und auch die Validierung des selbigen O.K. bzw. „grün“ ist, können wir das Kapitel SMTP-Daemon (Empfang von eMails) schließen und uns dem nächsten Punkt SMTP-Client (Versand von eMails).
SMTP-Client (Versand von eMails)
Versendet unser Postfix MTA eine Nachricht an einen entfernten Mailserver, wird dieser nach dem STARTTLS sein Serverzertifikat präsentieren. Mit publickey des empfangenen Serverzertifikats kann unser Client die Parameter, die nur zur Verschlüsselung der nachfolgenden Nachricht(en) ausgehandelt werden, verschlüsseln. Wir benötigen also auf unserem Mailserver erst einmal kein eigenes Client-Zertifikat mit dem zugehörigen privaten Schlüssel.
Haben wir eine TLS-Verschlüsselung des SMTP-Clients aktiviert, sieht der Empfänger die Verschlüsselung in den Mailheadern, vorausgesetzt der Postmaster des Zielsystems hat diese Funktion bei seinem MTA auch aktiviert.
Received: from mx01.nausch.org (mx01.nausch.org [217.91.103.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.piratenpartei-bayern.de (Postfix) with ESMTPS
Der Zusatz (Client did not present a certificate) weisst darauf hin, dass unser SMTP-Client kein Zertifikat übertragen hat. Nachdem wir noch kein Zertifikat unseren SMTP-Client bekannt gegeben haben, ist dieser Hinweis einfach zu erklären.
Wir werden also unserem SMTP-Client ein passendes Serverzertifikat benennen. Im einfachsten Fall verwenden wir das gleiche Zertifikat, welches auch schon unsere SMTP-Daemon verwendet.
# Django : 2014-10-19 - SSL/TLS - Schutz durch verschlüsselte Verbindungen # (Postfixbuch: Kapitel 20.2) # Pfade für die Key- und Zertifikatsdateien für den SMTP-Client # Konfigurationsbeispiel "b" bei dem das Serverzertifikat und die beiden # Root-Zertifikate der CA in einer gemainsamen Dateien vorliegen. # default: smtpd_tls_key_file = $smtpd_tls_cert_file # smtpd_tls_cert_file = # smtpd_tls_CAfile = smtp_tls_key_file = $smtpd_tls_key_file smtp_tls_cert_file = $smtpd_tls_cert_file smtp_tls_CAfile =
Soll der Client über ein eigenes Zertifikat verfügen, müssen wir natürlich statt der Variablen, die Pfadangaben zum Zertifikat und Schlüssel angeben. Ist dieses erfolgt, wird der Empfänger in den Mailhaedern sehen können, dass sich unser Client mit seinem Certifikat Client CN "mx01.nausch.org", Issuer "RapidSSL SHA256 CA - G4" gemeldet hatte, da der Zielserver nach diesem fragte. Vertraut der Empfänger der Zertifikatskette wird auch ein Verify mit positivem Ergebnis verified OK beendet.
from mx01.nausch.org (mx01.nausch.org [217.91.103.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx01.nausch.org", Issuer "RapidSSL SHA256 CA - G4" (verified OK)) by mx1.piratenpartei-bayern.de (Postfix) with ESMTPS for; Thu, 22 Oct 2015 14:38:38 +0200 (CEST)
Da wir unserem SMTP-Client noch keine Root-CA-Zertifikate an die Hand gegeben haben, kann dieser auch nicht prüfen, ob dem Serverzertifikat, welches ihm der SMTP-Daemon des Zielservers übermittelte, vertraut werden kann. Im Maillog unseres Servers sehen wir auch dass eine „Untrusted TLS connection established to“ erfolgte.
Oct 22 14:38:38 vml000087 postfix/smtp[2640]: Untrusted TLS connection established to mx1.piratenpartei-bayern.de[88.198.212.215]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Wir vervollständigen nun unsere postfix-Konfiguration und geben beim Parameter smtp_tls_CAfile an, dass er die gleiche Datei verwenden soll, die auch schon der Daemon verwendet.
# Django : 2014-10-19 - SSL/TLS - Schutz durch verschlüsselte Verbindungen # (Postfixbuch: Kapitel 20.2) # Pfade für die Key- und Zertifikatsdateien für den SMTP-Client # Konfigurationsbeispiel "b" bei dem das Serverzertifikat und die beiden # Root-Zertifikate der CA in einer gemainsamen Dateien vorliegen. # default: smtpd_tls_key_file = $smtpd_tls_cert_file # smtpd_tls_cert_file = # smtpd_tls_CAfile = smtp_tls_key_file = $smtpd_tls_key_file smtp_tls_cert_file = $smtpd_tls_cert_file smtp_tls_CAfile = $smtpd_tls_CAfile
Baut nun unser SMTP-Client eine Verbindung zu einem Zielserver auf und stuft die Verbindung an Hand des Zertifikates als vertrauenswürdig ein, wird im Maillog unseres Servers dies mit einem Trusted vermewrkt.
Oct 22 15:06:55 vml000087 postfix/smtp[9255]: Trusted TLS connection established to mx1.piratenpartei-bayern.de[88.198.212.215]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Ciphers - Chiffren zur Ver- und Entschlüsselung
opportunistische Verschlüsselung
Mit dem Parameter smtpd_tls_ciphers wird definiert, welchen TLS Cipher Grad der Postfix SMTP-Server bei der opportunistischen TLS-Verschlüsselung verwenden soll. Der Standardwert „export“ sorgt dabei für maximale Interoperabilität. Folgende Werte können dabei gesetzt werden.
- export Aktiviert „export-grade“ oder bessere OpenSSL Chiffren.
tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
- low Aktiviert „low-grade“ oder bessere OpenSSL Chiffren.
tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
- medium Aktiviert „medium-grade“ oder bessere OpenSSL Chiffren.
tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
- high Aktiviert „high-grade“ oder bessere OpenSSL Chiffren.
tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
- null Aktiviert lediglich die „NULL“ OpenSSL Chiffren und stellt so nur Authentifizierung ohne Verschlüsselung zur Verfügung.
tls_null_cipherlist = eNULL:!aNULL
Da die Verschlüsselung optional ist, ist eine Änderung der Option nicht notwendig, es sei denn die Änderung ist notwendig und daher gut überlegt sowie unumgänglich!
Der Parameter smtpd_tls_ciphers definiert, welchen TLS Cipher Grad der Postfix SMTP-Daemon (ankommende Verbindungen) bei der opportunistischen TLS-Verschlüsselung verwenden soll.
# Django : 2014-10-25 - Minimaler TLS Cipher Grad für die opportunistischen TLS-Verschlüsselung # des Postfix SMTP-Daemon bei ankommenden Verbindungen # http://www.postfix.org/postconf.5.html#smtpd_tls_ciphers # default: smtpd_tls_ciphers = export
Der Parameter smtp_tls_ciphers definiert, welchen TLS Cipher Grad der Postfix SMTP-Client (abgehende Verbindungen) bei der opportunistischen TLS-Verschlüsselung verwenden soll.
# Django : 2014-10-25 - Minimaler TLS Cipher Grad für die opportunistischen TLS-Verschlüsselung # des Postfix SMTP-Client bei ausgehenden Verbindungen # http://www.postfix.org/postconf.5.html#smtp_tls_ciphers # default: smtp_tls_ciphers = export
Der Parameter smtpd_tls_exclude_ciphers legt eine Liste von Chiffren oder Chiffre-Typen fest, welche bei allen TLS Sicherheitsstufen beim ankommenden Verkehr beim Postfix SMTP-Daemon ausgeschlossen werden sollen.
# Django : 2014-10-25 - Liste der Chiffren oder Chiffre-Typen, die bei allen TLS # Sicherheitsstufen des Postfix SMTP-Daemon ausgeschlossen werden sollen. # http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers # default: smtpd_tls_exclude_ciphers = smtpd_tls_exclude_ciphers = aNULL eNULL EXPORT DES 3DES RC4 MD5 PSK aECDH EDH-DSS-DES-CBC3-SHA EDH-RSA-DES-CDC3-SHA KRB5-DE5 CBC3-SHA
Der Parameter smtp_tls_exclude_ciphers legt eine Liste von Chiffren oder Chiffre-Typen fest, welche bei allen TLS Sicherheitsstufen beim ausgehenden Verkehr des Postfix SMTP-Client ausgeschlossen werden sollen.
# Django : 2014-10-25 - Liste der Chiffren oder Chiffre-Typen des Postfix SMTP-Client # bei allen TLS Sicherheitsstufen ausgeschlossen werden sollen. # http://www.postfix.org/postconf.5.html#smtp_tls_exclude_ciphers # default: smtp_tls_exclude_ciphers = smtp_tls_exclude_ciphers = aNULL eNULL EXPORT DES 3DES RC4 MD5 PSK aECDH EDH-DSS-DES-CBC3-SHA EDH-RSA-DES-CDC3-SHA KRB5-DE5 CBC3-SHA AES128-SHA DHE-RSA-AES128-SHA AES256-SHA DHE-RSA-AES256-SHA CAMELLIA128-SHA DHE-RSA-CAMELLIA128-SHA CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
verpflichtende Verschlüsselung
Der Parameter smtpd_tls_mandatory_ciphers definiert, welchen TLS Cipher Grad der Postfix SMTP-Daemon bei der verpflichtenden TLS-Verschlüsselung verwenden soll.
# Django : 2014-10-19 - Minimum TLS Cipher für die verpflichtende Verschlüsselung # des Postfix SMTP-Daemon bei ankommenden Verbindungen # http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers # default: smtpd_tls_mandatory_ciphers = medium smtpd_tls_mandatory_ciphers = high
Der Parameter smtp_tls_mandatory_ciphers definiert, welchen TLS Cipher Grad der Postfix SMTP-Client bei der verpflichtenden TLS-Verschlüsselung verwenden soll.
# Django : 2014-10-19 - Minimum TLS Cipher für die verpflichtende Verschlüsselung # des Postfix SMTP-Clients bei ausgehenden Verbindungen # http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers # default: smtp_tls_mandatory_ciphers = medium smtp_tls_mandatory_ciphers = high
Der Parameter smtpd_tls_mandatory_exclude_ciphers legt eine Liste von Chiffren oder Chiffre-Typen fest, welche bei allen verpflichtenden TLS Sicherheitsstufen beim ankommenden Verkehr des Postfix SMTP-Daemon ausgeschlossen werden sollen. Im RFC 7465 wird unter anderem die Verwendung des RC4 Algorithmus explizit mit MUST NOT verboten.
# Django : 2014-10-19 - Ausschlussliste der verpflichtenden TLS Verschlüsselung # des postfix SMTP-Daemons. # http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_exclude_ciphers # default: smtpd_tls_mandatory_exclude_ciphers = smtpd_tls_mandatory_exclude_ciphers = aNULL eNULL EXPORT DES RC4 MD5 PSK aECDH EDH-DSS-DES-CBC3-SHA EDH-RSA-DES-CDC3-SHA KRB5-DE5 CBC3-SHA
Der Parameter smtp_tls_mandatory_exclude_ciphers legt eine Liste von Chiffren oder Chiffre-Typen fest, welche bei allen verpflichtenden TLS Sicherheitsstufen beim ausgehenden Verkehrs des Postfix SMTP-Client ausgeschlossen werden sollen. Im RFC 7465 wird unter anderem die Verwendung des RC4 Algorithmus explizit mit MUST NOT verboten.
# Django : 2014-10-19 - Ausschlussliste der verpflichtenden TLS Verschlüsselung # des postfix SMTP-Clients. # http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_exclude_ciphers # default: smtp_tls_mandatory_exclude_ciphers = smtp_tls_mandatory_exclude_ciphers = smtp_tls_exclude_ciphers = aNULL eNULL EXPORT DES RC4 MD5 PSK aECDH EDH-DSS-DES-CBC3-SHA EDH-RSA-DES-CDC3-SHA KRB5-DE5 CBC3-SHA AES128-SHA DHE-RSA-AES128-SHA AES256-SHA DHE-RSA-AES256-SHA CAMELLIA128-SHA DHE-RSA-CAMELLIA128-SHA CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
Protokolle
opportunistische Verschlüsselung
Mit dem Parameter smtpd_tls_protocols kann definiert werden, welche TLS Protokolle bei der opportunistischen Verschlüsselung des ankommenden SMTP-Verkehrs beim Postfix SMTP Daemon ein- oder ausgeschlossen werden sollen.
# Django : 2014-10-19 - Positiv-/Negativliste aller TLS-Protokolle, die der # Postfix SMTP-Server bei der opportunischtischen Verschlüsselung # berücksichtigen soll. # http://www.postfix.org/postconf.5.html#smtpd_tls_protocols # default: smtpd_tls_protocols = smtpd_tls_protocols = !SSLv2 !SSLv3
Mit dem Parameter smtp_tls_protocols und lmtp_tls_protocols kann definiert werden, welche TLS Protokolle bei der opportunistischen Verschlüsselung des ausgehenden SMTP/LMTP-Verkehrs des Postfix SMTP Client ein- oder ausgeschlossen werden sollen.
# Django : 2014-10-19 - Positiv-/Negativliste aller TLS-Protokolle, die der # Postfix SMTP-/LMTP-Client bei der opportunischtischen Verschlüsselung # berücksichtigen soll. # http://www.postfix.org/postconf.5.html#smtp_tls_protocols # default: smtp_tls_protocols = !SSLv2 # lmtp_tls_protocols = !SSLv2 smtp_tls_protocols = !SSLv2 !SSLv3 lmtp_tls_protocols = $smtp_tls_protocols
verpflichtende Verschlüsselung
Mit dem Parameter smtpd_tls_mandatory_protocols wird definiert, welche TLS Protokolle bei der verpflichtenden Verschlüsselung des ankommenden SMTP-Verkehrs beim Postfix SMTP Daemon ein- oder ausgeschlossen werden sollen.
# Django : 2014-10-19 - Positiv-/Negativliste aller TLS-Protokolle, die der # Postfix SMTP-Server bei der verpflichtenden Verschlüsselung # berücksichtigen soll. # http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_protocols # default: smtpd_tls_mandatory_protocols = !SSLv2 smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
Mit dem Parameter smtp_tls_mandatory_protocols und lmtp_tls_mandatory_protocols wird definiert, welche TLS Protokolle bei der verpflichtenden Verschlüsselung des ausgehenden SMTP/LMTP-Verkehrs beim Postfix SMTP Daemon ein- oder ausgeschlossen werden sollen.
# Django : 2014-10-19 - Positiv-/Negativliste aller TLS-Protokolle, die der # Postfix SMTP-/LMTP-Client bei der verpflichtenden Verschlüsselung # berücksichtigen soll. # http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols # default: smtp_tls_mandatory_protocols = !SSLv2 smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 lmtp_tls_mandatory_protocols = $smtp_tls_mandatory_protocols
Verschlüsselung beim SMTP-Daemon
Mit der Option smtpd_tls_security_level beeinflusst man das SMTP TLS Verhalten des Postfix SMTP Daemons. Folgende Verschlüsselungsvarianten sind einstellbar:
- none: TLS wird nicht genutzt; d.h. die Übertragung werden nicht verschlüsselt!
- may: Opportunistische TLS Verschlüsselung: Einliefernden SMTP-Clients wird STARTTLS angeboten, aber nicht zwingend vorgeschrieben. Der Client bestimmt dann ob verschlüsselt gesprochen werden soll, oder nicht.
- encrypt: Vorgeschriebene TLS Verschlüsselung: Einliefernden SMTP-Clients wird STARTTLS angeboten und zwingend vorgeschrieben! Diese Einstellung ist aber gemäß RFC 2487 nur für dedizierte Mailserver zu wählen. Öffentlich erreichbare Mailserver müssen neben einer TLS-geschützen Übertragung auch PLAIN-TEXT Übertragungen zulassen!
opportunistische Verschlüsselung
Soll der SMTP-Daemon dem SMTP-Client eine TLS-Verschlüsselung anbieten, aber nicht zwingend vorschreiben, setzt man den Parameter smtpd_tls_security_level=may. Somit obliegt es dem SMTP-Client ob dieser mit einem STARTTLS die TLS-Verschlüsselung initiiert, oder nicht. Haben wir einen Mailserver, der auch aus dem Internet Nachrichten empfangen soll, ist dieses „best practices“ Verfahren zu wählen.
# Django : 2014-10-19 - Opportunistische TLS-Verschlüsselung für den # SMTP-Daemon für den ankommenden Verkehr aktiviert; d.h. STARTTLS # wird dem Remote-SMTP-Client angeboten aber nicht zwingend # vorgeschrieben. # http://www.postfix.org/postconf.5.html#smtpd_tls_security_level # # Folgende Verschlüsselungsvarianten sind einstellbar: # none: TLS wird nicht genutzt; d.h. die Übertragung werden nicht ver- # schlüsselt! # # may : Opportunistische TLS Verschlüsselung: Einliefernden SMTP-Clients # wird STARTTLS angeboten, aber nicht zwingend vorgeschrieben. Der # Client bestimmt dann ob verschlüsselt gesprochen werden soll, # oder nicht. # # encrypt: Vorgeschriebene TLS Verschlüsselung: Einliefernden SMTP-Clients # wird STARTTLS angeboten und zwingend vorgeschrieben! Diese # Einstellung ist aber gemäß RFC 2487 nur für dedizierte Mailserver # zu wählen. Öffentlich erreichbare Mailserver müssen neben einer # TLS-geschützen Übertragung auch PLAIN-TEXT Übertragungen zulassen! # default: smtpd_tls_security_level = smtpd_tls_security_level = may
verpflichtende Verschlüsselung für alle Clients
Betreibt man ein Mailgateway, welches ausschließlich Nachrichten von dedizierten Mailservern Nachrichten entgegen nimmt, setzt man den Parameter smtpd_tls_security_level=encrypt. Somit wird STARTTLS dem einliefernden SMTP-Clients angeboten und zwingend vorgeschrieben! Diese Einstellung darf gemäß RFC 2487 jedoch ausschliesslich für dedizierte Mailserver erlaubt. Öffentlich erreichbare Mailserver müssen neben einer TLS-geschützen Übertragung auch PLAIN-TEXT Übertragungen zulassen!
# Django : 2014-10-19 - Opportunistische TLS-Verschlüsselung für den # SMTP-Daemon für den ankommenden Verkehr aktiviert; d.h. STARTTLS # wird dem Remote-SMTP-Client angeboten aber nicht zwingend # vorgeschrieben. # http://www.postfix.org/postconf.5.html#smtpd_tls_security_level # # Folgende Verschlüsselungsvarianten sind einstellbar: # none: TLS wird nicht genutzt; d.h. die Übertragung werden nicht ver- # schlüsselt! # # may : Opportunistische TLS Verschlüsselung: Einliefernden SMTP-Clients # wird STARTTLS angeboten, aber nicht zwingend vorgeschrieben. Der # Client bestimmt dann ob verschlüsselt gesprochen werden soll, # oder nicht. # # encrypt: Vorgeschriebene TLS Verschlüsselung: Einliefernden SMTP-Clients # wird STARTTLS angeboten und zwingend vorgeschrieben! Diese # Einstellung ist aber gemäß RFC 2487 nur für dedizierte Mailserver # zu wählen. Öffentlich erreichbare Mailserver müssen neben einer # TLS-geschützen Übertragung auch PLAIN-TEXT Übertragungen zulassen! # default: smtpd_tls_security_level = smtpd_tls_security_level = encrypt
verpflichtende Verschlüsselung nur für ausgewählte Clients
Betreiben wir einen Mailserver, der Nachrichten aus dem Internet empfangen soll, werden in aller Regel die Option smtpd_tls_security_level = may15) wählen, damit auch Server, die warum auch immer kein TLS sprechen können, eine Chance haben Nachrichten zustellen zu können.
Sehr wohl gibt es aber meist Kommunikationspartner, denen wir eine besondere Vertrauensstellung einräumen wollen oder gar müssen. Es gilt also die Devise, opportunistische Verschlüsselung jedem anbieten, der eine Nachricht bei uns abliefern möchte. Jedoch soll von einen oder mehreren Partnern eine verpflichtende Verschlüsselung zwingend vorgeschrieben werden, wenn diese eMails bei unserem MTA abliefern wollen.
Wir setzen also die Option smtpd_tls_security_level = may damit unser SMTP-Daemon allen TLS anbietet, die nach dieser Eigenschaft fragen bzw. die mit dem SMTP-Kommando STARTTLS einen transportverschlüsselten Kanal aufbauen wollen.
# Django : 2014-10-19 - Opportunistische TLS-Verschlüsselung für den # SMTP-Daemon für den ankommenden Verkehr aktiviert; d.h. STARTTLS # wird dem Remote-SMTP-Client angeboten aber nicht zwingend # vorgeschrieben. # http://www.postfix.org/postconf.5.html#smtpd_tls_security_level # # Folgende Verschlüsselungsvarianten sind einstellbar: # none: TLS wird nicht genutzt; d.h. die Übertragung werden nicht ver- # schlüsselt! # # may : Opportunistische TLS Verschlüsselung: Einliefernden SMTP-Clients # wird STARTTLS angeboten, aber nicht zwingend vorgeschrieben. Der # Client bestimmt dann ob verschlüsselt gesprochen werden soll, # oder nicht. # # encrypt: Vorgeschriebene TLS Verschlüsselung: Einliefernden SMTP-Clients # wird STARTTLS angeboten und zwingend vorgeschrieben! Diese # Einstellung ist aber gemäß RFC 2487 nur für dedizierte Mailserver # zu wählen. Öffentlich erreichbare Mailserver müssen neben einer # TLS-geschützen Übertragung auch PLAIN-TEXT Übertragungen zulassen! # default: smtpd_tls_security_level = smtpd_tls_security_level = may
Bei der Konfiguration unseres MTAs Postfix 2.11 unter CentOS7 haben wir in der Sektion SMTP Recipient Restrictions mehrere access-Tabellen zum White-/Blacklisten von Sendern und Empfängern angelegt.
In der Lookup-Tabelle sender_access werden wir all diejenigen Quellen aufnehmen, von denen wir nur eMails annehmen wollen, wenn die Übertragung mittels STARTTLS initiiert worden ist. Somit gilt für ausgewählte Kommunikationspartner eine verpflichtende und für alle anderen eine opportunistische Verschlüsselung.
# vim /etc/postfix/access_sender
- /etc/postfix/access_sender
# Django : 2012-02-06 # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht? # Tabelle zum black- und whitelisten einzelner Absender auf Basis ihrer # eMail-Adresse. Nach dem Ändern und/oder Erweitern der Tabelle, muß noch # mittels: # $ postmap /etc/postfix/access_sender # # die zugehörige Datenbank erzeugt werden. # sys4.de reject_plaintext_session
Anschließend erstellen wir die zugehörige db-Datei mit folgendem Aufruf.
# postmap /etc/postfix/access_sender
Testmail mit STARTTLS
Als erstes Testen wir nun, ob von der betreffenden Domain aus noch eMail eingeliefert werden können. Der Einfachheit halber nutzen wir hierzu das Swiss Army Knife for SMTP von John Jetmore.
# swaks --to django@nausch.org --from p@sys4.de --header-X-Test "Test-eMail" --server mx01.nausch.org --port 25 --tls --header "Subject: Test zur verpflichtenden TLS-Verschlüsselung auf Port 25".
=== Trying mx01.nausch.org:25... === Connected to mx01.nausch.org. <- 220 mx01.nausch.org ESMTP Postfix -> EHLO mail.sys4.de <- 250-mx01.nausch.org <- 250-PIPELINING <- 250-SIZE 52428800 <- 250-ETRN <- 250-STARTTLS <- 250-ENHANCEDSTATUSCODES <- 250 8BITMIME -> STARTTLS <- 220 2.0.0 Ready to start TLS === TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 === TLS no local certificate set === TLS peer DN="/serialNumber=3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP/OU=GT49447951/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.nausch.org" ~> EHLO p@sys4.de <~ 250-mx01.nausch.org <~ 250-PIPELINING <~ 250-SIZE 52428800 <~ 250-ETRN <~ 250-ENHANCEDSTATUSCODES <~ 250 8BITMIME ~> MAIL FROM:<p@sys4.de> <~ 250 2.1.0 Ok ~> RCPT TO:<django@nausch.org> <~ 250 2.1.5 Ok ~> DATA <~ 354 End data with <CR><LF>.<CR><LF> ~> Date: Fri, 09 Oct 2015 15:24:46 +0200 ~> To: django@nausch.org ~> From: p@sys4.de ~> Subject: Test zur verpflichtenden Verschlüsselung auf Port 25 ~> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/ ~> X-Test: Test-eMail ~> ~> This is a test mailing ~> ~> . <~ 250 2.0.0 Ok: queued as 80149C00093 ~> QUIT <~ 221 2.0.0 Bye === Connection closed with remote host.
Die Nachricht wurde also wie erwartet angenommen und zugestellt, den zugehörigen Eintrag dazu finden wir im Maillog unseres Servers.
# less /var/log/maillog
Oct 9 15:24:52 vml000087 postfix/smtpd[25034]: Anonymous TLS connection established from mail.sys4.de[194.126.158.132]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 9 15:24:52 vml000087 postfix/smtpd[25034]: 80149C00093: client=mail.sys4.de[194.126.158.132]
Oct 9 15:24:52 vml000087 postfix/cleanup[26483]: 80149C00093: message-id=<>
Oct 9 15:24:53 vml000087 postfix/qmgr[4468]: 80149C00093: from=<p@sys4.de>, size=597, nrcpt=1 (queue active)
Oct 9 15:24:53 vml000087 postfix/smtpd[25034]: disconnect from mail.sys4.de[194.126.158.132]
Oct 9 15:24:53 vml000087 postfix/lmtp[23271]: 80149C00093: to=<django@nausch.org>, relay=10.0.0.77[10.0.0.77]:24, delay=1.2, delays=0.99/0/0.07/0.15, dsn=2.0.0, status=sent (250 2.0.0 <django@nausch.org> 7VEcCTe7F1Y4eQAArK2B9Q Saved)
Oct 9 15:24:53 vml000087 postfix/qmgr[4468]: 80149C00093: removed
Ob nun die Übertragung von eMail von der Domäne sys4.de unterbunden wird, wenn keine TLS-Verschlüsselung zu Stande kommt, werden wir nun als nächstes testen. Hierzu verwenden wir, wie zuvor auch schon das Programm swaks aber diesesmal ohne den Parameter --tls.
# swaks --to django@nausch.org --from p@sys4.de --header-X-Test "Test-eMail" --server mx01.nausch.org --port 25 --header "Subject: Test ohne verpflichtenden TLS-Verschlüsselung auf Port 25".
=== Trying mx01.nausch.org:25... === Connected to mx01.nausch.org. <- 220 mx01.nausch.org ESMTP Postfix -> EHLO mail.sys4.de <- 250-mx01.nausch.org <- 250-PIPELINING <- 250-SIZE 52428800 <- 250-ETRN <- 250-STARTTLS <- 250-ENHANCEDSTATUSCODES <- 250 8BITMIME -> MAIL FROM:<p@sys4.de> <- 250 2.1.0 Ok -> RCPT TO:<django@nausch.org> <** 571 5.7.1 Session encryption is required. Contact your postmaster/admin for technical assistance. He can achieve our postmaster via email: postmaster@nausch.org or via fax: +49 8121 883179. In any case, please provide the following information in your problem report: This error message, time (Oct 12 10:33:16), client (194.126.158.132) and server (mx01.nausch.org). -> QUIT <- 221 2.0.0 Bye === Connection closed with remote host.
Wie erwartet wird die Annahme der Nachricht von unserem Mailserver geblockt, da wir ja definiert hatten, dass Nachrichten von sys4.de nur noch angenommen werden, wenn eine TLS-Verschlüsselung (verpflichtend!) zu Stande kam„! Der Zustellversuch wurde mit einem temporären Fehler 450 4.7.1 Session encryption is required; abgelehnt
Im Maillog unseres MX wird dies natürlich entsprechend dokumentiert.
Oct 9 13:26:48 vml000087 postfix/smtpd[1413]: connect from mail.sys4.de[194.126.158.132] Oct 9 13:27:21 vml000087 postfix/smtpd[1413]: NOQUEUE: reject: RCPT from mail.sys4.de[194.126.158.132]: 450 4.7.1 Session encryption is required; from=<p@sys4.de> to=<django@nausch.org> proto=SMTP helo=<mail.sys4.de> Oct 9 13:27:27 vml000087 postfix/smtpd[1413]: disconnect from mail.sys4.de[194.126.158.132]
Da es sich aber um ein erwünschtes Ergebnis unserer Konfigurationsbemühungen handelt handelt, werden einen 500er Fehlercode ausgeben, damit der einliefernde Client sofort über das Ergebnis informiert wird. Hierzu passen wir den betreffenden plaintext_reject_code = 571 in der Sektion RÜCKMELDUNGEN BEEINFLUSSEN UND INDIVIDUALISIEREN unserer /etc/postfix/main.cf an. Zum Aktivieren führen wir nun noch einen Reload unseres SMTP-Daemons durch.
# systemctl restart postfix.service
Anschließend versuchen wir erneut eine Nachricht ohne STARTTLS einzuliefern.
# swaks --to django@nausch.org --from p@sys4.de --header-X-Test "Test-eMail" --server mx01.nausch.org --port 25 --header "Subject: Test ohne verpflichtenden TLS-Verschlüsselung auf Port 25".
=== Trying mx01.nausch.org:25... === Connected to mx01.nausch.org. <- 220 mx01.nausch.org ESMTP Postfix -> EHLO mail.sys4.de <- 250-mx01.nausch.org <- 250-PIPELINING <- 250-SIZE 52428800 <- 250-ETRN <- 250-STARTTLS <- 250-ENHANCEDSTATUSCODES <- 250 8BITMIME -> MAIL FROM:<p@sys4.de> <- 250 2.1.0 Ok -> RCPT TO:<django@nausch.org> <** 571 5.7.1 Session encryption is required. Contact your postmaster/admin for technical assistance. He can achieve our postmaster via email: postmaster@nausch.org or via fax: +49 8121 883179. In any case, please provide the following information in your problem report: This error message, time (Oct 12 10:44:38), client (194.126.158.132) and server (mx01.nausch.org). -> QUIT <- 221 2.0.0 Bye === Connection closed with remote host.
Auch dieser Zustellversuch wird im Maillog vermerkt, dieses mal aber mit dem Fehlercode 571 5.7.1 Session encryption is required.
Oct 9 13:38:08 vml000087 postfix/smtpd[4495]: connect from mail.sys4.de[194.126.158.132] Oct 9 13:38:27 vml000087 postfix/smtpd[4495]: NOQUEUE: reject: RCPT from mail.sys4.de[194.126.158.132]: 571 5.7.1 Session encryption is required; from=<p@sys4.de> to=<django@nausch.org> proto=SMTP helo=<mail.sys4.de> Oct 9 13:38:30 vml000087 postfix/smtpd[4495]: disconnect from mail.sys4.de[194.126.158.132]
Verschlüsselung beim SMTP-Client
Mit der Option smtp_tls_security_level beeinflusst man das SMTP TLS Verhalten des Postfix SMTP Clients, also dem ausgehenden Mailverkehr. Folgende Verschlüsselungsvarianten sind einstellbar:
- none: TLS-Verschlüsselung wird nicht genutzt, es sei denn für bestimmte Ziele wird mit der Option smtp_tls_policy_maps eine anderweitige Regelung getroffen.
- may: Opportunistische TLS-Verschlüsselung wird verwendet, sofern der Zielserver eine TLS-Verschlüsselung anbietet. Unterstützt der Zielserver keine TLS-Verschlüsselung wird unverschlüsselt übertragen!
- encrypt: Vorgeschriebene TLS-Verschlüsselung. Um ein Mindestmaß an Sicherheit garantieren zu können, kann mit der Option smtp_tls_mandatory_ciphers die mindestens zu unterstützenden Chiffren und mit der Option smtp_tls_mandatory_protocols die zu unterstützenden Protokolle definiert werden. Diese gelten dann für diese TLS-Sicherheitssufe und entsprechend höhere. Diese Option darf nicht für einen öffentlich erreichbaren und agierenden Mailserver verwendet werden.
- dane: Opportunistisches DANE TLS. Bei dieser Sicherheitsstufe wird die TLS Policy des Ziels via DNSSEC ermittelt. Hierzu ist es notwendig, dass die DNS-Zone der Zieldomäne digital signiert ist und der Host, auf dem der Postfix SMTP-Client läuft, die signierten DNS-Antorten überprüfen kann. Jede MX-Host-DNS-Zone sollte darüber hinaus auch signiert sein und sollte entsprechende DANE TLSA (RFC 6698) Records mit den Informationen zur Validierung des TLS Zertifikates zur Verfügung stellen.
Wird kein DNSSEC-validierter TLSA Datensatz ermittelt werden kann, wird als Fallback die Sicherheitsstufe may verwendet. Wurden zwar TLSA Records gefunden, diese aber nicht brauchbar sein sollten, wird die Sicherheitsstufe encrypt verwendet. - dane-only: Verpflichtenes DANE TLS, bei dem DANE TLSA Authentifizierung als zwingend vorgeschrieben ist. Bei dieser Sicherheitsoption gibt es keinen Fallback zu “may„ oder “encrypt„ für den Fall dass TLSA Records fehlen, fehlerhaft als unbrauchbar sind!
- fingerprint: Fingerabdrucküberprüfung der Zertifikate. Bei dieser Option gibt es weder eine Prüfung der Zertifikatskette, der Zertifikatsgültigkeit, von vertrauenswürdigen Zertifizierungsstellen oder anderem. Stattdessen wird der Fingerabruck des Zertifikates bzw. der öffentliche Schlüssel des Serverzertifikates überprüft. Der hierzu nötige Hash-Algorithmus wird abhängig von der Option smtp_tls_fingerprint_cert gebildet.
- verify: Vorgeschriebene TLS Überprüfung. Bei dieser Sicherheitsstufe wird der Name des Serverzertifikates mit dem Ergebnis der DNS MX Abfrage verglichen und vertraut. Der Parameter smtp_tls_verify_cert_match definiert, wie der Name des Servers überprüft wird.
- secure: Secure-Channel TLS Bei dieser Sicherheitsstufe wird das Ergebnis der DNS MX Abfrage nicht als hinreichend sicher betrachtet umd damit eine TLS Peername Überprüfung durchzuführen. Stattdessen wird der Standardname des Serverzertifikates, abhängig von der smtp_tls_secure_cert_match Option, geprüft, ob dieser mit dem (Sub-)Domain-Namen des Zielservers entspricht.
opportunistische Verschlüsselung
Soll der SMTP-Client vor dem Übertragen der Nachrichten eine angebotene TLS-Verschlüsselung nutzen, aber beim Nichtzustandekommen des TLS-Handshakes die Nachricht unverschlüsselt übertragen, setzt man den Parameter smtp_tls_security_level=may. Somit obliegt es dem SMTP-Client ob dieser mit einem STARTTLS die TLS-Verschlüsselung initiiert, oder nicht. Haben wir einen Mailserver, der auch Nachrichten an beliebige Mailserver im Internet senden soll, kann man dieses „best practices“ Verfahren wählen
# Django : 2014-10-19 - Opportunistische TLS-Verschlüsselung für den # Opportunistische TLS-Verschlüsselung wird verwendet, sofern der # Zielserver eine TLS-Verschlüsselung anbietet. Unterstützt der # Zielserver keine TLS-Verschlüsselung wird unverschlüsselt über- # tragen! # http://www.postfix.org/postconf.5.html#smtp_tls_security_level # default: smtp_tls_security_level = smtp_tls_security_level = may
verpflichtende Verschlüsselung zu allen Empfängern/Servern
Betreibt man ein Mailgateway in einer kundeneigenen Infrastruktur, bei dem alle Kommunikationspartner bekannt sind, wird man Nachrichten nur austauschen wollen, wenn eine entsprechend gesicherte Verbindung etabliert werden konnte. Hier können wir folgende smtp_tls_security_level Optionen nutzen:
- encrypt: Vorgeschriebene TLS-Verschlüsselung. Um ein Mindestmaß an Sicherheit garantieren zu können, kann mit der Option smtp_tls_mandatory_ciphers die mindestens zu unterstützenden Chiffren und mit der Option smtp_tls_mandatory_protocols die zu unterstützenden Protokolle definiert werden. Diese gelten dann für diese TLS-Sicherheitssufe und entsprechend höhere. Diese Option darf nicht für einen öffentlich erreichbaren und agierenden Mailserver verwendet werden.
- dane-only: Verpflichtenes DANE TLS, bei dem DANE TLSA Authentifizierung als zwingend vorgeschrieben ist. Bei dieser Sicherheitsoption gibt es keinen Fallback zu “may„ oder “encrypt„ für den Fall dass TLSA Records fehlen, fehlerhaft als unbrauchbar sind!
- verify: Vorgeschriebene TLS Überprüfung. Bei dieser Sicherheitsstufe wird der Name des Serverzertifikates mit dem Ergebnis der DNS MX Abfrage verglichen und vertraut. Der Parameter smtp_tls_verify_cert_match definiert, wie der Name des Servers überprüft wird.
- secure: Secure-Channel TLS Bei dieser Sicherheitsstufe wird das Ergebnis der DNS MX Abfrage nicht als hinreichend sicher betrachtet und damit eine TLS Peername Überprüfung durchzuführen. Stattdessen wird der Standardname des Serverzertifikates, abhängig von der smtp_tls_secure_cert_match Option, geprüft, ob dieser mit dem (Sub-)Domain-Namen des Zielservers entspricht.
Betreiben wir aber einen Mailserver, der letztendlich zu vielen wenn nicht gar allen Mailservern im Internet Nachrichten zustellen muss, werden wir nicht generell eine verpflichtende TLS-Verschlüsselung zu allen Zielen vorschreiben können! Über die smtp_tls_policy_maps können wir jedoch gezielt für einzelne Ziele feingranular festlegen, welche Kriterien für eine verpflichtende TLS-Verschlüsselung herangezogen werden sollen.
verpflichtende Verschlüsselung zu ausgewählten Empfängern/Servern
An Hand eines Praxis-Beispiel wollen wir nun die Zielpunkt abhängige verpflichtende Verschlüsselung genauer betrachten. Unser Mailserver soll Nachrichten nur an die Zieldomäne tachtler.net übertragen, wenn eine TLS-Verschlüsselung überprüfbar zum zugehörigen Mailserver etabliert werden konnte. Als Kriterium ob wir nun wirklich mit dem Zielserver mx1.tachtler.net sprechen, werden wir dabei den SHA1 Fingerprint des Serverzertifikates von mx1.tachtler.net verwenden! openssl s_client -starttls smtp -connect mx1.tachtler.net:25 < /dev/null 2>/dev/null | openssl x509 -noout -fingerprint Als ersten Schritt holen wir uns das Serverzertifikat und errechnen den zugehörigen Fingerprint mit nachfolgendem Befehl.
# openssl s_client -starttls smtp -connect mx1.tachtler.net:25 < /dev/null 2>/dev/null | openssl x509 -noout -fingerprint
SHA1 Fingerprint=C3:17:BB:DC:7F:E3:51:F6:3E:48:E7:4F:5A:48:48:6C:94:24:63:0E
Den erhaltenen Fingerprint C3:17:BB:DC:7F:E3:51:F6:3E:48:E7:4F:5A:48:48:6C:94:24:63:0E lassen wir uns nun vom Postmaster des Zielmailservers bestätigen. Hierzu wählen wir ein anderes Übertragungsmedium wie z.B. Telefon oder Faksimile.
Keinesfalls vermerken wir ohne weitere Prüfung den Fingerprints in einer lokalen Konfigurationsdatei!
Den verifizierten Fingerprint hinterlegen wir nun in einer eigenen Konfigurationsdatei smtp_tls_policy_maps die wir anschliessend unserem Postfix-Mailserver bekannt geben.
Zunächst legen wir uns die benötigte Konfigurationsdatei an.
# vim /etc/postfix/smtp_tls_policy_maps
- /etc/postfix/smtp_tls_policy_maps
# Django : 2015-10-07 - Empfängerbasierte verpflichtende TLS-Verschlüsselung # Tabelle für die zielwegorientierte individuelle Vorgabe einer # verpflichtenden TLS-Transportverschlüsselung einzelner Zieldomains. # http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps # # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels: # # $ postmap /etc/postfix/smtp_tls_policy_maps # # die zugehörige Datenbank erzeugt werden. # Zieldomain smtp_tls_security_level optionale Parameter tachtler.net fingerprint match=C3:17:BB:DC:7F:E3:51:F6:3E:48:E7:4F:5A:48:48:6C:94:24:63:0E
Wie in der Konfigurationsdatei angegeben erstellen wir nun noch die benötigte Datenbank-Datei.
# postmap /etc/postfix/smtp_tls_policy_maps
Damit nun der SMTP-Client weiss wie er den richtigen Fingerprint (MD5 oder SHA1) des empfangenen Server-Zertifikates ermitteln soll, müssen wir den verwendeten Hash-Algorithmus unserem Server noch vorgeben. Dies tragen wir in der Sektion TLS/SSL-VERSCHLÜSSELUNG unserer Postfixinstallation ein.
# vim /etc/postfix/main.cf
################################################################################ ## TLS/SSL-VERSCHLÜSSELUNG # ... # Django : 2015-10-07 - Hashfunktion für den Fingerprint der Zertifikate # Empfängt der SMTP-Client ein Serverzertifikat, kann er zur # Prüfung, ob er mit dem richtigen Zielserver verbunden ist, # den Zertifikatsfingerprint ermitteln. # default: smtp_tls_fingerprint_digest = md5 smtp_tls_fingerprint_digest = sha1 # Django : 2015-10-07 - Zielorientierte SMTP TLS Policies # Nutzung einer Tabelle für die zielwegorientierte individuelle # Vorgabe einer verpflichtenden TLS-Transportverschlüsselung # einzelner Zieldomains. # smtp_tls_security_level eine individuelle Tabelle für die # http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps # default: smtp_tls_policy_maps = smtp_tls_policy_maps = btree:/etc/postfix/smtp_tls_policy_maps ...
Zur Aktivierung der Konfiguration führen wir noch einen Reload des Daemon durch.
# systemctl reload postfix.service
Unser Mailserver wir nun Nachrichten nur noch beim Zielsystem mx1.tachtler.net abliefern, wenn der Fingerprint des empfangenen Serverzertifikates dem entspricht, der in der Datei /etc/postfix/smtp_tls_policy_maps vermerkt wurde.
Zum Testen unserer Konfigurationsänderung tragen wir einfach kurz einen falschen Fingerprint der Zieldomain ein und beobachten unser maillog.
# tailf /var/log/maillog
Oct 12 14:59:42 vml000087 postfix/submission/smtpd[17446]: connect from ppp-93-104-85-187.dynamic.mnet-online.de[93.104.85.187] Oct 12 14:59:43 vml000087 postfix/submission/smtpd[17446]: Anonymous TLS connection established from ppp-93-104-85-187.dynamic.mnet-online.de[93.104.85.187]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Oct 12 14:59:43 vml000087 postfix/submission/smtpd[17446]: 9BE5BC00090: client=ppp-93-104-85-187.dynamic.mnet-online.de[93.104.85.187], sasl_method=PLAIN, sasl_username=django@nausch.org Oct 12 14:59:43 vml000087 postfix/cleanup[17451]: 9BE5BC00090: message-id=<561BAEBE.5070208@nausch.org> Oct 12 14:59:43 vml000087 postfix/qmgr[17413]: 9BE5BC00090: from=<michael@nausch.org>, size=865, nrcpt=1 (queue active) Oct 12 14:59:44 vml000087 postfix/submission/smtpd[17446]: disconnect from ppp-93-104-85-187.dynamic.mnet-online.de[93.104.85.187] Oct 12 14:59:44 vml000087 postfix/smtpd[18113]: connect from vml000067.dmz.nausch.org[10.0.0.67] Oct 12 14:59:44 vml000087 postfix/smtpd[18113]: CC17DC00092: client=vml000067.dmz.nausch.org[10.0.0.67], orig_client=unknown[10.0.0.87] Oct 12 14:59:44 vml000087 postfix/cleanup[17649]: CC17DC00092: message-id=<561BAEBE.5070208@nausch.org> Oct 12 14:59:44 vml000087 postfix/qmgr[17413]: CC17DC00092: from=<michael@nausch.org>, size=2381, nrcpt=1 (queue active) Oct 12 14:59:44 vml000087 postfix/smtp[20834]: 9BE5BC00090: to=<klaus@tachtler.net>, relay=10.0.0.67[10.0.0.67]:10024, delay=1.3, delays=0.3/0/0.01/1, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[10.0.0.87]:10025): 250 2.0.0 Ok: queued as CC17DC00092) Oct 12 14:59:44 vml000087 postfix/qmgr[17413]: 9BE5BC00090: removed Oct 12 14:59:45 vml000087 postfix/smtp[20834]: Trusted TLS connection established to mx1.tachtler.net[88.217.171.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Oct 12 14:59:45 vml000087 postfix/smtp[20834]: CC17DC00092: to=<klaus@tachtler.net>, relay=mx1.tachtler.net[88.217.171.167]:25, delay=0.77, delays=0.06/0.01/0.7/0, dsn=4.7.5, status=deferred (Server certificate not verified)
Wir sehen in dem Beispiel die Einlieferung einer Nachricht via submission Port 587, gefolgt vom Verbindungsaufbau des SMTP-Clients in Richtung mx1.tachtler.net[88.217.171.167]:25.
Wurde das Zertifikat ausgetauscht ohne dem versendenden Kommunikationspartner zu informieren, scheitert die verschlüsselte und verifizierte Verbindung, da die Überprüfung des Fingerprints kein positives Ergebnis mehr bringen kann:
Oct 1 19:02:56 vml000087 postfix/smtp[2818]: Trusted TLS connection established to mx1.tachtler.net[88.217.171.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 1 19:02:56 vml000087 postfix/smtp[2818]: DEA87C0008A: to=<klaus@tachtler.net>, relay=mx1.tachtler.net[88.217.171.167]:25, delay=88445, delays=88437/0.04/8.5/0, dsn=4.7.5, status=deferred (Server certificate not verified)
Die Nachricht wird also nicht versandt, da nicht sichergestellt werden kann, dass wir auch wirklich mit dem richtigen Empfangssystem reden. Statt dessen wir die Nachricht in die deffered-Queue eingestellt! Am besten überwacht man daher das maillog mit Hilfe einer gängigen Monitoring-Lösung wie graylog oder icinga 2.
An Hand dieses Beispiels kann man also zielwegorientiert eine verpflichtende Verschlüsselung zur Übertragung definieren. In Verbindung mit der verpflichtenden Verschlüsselung beim SMTP-Dämon des Empfängers, können wir so sicherstellen, dass sensible Daten nicht nur TLS-gesichert sondern auch mit dem verifizierten Ziel ausgetauscht werden!
Hat man viele dieser Ziele, kann das manuelle Pflegen von Fingerprints zum zeitaufwändigen Unterfangen werden. Zumal bei anstehenden Zertifikatsänderungen rechtzeitig dafür gesorgt werden muss, dass das sendende System die neuen Fingerprints auch kennt. Beispiele aus der Praxis zeigen leider, dass viele professionelle Dienstleister und auch entsprechend versierte und geschulte Postmaster hier grosse Schwierigkeiten beim Ablauf und rechtzeitigen Erneuerung der Fingerprints haben.
Wesentlich einfacher ist hier die Nutzung einer verpflichtenden Verschlüsselung unter Zuhilfenahme der Option dane-only.
"DANE" & TLS
Haben wir einen DNSSEC fähigen Resolver wie z.B. unbound oder bind können wir für die Überprüfung des Serverzertifikates bei ausgehenden Verbindungen den TLSA-Eintrag des Zielmailservers abfragen. Somit können wird überprüfen ob wie auch wirklich beim gewünschten Ziel angelangt sind, oder ob uns ein unbekannter Dritter vorgaukelt der Zielmailserver zu sein.
Mit Hilfe der Postfix Konfigurationsparameter smtp_tls_policy_maps oder smtp_tls_security_level können wir Festlegung ob eine DANE/TLSA-Überprüfung für alle Ziele optional, also opportunistisch, oder verpflichtend für alles bzw. einzelne Systeme gezielt gelten soll.
Egal ob nun opportunistisch oder verpflichtend, müssen wir unserem Postfix-Client angeben, ob der DNSSEC-Anfragen stellen soll, oder nicht. Bei beiden Varianten setzen wir den Parameter smtp_dns_support_level in unserer /etc/postfix/main.cf in der Sektion TLS/SSL-VERSCHLÜSSELUNG.
# vim /etc/postfix/main.cf
################################################################################ ## TLS/SSL-VERSCHLÜSSELUNG # ... # Django : 2015-02-04 - DNS-Support des Postfix SMTP-Client # Wird der Parameter smtp_dns_support_level auf seinem Defaultwert # belassen, wird der SMTP-Client abhängig vom Parameter # disable_dns_lookups, DNS-Abfragen vornehmen oder dies unterlassen. # Folgende Werte können bei smtp_dns_support_level gesetzt werden: # - disabled : Es werden keinerlei DNS-Abfragen vom Client vorge- # genommen. Der Client benutzt lediglich die konfigu- # rierten IP-Adressen verwendet # # - enabled : Der Client führt DNS-Anfragen zur Ermittlung der # zugehörigen IP-Adressen verwendet. Bei Namen, die # nicht von []-Klöammern eingeschlossen sind, wird # nicht der zugehörige A-Record angefragt, sondern # der MX-Record # # - dnssec : Anfragen an den DNS-Resolver werden als dnssec-An- # fragen gestellt und die Rückgabewerte entsprechend # erwartet. Der Parameterwert dnssec ist nur bei # gleichzeitiger TLS-Sicherheitsstoufe "dane" bzw. # "dane-only" zu setzen. Für "normale" anfragen # ergibt sich bei Verwendung des Parameters "dnssec" # keine zusätzliche Sicherheit im Sinne von Postfix. # default: smtp_dns_support_level = smtp_dns_support_level = dnssec # Django : 2015-02-04 - Opportunistische DANE TLS-Verschlüsselung für den # SMTP-Client für den ausgehenden Verkehr aktiviert; Bei diesem # Sicherhietslevel wird versucht die TLS Sicherheitsvorgaben via # DNSsec zu erfragen. # default: smtp_tls_security_level = # last : smtp_tls_security_level = may smtp_tls_security_level = dane ...
Wollen wir für bestimmte Kommunikationspartner definieren, dass Nachrichten nur versandt werden dürfen, wenn der Wert des TLSA-Records dem entspricht, den unser Client vom zur Verfügung gestellten Serverzertifikats ermittelt hat, greifen wir wieder auf die smtp_tls_policy_maps zurück.
In folgendem Beispiel, wird für den Kommunikationspartner tachtler.net „nur“ der Fingerprint des Serverzertifikats überprüft. Nachrichten an die Domäne sys4.de werden hingegen nur übertragen, wenn das Serverzertifikat dem des TLSA-Records entspricht.
# vim /etc/postfix/smtp_tls_policy_maps
- /etc/postfix/smtp_tls_policy_maps
# Django : 2015-10-07 - Empfängerbasierte verpflichtende TLS-Verschlüsselung # Tabelle für die zielwegorientierte individuelle Vorgabe einer # verpflichtenden TLS-Transportverschlüsselung einzelner Zieldomains. # http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps # # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels: # # $ postmap /etc/postfix/smtp_tls_policy_maps # # die zugehörige Datenbank erzeugt werden. # Zieldomain smtp_tls_security_level optionale Parameter tachtler.net fingerprint match=C3:17:BB:DC:7F:E3:51:F6:3E:48:E7:4F:5A:48:48:6C:94:24:63:0E sys4.de dane-only
Vor der Aktivierung einer Konfigurationsänderung musss noch die zugehörige db_Datei der lookup- Tabelle smtp_tls_policy_maps.
# postmap /etc/postfix/smtp_tls_policy_maps
Nun aktivieren wir noch die Änderungen an unserer main.cf.
# systemctl restart postfix.service
Wir nun eine Nachricht an den Zielserver gesendet, für die wir einen smtp_tls_security_level = dane-only definiert haben, wird der Zertifikats-Fingerprint via DNSSEC-Anfrage geholt und mit dem Wert verglichen, den der SMTP-Client vom empfangenen Server-Zertifikat ermitelt hat. Sind beide Fingerprints gleich, wird unser MTA mit der Üertragung der Nachricht(en) fortfahren. Im Maillog unseres Servers wird dies entsprehend positiv vermerkt.
Oct 13 09:53:36 vml000087 postfix/smtp[18312]: connect to mail.sys4.de[194.126.158.132]:25
Oct 13 09:53:36 vml000087 postfix/smtp[18312]: Verified TLS connection established to mail.sys4.de[194.126.158.132]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 13 09:53:37 vml000087 postfix/smtp[18312]: 17D5FC00097: to=<p@sys4.de>, relay=mail.sys4.de[194.126.158.132]:25, delay=1.8, delays=0.05/0.02/0.71/1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3nZpz5107tz1G7x)
Oct 13 09:53:37 vml000087 postfix/qmgr[18157]: 17D5FC00097: removed
Unterscheiden sich aber beide Fingerprints wird die Kommunikation mit dem Zielsystem abgebrochen und die Nachricht in die deffered-Queue gestellt und ggf. später wieder versucht die eMail zuzustellen.
Oct 13 12:32:22 mailslut1 postfix/smtp[27804]: Trusted TLS connection established to mx01.nausch.org[217.91.103.190]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 13 12:32:22 mailslut1 postfix/smtp[27804]: 1945C180008B: to=<django@nausch.org>, relay=mx01.nausch.org[217.91.103.190]:25, delay=56, delays=55/0.04/1.2/0, dsn=4.7.5, status=deferred (Server certificate not verified)
Perfect Forward Secrecy
Zur Aktivierung von PFS16) sind nachfolgende Optionen von entscheidender Bedeutung.
- Ephemeral-Diffie-Hellmann Schlüssel: Unsere bereits generierten Diffie Hellmann Schlüssel binden wir nun in unserer Postfix-Konfigurationsdatei ein.
# Django : 2014-10-19 - EDH Server support # http://www.postfix.org/FORWARD_SECRECY_README.html # Definition des 512 bit Schlüssels (export ciphers) für die obsoleten # „Export“-Ciphers und des 2048-bit (non export ciphers) Schlüssels # für all die anderen EDH Cipher Suits. # default: smtpd_tls_dh512_param_file = # smtpd_tls_dh1024_param_file = smtpd_tls_dh1024_param_file = /etc/pki/postfix/private/dh_4096.pem smtpd_tls_dh512_param_file = /etc/pki/postfix/private/dh_512.pem
- „Ephemeral Elliptic Curve Diffie-Hellman“ Schlüsselaustausch: Definition des Grads der Sicherheit beim EECDH Schlüsselaustausch
# Django : 2014-10-19 - Grad der Sicherheit beim EECDH Schlüsselaustausch # Ephemeral Elliptic-Curve Diffie-Hellman (EECDH) # http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade # default: smtpd_tls_eecdh_grade = strong smtpd_tls_eecdh_grade = ultra
- Präferierter standardisierter kryptographischer Algorithmus: Statt der vom Client gewünschte Cipher, wird die Default Cipher Liste des Servers verwendet.
# Django : 2014-10-19 - Default Cipher Liste des Servers verwenden, statt der # vom Client genannten Wunsch-Ciphers # http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist # default: tls_preempt_cipherlist = no tls_preempt_cipherlist = yes
TLS Logging
Informationen im Mailheader zur Verschlüsselung
Unser MTA kann mit der Option smtpd_tls_received_header im Mailheader der Nachricht folgende Daten vermerken:
- Protocol
- Cipher
- SMTP Client CommonName
- Client Certificate Issuer CommonName
# Django : 2014-10-19 - Headerzeile in der eMail einfügen mit Informationen # zur verwendeten Verschlüsselung # http://www.postfix.org/postconf.5.html#smtpd_tls_received_header # default: smtpd_tls_received_header = no smtpd_tls_received_header = yes
TLS-Logging beim Mailempfang
Mit Hilfe der Option smtpd_tls_loglevel kann das Logging des SMTP Daemons beeinflusst werden. Bei den einzelnen Loglevel schließt ein höherer Loglevel entsprechend niedrigere jeweils mit ein.
- 0 TLS-Logging deaktiviert (Defaultwert)
- 1 Pro Verbindung wird eine Logzeile mit der Zusammenfassung des TLS Handshakes erzeugt. Sofern die Überprüfung des Client Zertifiaktes nicht gefordert ist, wird keine Fehlermeldung zur Zertifikatskette des Clientzertifikates erzeugt.
- 2 Zusätzlich die TLS Negotiation loggen.
- 3 Zusätzlich einen ASCII Dump und die zugehörigen Hexadecimal-Werte des TLS Negotiation-Prozesses mitloggen.
- 4 Den kompletten Verkehr nach dem STARTTLS als ASCII Dump und die zugehörigen Hexadecimal-Werte mitloggen.
Im Normalbetrieb werden „nur“ die Werte 0 und 1 gesetzt. Loglevel 2 und höher benötigt man nur zur Problembehandlung. Von der Benutzung des Loglefel 4 wird dringend abgeraten!
# Django : 2014-10-19 - Logging der TLS-Infomationen zu den Verbindungen im # Maillog des SMTP-Daemons für den ankommenden SMTP-Verkehr. # http://www.postfix.org/postconf.5.html#smtpd_tls_loglevel # default: smtpd_tls_loglevel = 0 smtpd_tls_loglevel = 1
TLS-Logging beim Mailversand
Mit Hilfe der Option smtp_tls_loglevel kann das Logging des SMTP Clients beeinflusst werden. Bei den einzelnen Loglevel schließt ein höherer Loglevel entsprechend niedrigere jeweils mit ein.
- 0 TLS-Logging deaktiviert (Defaultwert)
- 1 Pro Verbindung wird eine Logzeile mit der Zusammenfassung des TLS Handshakes erzeugt. Sofern die Überprüfung des Client Zertifiaktes nicht gefordert ist, wird keine Fehlermeldung zur Zertifikatskette des Clientzertifikates erzeugt.
- 2 Zusätzlich die TLS Negotiation loggen.
- 3 Zusätzlich einen ASCII Dump und die zugehörigen Hexadecimal-Werte des TLS Negotiation-Prozesses mitloggen.
- 4 Den kompletten Verkehr nach dem STARTTLS als ASCII Dump und die zugehörigen Hexadecimal-Werte mitloggen.
Im Normalbetrieb werden „nur“ die Werte 0 und 1 gesetzt. Loglevel 2 und höher benötigt man nur zur Problembehandlung. Von der Benutzung des Loglefel 4 wird dringend abgeraten!
# Django : 2014-10-19 - Logging der TLS-Infomationen zu den Verbindungen im # Maillog des SMTP-Clients für den ausgehenden SMTP-Verkehr. # http://www.postfix.org/postconf.5.html#smtp_tls_loglevel # default: smtp_tls_loglevel = 0 smtp_tls_loglevel = 1
Konfiguration aktivieren
Zum Aktivieren unserer SSL/TLS-Verschlüsselung starten wir nun unseren Postfix-Daemon einmal durch.
# systemctl restart postfix.service
Postfix Verbindungstests
erster Test
Als erstes kontrollieren wir, ob unser MX nun STARTTLS als ESMTP-Komando anbietet:
# telnet ::1 25
Trying ::1... Connected to ::1. Escape character is '^]'. 220 mx01.nausch.org ESMTP Postfix EHLO foo 250-mx01.nausch.org 250-PIPELINING 250-SIZE 52428800 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME quit 221 2.0.0 Bye Connection closed by foreign host.
Unser Server bietet also nun TLS an; wir sehen dies an der Rückmeldung 250-STARTTLS.
zweiter Verbindungstest
Als nächstes verbinden wir uns unter Einbeziehung von OpenSSL mit unserem Mailserver via telnet auf Port 25:
$ openssl s_client -starttls smtp -connect mx01.nausch.org:25
CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA verify return:1 depth=0 serialNumber = 3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP, OU = GT49447951, OU = See www.rapidssl.com/resources/cps (c)13, OU = Domain Control Validated - RapidSSL(R), CN = *.nausch.org verify return:1 --- Certificate chain 0 s:/serialNumber=3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP/OU=GT49447951/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.nausch.org i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA --- Server certificate -----BEGIN CERTIFICATE----- MIIFKjCCBBKgAwIBAgIDEdPpMA0GCSqGSIb3DQEBCwUAMDwxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew HhcNMTQwNDA4MDMyNTAyWhcNMTYwNjAyMDEzODU0WjCBuzEpMCcGA1UEBRMgM1M3 eDJsY2JZaUFjY0taUG9oYTBNU3dQNWhOc3VTVFAxEzARBgNVBAsTCkdUNDk0NDc5 NTExMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29tL3Jlc291cmNlcy9jcHMg KGMpMTMxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZhbGlkYXRlZCAtIFJhcGlk U1NMKFIpMRUwEwYDVQQDDAwqLm5hdXNjaC5vcmcwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDRhxUen7499yElJr2cOIPdg4u/E93rgFw3DhflaV54r8G3 oA1U+brU7XNpnRVA+QHk1aXTnROwGX46mlxacKOQPE0U9dXMRFrWfnCcOCgUqkjY vQdivwKUOJqfJfef0Zun4C7LabfP/Gb5TkFUC7+Hq3jzoZnifleRuK+2MZXX05/E +T5jKrVsanfh2bN6WKgzwvmPaurpelA1f5ciiaWcuXtTc8Hrshyko30IeyIxAJ2J aj3zHKEjuTMNn/fsMOOFO0LG2T68Wc9gFRa0ds1LXFbuwOxi1i/dLRWDFhGZtplp HOBlYBkwnEawpsHS+nQVEc2d7CFCBWr2MCSQLQQvAgMBAAGjggGzMIIBrzAfBgNV HSMEGDAWgBRraT1qGEJK3Y8CZTn9NSSGeJEWMDAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMCMGA1UdEQQcMBqCDCoubmF1c2No Lm9yZ4IKbmF1c2NoLm9yZzBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vcmFwaWRz c2wtY3JsLmdlb3RydXN0LmNvbS9jcmxzL3JhcGlkc3NsLmNybDAdBgNVHQ4EFgQU HjMj1hUDkcufmSmgDVeMt7sdoAkwDAYDVR0TAQH/BAIwADB4BggrBgEFBQcBAQRs MGowLQYIKwYBBQUHMAGGIWh0dHA6Ly9yYXBpZHNzbC1vY3NwLmdlb3RydXN0LmNv bTA5BggrBgEFBQcwAoYtaHR0cDovL3JhcGlkc3NsLWFpYS5nZW90cnVzdC5jb20v cmFwaWRzc2wuY3J0MEwGA1UdIARFMEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUF BwIBFiVodHRwOi8vd3d3Lmdlb3RydXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqG SIb3DQEBCwUAA4IBAQACZLmO7zRHC4zEXyXCHpIgZ/TIo8sdvGzDH2koZgU0ZlCR psebPpulKDr2Q6JYVPsS6z7sqw9SNCmVjeRngIgCpuih7DGUzrc7YzPw4vmGTgND KTCQ8B3TqjYak3pG3LUUwsSIL1//oSuYKkdClmpNgFgYJegVdXrE3+EjuoLq5wwb xsGzO1KW5olUX7J4IwZbnE5ZRrhF+UIRtj1yPx2fqXOBGuqGdhZ4pTrsY20e6mJJ 4ZOK0RY0MFy1JN3cWAsL5mR3wZwLeUYXnwSHKqWHE0TjJcy5X6sLZP5IoOt61vu1 7Zv1GcT4i3a/8uGGAGINouL3WmdqQ5Uj5qyhceli -----END CERTIFICATE----- subject=/serialNumber=3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP/OU=GT49447951/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.nausch.org issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA --- No client certificate CA names sent Server Temp Key: ECDH, secp384r1, 384 bits --- SSL handshake has read 4057 bytes and written 442 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 73C80E733671FD4E5012E569A1C6B8053DC7CCD7D5BAA7CB824A7608B14E0F87 Session-ID-ctx: Master-Key: 24BA85939899214B7F27361C9BE49B3BA8756F3FCBF6B504346CF4CD17445A26A0F91BF1495B35F632ECDEEAFD8A3F93 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - a1 0e 3f 20 a4 82 fc 58-2e 40 23 06 99 ac 5a d1 ..? ...X.@#...Z. 0010 - 86 06 3a 5c 57 99 91 70-6a df ec ba 04 65 43 a5 ..:\W..pj....eC. 0020 - 45 03 af 61 3d 59 10 f8-eb 6a 94 aa 4c b7 50 82 E..a=Y...j..L.P. 0030 - b6 ca a1 be 4f 10 fa 67-a5 90 fa f9 92 fe 3c 79 ....O..g......<y 0040 - 57 bf 34 22 83 47 db f7-5c 8e fc 5b d5 25 f4 47 W.4".G..\..[.%.G 0050 - 16 cf 5c 05 f9 0d 96 aa-92 9d 11 ff 68 dc 56 3b ..\.........h.V; 0060 - 8e 02 99 79 a1 ba 31 68-38 91 1e 4e 51 94 aa 64 ...y..1h8..NQ..d 0070 - 0a 73 fd 0f b3 e2 74 ab-71 ed ad 2e 5d e8 ac 7c .s....t.q...]..| 0080 - 41 6e d1 2c 7a 28 30 98-b1 33 3b 34 55 34 b4 30 An.,z(0..3;4U4.0 0090 - 23 30 69 4b ac 01 76 5d-5f c9 6a 42 14 0c 05 d8 #0iK..v]_.jB.... Start Time: 1414359330 Timeout : 300 (sec) Verify return code: 0 (ok) --- 250 DSN quit 221 2.0.0 Bye closed
Im obigen Beispiel sehen wir, dass:
- Protokoll: TLSv1.2
- Cipher : ECDHE-RSA-AES256-GCM-SHA384
und als temporärer Server-Key ECDH, secp384r1, 384 bits verwendet wurden.
Die Verbindung wurde uns im Maillog entsprechend positiv quittiert:
Oct 26 22:35:30 vml000087 postfix/smtpd[22081]: connect from vml000087.dmz.nausch.org[10.0.0.87] Oct 26 22:35:30 vml000087 postfix/smtpd[22081]: Anonymous TLS connection established from vml000087.dmz.nausch.org[10.0.0.87]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Oct 26 22:35:34 vml000087 postfix/smtpd[22081]: disconnect from vml000087.dmz.nausch.org[10.0.0.87]
cipherscan
Zum Überprüfen welche Chiffren vom Server angeboten und unterstützt werden, greifen wir auf das Tool cipherscan von Julien Vehent und Hubert Kario zurück. Das Projekt basiert auf den openssl-Bibliotheken und wird auf GitHub zur Verfügung gestellt.
Mit nachfolgendem Aufruf kann überprüft werden, welche Ciphers angeboten werden.
# /usr/local/src/cipherscan-master/cipherscan -o /usr/local/src/cipherscan-master/openssl --curves -starttls smtp mx1.nausch.org:587
..................................... Target: imap.nausch.org:587 prio ciphersuite protocols pfs curves 1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1,secp384r1,secp521r1 2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1,secp384r1,secp521r1 3 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1,secp384r1,secp521r1 4 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1,secp384r1,secp521r1 5 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1,secp384r1,secp521r1 6 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1,secp384r1,secp521r1 7 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,4096bits None 8 DHE-RSA-AES256-SHA256 TLSv1.2 DH,4096bits None 9 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,4096bits None 10 DHE-RSA-CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,4096bits None 11 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,4096bits None 12 DHE-RSA-AES128-SHA256 TLSv1.2 DH,4096bits None 13 DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,4096bits None 14 DHE-RSA-SEED-SHA TLSv1,TLSv1.1,TLSv1.2 DH,4096bits None 15 DHE-RSA-CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,4096bits None Certificate: trusted, 4096 bit, sha512WithRSAEncryption signature TLS ticket lifetime hint: 300 OCSP stapling: not supported Cipher ordering: server Curves ordering: server Curves fallback: False
Die Bewertung der einzelnen Chiffren müssen wir hier immer noch selbst vornehmen; hilfreiche Informationen hierzu findet man z.B. im Buch BULLETPROOF SSL AND TLS von Ivan Ristić. Wir können aber auch zur genauen Bewertung der TLS-Verwundbarkeit unseres SMTP-Servers auf das nachfolgend beschriebene Projekt testssl zurückgreifen.
testssl
Zum Überprüfen welche Chiffren vom Server angeboten und unterstützt werden, greifen wir auf das Tool testssl von Dr. Wetter zurück. Wir können damit, ähnlich wie bei SSL Server Test lokal unsere Server testen, nicht nur unsere Webserver, sondern auch unsere Mailserver!
Das Shell-Script basiert auf den openssl-Bibliotheken und wird auf testssl-Projektseite zur Verfügung gestellt.
Zum Testen unseres SMTP-Servers nutzen wir nachfolgenden Aufruf.
# testssl.sh --starttls smtp 10.0.0.87:25
Als Ergebnis erhalten wir eine ausführliche Aufstellung zum TLS-Gesundheitszustandes unseres Servers.
No mapping file found ########################################################### testssl.sh 2.6 from https://testssl.sh/ (1.379c 2015/09/29 16:47:47) This program is free software. Distribution and modification under GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK! Please file bugs @ https://testssl.sh/bugs/ ########################################################### Using "OpenSSL 1.0.2-chacha (1.0.2d-dev)" [~181 ciphers] on vml000087.dmz.nausch.org:/root/bin/openssl.Linux.x86_64 (built: "Jul 6 18:05:33 2015", platform: "linux-x86_64") Testing now (2015-10-13 12:54) ---> 10.0.0.87:25 (10.0.0.87) <--- rDNS (10.0.0.87): vml000087.dmz.nausch.org. Service set: STARTTLS via SMTP
--> Testing protocols (via openssl, SSLv2 via sockets) SSLv2 not offered (OK) SSLv3 not offered (OK) SSL 1 not offered (OK) SSL 1.1 not offered (OK) SSL 1.2 not offered (OK) SPDY/NPN (SPDY is a HTTP protocol and thus not tested here)
--> Testing ~standard cipher lists> Testing protocols
Null Ciphers not offered (OK) Anonymous NULL Ciphers not offered (OK) Anonymous DH Ciphers not offered (OK) 40 Bit encryption not offered (OK) 56 Bit encryption not offered (OK) Export Ciphers (general) not offered (OK) Low (<=64 Bit) not offered (OK) DES Cipherss not offered (OK) Medium grade encryption offered (NOT ok) Triple DES Ciphers offered (NOT ok)
--> Testing ~standard cipher lists> Testing protocols -- omitting 3DES, RC4 and Null Encryption here
PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSAAES128-SHA256 DHE-RSA-AES128-SHA DHE-RSA-SEED-SHA DHE-RSA-CAMELLIA128-SHA ECDHE-RSA-AES128-SHA
--> Testing server preferences
Has server cipher order? yes (OK) Negotiated protocol? TLSv1.2 Negotiated cipher order? ECDHE-RSA-AES256-GCM-SHA384(OK), 384 bit ECDH Cipher order TLSv1: ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA AES256-SHA CAMELLIA256-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA ECDHE-RSA-DES-CBC3-SHA DHE-RSA-SEED-SHA DHE-RSA-CAMELLIA128-SHA EDH-RSA-DES-CBC3-SHA AES128-SHA SEED-SHA CAMELLIA128-SHA DES-CBC3-SHA IDEA-CBC-SHA TLSv1.1: ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA AES256-SHA CAMELLIA256-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA ECDHE-RSA-DES-CBC3-SHA DHE-RSA-SEED-SHA DHE-RSA-CAMELLIA128-SHA EDH-RSA-DES-CBC3-SHA AES128-SHA SEED-SHA CAMELLIA128-SHA DES-CBC3-SHA IDEA-CBC-SHA TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA CAMELLIA256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA ECDHE-RSA-DES-CBC3-SHA DHE-RSA-SEED-SHA DHE-RSA-CAMELLIA128-SHA EDH-RSA-DES-CBC3-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA SEED-SHA CAMELLIA128-SHA DES-CBC3-SHA IDEA-CBC-SHA SPDY/NPN: (SPDY is a HTTP protocol and thus not tested here)
--> Testing server defaults (Server Hello)
TLS server extensions renegotiation info, EC point formats, session ticket, heartbeat Session Tickets RFC 5077 7200 seconds Server key size 2048 bit Signature Algorithm SHA256 with RSA Fingerprint / Serial SHA1 F6A2584CCA1F526869FF8773CF62408087AC21B2 / 11D3E9 SHA256 AE3368DBD3199A34402C46636F4207EBC3235D84398C9F5C598AF737D1F4E690 Common Name (CN) *.nausch.org (wildcard certificate match) subjectAltName (SAN) *.nausch.org nausch.org Issuer RapidSSL CA (GeoTrust, Inc. from US) EV cert (experimental) no Certificate Expiration >= 60 days (2014-04-08 05:25 --> 2016-06-02 03:38 +0200) # of certificates provided 4 Certificate Revocation List http://rapidssl-crl.geotrust.com/crls/rapidssl.crl OCSP URI http://rapidssl-ocsp.geotrust.com OCSP stapling not offered TLS clock skew 0 sec from localtime
--> Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK) (timed out) CCS (CVE-2014-0224) not vulnerable (OK) Secure Renegotiation (CVE-2009-3555) not vulnerable (OK) Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat CRIME, TLS (CVE-2012-4929) not vulnerable (OK) (not using HTTP anyway) POODLE, SSL (CVE-2014-3566) not vulnerable (OK) TLS_FALLBACK_SCSV (RFC 7507), experim. Downgrade attack prevention supported (OK) FREAK (CVE-2015-0204) not vulnerable (OK) 29)">Downgrade attack prevention supported (OK) LOGJAM (CVE-2015-4000), experimental not vulnerable (OK) , common primes not checked. See below for any DH ciphers + bit size BEAST (CVE-2011-3389) TLS1: IDEA-CBC-SHA ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA DES-CBC3-SHA -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2 RC4 (CVE-2013-2566, CVE-2015-2808 no RC4 ciphers detected (OK)
--> Testing all locally available 181 ciphers against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits ------------------------------------------------------------------------- xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 384 AESGCM 256 xc028 ECDHE-RSA-AES256-SHA384 ECDH 384 AES 256 xc014 ECDHE-RSA-AES256-SHA ECDH 384 AES 256 x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 x6b DHE-RSA-AES256-SHA256 DH 2048 AES 256 x39 DHE-RSA-AES256-SHA DH 2048 AES 256 x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 x9d AES256-GCM-SHA384 RSA AESGCM 256 x3d AES256-SHA256 RSA AES 256 x35 AES256-SHA RSA AES 256 x84 CAMELLIA256-SHA RSA Camellia 256 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 384 AESGCM 128 xc027 ECDHE-RSA-AES128-SHA256 ECDH 384 AES 128 xc013 ECDHE-RSA-AES128-SHA ECDH 384 AES 128 x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 x67 DHE-RSA-AES128-SHA256 DH 2048 AES 128 x33 DHE-RSA-AES128-SHA DH 2048 AES 128 x9a DHE-RSA-SEED-SHA DH 2048 SEED 128 x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 x9c AES128-GCM-SHA256 RSA AESGCM 128 x3c AES128-SHA256 RSA AES 128 x2f AES128-SHA RSA AES 128 x96 SEED-SHA RSA SEED 128 x41 CAMELLIA128-SHA RSA Camellia 128 x07 IDEA-CBC-SHA RSA IDEA 128 xc012 ECDHE-RSA-DES-CBC3-SHA ECDH 384 3DES 168 x16 EDH-RSA-DES-CBC3-SHA DH 2048 3DES 168 x0a DES-CBC3-SHA RSA 3DES 168 Done now (2015-10-13 12:55) ---> 10.0.0.87:25 (10.0.0.87) <---
ssl-tools.net
Für eine sichere Verschlüsselung beim eMailtransport muss der Mailserver STARTTLS unterstützen. Ein vertrauenswürdiges SSL-Zertifikat sollte ebenso wie DANE zum Einsatz kommen. Selbstredend darf der Server nicht für Heartbleed anfällig sein und Perfect Forward Secrecy unterstützen.
All diese Dinge lassen sich über die Testseite https://de.ssl-tools.net/mailservers/ überprüfen. Über den Link Mailzustellung testen kann man auch noch die Mailzustellung testen. Als Ergebnis erhält man eine aussagekräftige Aufstellung der Ergebnisse, so z.B. für den Mailserver von nausch.org: https://de.ssl-tools.net/mailservers/nausch.org
eMail-Verkehr
Der verschlüsselte Transportweg wird in der Headerzeilen einer eMail entsprechend vermerkt:
Received: from mx1.tachtler.net (mx1.tachtler.net [88.217.171.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.nausch.org (Postfix) with ESMTP for <michael@nausch.org>; Thu, 26 Mar 2009 09:30:36 +0100 (CET)
Auch im Maillog wird die gesicherte Kommunikation protokolliert:
Mar 26 23:40:40 nss postfix/smtp[18519]: setting up TLS connection to mx1.tachtler.net
Mar 26 23:40:40 nss postfix/smtp[18519]: TLS connection established to mx1.tachtler.net: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 26 23:40:52 nss postfix/smtp[18519]: ECC0E1158526: to=<root@tachtler.net>, relay=mx1.tachtler.net[88.217.171.167]:25, delay=13, delays=0.01/0.14/0.81/12, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D7C7141582)
TLS-Verkehrsstatistik
Bei bedarf können wir uns bei unserem Mailserver, mit Hilfe der nachfolgenden Befehle, einen Überblick über Anzahl und Art der einzelnen TLS-Verbindungen anzeigen lassen.
ankommender TLS-Verkehr
# grep 'TLS connection established from' /var/log/maillog | sed -e 's/^.*\]\: //' -e 's/ with cipher.*//' | sort | uniq -c
42184 TLSv1 167813 TLSv1.2
ausgehender TLS-Verkehr
# grep 'TLS connection established to' /var/log/maillog | sed -e 's/^.*\]:25\: //' -e 's/ with cipher.*//' | sort | uniq -c
69741 TLSv1 3323 TLSv1.1 396939 TLSv1.2
graphische Übersicht des TLS-Clientverkehrs
Eine fortlaufende Übersicht der ausgehenden Verbindungen kann man sich mit Hilfe von Mailgraph erstellen lassen. Nachfolgende Graphik zeigt exemplarisch die Verkehrsstatistik des hier benutzten Mailservers.