TLS-Verbindungen, verschlüsselte Kommunikation für Postfix 3.x unter CentOS 7

Bild: Weltkugel
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 großer krimineller Energie versuchen an diese Daten zu kommen.

Inwieweit staatliche Stellen den Datenverkehr abhören, protokollieren und abgreifen und zu manipulieren bzw. zensieren versuchen, weiß

  1. keiner so genau und
  2. 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. Bild: Ausrufezeichen 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! Selbst das „Aufbrechen von Verschlüsselungen“ durch MITM1) Attacken scheinen manchen Institutionen und Firmen das legitime Mittel zu sein um an Inhalte der Übertragungen zu kommen. m(

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 und Absender darauf vertrauen können, dass Informationen tatsächlich von dem versandt bzw. dass wir auch nur dann Nachrichten an den Empfänger übertragen, von dem wir glauben, diese rechtmäßig erhalten zu haben bzw. gesendet haben.

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. SSL/TLS Logo 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 PFS2) 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 SSL3). SSL oder TLS4) 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.

Sind wir mit den Grundprinzipien der asynchronen Verschlüsselung, Zertifikaten und Themen rund um CAs bereits vertraut können wir natürlich gleich mit der Schlüsselgenerierung und dem erstellen eines Zertifikats Signing Requests fortfahren und nachfolgende Kapitel überspringen.

Haben wir auch das bereits erfolgreich erledigt können wir uns direkt mit der Konfiguration unseres MTAs Postfix beschäftigen.

Zertifikate

Technisch gesehen unterscheiden sich Zertifikate einer „offiziellen“ oder besser gesagt einer kommerziellen CA nicht von Zertifikaten einer eigenen (Unternehmens-)CA, von Zertifikaten einer freien CA wie z.B. let's encrypt oder auch von „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. Ein weiterer Punkt wird sein, ob wir nun „nur bestmöglich verschlüsselt“- opportunistische Verschlüsselung - oder doch mit Kommunikationspartnern/Servern zwingend verschlüsseln wollen bzw. müssen.

Egal welchen Weg wir hier gehen können oder müssen, zur Absicherung unserer Kommunikation benötigen wir drei Dinge:

  1. unseren Private Key, den wir hüten wie unseren Augapfel
  2. unseren Public Key mit zusätzlichen Daten , auch bekannt als CSR5), den wir von einer CA6) signieren lassen. Dies ist das Zertifikat, welches wir von unserer eigenen CA oder auch eine der vielen kommerziellen erhalten, und
  3. den Public Key der unterschreibenden CA, um deren Unterschrift zu prüfen, auch als Root-Zertifikat bekannt.

Sobald wir diese drei Teile erstellt bzw. uns besorgt haben können wir mit der Konfiguration unseres MTA fortfahren.

Vertrauensmodelle in Public-Key-Infrastrukturen

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.

BILD: schematische Darstellung des Vertrauensverhältnis beim PKI Modell

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. Beziehungsweise wird unser Mailserver (SMTP-Client) zu sehr vielen Mailservern (SMTP-Server) Verbindungen aufbauen. 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 CA7) 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.

BILD: schematische Darstellung eines X.509 Zertifikates

Ohne dem übergeordneten Root Zertifikat kann zwar verschlüsselt kommuniziert werden (oppotunistischen Verschlüsselung), wir wissen aber dabei nicht, ob der zur Verschlüsselung zugrunde liegender Schlüsselmaterials valide ist und ob der Gesprächspartner derjenige ist, den er vorzugeben scheint.

Unserem Kommunikationssystem, egal ob das nun ein WEB-Browser oder ein Web- oder Mailserver ist, müssen wir nun also noch zwei Dinge beibringen.

  1. Root Zertifikate:
    Wir müssen die benötigten Root-Zertifikate unserem System zur Verfügung stellen.
  2. CA Vertrauen:
    Der jeweiligen CA und dessen Root-Zertifikat müssen wir noch explizit unser Vertrauen aussprechen

Ohne diese beiden essentiellen Maßnahmen, können wir zwar verschlüsselt Kommunizieren, wir wissen aber nicht, ob der Adressat derjenige ist den wir meinen und ob dieser die Daten auch wirklich entschlüsseln kann!

CA-Zertifikate unter CentOS 7

Die wichtigsten Zertifizierungsstellen und deren Root-Zertifikate müssen wir uns nun nicht alle einzeln auf diversen Webseiten zusammensuchen. Mit Hilfe des RPM-Paketes ca-certificates können wir zum einen die wichtigsten, von der Mozilla Foundation ausgewählten, CAs zurückgreifen. Bei der Grundinstallation unseres Systems wurde bereits dieses Paket installiert; was es mitbrachte zeigt uns der folgende Aufruf.

 # rpm -qil ca-certificates
Name        : ca-certificates
Version     : 2018.2.22
Release     : 70.0.el7_5
Architecture: noarch
Install Date: Sat 26 Jan 2019 06:11:37 PM CET
Group       : System Environment/Base
Size        : 973960
License     : Public Domain
Signature   : RSA/SHA256, Thu 17 May 2018 03:16:26 PM CEST, Key ID 24c6a8a7f4a80eb5
Source RPM  : ca-certificates-2018.2.22-70.0.el7_5.src.rpm
Build Date  : Wed 16 May 2018 06:36:08 AM CEST
Build Host  : c1bm.rdu2.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.mozilla.org/
Summary     : The Mozilla CA root certificate bundle
Description :
This package contains the set of CA certificates chosen by the
Mozilla Foundation for use with the Internet PKI.
/etc/pki/ca-trust
/etc/pki/ca-trust/README
/etc/pki/ca-trust/ca-legacy.conf
/etc/pki/ca-trust/extracted
/etc/pki/ca-trust/extracted/README
/etc/pki/ca-trust/extracted/java
/etc/pki/ca-trust/extracted/java/README
/etc/pki/ca-trust/extracted/java/cacerts
/etc/pki/ca-trust/extracted/openssl
/etc/pki/ca-trust/extracted/openssl/README
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/pem
/etc/pki/ca-trust/extracted/pem/README
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/etc/pki/ca-trust/source
/etc/pki/ca-trust/source/README
/etc/pki/ca-trust/source/anchors
/etc/pki/ca-trust/source/blacklist
/etc/pki/ca-trust/source/ca-bundle.legacy.crt
/etc/pki/java
/etc/pki/java/cacerts
/etc/pki/tls
/etc/pki/tls/cert.pem
/etc/pki/tls/certs
/etc/pki/tls/certs/ca-bundle.crt
/etc/pki/tls/certs/ca-bundle.trust.crt
/etc/ssl
/etc/ssl/certs
/usr/bin/ca-legacy
/usr/bin/update-ca-trust
/usr/share/doc/ca-certificates-2018.2.22/README
/usr/share/man/man8/ca-legacy.8.gz
/usr/share/man/man8/update-ca-trust.8.gz
/usr/share/pki
/usr/share/pki/ca-trust-legacy
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt
/usr/share/pki/ca-trust-source
/usr/share/pki/ca-trust-source/README
/usr/share/pki/ca-trust-source/anchors
/usr/share/pki/ca-trust-source/blacklist
/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit

manpage von update-ca-trust

In der recht ausführlichen manpage von update-ca-trust finden sich viele hilfreiche Detailangaben zum Importieren und Trusten von zusätzlichen Root-Zertifikaten.

 # man update-ca-trust
UPDATE-CA-TRUST(8)                                                     UPDATE-CA-TRUST(8)

NAME
       update-ca-trust - manage consolidated and dynamic configuration of CA certificates
       and associated trust

SYNOPSIS
       update-ca-trust [COMMAND]

DESCRIPTION
       update-ca-trust(8) is used to manage a consolidated and dynamic configuration
       feature of Certificate Authority (CA) certificates and associated trust.

       The feature is available for new applications that read the consolidated
       configuration files found in the /etc/pki/ca-trust/extracted directory or that
       load the PKCS#11 module p11-kit-trust.so

       Parts of the new feature are also provided in a way to make it useful for legacy
       applications.

       Many legacy applications expect CA certificates and trust configuration in a fixed
       location, contained in files with particular path and name, or by referring to a
       classic PKCS#11 trust module provided by the NSS cryptographic library.

       The dynamic configuration feature provides functionally compatible replacements
       for classic configuration files and for the classic NSS trust module named
       libnssckbi.

       In order to enable legacy applications, that read the classic files or access the
       classic module, to make use of the new consolidated and dynamic configuration
       feature, the classic filenames have been changed to symbolic links. The symbolic
       links refer to dynamically created and consolidated output stored below the
       /etc/pki/ca-trust/extracted directory hierarchy.

       The output is produced using the update-ca-trust command (without parameters), or
       using the update-ca-trust extract command. In order to produce the output, a
       flexible set of source configuration is read, as described in section SOURCE
       CONFIGURATION.

       In addition, the classic PKCS#11 module is replaced with a new PKCS#11 module
       (p11-kit-trust.so) that dynamically reads the same source configuration.

SOURCE CONFIGURATION
       The dynamic configuration feature uses several source directories that will be
       scanned for any number of source files. It is important to select the correct
       subdirectory for adding files, as the subdirectory defines how contained
       certificates will be trusted or distrusted, and which file formats are read.

       Files in subdirectories below the directory hierarchy
       /usr/share/pki/ca-trust-source/ contain CA certificates and trust settings in the
       PEM file format. The trust settings found here will be interpreted with a low
       priority.

       Files in subdirectories below the directory hierarchy /etc/pki/ca-trust/source/
       contain CA certificates and trust settings in the PEM file format. The trust
       settings found here will be interpreted with a high priority.

       You may use the following rules of thumb to decide, whether your configuration
       files should be added to the /etc or rather to the /usr directory hierarchy:

       ·   If you are manually adding a configuration file to a system, you probably want
           it to override any other default configuration, and you most likely should add
           it to the respective subdirectory in the /etc hierarchy.

       ·   If you are creating a package that provides additional root CA certificates,
           that is intended for distribution to several computer systems, but you still
           want to allow the administrator to override your list, then your package
           should add your files to the respective subdirectory in the /usr hierarchy.

       ·   If you are creating a package that is supposed to override the default system
           trust settings, that is intended for distribution to several computer systems,
           then your package should install the files to the respective subdirectory in
           the /etc hierarchy.

       QUICK HELP 1: To add a certificate in the simple PEM or DER file formats to the
       list of CAs trusted on the system:

       ·   add it as a new file to directory /etc/pki/ca-trust/source/anchors/

       ·   run update-ca-trust extract

       QUICK HELP 2: If your certificate is in the extended BEGIN TRUSTED file format
       (which may contain distrust/blacklist trust flags, or trust flags for usages other
       than TLS) then:

       ·   add it as a new file to directory /etc/pki/ca-trust/source/

       ·   run update-ca-trust extract

       In order to offer simplicity and flexibility, the way certificate files are
       treated depends on the subdirectory they are installed to.

       ·   simple trust anchors subdirectory: /usr/share/pki/ca-trust-source/anchors/ or
           /etc/pki/ca-trust/source/anchors/

       ·   simple blacklist (distrust) subdirectory:
           /usr/share/pki/ca-trust-source/blacklist/ or
           /etc/pki/ca-trust/source/blacklist/

       ·   extended format directory: /usr/share/pki/ca-trust-source/ or
           /etc/pki/ca-trust/source/

       In the main directories /usr/share/pki/ca-trust-source/ or
       /etc/pki/ca-trust/source/ you may install one or multiple files in the following
       file formats:

       ·   certificate files that include trust flags, in the BEGIN/END TRUSTED
           CERTIFICATE file format (any file name), which have been created using the
           openssl x509 tool and the -addreject -addtrust options. Bundle files with
           multiple certificates are supported.

       ·   files in the p11-kit file format using the .p11-kit file name extension, which
           can (e.g.) be used to distrust certificates based on serial number and issuer
           name, without having the full certificate available. (This is currently an
           undocumented format, to be extended later. For examples of the supported
           formats, see the files shipped with the ca-certificates package.)

       ·   certificate files without trust flags in either the DER file format or in the
           PEM (BEGIN/END CERTIFICATE) file format (any file name). Such files will be
           added with neutral trust, neither trusted nor distrusted. They will simply be
           known to the system, which might be helpful to assist cryptographic software
           in constructing chains of certificates. (If you want a CA certificate in these
           file formats to be trusted, you should remove it from this directory and move
           it to the ./anchors subdirectory instead.)

       In the anchors subdirectories /usr/share/pki/ca-trust-source/anchors/ or
       /etc/pki/ca-trust/source/anchors/ you may install one or multiple certificates in
       either the DER file format or in the PEM (BEGIN/END CERTIFICATE) file format. Each
       certificate will be treated as trusted for all purposes.

       In the blacklist subdirectories /usr/share/pki/ca-trust-source/blacklist/ or
       /etc/pki/ca-trust/source/blacklist/ you may install one or multiple certificates
       in either the DER file format or in the PEM (BEGIN/END CERTIFICATE) file format.
       Each certificate will be treated as distrusted for all purposes.

       Please refer to the x509(1) manual page for the documentation of the BEGIN/END
       CERTIFICATE and BEGIN/END TRUSTED CERTIFICATE file formats.

       Applications that rely on a static file for a list of trusted CAs may load one of
       the files found in the /etc/pki/ca-trust/extracted directory. After modifying any
       file in the /usr/share/pki/ca-trust-source/ or /etc/pki/ca-trust/source/
       directories or in any of their subdirectories, or after adding a file, it is
       necessary to run the update-ca-trust extract command, in order to update the
       consolidated files in /etc/pki/ca-trust/extracted/ .

       Applications that load the classic PKCS#11 module using filename libnssckbi.so
       (which has been converted into a symbolic link pointing to the new module) and any
       application capable of loading PKCS#11 modules and loading p11-kit-trust.so, will
       benefit from the dynamically merged set of certificates and trust information
       stored in the /usr/share/pki/ca-trust-source/ and /etc/pki/ca-trust/source/
       directories.

EXTRACTED CONFIGURATION
       The directory /etc/pki/ca-trust/extracted/ contains generated CA certificate
       bundle files which are created and updated, based on the SOURCE CONFIGURATION by
       running the update-ca-trust extract command.

       If your application isn’t able to load the PKCS#11 module p11-kit-trust.so, then
       you can use these files in your application to load a list of global root CA
       certificates.

       Please never manually edit the files stored in this directory, because your
       changes will be lost and the files automatically overwritten, each time the
       update-ca-trust extract command gets executed.

       In order to install new trusted or distrusted certificates, please rather install
       them in the respective subdirectory below the /usr/share/pki/ca-trust-source/ or
       /etc/pki/ca-trust/source/ directories, as described in the SOURCE CONFIGURATION
       section.

       The directory /etc/pki/ca-trust/extracted/java/ contains a CA certificate bundle
       in the java keystore file format. Distrust information cannot be represented in
       this file format, and distrusted certificates are missing from these files. File
       cacerts contains CA certificates trusted for TLS server authentication.

       The directory /etc/pki/ca-trust/extracted/openssl/ contains CA certificate bundle
       files in the extended BEGIN/END TRUSTED CERTIFICATE file format, as described in
       the x509(1) manual page. File ca-bundle.trust.crt contains the full set of all
       trusted or distrusted certificates, including the associated trust flags.

       The directory /etc/pki/ca-trust/extracted/pem/ contains CA certificate bundle
       files in the simple BEGIN/END CERTIFICATE file format, as decribed in the x509(1)
       manual page. Distrust information cannot be represented in this file format, and
       distrusted certificates are missing from these files. File tls-ca-bundle.pem
       contains CA certificates trusted for TLS server authentication. File
       email-ca-bundle.pem contains CA certificates trusted for E-Mail protection. File
       objsign-ca-bundle.pem contains CA certificates trusted for code signing.

COMMANDS
       (absent/empty command)
           Same as the extract command described below. (However, the command may print
           fewer warnings, as this command is being run during rpm package installation,
           where non-fatal status output is undesired.)

       extract
           Instruct update-ca-trust to scan the SOURCE CONFIGURATION and produce updated
           versions of the consolidated configuration files stored below the
           /etc/pki/ca-trust/extracted directory hierarchy.

FILES
       /etc/pki/tls/certs/ca-bundle.crt
           Classic filename, file contains a list of CA certificates trusted for TLS
           server authentication usage, in the simple BEGIN/END CERTIFICATE file format,
           without distrust information. This file is a symbolic link that refers to the
           consolidated output created by the update-ca-trust command.

       /etc/pki/tls/certs/ca-bundle.trust.crt
           Classic filename, file contains a list of CA certificates in the extended
           BEGIN/END TRUSTED CERTIFICATE file format, which includes trust (and/or
           distrust) flags specific to certificate usage. This file is a symbolic link
           that refers to the consolidated output created by the update-ca-trust command.

       /etc/pki/java/cacerts
           Classic filename, file contains a list of CA certificates trusted for TLS
           server authentication usage, in the Java keystore file format, without
           distrust information. This file is a symbolic link that refers to the
           consolidated output created by the update-ca-trust command.

       /usr/share/pki/ca-trust-source
           Contains multiple, low priority source configuration files as explained in
           section SOURCE CONFIGURATION. Please pay attention to the specific meanings of
           the respective subdirectories.

       /etc/pki/ca-trust/source
           Contains multiple, high priority source configuration files as explained in
           section SOURCE CONFIGURATION. Please pay attention to the specific meanings of
           the respective subdirectories.

       /etc/pki/ca-trust/extracted
           Contains consolidated and automatically generated configuration files for
           consumption by applications, which are created using the update-ca-trust
           extract command. Don’t edit files in this directory, because they will be
           overwritten. See section EXTRACTED CONFIGURATION for additional details.

AUTHOR
       Written by Kai Engert and Stef Walter.

update-ca-trust                         09/18/2014                     UPDATE-CA-TRUST(8)

/etc/pki/ca-trust/source/README

Da wir einzelnen Root-Zertifikaten explizit das Vertrauen aussprechen wollen, werden wir die vom RPM-Paket mitgebrachten Verzeichnisstrukturen unter /etc verwenden. Dort finden wir auch noch eine entsprechende README Datei.

 # less /etc/pki/ca-trust/source/README
This directory /etc/pki/ca-trust/source/ contains CA certificates and 
trust settings in the PEM file format. The trust settings found here will be
interpreted with a high priority - higher than the ones found in 
/usr/share/pki/ca-trust-source/.

=============================================================================
QUICK HELP: To add a certificate in the simple PEM or DER file formats to the
            list of CAs trusted on the system:

            Copy it to the
                    /etc/pki/ca-trust/source/anchors/
            subdirectory, and run the
                    update-ca-trust
            command.

            If your certificate is in the extended BEGIN TRUSTED file format,
            then place it into the main source/ directory instead.
=============================================================================

Please refer to the update-ca-trust(8) manual page for additional information.

Import-Beispiel am CAcert Root-Zertifikat

Im folgendem Beispiel wollen wir uns das Root-Zertifikat von CAcert als vertrauenswürdige Root-Zertifikate importieren.

Hierzu wechseln wir im ersten Schritt in das Verzeichnis /etc/pki/ca-trust/source/anchors.

 # cd /etc/pki/ca-trust/source/anchors

Anschließend holen wir uns das Root-Certifikat von CAcert von deren Homepage auf unseren Server.

 # wget -O CAcert_class1.pem --no-check-certificate https://www.cacert.org/certs/root.crt

Somit befindet sich nun das Root-Zertifikat von CAcert in unserem Verzeichnis.

 # less CAcert_class1.pem
-----BEGIN CERTIFICATE-----
MIIHPTCCBSWgAwIBAgIBADANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290
IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNB
IENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA
Y2FjZXJ0Lm9yZzAeFw0wMzAzMzAxMjI5NDlaFw0zMzAzMjkxMjI5NDlaMHkxEDAO
BgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEi
MCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ
ARYSc3VwcG9ydEBjYWNlcnQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC
CgKCAgEAziLA4kZ97DYoB1CW8qAzQIxL8TtmPzHlawI229Z89vGIj053NgVBlfkJ
8BLPRoZzYLdufujAWGSuzbCtRRcMY/pnCujW0r8+55jE8Ez64AO7NV1sId6eINm6
zWYyN3L69wj1x81YyY7nDl7qPv4coRQKFWyGhFtkZip6qUtTefWIonvuLwphK42y
fk1WpRPs6tqSnqxEQR5YYGUFZvjARL3LlPdCfgv3ZWiYUQXw8wWRBB0bF4LsyFe7
w2t6iPGwcswlWyCR7BYCEo8y6RcYSNDHBS4CMEK4JZwFaz+qOqfrU0j36NK2B5jc
G8Y0f3/JHIJ6BVgrCFvzOKKrF11myZjXnhCLotLddJr3cQxyYN/Nb5gznZY0dj4k
epKwDpUeb+agRThHqtdB7Uq3EvbXG4OKDy7YCbZZ16oE/9KTfWgu3YtLq1i6L43q
laegw1SJpfvbi1EinbLDvhG+LJGGi5Z4rSDTii8aP8bQUWWHIbEZAWV/RRyH9XzQ
QUxPKZgh/TMfdQwEUfoZd9vUFBzugcMd9Zi3aQaRIt0AUMyBMawSB3s42mhb5ivU
fslfrejrckzzAeVLIL+aplfKkQABi6F1ITe1Yw1nPkZPcCBnzsXWWdsC4PDSy826
YreQQejdIOQpvGQpQsgi3Hia/0PsmBsJUUtaWsJx8cTLc6nloQsCAwEAAaOCAc4w
ggHKMB0GA1UdDgQWBBQWtTIb1Mfz4OaO873SsDrusjkY0TCBowYDVR0jBIGbMIGY
gBQWtTIb1Mfz4OaO873SsDrusjkY0aF9pHsweTEQMA4GA1UEChMHUm9vdCBDQTEe
MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0
IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy
dC5vcmeCAQAwDwYDVR0TAQH/BAUwAwEB/zAyBgNVHR8EKzApMCegJaAjhiFodHRw
czovL3d3dy5jYWNlcnQub3JnL3Jldm9rZS5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0
dHBzOi8vd3d3LmNhY2VydC5vcmcvcmV2b2tlLmNybDA0BglghkgBhvhCAQgEJxYl
aHR0cDovL3d3dy5jYWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg
b3ZlciB0byBodHRwOi8vd3d3LmNhY2VydC5vcmcwDQYJKoZIhvcNAQEEBQADggIB
ACjH7pyCArpcgBLKNQodgW+JapnM8mgPf6fhjViVPr3yBsOQWqy1YPaZQwGjiHCc
nWKdpIevZ1gNMDY75q1I08t0AoZxPuIrA2jxNGJARjtT6ij0rPtmlVOKTV39O9lg
18p5aTuxZZKmxoGCXJzN600BiqXfEVWqFcofN8CCmHBh22p8lqOOLlQ+TyGpkO/c
gr/c6EWtTZBzCDyUZbAEmXZ/4rzCahWqlwQ3JNgelE5tDlG+1sSPypZt90Pf6DBl
Jzt7u0NDY8RD97LsaMzhGY4i+5jhe1o+ATc7iwiwovOVThrLm82asduycPAtStvY
sONvRUgzEv/+PDIqVPfE94rwiCPCR/5kenHA0R6mY7AHfqQv0wGP3J8rtsYIqQ+T
SCX8Ev2fQtzzxD72V7DX3WnRBnc0CkvSyqD/HMaMyRa+xMwyN2hzXwj7UfdJUzYF
CpUCTPJ5GhD22Dp1nPMd8aINcGeGG7MW9S/lpOt5hvk9C8JzC6WZrG/8Z7jlLwum
GCSNe9FINSkYQKyTYOGWhlC0elnYjyELn8+CkcY7v2vcB5G5l1YjqrZslMZIBjzk
zk6q5PYvCdxTby78dOs6Y5nCpqyJvKeyRKANihDjbPIky/qbn3BHLt4Ui9SyIAmW
omTxJBzcoTWcFbLUvFUufQb1nA5V9FrWk9p2rSVzTMVD
-----END CERTIFICATE-----

Das gleiche machen wir nun mit dem Class3 Zertifikat von CAcert.

 # wget -O CAcert_class3.pem --no-check-certificate https://www.cacert.org/certs/class3.crt

Nun haben wir auch das Class3 Root-Zertifikat von CAcert in unserem Verzeichnis.

 # less CAcert_class3.pem
-----BEGIN CERTIFICATE-----
MIIHWTCCBUGgAwIBAgIDCkGKMA0GCSqGSIb3DQEBCwUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y
dEBjYWNlcnQub3JnMB4XDTExMDUyMzE3NDgwMloXDTIxMDUyMDE3NDgwMlowVDEU
MBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0
Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZIhvcN
AQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57a
iX3h++tykA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1
aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6C
jQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgia
pNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0
FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPt
XapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luL
oFvqTpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6
R9Wb7yQocDggL9V/KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGp
rmB6gCZIALgBwJNjVSKRPFbnr9s6JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/
LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+YnMtHmJVA
BfvpAgMBAAGjggINMIICCTAdBgNVHQ4EFgQUdahxYEyIE/B42Yl3tW3Fid+8sXow
gaMGA1UdIwSBmzCBmIAUFrUyG9TH8+DmjvO90rA67rI5GNGhfaR7MHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAG
A1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnggEAMA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUH
AQEEUTBPMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggr
BgEFBQcwAoYcaHR0cDovL3d3dy5DQWNlcnQub3JnL2NhLmNydDBKBgNVHSAEQzBB
MD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
Zy9pbmRleC5waHA/aWQ9MTAwNAYJYIZIAYb4QgEIBCcWJWh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwUAYJYIZIAYb4QgENBEMWQVRvIGdldCB5
b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSwgZ28gdG8gaHR0cDovL3d3dy5D
QWNlcnQub3JnMA0GCSqGSIb3DQEBCwUAA4ICAQApKIWuRKm5r6R5E/CooyuXYPNc
7uMvwfbiZqARrjY3OnYVBFPqQvX56sAV2KaC2eRhrnILKVyQQ+hBsuF32wITRHhH
Va9Y/MyY9kW50SD42CEH/m2qc9SzxgfpCYXMO/K2viwcJdVxjDm1Luq+GIG6sJO4
D+Pm1yaMMVpyA4RS5qb1MyJFCsgLDYq4Nm+QCaGrvdfVTi5xotSu+qdUK+s1jVq3
VIgv7nSf7UgWyg1I0JTTrKSi9iTfkuO960NAkW4cGI5WtIIS86mTn9S8nK2cde5a
lxuV53QtHA+wLJef+6kzOXrnAzqSjiL2jA3k2X4Ndhj3AfnvlpaiVXPAPHG0HRpW
Q7fDCo1y/OIQCQtBzoyUoPkD/XFzS4pXM+WOdH4VAQDmzEoc53+VGS3FpQyLu7Xt
hbNc09+4ufLKxw0BFKxwWMWMjTPUnWajGlCVI/xI4AZDEtnNp4Y5LzZyo4AQ5OHz
0ctbGsDkgJp8E3MGT9ujayQKurMcvEp4u+XjdTilSKeiHq921F73OIZWWonO1sOn
ebJSoMbxhbQljPI/lrMQ2Y1sVzufb4Y6GIIiNsiwkTjbKqGTqoQ/9SdlrnPVyNXT
d+pLncdBu8fA46A/5H2kjXPmEkvfoXNzczqA6NXLji/L6hOn1kGLrPo8idck9U60
4GGSt/M3mMS+lqO3ig==
-----END CERTIFICATE-----

WICHTIG:

Bevor wir nun dem Zertifikat bzw. der CA das Vertrauen aussprechen, überprüfen wir noch die Echteit des Zertifikates an Hand dessen Fingerprints.

 # openssl x509 -noout -fingerprint -in CAcert_class1.pem 
SHA1 Fingerprint=13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33

Diesen Fingerprint vergleichen wir nun mit den Angaben von CAcert auf deren Homepage. Dort finden wir folgende Daten:

SHA1 Fingerabdruck: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33


Unterscheiden sich die beiden Fingerprints ist SOFORT mit dem Importvorgang abzubrechen!

Da beide Fingerprints gleich sind, können wir nun noch mit dem zweite CAcert Class3 Zertifikat genau so verfahren dabei wie beim ersten Zertifikat.

 # openssl x509 -noout -fingerprint -in CAcert_class3.pem
SHA1 Fingerprint=AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE

Diesen Fingerprint vergleichen wir nun mit den Angaben von CAcert auf deren Homepage. Dort finden wir folgende Daten:

SHA1 Fingerabdruck: AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE

Ist Fingerprint Vergleich beim Class 3 Zertifikat auch gleich, können wir mit dem eigentlichem Importvorgang der beiden Zertifikate fortfahren!

Zum Importieren der CAcert-Root-Zertifikate benutzen wir nun den Befehl update-ca-trust.

 # update-ca-trust

Ist der Importvorgang abgeschlossen, befinden sich in der in der Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem die gerade importierten Root-Zertifikate.

Wollen wir überprüfen, ob die gewünschten Zertifikate auch wirklich in dem erstellten Zertifikats-Bundle enthalten sind, greifen wir auf ein kleines Script zurück. Mit dem folgenden Perl-Script kann eine Liste aller Zertifikate erstellt werden, die sich in einer Zertifikats-Bundle-Datei befinden.

 # vim /usr/local/bin/ca-list
/usr/local/bin/ca-list
#!/usr/bin/perl
# Liste eines Zertifikatsbundles ausgeben.
# Django <django@mailserver.guru> (c) 2019
#
$file = shift;
unless($file) { die("Ohne Zertifikatsbundle kann die Liste nicht erstellt werden!\n"); }
open LISTE, "<$file" or die("Fehler beim Laden der Datei \"$file\"\n");
 
$certfile = "";
print "Folgende Zertifikate befinden sich in der Datei $file:\n";
 
while(<LISTE>) {
        $certfile .= $_;
        if($_ =~ /^\-+END(\s\w+)?\sCERTIFICATE\-+$/) {
                print `echo "$certfile" | openssl x509 -noout -subject`;
                $certfile = "";
        }
}
close LISTE;

Das gerade angelegt Script statten wir noch mit den x-Ausführungsrecht aus.

 # chmod +x /usr/local/bin/ca-list

Nun können wir auch überprüfen, ob sich die zuvor installierten Root-Zertifikate von CAcert in der Zertifikats-Bundle-Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem befinden.

 # ca-list /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem | grep -i cacert.org
subject= /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
subject= /O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root

CA Vetrauensmodell - 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 CA8) 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 CN9) dokuwiki.nausch.org.

Bild: Zertifikatskette eines Zertifikates (Firefox)

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.

  1. 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.

  2. Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat RapidSSL_CA.pem auf unseren Rechner.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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!

  8. 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
  9. 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!

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.

selbssigniertes/selfsigned Zertifikat

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.

Evolution Warnung

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 rsa cakey_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)

Nutzung einer öffentlichen vertrauenswürdigen CA

Da wir nicht nur mit unseren Kunden, sondern auch mit externen Mailsystemen nicht nur eine opportunistische Verschlüsselung mit unserem Mailserver aufbauen können soll, werden wir uns zur Absicherung des Mail-Transports ein Zertifikat einer öffentlichen kommerziellen CA verwenden.

Ob man in Zeiten von Überwachungsphantasten in Unternehmen und vor allem auch bei einer NSA oder BND, noch solchen RSA-Schlüssel einsetzen kann und mag, muss natürlich jeder Admin für sich selbst entscheiden.

Der Sicherheitsguru Bruce Schneier hat in seinem Blog hierzu eine eindeutige Aussage getätigt:

„On the crypto bits in your guardian piece, I found especially interesting that you suggest classic discrete log crypto over ecc. I want to ask if you could elaborate more on that.“ I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.

Ausschließlich auf RSA-Keys bei Zertifikaten muss man aber nicht mehr zwingend zurückgreifen, stehen doch aktuellere und zeitgemäßere Cipher, MACs, Schlüssel Typen und Key Exchange Algorithmen zur Verfügung. Alternativ zu einem Zertifikaten mit einem RSA-Key, wollen wir nun nun ein Zertifikat mit einem ed25519 Schlüssel verwenden. Ed25519 ist ein Elliptic Curve Signature Schema, welches beste Sicherheit bei vertretbaren Aufwand verspricht, als ECDSA oder DSA dies der Fall ist. Zur Auswahl sicherer kryptografischer Kurven bei der Elliptic-Curve Cryptography findet man auf der Seite hier hilfreiche Erklärungen und eine Gegenüberstellung der möglichen verschiedenen Alternativen.

Postfix unterstützt schon seit Version 2.6 den Parallelbetrieb mit ECDSA– / RSA-Zertifikaten. Zur Nutzung ist es natürlich erforderlich dass unser System über eine aktuelle OpenSSL-Implementierung verfügt - unter CentOS 7 sind wir hier bereits gut aufgestellt.

Schlüssel für das Serverzertifikat erzeugen

RSA-Key

Als erstes erzeugen wir nun 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

EC-Key

Nachdem wir unseren RSA-Schlüssel für den CSR erstellt haben, erzeugen wir nun im nächsten Schritt einen Schlüssel auf Basis EC10), den wir für unser ECDSA-Zertifikat benötigen. Auch hier ist die Eingaben sind in der Farbe blau gekennzeichnet.

# openssl ecparam -genkey -name secp384r1 > ecdsa-serverkey.pem

Der Schlüssel wird direkt ohne Passphrase erstellt und der Schlüssel wir auch ohne Rückmeldung auf Platte geschrieben. Wir werden nun auch noch bei dieser Schlüssel-Datei die Dateirechte anpassen, so dass niemand außer der User root diese lesen darf.

# chmod 400 ecdsa-serverkey.pem

Certificate Signing Request erzeugen

Im folgenden Schritt zu unserem eigenen Zertifikat erzeugen wir einen CSR11), 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.

Im Fall unseres RSA-Schlüssel geben wir beim Parameter -key die betreffende Schlüsseldatei serverkey.pem.

# 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) []: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 []:

Für unser ECDSA-Zertifikat oder besser gesagt für den zugehörigen CSR rufen wir den Befehl erneut auf, nur im Gegensatz zum ersten Aufruf geben wir nun bei der Option -key die richtige Schlüsseldatei ecdsa-serverkey.pem an.

# openssl req -new -key ecdsa-serverkey.pem -out ecdsa-csr.pem -nodes

Wollen oder müssen wir offizielle (kommerzielle) Zertifikate nutzen, so lassen wir die beiden CSRs der ausgewählten 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-----

und:

 # cat ecdsa-csr.pem
-----BEGIN CERTIFICATE REQUEST-----
MIIBkzCCARoCAQAwgZoxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP
BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRMwEQYDVQQLDApQ
b3N0b2ZmaWNlMRcwFQYDVQQDDA5teDEubmF1c2NoLm9yZzEkMCIGCSqGSIb3DQEJ
ARYVcG9zdG1hc3RlckBuYXVzY2gub3JnMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE
zj6OgeOixEALxP2HYGf9ANpE4hAnHgDCY35o9Rd9bKgWEDSV2WLNXP8U3YIJq46W
/p/+sYeVqN2lPNEHtX3QG/7Y3FqJnZ/2N/SehNPdMVQgaEAe6QXmTygH+Yu4OIxk
oAAwCgYIKoZIzj0EAwIDZwAwZAIwRimOgmP+SMUXlnz7auVkBwFiRyx8F/J8SRDr
rsLagViWUs256lyv3p2UAvIBEG01AjA1YG0yn/bgUQZASeCXZR2Uy6OmkZQwXm3j
hEMg1jwiW4tDLA5HTVDGixxcMa8A8J0=
-----END CERTIFICATE REQUEST-----

Bei Interesse können wir uns unseren CSR auch ansehen, dazu benutzen wir folgenden Befehl:

 # openssl req -noout -text -in ecdsa-csr.pem
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Postoffice, CN=mx1.nausch.org/emailAddress=postmaster@nausch.org
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub: 
                    04:ce:3e:8e:81:e3:a2:c4:40:0b:c4:fd:87:60:67:
                    fd:00:da:44:e2:10:27:1e:00:c2:63:7e:68:f5:17:
                    7d:6c:a8:16:10:34:95:d9:62:cd:5c:ff:14:dd:82:
                    09:ab:8e:96:fe:9f:fe:b1:87:95:a8:dd:a5:3c:d1:
                    07:b5:7d:d0:1b:fe:d8:dc:5a:89:9d:9f:f6:37:f4:
                    9e:84:d3:dd:31:54:20:68:40:1e:e9:05:e6:4f:28:
                    07:f9:8b:b8:38:8c:64
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        Attributes:
            a0:00
    Signature Algorithm: ecdsa-with-SHA256
         30:64:02:30:46:29:8e:82:63:fe:48:c5:17:96:7c:fb:6a:e5:
         64:07:01:62:47:2c:7c:17:f2:7c:49:10:eb:ae:c2:da:81:58:
         96:52:cd:b9:ea:5c:af:de:9d:94:02:f2:01:10:6d:35:02:30:
         35:60:6d:32:9f:f6:e0:51:06:40:49:e0:97:65:1d:94:cb:a3:
         a6:91:94:30:5e:6d:e3:84:43:20:d6:3c:22:5b:8b:43:2c:0e:
         47:4d:50:c6:8b:1c:5c:31:af:00:f0:9d

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

  1. unseren Serverzertifikat : servercert.pem
     # mv /etc/pki/CA/servercert.pem /etc/pki/postfix/certs/servercert.pem
  2. unseren Serverschlüssel : serverkey.pem
     # mv /etc/pki/CA/serverkey.pem /etc/pki/postfix/private/serverkey.pem
  3. das CA-Zertifikat : cacert.pem
     # cp /etc/pki/CA/cacert.pem /etc/pki/postfix/certs/
  4. und schützen diese Dateien mit den Dateirechten 400:
     # chmod 400 /etc/pki/postfix/private/*.pem
     # chmod 400 /etc/pki/postfix/certs/*.pem

Bevor wir uns nun mit der Konfiguration unseres MTAs beschäftigen, gehen wir nun kurz auf die für die Verschlüsselung zu Grunde liegende OpenSSL Implementierung und insbesondere auf das Thema Forward Secrecy und Enhanced Diffie Hellman Keys ein.

Bei der Standardinstallation unseres Systems wurde in der Regel bereits das Paket openssl installiert. Ein kurzer Blick in die RPM Datenbank schafft hierzu Gewissheit.

 # yum list openssl
Installed Packages
openssl.x86_64                                  1:1.0.2k-16.el7

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.2k
Release     : 16.el7
Architecture: x86_64
Install Date: Sat 26 Jan 2019 06:12:00 PM CET
Group       : System Environment/Libraries
Size        : 833647
License     : OpenSSL
Signature   : RSA/SHA256, Mon 12 Nov 2018 03:42:01 PM CET, Key ID 24c6a8a7f4a80eb5
Source RPM  : openssl-1.0.2k-16.el7.src.rpm
Build Date  : Tue 30 Oct 2018 11:43:57 PM CET
Build Host  : x86-01.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.2k
/usr/share/doc/openssl-1.0.2k/FAQ
/usr/share/doc/openssl-1.0.2k/NEWS
/usr/share/doc/openssl-1.0.2k/README
/usr/share/doc/openssl-1.0.2k/README.FIPS
/usr/share/doc/openssl-1.0.2k/README.legacy-settings
/usr/share/licenses/openssl-1.0.2k
/usr/share/licenses/openssl-1.0.2k/LICENSE
/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/dss1.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/sha224.1ssl.gz
/usr/share/man/man1/sha256.1ssl.gz
/usr/share/man/man1/sha384.1ssl.gz
/usr/share/man/man1/sha512.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/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-Suites12) (Chiffrensammlung) unser installiertes OpenSSL-Paket mitbringt, können wir wie folgt abfragen13).

 # 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
DH-DSS-AES256-GCM-SHA384      TLSv1.2 Kx=DH/DSS     Au=DH    Enc=AESGCM(256)   Mac=AEAD
DHE-DSS-AES256-GCM-SHA384     TLSv1.2 Kx=DH         Au=DSS   Enc=AESGCM(256)   Mac=AEAD
DH-RSA-AES256-GCM-SHA384      TLSv1.2 Kx=DH/RSA     Au=DH    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
DH-RSA-AES256-SHA256          TLSv1.2 Kx=DH/RSA     Au=DH    Enc=AES(256)      Mac=SHA256
DH-DSS-AES256-SHA256          TLSv1.2 Kx=DH/DSS     Au=DH    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
DH-RSA-AES256-SHA             SSLv3   Kx=DH/RSA     Au=DH    Enc=AES(256)      Mac=SHA1
DH-DSS-AES256-SHA             SSLv3   Kx=DH/DSS     Au=DH    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
DH-RSA-CAMELLIA256-SHA        SSLv3   Kx=DH/RSA     Au=DH    Enc=Camellia(256) Mac=SHA1
DH-DSS-CAMELLIA256-SHA        SSLv3   Kx=DH/DSS     Au=DH    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
DH-DSS-AES128-GCM-SHA256      TLSv1.2 Kx=DH/DSS     Au=DH    Enc=AESGCM(128)   Mac=AEAD
DHE-DSS-AES128-GCM-SHA256     TLSv1.2 Kx=DH         Au=DSS   Enc=AESGCM(128)   Mac=AEAD
DH-RSA-AES128-GCM-SHA256      TLSv1.2 Kx=DH/RSA     Au=DH    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
DH-RSA-AES128-SHA256          TLSv1.2 Kx=DH/RSA     Au=DH    Enc=AES(128)      Mac=SHA256
DH-DSS-AES128-SHA256          TLSv1.2 Kx=DH/DSS     Au=DH    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
DH-RSA-AES128-SHA             SSLv3   Kx=DH/RSA     Au=DH    Enc=AES(128)      Mac=SHA1
DH-DSS-AES128-SHA             SSLv3   Kx=DH/DSS     Au=DH    Enc=AES(128)      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
DH-RSA-SEED-SHA               SSLv3   Kx=DH/RSA     Au=DH    Enc=SEED(128)     Mac=SHA1
DH-DSS-SEED-SHA               SSLv3   Kx=DH/DSS     Au=DH    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
DH-RSA-CAMELLIA128-SHA        SSLv3   Kx=DH/RSA     Au=DH    Enc=Camellia(128) Mac=SHA1
DH-DSS-CAMELLIA128-SHA        SSLv3   Kx=DH/DSS     Au=DH    Enc=Camellia(128) 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
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
PSK-AES128-CBC-SHA            SSLv3   Kx=PSK        Au=PSK   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
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
DH-RSA-DES-CBC3-SHA           SSLv3   Kx=DH/RSA     Au=DH    Enc=3DES(168)     Mac=SHA1
DH-DSS-DES-CBC3-SHA           SSLv3   Kx=DH/DSS     Au=DH    Enc=3DES(168)     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
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-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 DH14) sowie den weiterentwickelten ECDH15).

In Summe bietet uns also OpenSSL 1.0.2k-fips16) in Summe 51 Forward-Secrecy-tauglichen Verschlüsselungsverfahren.

 # openssl ciphers -v 'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' | wc -l
51

Enhanced Diffie Hellman Keys

Postfix stellt Forward Secrecy bereits ohne besondere zusätzliche Konfiguration zur Verfügung. Allerdings werden für den Schlüsselaustausch, die bei der Postfix-Installation vordefinierte mitgelieferten Schlüssel verwendet, 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) 2019
cd /etc/pki/tls/tmp
umask 022
openssl dhparam -out dh_512.pem  -2  512
openssl dhparam -out dh_1024.pem -2 1024
openssl dhparam -out dh_2048.pem -2 2048
openssl dhparam -out dh_4096.pem -2 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

Dass es für eine verschlüsselte Kommunikation zwischen Mailsevern und auch zwischen Endnutzern und Mailserver gute Gründe gibt, wurde zu Beginn dieses Kapitels bereits ausführlich betrachtet. Noch vor Jahren war dieses Sebstverständnis bei weitem noch nicht so ausgeprägt, sei es durch Unwissenheit, Ignoranz oder auch Vorgaben durch Dritte. Wirft man einen Blick nun in Langzeitstatistiken kann man jedoch feststellen, dass über die Jahre der Anteil verschlüsselter und vor allem auch geprüfter verschlüsselter Verbindungen stark zugenommen haben. Genauere technische Details zur TLS-Verschlüsselung sind im RFC 7525 geregelt

Beim Thema Verschlüsselung kommt es natürlich auch immer auf beide Kommunikationspartner an. Es kann sich einer von beiden noch so anstrengen und ggf. mit viel Geld versuchen eine Verschlüsselung anzubieten oder versuchen zu initiieren, wenn der Kommunikationspartner nicht will oder kann, wird dieses Vorhaben zum Scheitern verurteilt sein. Denkbar sind hierbei mehrere Ursachen/Möglichkeiten:

  • Einer der beiden Partner kann oder will gar nicht,
  • beide Partner wollen zwar, können sich aber auf kein gemeinsames Verfahren (TLS-Version) einigen, oder
  • die angebotenen bzw. nutzbaren Cipher-Protokoll-Suiten passen nicht zueinander. Und zu guter Letzt gibt es auch noch die denkbare und mögliche Variante, dass
  • ein außenstehender Dritter den Wechsel von der unverschlüsselten Verbindung mit Hilfe des SMTP-Befehls STARTTLS durch Manipulation dieses Befehls verhindert.

Die Konfiguration der TLS-Optionen für den SMTP-Client für den Versand der Nachrichten wie auch für den SMTP-Daemon, der für den die Nachrichtenempfang zuständig ist, 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:

  1. privaten Schlüssel/Serverkey, den bzw. die wir auf unserem Server erstellt haben.
  2. Zertifikat(e), welches die CA17) an Hand unseres bzw. unserer CSR18) erstellt und mit dem Root- bzw. intermediate Zertifikat signiert hat.
  3. 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

bzw. bei Verwendung eines ECDSA-Schlüssels/Zertifikates,

  • smtpd_tls_kecey_file,
  • smtpd_tls_eccert_file und
  • smtpd_tls_CAfile

zu. In nachfolgendem Konfigurationsbeispiel gehen von der Verwendung beider Schlüssel/Zertifikate aus:

  1. privaten Schlüssel/Serverkey:
    Die beiden privaten Schlüssel/Serverkey haben wir in der Dateien serverkey.pem und ecdsa-serverkey.pem im Verzeichnis /etc/pki/postfix/private/ abgelegt.

    /etc/pki/postfix/private/
    ├── dh_1024.pem
    ├── dh_2048.pem
    ├── dh_4096.pem
    ├── dh_512.pem
    ├── ecdsa-serverkey.pem
    └── serverkey.pem
  2. Zertifikat:
    Das bzw. die Serverzertifikat(e), welche(s) wir von der ausstellenden CA erhalten haben, legen wir im Verzeichnis /etc/pki/postfix/certs/ ab. In unserem Konfigurationsbeispiel wäre das die beiden Dateien rsa-servercert.pem und ecdsa-servercert.pem.

     # less /etc/pki/postfix/certs/rsa-servercert.pem
    -----BEGIN CERTIFICATE-----
    MIIH0DCCBrigAwIBAgIMY8a8PUtkjjqQMKTgMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
    BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
    bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE4MDExOTEwMjkwOFoXDTIwMTIx
    OTA5NDIxNVowOjEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRUw
    EwYDVQQDDAwqLm5hdXNjaC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
    AoICAQDlCD/G1lwtYBU1sTvgPkfzGG8cogT+oEidIUXrcJB3CPxZho3OqR7rfPp/
    OxYJRKTEzuKEadsn6wcfDL/3+WkO6kkJaBYYK2brW4FYXi2xhQAshGt7OrHFJgs1
    395BSgFDyA+7fGJ7MRuKwpGKotY1kNIynnys7eyuMsFJJQuqMPhwovpo/siFAK+W
    OXSu6xygsKuXEgAEag59yVbUwJLDSWV7KkFyiVyFgmDGbMSy1gazMLRlR688CYXD
    HwsmhgTTYHG5rS7MeJxK7uVW4poowSehLfX/wnHDoz2T96vP3+36tpr/Wylmzdlh
    pCEkHcXLT+X6eL9eYA7c7PkX5QvUom5uyuYWjhrp/TKfbl85en5UflG/kpFcaKdE
    MzTNGLlHALgYsGvfmsnH51wi13T5decxpw93zjWVQWQQl2S0mNlTJCnTLfVtiySy
    LiiI6wKuDvEwAtTx2sbZChjuXMR2QgxtPi2yeOSSQuxTOXlHeSbirbXNMqEjSAAD
    /UaWZAsH+SlHXiTPaDzTvDLng5jEUGlj4XPSgO0/S5fLoZNw+iHmypYGYnIMdr18
    O8Z129DugKLlHsquu+sXhgUn5dOtU4hlOHyG21TL5QYWKLWXq3sDfDhMzWYEALOu
    GRCALmrOfYpoBGeIv0K79JQ1Mn7CP7YTXB86pCL2xKJ3vtMUoQIDAQABo4IDwjCC
    A74wDgYDVR0PAQH/BAQDAgWgMIGJBggrBgEFBQcBAQR9MHswQgYIKwYBBQUHMAKG
    Nmh0dHA6Ly9zZWN1cmUyLmFscGhhc3NsLmNvbS9jYWNlcnQvZ3NhbHBoYXNoYTJn
    MnIxLmNydDA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29t
    L2dzYWxwaGFzaGEyZzIwVwYDVR0gBFAwTjBCBgorBgEEAaAyAQoKMDQwMgYIKwYB
    BQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMAgG
    BmeBDAECATAJBgNVHRMEAjAAMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9jcmwy
    LmFscGhhc3NsLmNvbS9ncy9nc2FscGhhc2hhMmcyLmNybDAjBgNVHREEHDAaggwq
    Lm5hdXNjaC5vcmeCCm5hdXNjaC5vcmcwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
    AQUFBwMCMB0GA1UdDgQWBBQDyR3b2ZT36dAxFdDx8Gb7rhlQyDAfBgNVHSMEGDAW
    gBT1zdU8CFD5ak86t5faVoPmadJo9zCCAfYGCisGAQQB1nkCBAIEggHmBIIB4gHg
    AHYA3esdK3oNT6Ygi4GtgWhwfi6OnQHVXIiNPRHEzbbsvswAAAFhDfcNVwAABAMA
    RzBFAiB9DzV7lyGG74++y4ZdBrHErsl1SX0nl5u51EjbIfmJvgIhAJfjKv08kN6t
    HXgb7+Ggsn+5TBCdJF4FXioUkY067f5RAHYAVhQGmi/XwuzT9eG9RLI+x0Z2ubyZ
    EVzA75SYVdaJ0N0AAAFhDfcNnAAABAMARzBFAiEA8nWr7yM/wAps1ze3AdauLZni
    +u97cFqzhWcM0fhFhXUCIBpbaFBevhAitT/taBQTVR7ExsthhTWOZ+063vAYHE0+
    AHcApLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN3BAAAAFhDfcQBQAABAMA
    SDBGAiEAtBVo0LvPgMlnHGGm2EN28yiuTxxO1Rlr+2hChCH/NgsCIQDi8uy+ji9e
    IORPAztAXRfPZcVXPUHdfCyonVjyluDWgQB1ALvZ37wfinG1k5Qjl6qSe0c4V5UK
    q1LoGpCWZDaOHtGFAAABYQ33EMUAAAQDAEYwRAIgNBUnjJs3WW/Y28Bc+nGIJCQz
    0YxM33sIjB6UklMHAxICIHZmbTgv4jRbzlwS5O0FeXU+W7p0YqWva+bfC1Saa1Sl
    MA0GCSqGSIb3DQEBCwUAA4IBAQApFh9mA/CrtzOXPAMq5M16yfcXvfoITGmj51xy
    J3qVnhcArTmo/l9zV66sBVJWlZYVVFnmDJO9pXboowVONhwmUjjLsdAMkdh3l74B
    CZtgjexGtGBzdtn5uI3CFArviBRcYraJ4xmW5IA9MjfN9SRb22gbjbdOKArXcGF9
    wxbWXm+u/GMeA0Wi9v16q75Mk+4jPV6YL0Ntz3fISv/knfR/7Vxt5Ms/+AcYytba
    rF4jI8lVL3OL4db0I8JimakS2bh1P9GTDzYw7nFfwe8WzPP1Eq1SSr7/mdhM0bNw
    R+tVuCsTWMn9SiXbrQzq7sSwzUkTIxkkWe78QEBE8ki/e+jM
    -----END CERTIFICATE-----
     # less /etc/pki/postfix/certs/ecdsa-servercert.pem
    -----BEGIN CERTIFICATE-----
    MIIFrjCCBJagAwIBAgIMApNDoSN56juh4oE5MA0GCSqGSIb3DQEBCwUAMEwxCzAJ
    BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
    bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE5MDIxMTExNDcwMVoXDTIxMDIx
    MTA3NTQ0MFowSTELMAkGA1UEBhMCREUxITAfBgNVBAsTGERvbWFpbiBDb250cm9s
    IFZhbGlkYXRlZDEXMBUGA1UEAxMObXgxLm5hdXNjaC5vcmcwdjAQBgcqhkjOPQIB
    BgUrgQQAIgNiAATOPo6B46LEQAvE/YdgZ/0A2kTiECceAMJjfmj1F31sqBYQNJXZ
    Ys1c/xTdggmrjpb+n/6xh5Wo3aU80Qe1fdAb/tjcWomdn/Y39J6E090xVCBoQB7p
    BeZPKAf5i7g4jGSjggM/MIIDOzAOBgNVHQ8BAf8EBAMCA4gwgYkGCCsGAQUFBwEB
    BH0wezBCBggrBgEFBQcwAoY2aHR0cDovL3NlY3VyZTIuYWxwaGFzc2wuY29tL2Nh
    Y2VydC9nc2FscGhhc2hhMmcycjEuY3J0MDUGCCsGAQUFBzABhilodHRwOi8vb2Nz
    cDIuZ2xvYmFsc2lnbi5jb20vZ3NhbHBoYXNoYTJnMjBXBgNVHSAEUDBOMEIGCisG
    AQQBoDIBCgowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j
    b20vcmVwb3NpdG9yeS8wCAYGZ4EMAQIBMAkGA1UdEwQCMAAwPgYDVR0fBDcwNTAz
    oDGgL4YtaHR0cDovL2NybDIuYWxwaGFzc2wuY29tL2dzL2dzYWxwaGFzaGEyZzIu
    Y3JsMBkGA1UdEQQSMBCCDm14MS5uYXVzY2gub3JnMB0GA1UdJQQWMBQGCCsGAQUF
    BwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQU4KkvjEsSjOHjrZtO0+WtQVu4huQwHwYD
    VR0jBBgwFoAU9c3VPAhQ+WpPOreX2laD5mnSaPcwggF9BgorBgEEAdZ5AgQCBIIB
    bQSCAWkBZwB2AFWB1MIWkDYBSuoLm1c8U/DA5Dh4cCUIFy+jqh0HE9MMAAABaNxh
    y6QAAAQDAEcwRQIhALLZ7bCbaXKUTPIQyzpXZ+spyVGlAJk8mDsb6Dtwp9mKAiAx
    O0walYwTiKADam3DswoeUeW/H5F3Xv2IngbIpQCHcQB2AKS5CZC0GFgUh7sTosxn
    cAo8NZgE+RvfuON3zQ7IDdwQAAABaNxhy4sAAAQDAEcwRQIgUkR0TQf/mTd0B93v
    drzZdlAmfn6PujwCd/BK4IpfQ98CIQCgtcxyu/bnjw9i9gE/58GWp1j0+lCNQkCe
    BkkWMbhF8gB1AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABaNxh
    y8QAAAQDAEYwRAIgM8oFFMaYS9yeX0tif6YcHj9Nak/bUtHwGx+K0E3mTK0CIBBq
    i9iEl/E79vC02SqxnxE5kT6VQq5nNs7KY/pJb/PLMA0GCSqGSIb3DQEBCwUAA4IB
    AQAvu5ioSMJpSfUx7krIcoAvQyBh9pfMCDXhu/nkQcVX5opEV2YhM1xDtMgpFyLL
    BJKRAuiZhqVkgLx1AON2MdB2s9/9xg6/OMBNpX1uoN+/lELdEz0qLtVBfZp4+HlO
    BA3fuwtqE5SGRCKUhH+/B5HzajfmRgouUoOxtxItXlqzRszMCuguXVRRJBbHmvTH
    dpKcNT3MTJjN8wtqRLAsjG3xFRrpilnHjCgQQZJWMfzlaSI/6hiB5cWnCyIpINxe
    liaMDWRK5U25sCrNuF2fH47EnozWNoaOmU3QHvCW7tHMnA/+UC7J8YnvavfvkAfn
    NE63Uo6TqLjkgtRpLmBf2CBM
    -----END CERTIFICATE-----
  3. 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.

    Das zu unserem Serverzertifikat passende Intermediate oder auch als Zwischenzertifikat bezeichnet, stellt uns in aller Regel die Ausstellende CA automatisch zur Verfügung. Dieses Zertifikat legen wir in einer Datei im Verzeichnis /etc/pki/postfix/certs/ ab.

     # vim AlphaSSL_Intermediate.certificate.pem
    -----BEGIN CERTIFICATE-----
    MIIETTCCAzWgAwIBAgILBAAAAAABRE7wNjEwDQYJKoZIhvcNAQELBQAwVzELMAkG
    A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
    b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
    MDBaFw0yNDAyMjAxMDAwMDBaMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
    YWxTaWduIG52LXNhMSIwIAYDVQQDExlBbHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcy
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2gHs5OxzYPt+j2q3xhfj
    kmQy1KwA2aIPue3ua4qGypJn2XTXXUcCPI9A1p5tFM3D2ik5pw8FCmiiZhoexLKL
    dljlq10dj0CzOYvvHoN9ItDjqQAu7FPPYhmFRChMwCfLew7sEGQAEKQFzKByvkFs
    MVtI5LHsuSPrVU3QfWJKpbSlpFmFxSWRpv6mCZ8GEG2PgQxkQF5zAJrgLmWYVBAA
    cJjI4e00X9icxw3A1iNZRfz+VXqG7pRgIvGu0eZVRvaZxRsIdF+ssGSEj4k4HKGn
    kCFPAm694GFn1PhChw8K98kEbSqpL+9Cpd/do1PbmB6B+Zpye1reTz5/olig4het
    ZwIDAQABo4IBIzCCAR8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
    AQAwHQYDVR0OBBYEFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MEUGA1UdIAQ+MDwwOgYE
    VR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hbHBoYXNzbC5jb20vcmVw
    b3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWdu
    Lm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6
    Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
    yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQsFAAOCAQEAYEBoFkfnFo3bXKFWKsv0
    XJuwHqJL9csCP/gLofKnQtS3TOvjZoDzJUN4LhsXVgdSGMvRqOzm+3M+pGKMgLTS
    xRJzo9P6Aji+Yz2EuJnB8br3n8NA0VgYU8Fi3a8YQn80TsVD1XGwMADH45CuP1eG
    l87qDBKOInDjZqdUfy4oy9RU0LMeYmcI+Sfhy+NmuCQbiWqJRGXy2UzSWByMTsCV
    odTvZy84IOgu/5ZR8LrYPZJwR2UcnnNytGAMXOLRc3bgr07i5TelRS+KIz6HxzDm
    MTh89N1SyvNTBCVXVmaU6Avu5gMUTu79bZRknl7OedSyps9AsUSoPocZXun4IRZZ
    Uw==
    -----END CERTIFICATE-----

    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/servercert.pem
    subject= /C=DE/OU=Domain Control Validated/CN=mx1.nausch.org
    issuer= /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
    notBefore=Feb 11 11:47:01 2019 GMT
    notAfter=Feb 11 07:54:40 2021 GMT

    Wir benötigen also das Zertifikat des CN=AlphaSSL CA - SHA256 - G2. Wir besorgen uns nun dieses Root-Zertifikat von der CA=GlobalSign.

     # vim AlphaSSL_Intermediate.certificate.pem
    -----BEGIN CERTIFICATE-----
    MIIETTCCAzWgAwIBAgILBAAAAAABRE7wNjEwDQYJKoZIhvcNAQELBQAwVzELMAkG
    A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
    b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
    MDBaFw0yNDAyMjAxMDAwMDBaMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
    YWxTaWduIG52LXNhMSIwIAYDVQQDExlBbHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcy
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2gHs5OxzYPt+j2q3xhfj
    kmQy1KwA2aIPue3ua4qGypJn2XTXXUcCPI9A1p5tFM3D2ik5pw8FCmiiZhoexLKL
    dljlq10dj0CzOYvvHoN9ItDjqQAu7FPPYhmFRChMwCfLew7sEGQAEKQFzKByvkFs
    MVtI5LHsuSPrVU3QfWJKpbSlpFmFxSWRpv6mCZ8GEG2PgQxkQF5zAJrgLmWYVBAA
    cJjI4e00X9icxw3A1iNZRfz+VXqG7pRgIvGu0eZVRvaZxRsIdF+ssGSEj4k4HKGn
    kCFPAm694GFn1PhChw8K98kEbSqpL+9Cpd/do1PbmB6B+Zpye1reTz5/olig4het
    ZwIDAQABo4IBIzCCAR8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
    AQAwHQYDVR0OBBYEFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MEUGA1UdIAQ+MDwwOgYE
    VR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hbHBoYXNzbC5jb20vcmVw
    b3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWdu
    Lm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6
    Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
    yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQsFAAOCAQEAYEBoFkfnFo3bXKFWKsv0
    XJuwHqJL9csCP/gLofKnQtS3TOvjZoDzJUN4LhsXVgdSGMvRqOzm+3M+pGKMgLTS
    xRJzo9P6Aji+Yz2EuJnB8br3n8NA0VgYU8Fi3a8YQn80TsVD1XGwMADH45CuP1eG
    l87qDBKOInDjZqdUfy4oy9RU0LMeYmcI+Sfhy+NmuCQbiWqJRGXy2UzSWByMTsCV
    odTvZy84IOgu/5ZR8LrYPZJwR2UcnnNytGAMXOLRc3bgr07i5TelRS+KIz6HxzDm
    MTh89N1SyvNTBCVXVmaU6Avu5gMUTu79bZRknl7OedSyps9AsUSoPocZXun4IRZZ
    Uw==
    -----END CERTIFICATE-----

    Zum Einbinden in unseren Postfix-Server benötigen wir nun eine Datei mit den beiden Zertifikaten, dem Server-Zertifikat und dem zugehörigen Intermediate-Zertifikat.

    Damit wir später leichter die Zertifikate zuordnen können, kopieren wir die Ausgaben der obigen openssl-Aufrufe zusammen mit den zugehörigen Zertifikaten eine einzige Zertifikatsdatei.

    Als erstes generieren wir uns unser Zertifikats-Chain-File mit dem RSA-Zertifikat.

     # openssl x509 -subject -issuer -dates -noout -in rsa-servercert.pem > rsa-full_certificate_chain.pem && \
        cat rsa-servercert.pem >> rsa-full_certificate_chain.pem && \
        openssl x509 -subject -issuer -dates -noout -in AlphaSSL_Intermediate.certificate.pem >> rsa-full_certificate_chain.pem && \
        cat AlphaSSL_Intermediate.certificate.pem >> rsa-full_certificate_chain.pem

    Das Gleiche machen wir nun mit unserem ECDSA-Zertifikat:

     # openssl x509 -subject -issuer -dates -noout -in ecdsa-servercert.pem > ecdsa-full_certificate_chain.pem && \
        cat ecdsa-servercert.pem >> ecdsa-full_certificate_chain.pem && \
        openssl x509 -subject -issuer -dates -noout -in AlphaSSL_Intermediate.certificate.pem >> ecdsa-full_certificate_chain.pem && \
        cat AlphaSSL_Intermediate.certificate.pem >> ecdsa-full_certificate_chain.pem

    Wir erhalten somit 2 Dateien mit den jeweiligen Zertifikaten. Beim nachfolgenden Beispiel werfen wir einfach einen Blick in die ECDSA-Zertifikatsdatei.

     # cat ecdsa-full_certificate_chain.pem
    /etc/pki/postfix/certs/ecdsa-full_certificate_chain.pem
    subject= /C=DE/OU=Domain Control Validated/CN=mx1.nausch.org
    issuer= /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
    notBefore=Feb 11 11:47:01 2019 GMT
    notAfter=Feb 11 07:54:40 2021 GMT
    -----BEGIN CERTIFICATE-----
    MIIFrjCCBJagAwIBAgIMApNDoSN56juh4oE5MA0GCSqGSIb3DQEBCwUAMEwxCzAJ
    BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
    bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE5MDIxMTExNDcwMVoXDTIxMDIx
    MTA3NTQ0MFowSTELMAkGA1UEBhMCREUxITAfBgNVBAsTGERvbWFpbiBDb250cm9s
    IFZhbGlkYXRlZDEXMBUGA1UEAxMObXgxLm5hdXNjaC5vcmcwdjAQBgcqhkjOPQIB
    BgUrgQQAIgNiAATOPo6B46LEQAvE/YdgZ/0A2kTiECceAMJjfmj1F31sqBYQNJXZ
    Ys1c/xTdggmrjpb+n/6xh5Wo3aU80Qe1fdAb/tjcWomdn/Y39J6E090xVCBoQB7p
    BeZPKAf5i7g4jGSjggM/MIIDOzAOBgNVHQ8BAf8EBAMCA4gwgYkGCCsGAQUFBwEB
    BH0wezBCBggrBgEFBQcwAoY2aHR0cDovL3NlY3VyZTIuYWxwaGFzc2wuY29tL2Nh
    Y2VydC9nc2FscGhhc2hhMmcycjEuY3J0MDUGCCsGAQUFBzABhilodHRwOi8vb2Nz
    cDIuZ2xvYmFsc2lnbi5jb20vZ3NhbHBoYXNoYTJnMjBXBgNVHSAEUDBOMEIGCisG
    AQQBoDIBCgowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j
    b20vcmVwb3NpdG9yeS8wCAYGZ4EMAQIBMAkGA1UdEwQCMAAwPgYDVR0fBDcwNTAz
    oDGgL4YtaHR0cDovL2NybDIuYWxwaGFzc2wuY29tL2dzL2dzYWxwaGFzaGEyZzIu
    Y3JsMBkGA1UdEQQSMBCCDm14MS5uYXVzY2gub3JnMB0GA1UdJQQWMBQGCCsGAQUF
    BwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQU4KkvjEsSjOHjrZtO0+WtQVu4huQwHwYD
    VR0jBBgwFoAU9c3VPAhQ+WpPOreX2laD5mnSaPcwggF9BgorBgEEAdZ5AgQCBIIB
    bQSCAWkBZwB2AFWB1MIWkDYBSuoLm1c8U/DA5Dh4cCUIFy+jqh0HE9MMAAABaNxh
    y6QAAAQDAEcwRQIhALLZ7bCbaXKUTPIQyzpXZ+spyVGlAJk8mDsb6Dtwp9mKAiAx
    O0walYwTiKADam3DswoeUeW/H5F3Xv2IngbIpQCHcQB2AKS5CZC0GFgUh7sTosxn
    cAo8NZgE+RvfuON3zQ7IDdwQAAABaNxhy4sAAAQDAEcwRQIgUkR0TQf/mTd0B93v
    drzZdlAmfn6PujwCd/BK4IpfQ98CIQCgtcxyu/bnjw9i9gE/58GWp1j0+lCNQkCe
    BkkWMbhF8gB1AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABaNxh
    y8QAAAQDAEYwRAIgM8oFFMaYS9yeX0tif6YcHj9Nak/bUtHwGx+K0E3mTK0CIBBq
    i9iEl/E79vC02SqxnxE5kT6VQq5nNs7KY/pJb/PLMA0GCSqGSIb3DQEBCwUAA4IB
    AQAvu5ioSMJpSfUx7krIcoAvQyBh9pfMCDXhu/nkQcVX5opEV2YhM1xDtMgpFyLL
    BJKRAuiZhqVkgLx1AON2MdB2s9/9xg6/OMBNpX1uoN+/lELdEz0qLtVBfZp4+HlO
    BA3fuwtqE5SGRCKUhH+/B5HzajfmRgouUoOxtxItXlqzRszMCuguXVRRJBbHmvTH
    dpKcNT3MTJjN8wtqRLAsjG3xFRrpilnHjCgQQZJWMfzlaSI/6hiB5cWnCyIpINxe
    liaMDWRK5U25sCrNuF2fH47EnozWNoaOmU3QHvCW7tHMnA/+UC7J8YnvavfvkAfn
    NE63Uo6TqLjkgtRpLmBf2CBM
    -----END CERTIFICATE-----
    subject= /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
    issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
    notBefore=Feb 20 10:00:00 2014 GMT
    notAfter=Feb 20 10:00:00 2024 GMT
    -----BEGIN CERTIFICATE-----
    MIIETTCCAzWgAwIBAgILBAAAAAABRE7wNjEwDQYJKoZIhvcNAQELBQAwVzELMAkG
    A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
    b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
    MDBaFw0yNDAyMjAxMDAwMDBaMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
    YWxTaWduIG52LXNhMSIwIAYDVQQDExlBbHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcy
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2gHs5OxzYPt+j2q3xhfj
    kmQy1KwA2aIPue3ua4qGypJn2XTXXUcCPI9A1p5tFM3D2ik5pw8FCmiiZhoexLKL
    dljlq10dj0CzOYvvHoN9ItDjqQAu7FPPYhmFRChMwCfLew7sEGQAEKQFzKByvkFs
    MVtI5LHsuSPrVU3QfWJKpbSlpFmFxSWRpv6mCZ8GEG2PgQxkQF5zAJrgLmWYVBAA
    cJjI4e00X9icxw3A1iNZRfz+VXqG7pRgIvGu0eZVRvaZxRsIdF+ssGSEj4k4HKGn
    kCFPAm694GFn1PhChw8K98kEbSqpL+9Cpd/do1PbmB6B+Zpye1reTz5/olig4het
    ZwIDAQABo4IBIzCCAR8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
    AQAwHQYDVR0OBBYEFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MEUGA1UdIAQ+MDwwOgYE
    VR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hbHBoYXNzbC5jb20vcmVw
    b3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWdu
    Lm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6
    Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
    yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQsFAAOCAQEAYEBoFkfnFo3bXKFWKsv0
    XJuwHqJL9csCP/gLofKnQtS3TOvjZoDzJUN4LhsXVgdSGMvRqOzm+3M+pGKMgLTS
    xRJzo9P6Aji+Yz2EuJnB8br3n8NA0VgYU8Fi3a8YQn80TsVD1XGwMADH45CuP1eG
    l87qDBKOInDjZqdUfy4oy9RU0LMeYmcI+Sfhy+NmuCQbiWqJRGXy2UzSWByMTsCV
    odTvZy84IOgu/5ZR8LrYPZJwR2UcnnNytGAMXOLRc3bgr07i5TelRS+KIz6HxzDm
    MTh89N1SyvNTBCVXVmaU6Avu5gMUTu79bZRknl7OedSyps9AsUSoPocZXun4IRZZ
    Uw==
    -----END CERTIFICATE-----

In unserem Konfigurationsverzeichnis /etc/pki/postfix/certs befinden sich nun folgende Dateien.

/etc/pki/tls/certs/
├── AlphaSSL_Intermediate.certificate.pem
├── ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
├── ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
├── ecdsa-full_certificate_chain.pem
├── ecdsa-servercert.pem
├── make-dummy-cert
├── Makefile
├── renew-dummy-cert
├── rsa-full_certificate_chain.pem
└── rsa-servercert.pem

Nun Stellen wir die beiden Zertifikate (RSA und ECDSA) und die zugehörigen Schlüssel unserem MTA zur Verfügung. Nun Ferner definieren wir noch, wo der Postfix Daemon das CA-Bundlefile finden kann. Hierzu legen wir uns in Haupkonfigurationsdatei main.cf eine eigene Sektion TLS/SSL-VERSCHLÜSSELUNG an.

 # vim /etc/postfix/main.cf
...

################################################################################
## TLS/SSL-VERSCHLÜSSELUNG
#
# Django : 2019-02-11 - SSL/TLS - Schutz durch verschlüsselte Verbindungen
#          (Postfixbuch: Kapitel 20.2)
#          Pfade für die Key- und Zertifikatsdateien
# default: smtpd_tls_key_file = $smtpd_tls_cert_file
#          smtpd_tls_cert_file =
#          smtpd_tls_CAfile =
#          smtp_tls_CAfile =

# RSA-Zertifikat für den SMTP-Daemon
smtpd_tls_key_file    = /etc/pki/postfix/private/rsa-serverkey.pem
smtpd_tls_cert_file   = /etc/pki/postfix/certs/rsa-full_certificate_chain.pem

# ECDSA-Zertifikat für den SMTP-Daemon
smtpd_tls_eckey_file  = /etc/pki/postfix/private/ecdsa-serverkey.pem
smtpd_tls_eccert_file = /etc/pki/postfix/certs/ecdsa-full_certificate_chain.pem

# CA-Bundle für den SMTP-Daemon
smtpd_tls_CAfile    = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

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 ; Mon, 11 Jan 2019 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 Client 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 : 2019-02-11 - 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 ; Mon, 11 Jan 2019 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.

Nimmt unser Mailserver nun Nachrichten über einen TLS-verschlüsselten Transportweg entgegen, frägt er den Client 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 ; Mon, 11 Jan 2019 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 mx1.nausch.org (mx1.nausch.org [217.92.13.131])
	  (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) weißt 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.

################################################################################
## TLS/SSL-VERSCHLÜSSELUNG
#
# Django : 2019-02-11 - SSL/TLS - Schutz durch verschlüsselte Verbindungen
#          (Postfixbuch: Kapitel 20.2)
#          Pfade für die Key- und Zertifikatsdateien
# default: smtpd_tls_key_file = $smtpd_tls_cert_file
#          smtpd_tls_cert_file =
#          smtpd_tls_CAfile =
#          smtp_tls_CAfile =

# RSA-Zertifikat für den SMTP-Daemon
smtpd_tls_key_file    = /etc/pki/postfix/private/rsa-serverkey.pem
smtpd_tls_cert_file   = /etc/pki/postfix/certs/rsa-full_certificate_chain.pem

# ECDSA-Zertifikat für den SMTP-Daemon
smtpd_tls_eckey_file  = /etc/pki/postfix/private/ecdsa-serverkey.pem
smtpd_tls_eccert_file = /etc/pki/postfix/certs/ecdsa-full_certificate_chain.pem

# CA-Bundle für den SMTP-Daemon
smtpd_tls_CAfile      = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# RSA-Zertifikat für den SMTP-Client
smtp_tls_key_file     = $smtpd_tls_key_file
smtp_tls_cert_file    = $smtpd_tls_cert_file

# ECDSA-Zertifikat für den SMTP-Client
smtp_tls_eckey_file   = $smtpd_tls_eckey_file
smtp_tls_eccert_file  = $smtpd_tls_eccert_file

CA-Bundle für den SMTP-Client
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 "mx1.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 mx1.nausch.org (mx1.nausch.org [217.92.13.131])
	  (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	  (Client CN "mx1.nausch.org", Issuer "AlphaSSL CA - SHA256 - G2" (verified OK))
	  by mx1.piratenpartei-bayern.de (Postfix) with ESMTPS
	  for ; Mon, 11 Feb 2019 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.

Feb 11 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.

################################################################################
## TLS/SSL-VERSCHLÜSSELUNG
#
# Django : 2019-02-11 - SSL/TLS - Schutz durch verschlüsselte Verbindungen
#          (Postfixbuch: Kapitel 20.2)
#          Pfade für die Key- und Zertifikatsdateien
# default: smtpd_tls_key_file = $smtpd_tls_cert_file
#          smtpd_tls_cert_file =
#          smtpd_tls_CAfile =
#          smtp_tls_CAfile =

# RSA-Zertifikat für den SMTP-Daemon
smtpd_tls_key_file    = /etc/pki/postfix/private/rsa-serverkey.pem
smtpd_tls_cert_file   = /etc/pki/postfix/certs/rsa-full_certificate_chain.pem

# ECDSA-Zertifikat für den SMTP-Daemon
smtpd_tls_eckey_file  = /etc/pki/postfix/private/ecdsa-serverkey.pem
smtpd_tls_eccert_file = /etc/pki/postfix/certs/ecdsa-full_certificate_chain.pem

# CA-Bundle für den SMTP-Daemon
smtpd_tls_CAfile      = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# RSA-Zertifikat für den SMTP-Client
smtp_tls_key_file     = $smtpd_tls_key_file
smtp_tls_cert_file    = $smtpd_tls_cert_file

# ECDSA-Zertifikat für den SMTP-Client
smtp_tls_eckey_file   = $smtpd_tls_eckey_file
smtp_tls_eccert_file  = $smtpd_tls_eccert_file

# CA-Bundle für den SMTP-Client
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 vermerkt.

Feb 11 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!

Laut den Hinweisen in der Original-Dokumentation wird sogar eindringlich gewarnt:
Es wird dringend empfohlen, diese Einstellung nicht zu ändern.

# Django : 2019-02-11 - Die OpenSSL-Chiffre-Liste für "hochgradige" Chiffren bei den "high" Settings
#          der Optionen smtpd_tls_ciphers, smtpd_tls_mandatory_ciphers, smtp_tls_ciphers, 
#          smtp_tls_mandatory_ciphers, lmtp_tls_ciphers, and lmtp_tls_mandatory_ciphers
#          http://www.postfix.org/postconf.5.html#tls_high_cipherlist
#          http://postfix.1071664.n5.nabble.com/ECDSA-and-RSA-setting-preference-td89971.html
# default: tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_high_cipherlist = ECDSA:AESGCM:aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH

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 : 2019-02-11 - 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
smtpd_tls_ciphers = high

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 : 2019-02-11 - 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
smtp_tls_ciphers = high

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 : 2019-02-11 - 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
           CBC-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 : 2019-02-11 - 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 =
           eNULL
           EXPORT
           DES
           3DES
           RC4
           MD5
           PSK
           aECDH
           EDH-DSS-DES-CBC3-SHA
           EDH-RSA-DES-CDC3-SHA
           KRB5-DE5
           CBC3-SHA
           CBC-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 : 2019-02-11 - 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 : 2019-02-11 - 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 : 2019-02-11 - 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
           3DES
           RC4
           MD5
           PSK
           aECDH
           EDH-DSS-DES-CBC3-SHA
           EDH-RSA-DES-CDC3-SHA
           KRB5-DE5
           CBC3-SHA
           CBC-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 : 2019-02-11 - 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 =
           aNULL
           eNULL
           EXPORT
           DES
           3DES
           RC4
           MD5
           PSK
           aECDH
           EDH-DSS-DES-CBC3-SHA
           EDH-RSA-DES-CDC3-SHA
           KRB5-DE5
           CBC3-SHA
           CBC-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 : 2019-02-11 - 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
           #!TLSv1
           #!TLSv1.1

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 : 2019-02-11 - 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
           #!TLSv1
           #!TLSv1.1
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 : 2019-02-11 - 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
           #!TLSv1
           #!TLSv1.1

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 : 2019-02-11 - 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
           #!TLSv1
           #!TLSv1.1
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 : 2019-02-11 - 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 ausschließlich für dedizierte Mailserver erlaubt.

Öffentlich erreichbare Mailserver müssen neben einer TLS-geschützen Übertragung auch PLAIN-TEXT Übertragungen zulassen!

# Django : 2019-02-11 - 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 = may19) 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 : 2019-02-11 - 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 3.x 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 und erfolgreich etabliert 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 : 2019-02-11
# 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, muss 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 mx1.nausch.org ESMTP Postfix
 -> EHLO vml000037.dmz.nausch.org
<-  250-mx1.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-ECDSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/C=DE/OU=Domain Control Validated/CN=mx1.nausch.org"
 ~> EHLO vml000037.dmz.nausch.org
<~  250-mx1.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: Thu, 14 Feb 2019 20:58:00 +0100
 ~> To: django@nausch.org
 ~> From: p@sys4.de
 ~> Subject: Test zur verpflichtenden TLS-Verschlüsselung auf Port 25
 ~> Message-Id: <20190214205800.030277@vml000037.dmz.nausch.org>
 ~> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
 ~> X-Test: Test-eMail
 ~> 
 ~> This is a test mailing
 ~> 
 ~> .
<~  250 2.0.0 Ok: queued as 898FEC0008A
 ~> 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
Feb 14 20:58:00 vml000087 postfix/smtpd[972]: connect from mail.sys4.de[194.126.158.132]
Feb 14 20:58:00 vml000087 postfix/smtpd[972]: Trusted TLS connection established from [194.126.158.132]:51788: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 14 20:58:01 vml000087 postfix/smtpd[972]: 898FEC0008A: client=unknown[194.126.158.132]
Feb 14 20:58:01 vml000087 postfix/cleanup[1002]: 898FEC0008A: message-id=<20190214205800.030277@vml000037.dmz.nausch.org>
Feb 14 20:58:02 vml000087 postfix/qmgr[32749]: 898FEC0008A: from=<p@sys4.de>, size=652, nrcpt=1 (queue active)
Feb 14 20:58:02 vml000087 postfix/smtpd[972]: disconnect from unknown[194.126.158.132]
Feb 14 20:58:02 vml000087 postfix/lmtp[1006]: 898FEC0008A: to=<django@nausch.org>, relay=10.0.0.77[10.0.0.77]:24, delay=1.1, delays=0.98/0.02/0.08/0.05, dsn=2.0.0, status=sent (250 2.0.0 <django@nausch.org> iIVpFUrIZVz6GQAArK2B9Q Saved)
Feb 14 20:58:02 vml000087 postfix/qmgr[32749]: 898FEC0008A: removed
Testmail ohne STARTTLS

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 dieses mal 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 zur verpflichtenden TLS-Verschlüsselung auf Port 25"
=== Trying mx01.nausch.org:25...
=== Connected to mx01.nausch.org.
<-  220 mx1.nausch.org ESMTP Postfix
 -> EHLO vml000037.dmz.nausch.org
<-  250-mx1.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>
<** 450 4.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 (Feb 14 21:10:37), client (194.126.158.132) and server (mx1.nausch.org).
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.

Wie erwartet wird die Annahme der Nachricht von unserem Mailserver verweigert, 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.

Feb 14 21:10:37 vml000087 postfix/smtpd[2744]: connect from mail.sys4.de[194.126.158.132]
Feb 14 21:10:37 vml000087 postfix/smtpd[2744]: 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>
Feb 14 21:10:37 vml000087 postfix/smtpd[2744]: 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 zur verpflichtenden TLS-Verschlüsselung auf Port 25"
=== Trying mx01.nausch.org:25...
=== Connected to mx01.nausch.org.
<-  220 mx1.nausch.org ESMTP Postfix
 -> EHLO vml000037.dmz.nausch.org
<-  250-mx1.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 (Feb 14 21:10:37), client (194.126.158.132) and server (mx1.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.

<code>Feb 14 21:13:37 vml000087 postfix/smtpd[2744]: connect from mail.sys4.de[194.126.158.132]
Feb 14 21:13:37 vml000087 postfix/smtpd[2744]: 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>
Feb 14 21:13:37 vml000087 postfix/smtpd[2744]: 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-Antworten ü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 Fingerabdruck 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 : 2019-02-11 - 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!

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 anschließend 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 : 2019-02-11 - 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 : 2019-02-11 - 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 : 2019-02-11 - 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
Feb 14 22:59:42 vml000087 postfix/submission/smtpd[17446]: connect from ppp-93-104-85-187.dynamic.mnet-online.de[93.104.85.187]                                                    
Feb 14 22: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)                                                                                                                                                 
Feb 14 22: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                                                                                                                                                                            
Feb 14 22:59:43 vml000087 postfix/cleanup[17451]: 9BE5BC00090: message-id=<561BAEBE.5070208@nausch.org>                                                                            
Feb 14 22:59:43 vml000087 postfix/qmgr[17413]: 9BE5BC00090: from=<michael@nausch.org>, size=865, nrcpt=1 (queue active)                                                            
Feb 14 22:59:44 vml000087 postfix/submission/smtpd[17446]: disconnect from ppp-93-104-85-187.dynamic.mnet-online.de[93.104.85.187]                                                 
Feb 14 22:59:44 vml000087 postfix/smtpd[18113]: connect from vml000067.dmz.nausch.org[10.0.0.67]                                                                                   
Feb 14 22:59:44 vml000087 postfix/smtpd[18113]: CC17DC00092: client=vml000067.dmz.nausch.org[10.0.0.67], orig_client=unknown[10.0.0.87]                                            
Feb 14 22:59:44 vml000087 postfix/cleanup[17649]: CC17DC00092: message-id=<561BAEBE.5070208@nausch.org>                                                                            
Feb 14 22:59:44 vml000087 postfix/qmgr[17413]: CC17DC00092: from=<michael@nausch.org>, size=2381, nrcpt=1 (queue active)                                                           
Feb 14 22: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)                                                                                                       
Feb 14 22:59:44 vml000087 postfix/qmgr[17413]: 9BE5BC00090: removed                                                                                                                

Feb 14 22: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)                                                                                                                                                                              
Feb 14 22: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:

 Feb 14 23: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)
 Feb 14 23: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 : 2019-02-11 - 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 : 2019-02-11 - Opportunistische DANE TLS-Verschlüsselung für den
#          SMTP-Client für den ausgehenden Verkehr aktiviert; Bei diesem
#          Sicherheitslevel 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 : 2019-02-11 - 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 muss 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 ermittelt hat. Sind beide Fingerprints gleich, wird unser MTA mit der Übertragung der Nachricht(en) fortfahren. Im Maillog unseres Servers wird dies entsprehend positiv vermerkt.

Feb 14 23:07:36 vml000087 postfix/smtp[18312]: connect to mail.sys4.de[194.126.158.132]:25
Feb 14 23:07: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)
Feb 14 23:07: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)
Feb 14 23:07: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.

Feb 14 23:08: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)
Feb 14 23:08: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 PFS20) sind nachfolgende Optionen von entscheidender Bedeutung.

  1. Ephemeral-Diffie-Hellmann Schlüssel: Unsere bereits generierten Diffie Hellmann Schlüssel binden wir nun in unserer Postfix-Konfigurationsdatei ein.

    # Django : 2019-02-11 -  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
  2. „Ephemeral Elliptic Curve Diffie-Hellman“ Schlüsselaustausch: Definition des Grads der Sicherheit beim EECDH Schlüsselaustausch

    # Django : 2019-02-11 - 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
  3. Präferierter standardisierter kryptographischer Algorithmus: Statt der vom Client gewünschte Cipher, wird die Default Cipher Liste des Servers verwendet.

    # Django : 2019-02-11 - 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 : 2019-02-11 - 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 : 2019-02-11 - 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 : 2019-02-11 - 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

Zum Aktivieren unserer SSL/TLS-Verschlüsselung starten wir nun unseren Postfix-Daemon einmal durch.

 # systemctl restart postfix.service

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 mx1.nausch.org:25
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify return:1
depth=0 C = DE, OU = Domain Control Validated, CN = mx1.nausch.org
verify return:1
---
Certificate chain
 0 s:/C=DE/OU=Domain Control Validated/CN=mx1.nausch.org
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFrjCCBJagAwIBAgIMApNDoSN56juh4oE5MA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE5MDIxMTExNDcwMVoXDTIxMDIx
MTA3NTQ0MFowSTELMAkGA1UEBhMCREUxITAfBgNVBAsTGERvbWFpbiBDb250cm9s
IFZhbGlkYXRlZDEXMBUGA1UEAxMObXgxLm5hdXNjaC5vcmcwdjAQBgcqhkjOPQIB
BgUrgQQAIgNiAATOPo6B46LEQAvE/YdgZ/0A2kTiECceAMJjfmj1F31sqBYQNJXZ
Ys1c/xTdggmrjpb+n/6xh5Wo3aU80Qe1fdAb/tjcWomdn/Y39J6E090xVCBoQB7p
BeZPKAf5i7g4jGSjggM/MIIDOzAOBgNVHQ8BAf8EBAMCA4gwgYkGCCsGAQUFBwEB
BH0wezBCBggrBgEFBQcwAoY2aHR0cDovL3NlY3VyZTIuYWxwaGFzc2wuY29tL2Nh
Y2VydC9nc2FscGhhc2hhMmcycjEuY3J0MDUGCCsGAQUFBzABhilodHRwOi8vb2Nz
cDIuZ2xvYmFsc2lnbi5jb20vZ3NhbHBoYXNoYTJnMjBXBgNVHSAEUDBOMEIGCisG
AQQBoDIBCgowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j
b20vcmVwb3NpdG9yeS8wCAYGZ4EMAQIBMAkGA1UdEwQCMAAwPgYDVR0fBDcwNTAz
oDGgL4YtaHR0cDovL2NybDIuYWxwaGFzc2wuY29tL2dzL2dzYWxwaGFzaGEyZzIu
Y3JsMBkGA1UdEQQSMBCCDm14MS5uYXVzY2gub3JnMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQU4KkvjEsSjOHjrZtO0+WtQVu4huQwHwYD
VR0jBBgwFoAU9c3VPAhQ+WpPOreX2laD5mnSaPcwggF9BgorBgEEAdZ5AgQCBIIB
bQSCAWkBZwB2AFWB1MIWkDYBSuoLm1c8U/DA5Dh4cCUIFy+jqh0HE9MMAAABaNxh
y6QAAAQDAEcwRQIhALLZ7bCbaXKUTPIQyzpXZ+spyVGlAJk8mDsb6Dtwp9mKAiAx
O0walYwTiKADam3DswoeUeW/H5F3Xv2IngbIpQCHcQB2AKS5CZC0GFgUh7sTosxn
cAo8NZgE+RvfuON3zQ7IDdwQAAABaNxhy4sAAAQDAEcwRQIgUkR0TQf/mTd0B93v
drzZdlAmfn6PujwCd/BK4IpfQ98CIQCgtcxyu/bnjw9i9gE/58GWp1j0+lCNQkCe
BkkWMbhF8gB1AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABaNxh
y8QAAAQDAEYwRAIgM8oFFMaYS9yeX0tif6YcHj9Nak/bUtHwGx+K0E3mTK0CIBBq
i9iEl/E79vC02SqxnxE5kT6VQq5nNs7KY/pJb/PLMA0GCSqGSIb3DQEBCwUAA4IB
AQAvu5ioSMJpSfUx7krIcoAvQyBh9pfMCDXhu/nkQcVX5opEV2YhM1xDtMgpFyLL
BJKRAuiZhqVkgLx1AON2MdB2s9/9xg6/OMBNpX1uoN+/lELdEz0qLtVBfZp4+HlO
BA3fuwtqE5SGRCKUhH+/B5HzajfmRgouUoOxtxItXlqzRszMCuguXVRRJBbHmvTH
dpKcNT3MTJjN8wtqRLAsjG3xFRrpilnHjCgQQZJWMfzlaSI/6hiB5cWnCyIpINxe
liaMDWRK5U25sCrNuF2fH47EnozWNoaOmU3QHvCW7tHMnA/+UC7J8YnvavfvkAfn
NE63Uo6TqLjkgtRpLmBf2CBM
-----END CERTIFICATE-----
subject=/C=DE/OU=Domain Control Validated/CN=mx1.nausch.org
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
Acceptable client certificate CA names
/C=DE/L=Munich/ST=Bavaria/O=Stadtsparkasse Muenchen (OnlineCA)/OU=OA/CN=SSKM CA/DC=sskm/DC=de
/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
/C=DE/O=Stadtsparkasse Muenchen/OU=OA/CN=SSKM ROOT CA
/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
/C=US/ST=New Jersey/L=Jersey City/O=Positive Software Corporation/CN=LiteSSL CA
/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
/C=DE/ST=Bayern/L=Pliening/O=nausch.org/OU=IT-Monitoring/CN=graylog CA/emailAddress=graylog-admin@nausch.org
/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
/CN=ACCVRAIZ1/OU=PKIACCV/O=ACCV/C=ES
/C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM
/C=IT/L=Milan/O=Actalis S.p.A./03358520967/CN=Actalis Authentication Root CA
/C=US/O=AffirmTrust/CN=AffirmTrust Commercial
/C=US/O=AffirmTrust/CN=AffirmTrust Networking
/C=US/O=AffirmTrust/CN=AffirmTrust Premium
/C=US/O=AffirmTrust/CN=AffirmTrust Premium ECC
/C=US/O=Amazon/CN=Amazon Root CA 1
/C=US/O=Amazon/CN=Amazon Root CA 2
/C=US/O=Amazon/CN=Amazon Root CA 3
/C=US/O=Amazon/CN=Amazon Root CA 4
/CN=Atos TrustedRoot 2011/O=Atos/C=DE
/C=ES/CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 Root CA
/C=NO/O=Buypass AS-983163327/CN=Buypass Class 3 Root CA
/C=SK/L=Bratislava/O=Disig a.s./CN=CA Disig Root R2
/C=CN/O=China Financial Certification Authority/CN=CFCA EV ROOT
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
/C=FR/O=Dhimyotis/CN=Certigna
/C=FR/O=Certinomis/OU=0002 433998903/CN=Certinomis - Root CA
/C=FR/O=Certplus/CN=Class 2 Primary CA
/C=FR/O=Certplus/CN=Certplus Root CA G1
/C=FR/O=Certplus/CN=Certplus Root CA G2
/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA 2
/C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
/O=Cybertrust, Inc/CN=Cybertrust Global Root
/C=DE/O=D-Trust GmbH/CN=D-TRUST Root Class 3 CA 2 2009
/C=DE/O=D-Trust GmbH/CN=D-TRUST Root Class 3 CA 2 EV 2009
/O=Digital Signature Trust Co./CN=DST Root CA X3
/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root G2
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root G3
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G3
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4
/C=TR/L=Ankara/O=E-Tu\xC4\x9Fra EBG Bili\xC5\x9Fim Teknolojileri ve Hizmetleri A.\xC5\x9E./OU=E-Tugra Sertifikasyon Merkezi/CN=E-Tugra Certification Authority
/C=ES/O=Agencia Catalana de Certificacio (NIF Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio Catalanes/CN=EC-ACC
/C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root CA/emailAddress=pki@sk.ee
/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - EC1
/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2
/C=CN/O=GUANG DONG CERTIFICATE AUTHORITY CO.,LTD./CN=GDCA TrustAUTH R5 ROOT
/C=US/O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
/C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2
/C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3
/C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA
/C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA 2
/OU=GlobalSign ECC Root CA - R4/O=GlobalSign/CN=GlobalSign
/OU=GlobalSign ECC Root CA - R5/O=GlobalSign/CN=GlobalSign
/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
/C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Global Chambersign Root - 2008
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
/C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions ECC RootCA 2015
/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2011
/C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2015
/C=HK/O=Hongkong Post/CN=Hongkong Post Root CA 1
/C=US/O=Internet Security Research Group/CN=ISRG Root X1
/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
/C=US/O=IdenTrust/CN=IdenTrust Public Sector Root CA 1
/C=ES/O=IZENPE S.A./CN=Izenpe.com
/C=LU/O=LuxTrust S.A./CN=LuxTrust Global Root 2
/C=HU/L=Budapest/O=Microsec Ltd./CN=Microsec e-Szigno Root CA 2009/emailAddress=info@e-szigno.hu
/C=HU/L=Budapest/O=NetLock Kft./OU=Tan\xC3\xBAs\xC3\xADtv\xC3\xA1nykiad\xC3\xB3k (Certification Services)/CN=NetLock Arany (Class Gold) F\xC5\x91tan\xC3\xBAs\xC3\xADtv\xC3\xA1ny
/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority
/C=CH/O=WISeKey/OU=Copyright (c) 2005/OU=OISTE Foundation Endorsed/CN=OISTE WISeKey Global Root GA CA
/C=CH/O=WISeKey/OU=OISTE Foundation Endorsed/CN=OISTE WISeKey Global Root GB CA
/C=FR/O=OpenTrust/CN=OpenTrust Root CA G1
/C=FR/O=OpenTrust/CN=OpenTrust Root CA G2
/C=FR/O=OpenTrust/CN=OpenTrust Root CA G3
/C=BM/O=QuoVadis Limited/OU=Root Certification Authority/CN=QuoVadis Root Certification Authority
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 1 G3
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 3
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 3 G3
/C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com EV Root Certification Authority ECC
/C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com EV Root Certification Authority RSA R2
/C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com Root Certification Authority ECC
/C=US/ST=Texas/L=Houston/O=SSL Corporation/CN=SSL.com Root Certification Authority RSA
/C=PL/O=Krajowa Izba Rozliczeniowa S.A./CN=SZAFIR ROOT CA2
/C=JP/O=Japan Certification Services, Inc./CN=SecureSign RootCA11
/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
/C=US/O=SecureTrust Corporation/CN=Secure Global CA
/C=JP/O=SECOM Trust Systems CO.,LTD./OU=Security Communication RootCA2
/C=JP/O=SECOM Trust.net/OU=Security Communication RootCA1
/C=FI/O=Sonera/CN=Sonera Class2 CA
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden EV Root CA
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G3
/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
/C=CH/O=SwissSign AG/CN=SwissSign Silver CA - G2
/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 3
/C=TR/L=Gebze - Kocaeli/O=Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK/OU=Kamu Sertifikasyon Merkezi - Kamu SM/CN=TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1
/C=TW/O=TAIWAN-CA/OU=Root CA/CN=TWCA Global Root CA
/C=TW/O=TAIWAN-CA/OU=Root CA/CN=TWCA Root Certification Authority
/C=TW/O=Government Root Certification Authority
/O=TeliaSonera/CN=TeliaSonera Root CA v1
/C=PA/ST=Panama/L=Panama City/O=TrustCor Systems S. de R.L./OU=TrustCor Certificate Authority/CN=TrustCor ECA-1
/C=PA/ST=Panama/L=Panama City/O=TrustCor Systems S. de R.L./OU=TrustCor Certificate Authority/CN=TrustCor RootCert CA-1
/C=PA/ST=Panama/L=Panama City/O=TrustCor Systems S. de R.L./OU=TrustCor Certificate Authority/CN=TrustCor RootCert CA-2
/C=GB/O=Trustis Limited/OU=Trustis FPS Root CA
/C=TR/L=Ankara/O=T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E./CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1 H5
/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust ECC Certification Authority
/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2007 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G4
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2008 VeriSign, Inc. - For authorized use only/CN=VeriSign Universal Root Certification Authority
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G3
/C=US/O=VISA/OU=Visa International Service Association/CN=Visa eCommerce Root
/C=US/OU=www.xrampsecurity.com/O=XRamp Security Services Inc/CN=XRamp Global Certification Authority
/C=RO/O=certSIGN/OU=certSIGN ROOT CA
/C=TW/O=Chunghwa Telecom Co., Ltd./OU=ePKI Root Certification Authority
/C=US/O=thawte, Inc./OU=(c) 2007 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G2
/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 19640 bytes and written 494 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 384 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 00E14958A9E2CCF094B038EB453E036859E4CDED4B1041968E22986E6C267083
    Session-ID-ctx: 
    Master-Key: 3CDED76860B11143F71233200F8F63059491E854E0D2E10DB719DB6CD58C4AF53A7387507ED94BB229D4785A33A1CDEE
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 21 d5 ca a3 29 93 27 53-18 10 fc cb c3 05 95 21   !...).'S.......!
    0010 - 72 db f9 54 aa 9e 5b 7e-72 11 77 c2 5b 35 3c 23   r..T..[~r.w.[5<#
    0020 - 5e eb e6 f7 15 06 4e 7e-53 14 b3 32 14 2b ac 29   ^.....N~S..2.+.)
    0030 - 8a fd 9b 8e d7 a5 58 a7-05 df 6f 74 26 1a be 19   ......X...ot&...
    0040 - cf e2 86 b8 56 70 1d 5f-40 15 50 e5 bc 00 c2 f5   ....Vp._@.P.....
    0050 - 8b a1 41 d8 4d 55 da a0-e3 a2 75 ff 5d 19 e4 12   ..A.MU....u.]...
    0060 - a0 aa cb 43 d9 53 9c d7-76 51 c2 dc 7c 69 b5 fa   ...C.S..vQ..|i..
    0070 - dd 32 82 a4 80 ef 13 b2-4a 75 02 ed d3 c3 78 08   .2......Ju....x.
    0080 - f5 52 c8 c2 d7 53 80 4d-0c 5b 90 93 f1 d2 af cf   .R...S.M.[......
    0090 - 7f a8 fa 63 06 dc 39 91-ad fd f0 c3 d5 30 a2      ...c..9......0.
    00a0 - <SPACES/NULS>

    Start Time: 1550179126
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 8BITMIME
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:

Feb 14 22:35:30 vml000087 postfix/smtpd[22081]: connect from vml000087.dmz.nausch.org[10.0.0.87]
Feb 14 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)
Feb 14 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/cipherscan -o /usr/local/src/cipherscan/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 --starttls smtp mx1.nausch.org:25

Als Ergebnis erhalten wir eine ausführliche Aufstellung zum TLS-Gesundheitszustandes unseres Servers.


No mapping file found ########################################################### testssl.sh 2.9.5 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.1.1a FIPS 20 Nov 2018" [~186 ciphers] on T410:/usr/bin/openssl (built: "Jan 15 14:37:19 2019", platform: "linux-x86_64") Start 2019-02-14 22:43:48 -->> 10.0.0.87:587 (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 2019-02-14 22:46:04 [ 30s] -->> 217.92.13.131:25 (mx1.nausch.org) <<--

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

Bild: Ergebnis des scans bei https://de.ssl-tools.net/mailservers/

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, 14 Feb 2019 19:13:37 +0100 (CET)

Auch im Maillog wird die gesicherte Kommunikation protokolliert:

Feb 14 19:13:37 nss postfix/smtp[18519]: setting up TLS connection to mx1.tachtler.net
Feb 14 19:13:37 nss postfix/smtp[18519]: TLS connection established to mx1.tachtler.net: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 14 19:13:37 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

Wieviele verschlüsselte Verbindungen unser MTA angenommen hat, verrät uns ein Blick in das Maillog. Dort suchen wir nach den entsprechenden Zeilen mit z.B. mit folgender Abfrage.

 # egrep "TLS connection established from.*with cipher" /var/log/maillog | awk '{printf("%s\n", $12)}'  \
         | sort | uniq -c | sort -nr
193593 TLSv1.2
   9578 TLSv1
    868 TLSv1.1

Eine Aufstellung der unterschiedlichen Protokolle mit den verwendeten Ciphern ermitteln wir mit folgendem Befehl:

 # egrep "TLS connection established from.*with cipher" /var/log/maillog | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' \
         | sort | uniq -c | sort -nr
 238038 TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
 173981 TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384
  10705 TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384
   6914 TLSv1 with cipher DHE-RSA-AES256-SHA
   5540 TLSv1.2 with cipher ECDHE-ECDSA-AES256-SHA384
   1265 TLSv1 with cipher ECDHE-RSA-AES256-SHA
    765 TLSv1 with cipher ECDHE-ECDSA-AES256-SHA
    666 TLSv1.2 with cipher AES256-GCM-SHA384
    421 TLSv1.2 with cipher DHE-RSA-AES256-SHA256
    400 TLSv1.2 with cipher ECDHE-RSA-AES256-SHA
    379 TLSv1.1 with cipher ECDHE-RSA-AES256-SHA
    167 TLSv1.1 with cipher ECDHE-ECDSA-AES256-SHA
    121 TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384
    105 TLSv1.2 with cipher AES256-SHA256
    105 TLSv1.2 with cipher AES256-SHA
    103 TLSv1.2 with cipher AES128-GCM-SHA256
    102 TLSv1.2 with cipher AES128-SHA256
    102 TLSv1.2 with cipher AES128-SHA
    102 TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256
    101 TLSv1.2 with cipher ECDHE-RSA-AES128-SHA
    101 TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256
    101 TLSv1.2 with cipher DHE-RSA-CAMELLIA256-SHA
    101 TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA
    100 TLSv1.2 with cipher DHE-RSA-AES256-SHA
    100 TLSv1.2 with cipher DHE-RSA-AES128-SHA256
    100 TLSv1.2 with cipher DHE-RSA-AES128-SHA
    100 TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256
     99 TLSv1.1 with cipher AES256-SHA
     99 TLSv1 with cipher AES256-SHA
     93 TLSv1 with cipher AES128-SHA
     92 TLSv1.2 with cipher CAMELLIA256-SHA
     92 TLSv1.2 with cipher ECDHE-ECDSA-AES256-SHA
     89 TLSv1.2 with cipher CAMELLIA128-SHA
     89 TLSv1.1 with cipher AES128-SHA
     88 TLSv1 with cipher ECDHE-RSA-AES128-SHA
     88 TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA
     86 TLSv1 with cipher DHE-RSA-CAMELLIA128-SHA
     52 TLSv1 with cipher DHE-RSA-AES128-SHA
     50 TLSv1 with cipher CAMELLIA256-SHA
     47 TLSv1 with cipher CAMELLIA128-SHA
     23 TLSv1.2 with cipher ECDHE-ECDSA-AES128-SHA256
     21 TLSv1.2 with cipher ECDHE-ECDSA-AES128-SHA
     19 TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256
     17 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA
     17 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA
     17 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA
     17 TLSv1.1 with cipher DHE-RSA-AES256-SHA
     17 TLSv1.1 with cipher DHE-RSA-AES128-SHA
     17 TLSv1.1 with cipher CAMELLIA256-SHA
     17 TLSv1.1 with cipher CAMELLIA128-SHA
     16 TLSv1 with cipher ECDHE-ECDSA-AES128-SHA
     15 TLSv1.1 with cipher ECDHE-ECDSA-AES128-SHA

ausgehender TLS-Verkehr

Wollen wir wissen wieviele TLS gesichete Verbindungen unser Mailserver zu anderen aufbaut können wir dies wie folgt abrufen

 # grep 'TLS connection established to' /var/log/maillog | sed -e 's/^.*\]:25\: //' -e 's/ with cipher.*//' | sort | uniq -c
  324664 TLSv1.2

Wollen wir wissen welche Cipher bei den unterschiedlichen Protokollen verwendet wurden, fragen wir dies mit folgendem Befehl ab:

 # egrep "TLS connection established to.*with cipher" /var/log/maillog | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' \ 
           | sort | uniq -c | sort -nr
 181337 TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256
 140867 TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
   1337 TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384
    679 TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384
    423 TLSv1.2 with cipher DHE-RSA-AES256-SHA256
     21 TLSv1.2 with cipher AES256-GCM-SHA384

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.

BILD: Ausgabegraphik von Mailgraph-NG zu den verschlüsselten abgehenden Verbindungen

Links


1)
ManInTheMiddle
2) , 20)
Perfect Forward Secrecy
3)
Secure Sockets Layer
4)
Transport Layer Security
5) , 11)
Certificate Signing Request
6)
Certification Authority
7) , 8)
Certificate Authority
9)
Common Name
10)
Elliptic Curve
12)
Sammlung von standardisierten kryptographischer Algorithmen
13)
Ausgabe in formatierter Tabelle
14)
Diffie Hellmann
15)
Elliptic Curve Diffie Hellmann
16)
Stand Januar 2019
17)
Certificate Authority
18)
Certificate Signing Request
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/mail_c7/postfix3_5.txt
  • Zuletzt geändert: 15.02.2019 11:06.
  • von django