SSL/TLS - Postfixverbindungen verschlüsselte Kommunikation
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.
Die für die Versachlüsselung notwendigen Schlüssel und Zertifikate erstellen wir mittels OpenSSL, einer freien Implementierung von SSL1). SSL oder TLS2) 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.i386 installed
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 -iql openssl Name : openssl Relocations: (not relocatable) ... ... URL : http://www.openssl.org/ Summary : Das OpenSSL-Toolkit Description : Das OpenSSL-Toolkit liefert Support für die sichere Kommunikation zwischen Computern. OpenSSL enthält ein zertifiziertes Management-Tool und gemeinsam genutzte Bibliotheken, die verschiedene kryptografische Algorithmen und Protokolle zur Verfügung stellen. /etc/pki/CA /etc/pki/CA/private /etc/pki/tls /etc/pki/tls/cert.pem /etc/pki/tls/certs /etc/pki/tls/certs/Makefile /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/make-dummy-cert /etc/pki/tls/misc /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 /etc/pki/tls/openssl.cnf /etc/pki/tls/private /lib/libcrypto.so.0.9.8b /lib/libcrypto.so.6 /lib/libssl.so.0.9.8b /lib/libssl.so.6 /usr/bin/openssl /usr/lib/openssl /usr/lib/openssl/engines /usr/lib/openssl/engines/lib4758cca.so /usr/lib/openssl/engines/libaep.so /usr/lib/openssl/engines/libatalla.so /usr/lib/openssl/engines/libchil.so /usr/lib/openssl/engines/libcswift.so /usr/lib/openssl/engines/libgmp.so /usr/lib/openssl/engines/libnuron.so /usr/lib/openssl/engines/libsureware.so /usr/lib/openssl/engines/libubsec.so /usr/share/doc/openssl-0.9.8b /usr/share/doc/openssl-0.9.8b/CHANGES /usr/share/doc/openssl-0.9.8b/FAQ /usr/share/doc/openssl-0.9.8b/INSTALL /usr/share/doc/openssl-0.9.8b/LICENSE /usr/share/doc/openssl-0.9.8b/NEWS /usr/share/doc/openssl-0.9.8b/README /usr/share/doc/openssl-0.9.8b/c-indentation.el /usr/share/doc/openssl-0.9.8b/openssl.txt /usr/share/doc/openssl-0.9.8b/openssl_button.gif /usr/share/doc/openssl-0.9.8b/openssl_button.html /usr/share/doc/openssl-0.9.8b/ssleay.txt /usr/share/man/man1/asn1parse.1ssl.gz /usr/share/man/man1/ca.1ssl.gz /usr/share/man/man1/ciphers.1ssl.gz ...
Zertifikatserstellung
Für die Verschlüsselung unserer Kommunikation nutzen wir ein selbstsigniertes Zertifikat. Hierzu benötigen wir:
- unseren Private Key, den wir hüten wie unseren Augapfel
- unseren Public Key, den wir von einer CA3) signieren, in unserem Falle unsere eigene CA, und
- den Public Key der unterschreibenden CA, um deren Unterschrift zu prüfen.
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
- 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 if [ -z "$OPENSSL" ]; then OPENSSL=openssl; fi DAYS="-days 2555" # 7 year CADAYS="-days 3650" # 10 years REQ="$OPENSSL req $SSLEAY_CONFIG" CA="$OPENSSL ca $SSLEAY_CONFIG" VERIFY="$OPENSSL verify" X509="$OPENSSL x509" CATOP=../../CA CAKEY=./cakey.pem CAREQ=./careq.pem CACERT=./cacert.pem for i do case $i in -\?|-h|-help) echo "usage: CA -newcert|-newreq|-newca|-sign|-verify" >&2 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" ;; -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 ${CATOP} mkdir ${CATOP}/certs mkdir ${CATOP}/crl mkdir ${CATOP}/newcerts mkdir ${CATOP}/private echo "00" > ${CATOP}/serial 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 $FILE ${CATOP}/private/$CAKEY RET=$? else echo "Making CA certificate ..." $REQ -new -keyout ${CATOP}/private/$CAKEY \ -out ${CATOP}/$CAREQ $CA -out ${CATOP}/$CACERT $CADAYS -batch \ -keyfile ${CATOP}/private/$CAKEY -selfsign \ -infiles ${CATOP}/$CAREQ RET=$? fi fi ;; -xsign) $CA -policy policy_anything -infiles newreq.pem RET=$? ;; -sign|-signreq) $CA -policy policy_anything -out newcert.pem -infiles newreq.pem RET=$? cat newcert.pem echo "Signed 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 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 0 ;; *) echo "Unknown arg $i"; exit 1 ;; esac done exit $RET
Verzeichnisse und Dateien anlegen
Als erstes legen wir die noch fehlenden verzeichnisse und Dateien an.
# mkdir /etc/pki/CA/certs # mkdir /etc/pki/CA/crl # mkdir /etc/pki/CA/newcerts # echo "00" > /etc/pki/CA/serial # touch /etc/pki/CA/index.txt
Somit befidnet sich in unserem Pfad /etc/pki/CA nun folgender Inhalt:
# ll /etc/pki/CA insgesamt 24 drwxr-xr-x 2 root root 4096 26. Mär 21:17 certs drwxr-xr-x 2 root root 4096 26. Mär 21:18 crl -rw-r--r-- 1 root root 0 26. Mär 21:20 index.txt drwxr-xr-x 2 root root 4096 26. Mär 21:18 newcerts drwx------ 2 root root 4096 26. Mär 20:30 private -rw-r--r-- 1 root root 3 26. Mär 21:19 serial
Erstellen unserer eigenen CA
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.
# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 9125 Generating a 2048 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) [GB]:DE State or Province Name (full name) [Berkshire]:Bayern Locality Name (eg, city) [Newbury]:Pliening Organization Name (eg, company) [My Company Ltd]:Nausch 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 1716 26. Mär 21:37 cacert.pem -rw-r--r-- 1 root root 1751 26. Mär 21:37 cakey.pem
Vorsichtshalber ä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: (2048 bit)
modulus:
00:d9:6d:c1:4f:c3:e4:e6:f4:14:64:60:57:ae:76:
68:40:ab:77:20:18:ae:fa:7c:ec:0c:1e:74:7f:ac:
a3:2b:74:8c:10:59:0c:63:03:46:04:a1:08:70:0c:
a1:04:62:10:2d:23:67:08:3f:f0:ec:36:eb:67:c4:
24:81:97:38:bc:e9:1f:80:51:61:19:e4:56:22:07:
54:88:6e:14:f8:d8:c2:67:c7:e9:96:e8:9d:11:f7:
68:40:ab:77:20:18:ae:fa:7c:ec:0c:1e:74:7f:ac:
58:84:b3:86:cb:4a:fe:52:20:fa:49:b9:3b:8c:07:
25:22:9e:9b:2e:ee:7f:72:95:d1:3a:af:f5:9c:8e:
24:81:97:38:bc:e9:1f:80:51:61:19:e4:56:22:07:
54:88:6e:14:f8:d8:c2:67:c7:e9:96:e8:9d:11:f7:
...
Will man die Passphrase eines Schlüssels entfernen, geht man wie folgt vor:
# openssl rsa <cakey.pem >cakey_ohne_passphrase.pem Enter pass phrase: des-woas-blos-I-und-sundst-koana writing RSA key
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 2048 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:
# openssl genrsa -out serverkey.pem -aes256 2048 -days 7300 Generating RSA private key, 2048 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, damit unser Postfix-Server, den Schlüssel ohne manuellen Eingriff laden und öffnen können muß! Schließlich wollen wir ja beim Systemstart nicht immer manuell die Passphrase eingeben müssen.
# openssl rsa <serverkey.pem >serverkey_2.pem
Wei schon zuvor schützen wir auch hier den Serverschlüssel über die Dateirechte, nachdem wir diesen umbenannt haben.
# mv serverkey_2.pem serverkey.pem # chmod 400 serverkey.pem
Certificate Signing Request erzeugen
Im folgenden Schritt zu unserem eigenen Zertifikat erzeugen wir einen CSR4), den wir dann in einem weiteren Schritt von unserer eigenen CA signieren lassen werden. Wichtig: Bei unserem Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name unseres Postfix-Server eingetragen werden, unter dem der Mailserver angesprochen wird!
# 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) [GB]:DE State or Province Name (full name) [Berkshire]:Bayern Locality Name (eg, city) [Newbury]:Pliening Organization Name (eg, company) [My Company Ltd]:Nausch Organizational Unit Name (eg, section) []:Postoffice Common Name (eg, your name or your server's hostname) []:mx1.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 []:
Serverzertifikat signieren
Bevor wir nun unser eigenes Zertifikat signieren können, passen wir in der OpenSSL-Konfigurationsdatei die Laufzeit an, da wir diese nicht auf der Komandozeile übergeben können.
# vim /etc/pki/tls/openssl.cnf
...
####################################################################
[ 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
default_days = 7300 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering
...
Außerdem verschieben wir den privaten Schlüssel unserer CA nach /etc/pki/CA/private/.
# mv /etc/pki/CA/cakey.pem /etc/pki/CA/private/
Kommen wir zum krönenen Abschluss - wir signieren nun das Server-Zertifikat durch unsere CA:
# 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:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 0 (0x0)
Validity
Not Before: Mar 26 21:59:14 2009 GMT
Not After : Mar 21 21:59:14 2029 GMT
Subject:
countryName = DE
stateOrProvinceName = Bayern
organizationName = Nausch
organizationalUnitName = Postoffice
commonName = mx1.nausch.org
emailAddress = postmaster@nausch.org
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
E7:13::9F:D0:C2:62:39:AE:B6:A1:73:70:95:D0:C2:62:CB:AD:46:15:BA:00
X509v3 Authority Key Identifier:
keyid:7D:3E:16:7D:D7:76:73:11:F4:74:34:EF:82:62:E8:75:75:0F:98:83
Certificate is to be certified until Mar 21 21:59:14 2029 GMT (7300 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
Schlüsseldateien ablegen
Für unsere Postfix-Installation legen wir uns am besten einen eigenen Unterordner unter /etc/pki an.
# mkdir /etc/pki/postfix
Anschließend legen wir dort die drei benötigten Dateien ab:
- unseren Serverzertifikat : servercert.pem
- unseren Serverschlüssel : serverkey.pem und
- das CA-Zertifikat : cacert.pem
und schützen diese Dateien mit den Dateirechten 400:
# mv /etc/pki/CA/servercert.pem /etc/pki/postfix/ # mv /etc/pki/CA/serverkey.pem /etc/pki/postfix/ # cp /etc/pki/CA/cacert.pem /etc/pki/postfix/ # chmod 400 /etc/pki/postfix/*.pem
Postfix Konfigurieren
SSL/TLS für den Mailempfang
Für den verschlüsselten Empfangsmodus erweitern wir unsere Postfix-Konfigurationsdatei wie folgt:
# # SSL/TLS - Schutz durch verschlüsselte Verbindungen (Kapitel 20.2) # eingetragen am 24.03.09 # # Pfade zu den Keys für den Mailempfang smtpd_tls_key_file = /etc/pki/postfix/serverkey.pem smtpd_tls_cert_file = /etc/pki/postfix/servercert.pem smtpd_tls_CAfile = /etc/pki/postfix/cacert.pem # Aktiviert STARTTLS für den Mailempfang smtpd_use_tls = yes
SSL/TLS für den Mailversand
Ähnlich trivial gestaltet sich die Geschichte für den Mailversand:
# Aktiviert STARTTLS für den Mailversand smtp_use_tls = yes
SSL/TLS - Logging im Maillog
Für die Dokumentation der Verschlüsselung tragen wir in der main.cf noch folgende Zeilen nach:
# Logged in den Received-Zeilen smtpd_tls_received_header = yes smtp_tls_loglevel = 1 smtpd_tls_loglevel = 1
Abschließend starten wir nun unseren Postfix einmal durch, damit unsere Änderungen aktiv werden.
# service postfix restart
Postfix Verbindungstest
erster Test
Als erstes kontrollieren wir, ob unser MX nun STARTTLS als ESMTP-Komando anbietet:
# telnet mx1.nausch.org 25
Trying 88.217.187.21...
Connected to mx1.nausch.org (88.217.187.21).
Escape character is '^]'.
220 mx1.nausch.org ESMTP Postfix
EHLO test
250-mx1.nausch.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
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 mx1.nausch.org:25
CONNECTED(00000003)
depth=1 /C=DE/ST=Bayern/L=Pliening/O=Nausch/OU=Zertifizierungsstelle/CN=nausch.org/emailAddress=ca-support@nausch.org
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=DE/ST=Bayern/O=Nausch/OU=Postoffice/CN=mx1.nausch.org/emailAddress=postmaster@nausch.org
i:/C=DE/ST=Bayern/L=Pliening/O=Nausch/OU=Zertifizierungsstelle/CN=nausch.org/emailAddress=ca-support@nausch.org
1 s:/C=DE/ST=Bayern/L=Pliening/O=Nausch/OU=Zertifizierungsstelle/CN=nausch.org/emailAddress=ca-support@nausch.org
i:/C=DE/ST=Bayern/L=Pliening/O=Nausch/OU=Zertifizierungsstelle/CN=nausch.org/emailAddress=ca-support@nausch.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEGDCCAwCgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBnTELMAkGA1UEBhMCREUx
DzANBgNVBAgTBkJheWVybjERMA8GA1UEBxMIUGxpZW5pbmcxDzANBgNVBAoTBk5h
dXNjaDEeMBwGA1UECxMVWmVydGlmaXppZXJ1bmdzc3RlbGxlMRMwEQYDVQQDEwpu
YXVzY2gub3JnMSQwIgYJKoZIhvcNAQkBFhVjYS1zdXBwb3J0QG5hdXNjaC5vcmcw
HhcNMDkwMzI2MjE1OTE0WhcNMjkwMzIxMjE1OTE0WjCBgzELMAkGA1UEBhMCREUx
DzANBgNVBAgTBkJheWVybjEPMA0GA1UEChMGTmF1c2NoMRMwEQYDVQQLEwpQb3N0
b2ZmaWNlMRcwFQYDVQQDEw5teDEubmF1c2NoLm9yZzEkMCIGCSqGSIb3DQEJARYV
cG9zdG1hc3RlckBuYXVzY2gub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyrqXcbSu0IDs6yM/3J/ClF1sZnKMqcxcbL+sGXhGXgShXM+SoK+21Hi9
m4Mll15Yhi8E6GBJr/3qwY4C8xeqBupBGux1h8Xtfll8u9LecCLuTQFum5tyeW1T
a78VTOpxcFwTD2cVbH/Z74Eijs78pPZOLyqGqRHcZRCKgvBWhU4TDymnoJOE/lfV
MCE2pdWJ9exucbTQ7qgIRxXCz+5REHFSghgGqG39TgMK248RW/K6FJ7xfmDjLTfw
7dNa4Cng/nWa8134J9qIskli8Iq+dT38LIa1oDjI56FgEL8ol+jW8wYb8wLSWwcr
o0zUhZerVYVaqHms2LAWsdcShZPMUQIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCG
SAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4E
FgQU5xMKn9DCYjmutqFzcOXLrUYVugAwHwYDVR0jBBgwFoAUTT4WTdd2cxH01DTv
gmLolXUPmIMwDQYJKoZIhvcNAQEFBQADggEBABH05WaHg3xM4sb1jAqDF+LMHPsZ
LIImt6BreB8WGNZGdfLF8HofRpcbmqci6/O+LcZdV+BhMEWFmZo5T2gV1zlKZMdk
ZEVhey5+LQq6WYNyQ+Kt7IZOdbKj0evNe+zv4V7Gqv1cqacL/+02BUpL3gw62BOG
PaIECvoCt+b0PQIRuu4hkPQp9hDGImZEU/NpWp2k4yrG4AgcL2lIO6RsZoaBU3DA
d+F+JIctlOpEO25SpazbzPsZuYZIeSDnn7vgll/NDMamXBGuEtokOizf1MfzOH8u
nRoL+jf/4jO6yQ3367YAE+7AUbIxelWYmXFFBUOYCnhvXRG0Hju+6+8cnyk=
-----END CERTIFICATE-----
subject=/C=DE/ST=Bayern/O=Nausch/OU=Postoffice/CN=mx1.nausch.org/emailAddress=postmaster@nausch.org
issuer=/C=DE/ST=Bayern/L=Pliening/O=Nausch/OU=Zertifizierungsstelle/CN=nausch.org/emailAddress=ca-support@nausch.org
---
No client certificate CA names sent
---
SSL handshake has read 3038 bytes and written 341 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: F6AD4BFB16B73DA658F36A6D1DD501592FB030BB73DA658FC6C1BD13CC8435A
Session-ID-ctx:
Master-Key: 36867781B392C49512375B320686FF078F353AB414F33C0137FEA2C4951F9CAE403E2F523209E49E75EB4167AEFC4BA59
Key-Arg : None
Krb5 Principal: None
Start Time: 1238106514
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
220 mx1.nausch.org ESMTP Postfix
EHLO test
250-mx1.nausch.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
DONE
Die Verbindung wurde uns im Maillog entsprechewnd positiv quittiert:
Mar 26 23:28:33 nss postfix/smtpd[6855]: connect from office.nausch.org[192.168.100.203] Mar 26 23:28:33 nss postfix/smtpd[6855]: setting up TLS connection from office.nausch.org[192.168.100.203] Mar 26 23:28:34 nss postfix/smtpd[6855]: TLS connection established from office.nausch.org[192.168.100.203]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Mar 26 23:29:00 nss postfix/smtpd[6855]: lost connection after EHLO from office.nausch.org[192.168.100.203] Mar 26 23:29:00 nss postfix/smtpd[6855]: disconnect from office.nausch.org[192.168.100.203]
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 with cipher ADH-AES256-SHA (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 with cipher ADH-AES256-SHA (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)
django