SSL gesicherter Webserver mit mod_ssl für Apache httpd 2.4 unter CentOS 7.x

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. Selbst in als vertrauenswürdig geltende Netze werden unter dem Vorwand von Sicherheit, verschlüsselte Verbindungen aufgebrochen und kompromitiert. Persönliche und vertrauliche Daten können so einfach Dritten in die Hände fallen, die mit grosser krimineller Energie versuchen an diese Daten zu kommen.

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

  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!

Was lernen wir aus dieser Tatsache? Unsere Kommunikation ist nach besten Wissen und Gewissen, so zu gestalten, damit andere unsere Daten nicht mitlesen und manipulieren können. Ferner ist sicherzustellen, dass Empfänger vertrauen können, dass Informationen tatsächlich von dem versandt wurden, von dem wir glauben, diese zu bekommen.

Nicht nur auf Seiten der Endkunden, die mit Hilfe von OpenPGP oder S/MIME vertraulich kommunizieren, sondern auch serverseitig kann der Übertragungsweg mit einfachen Mitteln entsprechend verschlüsselt werden. SSL/TLS Logo Für die vertrauliche Kommunikation zwischen unseren Usern und z.B. unserm Dovcot-Mailserver bietet sich eine verschlüsselte Kommunikation mit Hilfe von SSL/TLS an.

Mit Hilfe von PFS1) können wir leicht und einfach sicherstellen, dass aufgezeichnete Datenströme im nach hinein nicht entschlüsselt werden können. Dies wird erreicht, da die beiden Kommunikationspartner, einen separaten und individuellen temporären Schlüssel zur Datensicherung verwenden. Dieser Schlüssel ist dabei nicht fix, sondern wird bei jeder Verbindung neu ausgehandelt. Da aber der Schlüssel an sich nicht ausgetauscht werden muss, ist es auch nicht möglich, den eventuell aufgezeichneten Datenstrom zu entschlüsseln, da der dazu benötigte Schlüssel nicht im Datenstrom enthalten war.

Perfect Forward Secrecy (PFS) basiert auf der Idee, dass Client und Server ihre Kommunikation über einen zusätzlichen temporären Schlüssel absichern, der wechselt. Da der Verbindungsaufbau so gestrickt ist, dass der Schlüssel selbst gar nicht ausgetauscht werden muss, kann der jeweils benutzte Sitzungsschlüssel selbst auch nicht aufgezeichnet werden. Eine nachträgliche Entschlüsselung einer früher aufgezeichneten Session ist damit nicht mehr möglich.

Die für die Verschlüsselung notwendigen Schlüssel und Zertifikate erstellen wir mittels OpenSSL, einer freien Implementierung von SSL2). SSL oder TLS3) ist ein hybrides Verschlüsselungsprotokoll zur Datenübertragung im Internet. Unter TLS 1.0, 1.1 und 1.2 versteht man die standardisierten Weiterentwicklungen von SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). Dies bedeutet also, SSL wird nun unter dem Namen TLS weiterentwickelt.

Bild: mod_ssl Logo Zur Absicherung unserer Privatsphäre bei unserem Webmailers setzen wir das Apache-Modul mod_ssl ein. Nachfolgende Beschreibung zeigt, wie man unter CentOS 7 einen SSL geschützten virtuellen Host aufsetzen kann.

Zum Absichern des Verkehrs setzen wir auf das Paket mod_ssl.

OpenSSL

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

 # yum list openssl
 Installed Packages
 openssl.x86_64                     1:1.0.1e-51.el7_2.7                             @updates-LC

Sollte das Paket noch fehlen, installieren wir dies einfach via:

 # yum install openssl

Was uns das Paket openssl alles mitbringt und wohin die Programme und Konfigurationsdateien kopiert werden, offenbart uns das System wie folgt.

 # rpm -qil openssl
Name        : openssl
Epoch       : 1
Version     : 1.0.1e
Release     : 51.el7_2.7
Architecture: x86_64
Install Date: Wed 28 Sep 2016 07:57:19 PM CEST
Group       : System Environment/Libraries
Size        : 1611113
License     : OpenSSL
Signature   : RSA/SHA256, Tue 27 Sep 2016 04:21:24 PM CEST, Key ID 24c6a8a7f4a80eb5
Source RPM  : openssl-1.0.1e-51.el7_2.7.src.rpm
Build Date  : Tue 27 Sep 2016 03:41:26 PM CEST
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.openssl.org/
Summary     : Utilities from the general purpose cryptography library with TLS implementation
Description :
The OpenSSL toolkit provides support for secure communications between
machines. OpenSSL includes a certificate management tool and shared
libraries which provide various cryptographic algorithms and
protocols.
/etc/pki/CA
/etc/pki/CA/certs
/etc/pki/CA/crl
/etc/pki/CA/newcerts
/etc/pki/CA/private
/etc/pki/tls/certs/Makefile
/etc/pki/tls/certs/make-dummy-cert
/etc/pki/tls/certs/renew-dummy-cert
/etc/pki/tls/misc/CA
/etc/pki/tls/misc/c_hash
/etc/pki/tls/misc/c_info
/etc/pki/tls/misc/c_issuer
/etc/pki/tls/misc/c_name
/usr/bin/openssl
/usr/share/doc/openssl-1.0.1e
/usr/share/doc/openssl-1.0.1e/CHANGES
/usr/share/doc/openssl-1.0.1e/FAQ
/usr/share/doc/openssl-1.0.1e/INSTALL
/usr/share/doc/openssl-1.0.1e/LICENSE
/usr/share/doc/openssl-1.0.1e/NEWS
/usr/share/doc/openssl-1.0.1e/README
/usr/share/doc/openssl-1.0.1e/README.FIPS
/usr/share/doc/openssl-1.0.1e/c-indentation.el
/usr/share/doc/openssl-1.0.1e/openssl.txt
/usr/share/doc/openssl-1.0.1e/openssl_button.gif
/usr/share/doc/openssl-1.0.1e/openssl_button.html
/usr/share/doc/openssl-1.0.1e/ssleay.txt
/usr/share/man/man1/asn1parse.1ssl.gz
/usr/share/man/man1/ca.1ssl.gz
/usr/share/man/man1/ciphers.1ssl.gz
/usr/share/man/man1/cms.1ssl.gz
/usr/share/man/man1/crl.1ssl.gz
/usr/share/man/man1/crl2pkcs7.1ssl.gz
/usr/share/man/man1/dgst.1ssl.gz
/usr/share/man/man1/dhparam.1ssl.gz
/usr/share/man/man1/dsa.1ssl.gz
/usr/share/man/man1/dsaparam.1ssl.gz
/usr/share/man/man1/ec.1ssl.gz
/usr/share/man/man1/ecparam.1ssl.gz
/usr/share/man/man1/enc.1ssl.gz
/usr/share/man/man1/errstr.1ssl.gz
/usr/share/man/man1/gendsa.1ssl.gz
/usr/share/man/man1/genpkey.1ssl.gz
/usr/share/man/man1/genrsa.1ssl.gz
/usr/share/man/man1/md2.1ssl.gz
/usr/share/man/man1/md4.1ssl.gz
/usr/share/man/man1/md5.1ssl.gz
/usr/share/man/man1/mdc2.1ssl.gz
/usr/share/man/man1/nseq.1ssl.gz
/usr/share/man/man1/ocsp.1ssl.gz
/usr/share/man/man1/openssl.1ssl.gz
/usr/share/man/man1/pkcs12.1ssl.gz
/usr/share/man/man1/pkcs7.1ssl.gz
/usr/share/man/man1/pkcs8.1ssl.gz
/usr/share/man/man1/pkey.1ssl.gz
/usr/share/man/man1/pkeyparam.1ssl.gz
/usr/share/man/man1/pkeyutl.1ssl.gz
/usr/share/man/man1/req.1ssl.gz
/usr/share/man/man1/ripemd160.1ssl.gz
/usr/share/man/man1/rsa.1ssl.gz
/usr/share/man/man1/rsautl.1ssl.gz
/usr/share/man/man1/s_client.1ssl.gz
/usr/share/man/man1/s_server.1ssl.gz
/usr/share/man/man1/s_time.1ssl.gz
/usr/share/man/man1/sess_id.1ssl.gz
/usr/share/man/man1/sha.1ssl.gz
/usr/share/man/man1/sha1.1ssl.gz
/usr/share/man/man1/smime.1ssl.gz
/usr/share/man/man1/speed.1ssl.gz
/usr/share/man/man1/spkac.1ssl.gz
/usr/share/man/man1/sslpasswd.1ssl.gz
/usr/share/man/man1/sslrand.1ssl.gz
/usr/share/man/man1/ts.1ssl.gz
/usr/share/man/man1/tsget.1ssl.gz
/usr/share/man/man1/verify.1ssl.gz
/usr/share/man/man1/version.1ssl.gz
/usr/share/man/man1/x509.1ssl.gz
/usr/share/man/man5/config.5ssl.gz
/usr/share/man/man5/openssl.cnf.5ssl.gz
/usr/share/man/man5/x509v3_config.5ssl.gz
/usr/share/man/man7/des_modes.7ssl.gz

Cipher-Suites und Diffie-Hellman

Möchte man in Erfahrung bringen, welche Cipher-Suites4) unser installiertes OpenSSL-Paket mitbringt, können wir wie folgt abfragen5).

 # openssl ciphers -v
ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH       Au=RSA   Enc=AESGCM(256)   Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AESGCM(256)   Mac=AEAD
ECDHE-RSA-AES256-SHA384       TLSv1.2 Kx=ECDH       Au=RSA   Enc=AES(256)      Mac=SHA384
ECDHE-ECDSA-AES256-SHA384     TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AES(256)      Mac=SHA384
ECDHE-RSA-AES256-SHA          SSLv3   Kx=ECDH       Au=RSA   Enc=AES(256)      Mac=SHA1
ECDHE-ECDSA-AES256-SHA        SSLv3   Kx=ECDH       Au=ECDSA Enc=AES(256)      Mac=SHA1
DHE-DSS-AES256-GCM-SHA384     TLSv1.2 Kx=DH         Au=DSS   Enc=AESGCM(256)   Mac=AEAD
DHE-RSA-AES256-GCM-SHA384     TLSv1.2 Kx=DH         Au=RSA   Enc=AESGCM(256)   Mac=AEAD
DHE-RSA-AES256-SHA256         TLSv1.2 Kx=DH         Au=RSA   Enc=AES(256)      Mac=SHA256
DHE-DSS-AES256-SHA256         TLSv1.2 Kx=DH         Au=DSS   Enc=AES(256)      Mac=SHA256
DHE-RSA-AES256-SHA            SSLv3   Kx=DH         Au=RSA   Enc=AES(256)      Mac=SHA1
DHE-DSS-AES256-SHA            SSLv3   Kx=DH         Au=DSS   Enc=AES(256)      Mac=SHA1
DHE-RSA-CAMELLIA256-SHA       SSLv3   Kx=DH         Au=RSA   Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA       SSLv3   Kx=DH         Au=DSS   Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AESGCM(256)   Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AESGCM(256)   Mac=AEAD
ECDH-RSA-AES256-SHA384        TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AES(256)      Mac=SHA384
ECDH-ECDSA-AES256-SHA384      TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AES(256)      Mac=SHA384
ECDH-RSA-AES256-SHA           SSLv3   Kx=ECDH/RSA   Au=ECDH  Enc=AES(256)      Mac=SHA1
ECDH-ECDSA-AES256-SHA         SSLv3   Kx=ECDH/ECDSA Au=ECDH  Enc=AES(256)      Mac=SHA1
AES256-GCM-SHA384             TLSv1.2 Kx=RSA        Au=RSA   Enc=AESGCM(256)   Mac=AEAD
AES256-SHA256                 TLSv1.2 Kx=RSA        Au=RSA   Enc=AES(256)      Mac=SHA256
AES256-SHA                    SSLv3   Kx=RSA        Au=RSA   Enc=AES(256)      Mac=SHA1
CAMELLIA256-SHA               SSLv3   Kx=RSA        Au=RSA   Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA            SSLv3   Kx=PSK        Au=PSK   Enc=AES(256)      Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH       Au=RSA   Enc=AESGCM(128)   Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AESGCM(128)   Mac=AEAD
ECDHE-RSA-AES128-SHA256       TLSv1.2 Kx=ECDH       Au=RSA   Enc=AES(128)      Mac=SHA256
ECDHE-ECDSA-AES128-SHA256     TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AES(128)      Mac=SHA256
ECDHE-RSA-AES128-SHA          SSLv3   Kx=ECDH       Au=RSA   Enc=AES(128)      Mac=SHA1
ECDHE-ECDSA-AES128-SHA        SSLv3   Kx=ECDH       Au=ECDSA Enc=AES(128)      Mac=SHA1
DHE-DSS-AES128-GCM-SHA256     TLSv1.2 Kx=DH         Au=DSS   Enc=AESGCM(128)   Mac=AEAD
DHE-RSA-AES128-GCM-SHA256     TLSv1.2 Kx=DH         Au=RSA   Enc=AESGCM(128)   Mac=AEAD
DHE-RSA-AES128-SHA256         TLSv1.2 Kx=DH         Au=RSA   Enc=AES(128)      Mac=SHA256
DHE-DSS-AES128-SHA256         TLSv1.2 Kx=DH         Au=DSS   Enc=AES(128)      Mac=SHA256
DHE-RSA-AES128-SHA            SSLv3   Kx=DH         Au=RSA   Enc=AES(128)      Mac=SHA1
DHE-DSS-AES128-SHA            SSLv3   Kx=DH         Au=DSS   Enc=AES(128)      Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA        SSLv3   Kx=ECDH       Au=RSA   Enc=3DES(168)     Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA      SSLv3   Kx=ECDH       Au=ECDSA Enc=3DES(168)     Mac=SHA1
DHE-RSA-SEED-SHA              SSLv3   Kx=DH         Au=RSA   Enc=SEED(128)     Mac=SHA1
DHE-DSS-SEED-SHA              SSLv3   Kx=DH         Au=DSS   Enc=SEED(128)     Mac=SHA1
DHE-RSA-CAMELLIA128-SHA       SSLv3   Kx=DH         Au=RSA   Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA       SSLv3   Kx=DH         Au=DSS   Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA          SSLv3   Kx=DH         Au=RSA   Enc=3DES(168)     Mac=SHA1
EDH-DSS-DES-CBC3-SHA          SSLv3   Kx=DH         Au=DSS   Enc=3DES(168)     Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AESGCM(128)   Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AESGCM(128)   Mac=AEAD
ECDH-RSA-AES128-SHA256        TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AES(128)      Mac=SHA256
ECDH-ECDSA-AES128-SHA256      TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AES(128)      Mac=SHA256
ECDH-RSA-AES128-SHA           SSLv3   Kx=ECDH/RSA   Au=ECDH  Enc=AES(128)      Mac=SHA1
ECDH-ECDSA-AES128-SHA         SSLv3   Kx=ECDH/ECDSA Au=ECDH  Enc=AES(128)      Mac=SHA1
ECDH-RSA-DES-CBC3-SHA         SSLv3   Kx=ECDH/RSA   Au=ECDH  Enc=3DES(168)     Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA       SSLv3   Kx=ECDH/ECDSA Au=ECDH  Enc=3DES(168)     Mac=SHA1
AES128-GCM-SHA256             TLSv1.2 Kx=RSA        Au=RSA   Enc=AESGCM(128)   Mac=AEAD
AES128-SHA256                 TLSv1.2 Kx=RSA        Au=RSA   Enc=AES(128)      Mac=SHA256
AES128-SHA                    SSLv3   Kx=RSA        Au=RSA   Enc=AES(128)      Mac=SHA1
SEED-SHA                      SSLv3   Kx=RSA        Au=RSA   Enc=SEED(128)     Mac=SHA1
CAMELLIA128-SHA               SSLv3   Kx=RSA        Au=RSA   Enc=Camellia(128) Mac=SHA1
DES-CBC3-SHA                  SSLv3   Kx=RSA        Au=RSA   Enc=3DES(168)     Mac=SHA1
IDEA-CBC-SHA                  SSLv3   Kx=RSA        Au=RSA   Enc=IDEA(128)     Mac=SHA1
PSK-AES128-CBC-SHA            SSLv3   Kx=PSK        Au=PSK   Enc=AES(128)      Mac=SHA1
PSK-3DES-EDE-CBC-SHA          SSLv3   Kx=PSK        Au=PSK   Enc=3DES(168)     Mac=SHA1
KRB5-IDEA-CBC-SHA             SSLv3   Kx=KRB5       Au=KRB5  Enc=IDEA(128)     Mac=SHA1
KRB5-DES-CBC3-SHA             SSLv3   Kx=KRB5       Au=KRB5  Enc=3DES(168)     Mac=SHA1
KRB5-IDEA-CBC-MD5             SSLv3   Kx=KRB5       Au=KRB5  Enc=IDEA(128)     Mac=MD5 
KRB5-DES-CBC3-MD5             SSLv3   Kx=KRB5       Au=KRB5  Enc=3DES(168)     Mac=MD5 
ECDHE-RSA-RC4-SHA             SSLv3   Kx=ECDH       Au=RSA   Enc=RC4(128)      Mac=SHA1
ECDHE-ECDSA-RC4-SHA           SSLv3   Kx=ECDH       Au=ECDSA Enc=RC4(128)      Mac=SHA1
ECDH-RSA-RC4-SHA              SSLv3   Kx=ECDH/RSA   Au=ECDH  Enc=RC4(128)      Mac=SHA1
ECDH-ECDSA-RC4-SHA            SSLv3   Kx=ECDH/ECDSA Au=ECDH  Enc=RC4(128)      Mac=SHA1
RC4-SHA                       SSLv3   Kx=RSA        Au=RSA   Enc=RC4(128)      Mac=SHA1
RC4-MD5                       SSLv3   Kx=RSA        Au=RSA   Enc=RC4(128)      Mac=MD5 
PSK-RC4-SHA                   SSLv3   Kx=PSK        Au=PSK   Enc=RC4(128)      Mac=SHA1
KRB5-RC4-SHA                  SSLv3   Kx=KRB5       Au=KRB5  Enc=RC4(128)      Mac=SHA1
KRB5-RC4-MD5                  SSLv3   Kx=KRB5       Au=KRB5  Enc=RC4(128)      Mac=MD5

Wir haben also mit der aktuellen Version von OpenSSL, den für Perfect Forward Secrecy benötigten kryptographischen Algorithmus DH6) sowie den weiterentwickelten ECDH7).

mod_ssl

Die installation des Paketes mod_ssl erfolgt mit Hilfe des Befehls yum.

 # yum install mod_ssl -y

Was uns das Paket mod_ssl alles mitbringt und wohin die Programme und Konfigurationsdateien kopiert werden, erkunden wir bei Bedarf mit nachfolgendem Aufruf.

 # rpm -qil mod_ssl
Name        : mod_ssl
Epoch       : 1
Version     : 2.4.6
Release     : 18.el7.centos
Architecture: x86_64
Install Date: Fri 29 Aug 2014 09:07:58 PM CEST
Group       : System Environment/Daemons
Size        : 224652
License     : ASL 2.0
Signature   : RSA/SHA256, Wed 23 Jul 2014 05:21:47 PM CEST, Key ID 24c6a8a7f4a80eb5
Source RPM  : httpd-2.4.6-18.el7.centos.src.rpm
Build Date  : Wed 23 Jul 2014 04:49:10 PM CEST
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://httpd.apache.org/
Summary     : SSL/TLS module for the Apache HTTP Server
Description :
The mod_ssl module provides strong cryptography for the Apache Web
server via the Secure Sockets Layer (SSL) and Transport Layer
Security (TLS) protocols.
/etc/httpd/conf.d/ssl.conf
/etc/httpd/conf.modules.d/00-ssl.conf
/usr/lib64/httpd/modules/mod_ssl.so
/usr/libexec/httpd-ssl-pass-dialog
/var/cache/httpd/ssl

Fachliteratur

Das Buch Bulletproof SSL and TLS von Ivan Ristić bringt viele wertvoller Erklärungen und kann jedem interessierten Webmaster wärmstens empfohlen werden! Neben den Grundlagen zu SSL/TLS und PKI finden sich dort auch weiterführende Konfigurationsbeispiele unter anderem zu unserem Apache-Webserver 2.4. Ausserdem erhält man als registrierter Leser wertvolle aktualisierte News in Form von regelmässigen eMails, in denen aktuellste Entwicklungen und Schwachstellen beleuchtet werden.

Also alles in allem sehr gut angelegte 55€ - das Buch 978-1-907117-04-6 (ISBN) ist in jedem gut sortierten Buchhandel vor Ort erhältlich sein sollte.

Seiten im WWW

Natürlich finden sich im *WWW unzählige Seiten, die sich dem Thema TLS/SSL annehmen. Die Seiten bei zu Security/Server Side TLS im Mozilla WIKI sind neben dem Blog und dem Security Guidelines zur Web Security als sehr gute Quelle zu bewerten. Auch die Wikipedia Seite zu Transport Layer Security erklärt anschaulich das Thema Transportverschlüsselung.

man-Pages

openssl

 # man openssl
OPENSSL(1)                                 OpenSSL                                 OPENSSL(1)

NAME
       openssl - OpenSSL command line tool

SYNOPSIS
       openssl command [ command_opts ] [ command_args ]

       openssl [ list-standard-commands | list-message-digest-commands | list-cipher-commands
       | list-cipher-algorithms | list-message-digest-algorithms | list-public-key-
       algorithms]

       openssl no-XXX [ arbitrary options ]

DESCRIPTION
       OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3)
       and Transport Layer Security (TLS v1) network protocols and related cryptography
       standards required by them.

       The openssl program is a command line tool for using the various cryptography
       functions of OpenSSL's crypto library from the shell.  It can be used for

        o  Creation and management of private keys, public keys and parameters
        o  Public key cryptographic operations
        o  Creation of X.509 certificates, CSRs and CRLs
        o  Calculation of Message Digests
        o  Encryption and Decryption with Ciphers
        o  SSL/TLS Client and Server Tests
        o  Handling of S/MIME signed or encrypted mail
        o  Time Stamp requests, generation and verification

COMMAND SUMMARY
       The openssl program provides a rich variety of commands (command in the SYNOPSIS
       above), each of which often has a wealth of options and arguments (command_opts and
       command_args in the SYNOPSIS).

       The pseudo-commands list-standard-commands, list-message-digest-commands, and list-
       cipher-commands output a list (one entry per line) of the names of all standard
       commands, message digest commands, or cipher commands, respectively, that are
       available in the present openssl utility.

       The pseudo-commands list-cipher-algorithms and list-message-digest-algorithms list all
       cipher and message digest names, one entry per line. Aliases are listed as:

        from => to

       The pseudo-command list-public-key-algorithms lists all supported public key
       algorithms.

       The pseudo-command no-XXX tests whether a command of the specified name is available.
       If no command named XXX exists, it returns 0 (success) and prints no-XXX; otherwise it
       returns 1 and prints XXX.  In both cases, the output goes to stdout and nothing is
       printed to stderr.  Additional command line arguments are always ignored.  Since for
       each cipher there is a command of the same name, this provides an easy way for shell
       scripts to test for the availability of ciphers in the openssl program.  (no-XXX is
       not able to detect pseudo-commands such as quit, list-...-commands, or no-XXX itself.)

   STANDARD COMMANDS
       asn1parse Parse an ASN.1 sequence.

       ca        Certificate Authority (CA) Management.

       ciphers   Cipher Suite Description Determination.

       cms       CMS (Cryptographic Message Syntax) utility

       crl       Certificate Revocation List (CRL) Management.

       crl2pkcs7 CRL to PKCS#7 Conversion.

       dgst      Message Digest Calculation.

       dh        Diffie-Hellman Parameter Management.  Obsoleted by dhparam.

       dhparam   Generation and Management of Diffie-Hellman Parameters. Superseded by
                 genpkey and pkeyparam

       dsa       DSA Data Management.

       dsaparam  DSA Parameter Generation and Management. Superseded by genpkey and pkeyparam

       ec        EC (Elliptic curve) key processing

       ecparam   EC parameter manipulation and generation

       enc       Encoding with Ciphers.

       engine    Engine (loadble module) information and manipulation.

       errstr    Error Number to Error String Conversion.

       gendh     Generation of Diffie-Hellman Parameters.  Obsoleted by dhparam.

       gendsa    Generation of DSA Private Key from Parameters. Superseded by genpkey and
                 pkey

       genpkey   Generation of Private Key or Parameters.

       genrsa    Generation of RSA Private Key. Superceded by genpkey.

       nseq      Create or examine a netscape certificate sequence

       ocsp      Online Certificate Status Protocol utility.

       passwd    Generation of hashed passwords.

       pkcs12    PKCS#12 Data Management.

       pkcs7     PKCS#7 Data Management.

       pkey      Public and private key management.

       pkeyparam Public key algorithm parameter management.

       pkeyutl   Public key algorithm cryptographic operation utility.

       rand      Generate pseudo-random bytes.

       req       PKCS#10 X.509 Certificate Signing Request (CSR) Management.

       rsa       RSA key management.

       rsautl    RSA utility for signing, verification, encryption, and decryption.
                 Superseded by  pkeyutl

       s_client  This implements a generic SSL/TLS client which can establish a transparent
                 connection to a remote server speaking SSL/TLS. It's intended for testing
                 purposes only and provides only rudimentary interface functionality but
                 internally uses mostly all functionality of the OpenSSL ssl library.

       s_server  This implements a generic SSL/TLS server which accepts connections from
                 remote clients speaking SSL/TLS. It's intended for testing purposes only and
                 provides only rudimentary interface functionality but internally uses mostly
                 all functionality of the OpenSSL ssl library.  It provides both an own
                 command line oriented protocol for testing SSL functions and a simple HTTP
                 response facility to emulate an SSL/TLS-aware webserver.

       s_time    SSL Connection Timer.

       sess_id   SSL Session Data Management.

       smime     S/MIME mail processing.

       speed     Algorithm Speed Measurement.

       spkac     SPKAC printing and generating utility

       ts        Time Stamping Authority tool (client/server)

       verify    X.509 Certificate Verification.
       version   OpenSSL Version Information.

       x509      X.509 Certificate Data Management.

   MESSAGE DIGEST COMMANDS
       md2       MD2 Digest

       md5       MD5 Digest

       mdc2      MDC2 Digest

       rmd160    RMD-160 Digest

       sha       SHA Digest

       sha1      SHA-1 Digest

       sha224    SHA-224 Digest

       sha256    SHA-256 Digest

       sha384    SHA-384 Digest

       sha512    SHA-512 Digest

   ENCODING AND CIPHER COMMANDS
       base64    Base64 Encoding

       bf bf-cbc bf-cfb bf-ecb bf-ofb
                 Blowfish Cipher

       cast cast-cbc
                 CAST Cipher

       cast5-cbc cast5-cfb cast5-ecb cast5-ofb
                 CAST5 Cipher

       des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ofb
                 DES Cipher

       des3 desx des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
                 Triple-DES Cipher

       idea idea-cbc idea-cfb idea-ecb idea-ofb
                 IDEA Cipher

       rc2 rc2-cbc rc2-cfb rc2-ecb rc2-ofb
                 RC2 Cipher

                 RC2 Cipher

       rc4       RC4 Cipher

       rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb
                 RC5 Cipher

PASS PHRASE ARGUMENTS
       Several commands accept password arguments, typically using -passin and -passout for
       input and output passwords respectively. These allow the password to be obtained from
       a variety of sources. Both of these options take a single argument whose format is
       described below. If no password argument is given and a password is required then the
       user is prompted to enter one: this will typically be read from the current terminal
       with echoing turned off.

       pass:password
                 the actual password is password. Since the password is visible to utilities
                 (like 'ps' under Unix) this form should only be used where security is not
                 important.

       env:var   obtain the password from the environment variable var. Since the environment
                 of other processes is visible on certain platforms (e.g. ps under certain
                 Unix OSes) this option should be used with caution.

       file:pathname
                 the first line of pathname is the password. If the same pathname argument is
                 supplied to -passin and -passout arguments then the first line will be used
                 for the input password and the next line for the output password. pathname
                 need not refer to a regular file: it could for example refer to a device or
                 named pipe.

       fd:number read the password from the file descriptor number. This can be used to send
                 the data via a pipe for example.

       stdin     read the password from standard input.

SEE ALSO
       asn1parse(1), ca(1), config(5), crl(1), crl2pkcs7(1), dgst(1), dhparam(1), dsa(1),
       dsaparam(1), enc(1), gendsa(1), genpkey(1), genrsa(1), nseq(1), openssl(1),
       sslpasswd(1), pkcs12(1), pkcs7(1), pkcs8(1), sslrand(1), req(1), rsa(1), rsautl(1),
       s_client(1), s_server(1), s_time(1), smime(1), spkac(1), verify(1), version(1),
       x509(1), crypto(3), ssl(3), x509v3_config(5)

HISTORY
       The openssl(1) document appeared in OpenSSL 0.9.2.  The list-XXX-commands pseudo-
       commands were added in OpenSSL 0.9.3; The list-XXX-algorithms pseudo-commands were
       added in OpenSSL 1.0.0; the no-XXX pseudo-commands were added in OpenSSL 0.9.5a.  For
       notes on the availability of other commands, see their individual manual pages.

1.0.1e                                    2016-09-27                               OPENSSL(1)

dhparam

 # man dhparam
DHPARAM(1)                                 OpenSSL                                 DHPARAM(1)

NAME
       dhparam - DH parameter manipulation and generation

SYNOPSIS
       openssl dhparam [-inform DER|PEM] [-outform DER|PEM] [-in filename] [-out filename]
       [-dsaparam] [-noout] [-text] [-C] [-2] [-5] [-rand file(s)] [-engine id] [numbits]

DESCRIPTION
       This command is used to manipulate DH parameter files.

OPTIONS
       -inform DER|PEM
           This specifies the input format. The DER option uses an ASN1 DER encoded form
           compatible with the PKCS#3 DHparameter structure. The PEM form is the default
           format: it consists of the DER format base64 encoded with additional header and
           footer lines.

       -outform DER|PEM
           This specifies the output format, the options have the same meaning as the -inform
           option.

       -in filename
           This specifies the input filename to read parameters from or standard input if
           this option is not specified.

       -out filename
           This specifies the output filename parameters to. Standard output is used if this
           option is not present. The output filename should not be the same as the input
           filename.

       -dsaparam
           If this option is used, DSA rather than DH parameters are read or created; they
           are converted to DH format.  Otherwise, "strong" primes (such that (p-1)/2 is also
           prime) will be used for DH parameter generation.

           DH parameter generation with the -dsaparam option is much faster, and the
           recommended exponent length is shorter, which makes DH key exchange more
           efficient.  Beware that with such DSA-style DH parameters, a fresh DH key should
           be created for each use to avoid small-subgroup attacks that may be possible
           otherwise.

       -2, -5
           The generator to use, either 2 or 5. 2 is the default. If present then the input
           file is ignored and parameters are generated instead.

       -rand file(s)
           a file or files containing random data used to seed the random number generator,
           or an EGD socket (see RAND_egd(3)).  Multiple files can be specified separated by
           or an EGD socket (see RAND_egd(3)).  Multiple files can be specified separated by
           a OS-dependent character.  The separator is ; for MS-Windows, , for OpenVMS, and :
           for all others.

       numbits
           this option specifies that a parameter set should be generated of size numbits. It
           must be the last option. If not present then a value of 512 is used. If this
           option is present then the input file is ignored and parameters are generated
           instead.

       -noout
           this option inhibits the output of the encoded version of the parameters.

       -text
           this option prints out the DH parameters in human readable form.

       -C  this option converts the parameters into C code. The parameters can then be loaded
           by calling the get_dhnumbits() function.

       -engine id
           specifying an engine (by its unique id string) will cause dhparam to attempt to
           obtain a functional reference to the specified engine, thus initialising it if
           needed. The engine will then be set as the default for all available algorithms.

WARNINGS
       The program dhparam combines the functionality of the programs dh and gendh in
       previous versions of OpenSSL and SSLeay. The dh and gendh programs are retained for
       now but may have different purposes in future versions of OpenSSL.

NOTES
       PEM format DH parameters use the header and footer lines:

        -----BEGIN DH PARAMETERS-----
        -----END DH PARAMETERS-----

       OpenSSL currently only supports the older PKCS#3 DH, not the newer X9.42 DH.

       This program manipulates DH parameters not keys.

BUGS
       There should be a way to generate and manipulate DH keys.

SEE ALSO
       dsaparam(1)

HISTORY
       The dhparam command was added in OpenSSL 0.9.5.  The -dsaparam option was added in
       OpenSSL 0.9.6.

1.0.1e                                    2013-02-11                               DHPARAM(1)

Apache.org

Viele wervolle Hinweise zu den Konfigurationsparameter zu mod_ssl findet man in der Dokumentation zum Apache Module mod_ssl und SSL/TLS Strong Encryption How-To.

Dreh- und Angelpunkt bei den CAs und den zugehörigen Root-Zertifikaten ist das Vertrauen, welches man diesen schenken ma und/oder kann. Mit sehr hoher Wahrscheinlichkeit kann man davon ausgehen dass eine CA wie z.B. swiss sign die von den Browserherstellern geforderten Sicherheitsprüfungen erfüllen. Eine wesentliche Schwachstelle der ganzen CAs ist aber, wer garantiert, dass nicht eine x-beliebige zweite CA ein Zertifikat für z.B. nausch.org erstellt, obwohl bereits GlobalSign hierzu ein X.509-Zertifikat ausgestellt hat?

Ein Umstand, den sich z.B. alle Man-in-the-Middle-Angriffe zu nutze machen und unberechtigter Weise falsche Zertifikate ausstellen und somit dem sorglosen Endanwender in betrügerischer Art und Weise einen gefälschte Identität und eine nicht mehr existierende Ende zu Ende Verschlüsselung zwischen dem Webserver und Browser vorgaukeln.

Wir werden später noch Lösungen aufzeigen, wie wir zum einen auf Serverseite diese betrügerischen Angriffsversuche serverseitig soweit wie möglich zu unterbinden und auch auf Clientseite Lösungen aufzeigen, wie ein Kunde am Browser sehr leicht feststellen kann, ob die Verbindung sicher ist, oder ob jemand mit krimineller Energie versucht an vertrauliche Informationen durch einen MitM-Angriff zu kommen!

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 äusserst 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. 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.

BILD: schematische Darstellung eines X.509 Zertifikates

Ohne dem übergeordneten Root Zertifikat kann zwar verschlüsselt kommuniziert werden, 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     : 2014.1.98
Release     : 70.0.el7_0
Architecture: noarch
Install Date: Mon 09 Feb 2015 03:36:17 PM CET
Group       : System Environment/Base
Size        : 1029265
License     : Public Domain
Signature   : RSA/SHA256, Thu 18 Sep 2014 03:53:56 PM CEST, Key ID 24c6a8a7f4a80eb5
Source RPM  : ca-certificates-2014.1.98-70.0.el7_0.src.rpm
Build Date  : Thu 18 Sep 2014 02:11:36 PM CEST
Build Host  : worker1.bsys.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/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/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/update-ca-trust
/usr/share/man/man8/update-ca-trust.8.gz
/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.neutral-trust.crt
/usr/share/pki/ca-trust-source/ca-bundle.supplement.p11-kit
/usr/share/pki/ca-trust-source/ca-bundle.trust.crt

Dokumentation

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) 2015
#
$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

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 äusserst 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 CA9) 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 CN10) 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 mx01.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 mx01.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) mx01.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 mx01.nausch.org.servercert.pem
    mx01.nausch.org.servercert.pem: OK

    Wir haben also bei diesem Konfigurationsbeispiel nun neben unserem Zertifikat mx01.nausch.org.servercert.pem die zugehörige Zertifikatskette rapid_geotrust_equifax_bundle.pem vorliegen!

Technisch gesehen unterscheiden sich Zertifikate einer „offiziellen“ oder besser gesagt einer kommerziellen CA nicht von Zertifikaten einer eigenen „self signed“ Zertifikaten. In aller Regel wird dies abhängig davon sein, ob die verwendeten Zertifikate anstandslos von den Clientprogrammen (Mailclients und ggf. Browser) beim Endnutzer akzeptiert werden, also von einer vertrauenswürdigen CA stammen.

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

  1. unseren Private Key, den wir hüten wie unseren Augapfel
  2. unseren Public Key mit zusätzlichen Daten , auch bekannt als CSR11), den wir von einer CA12) 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.

Nutzt man ein kommerzielle CA können wir die nächsten Kapitel FIXME getrost überspringen und gleich damit starten, den nötigen Schlüssel für unser Zertifikat/CSR zu erstellen.

Erstellen einer eigenen CA

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 schwarz 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 Aug 29 21:46 cacert.pem
-rw-r--r-- 1 root root 3406 Aug 29 21:46 cakey.pem

Sichtshalber ä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.pem >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 schwarz gekennzeichnet.

Den Schlüssel unserer eigenen CA verschieben wir nun an die richtige Stelle.

 # mv cakey.pem /etc/pki/CA/private/cakey.pem

Das Gleiche machen wir mit dem eigenen Root-Zertifikat.

 # mv cacert.pem /etc/pki/CA/cacert.pem
Laufzeit der Zertifikate anpassen

Da wir die Laufzeit der erzeugten Zertifikate nicht auf der Kommandozeile beim Aufruf von openssl angeben können, passen wir in der OpenSSL-Konfigurationsdatei die Laufzeit default_days an.

 # vim /etc/pki/tls/openssl.cnf
/etc/pki/tls/openssl.cnf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
 
# This definition stops the following lines choking if HOME isn't
# defined.
HOME			= .
RANDFILE		= $ENV::HOME/.rnd
 
# Extra OBJECT IDENTIFIER info:
#oid_file		= $ENV::HOME/.oid
oid_section		= new_oids
 
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions		= 
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
 
[ new_oids ]
 
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
 
# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
 
####################################################################
[ ca ]
default_ca	= CA_default		# The default ca section
 
####################################################################
[ CA_default ]
 
dir		= /etc/pki/CA		# Where everything is kept
certs		= $dir/certs		# Where the issued certs are kept
crl_dir		= $dir/crl		# Where the issued crl are kept
database	= $dir/index.txt	# database index file.
#unique_subject	= no			# Set to 'no' to allow creation of
					# several ctificates with same subject.
new_certs_dir	= $dir/newcerts		# default place for new certs.
 
certificate	= $dir/cacert.pem 	# The CA certificate
serial		= $dir/serial 		# The current serial number
crlnumber	= $dir/crlnumber	# the current crl number
					# must be commented out to leave a V1 CRL
crl		= $dir/crl.pem 		# The current CRL
private_key	= $dir/private/cakey.pem# The private key
RANDFILE	= $dir/private/.rand	# private random number file
 
x509_extensions	= usr_cert		# The extentions to add to the cert
 
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt 	= ca_default		# Subject Name options
cert_opt 	= ca_default		# Certificate field options
 
# Extension copying option: use with caution.
# copy_extensions = copy
 
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions	= crl_ext
 
# Django : 2014-07-23
# default: default_days    = 365        # how long to certify for (one year)
default_days	= 730			# how long to certify for (two years)
default_crl_days= 30			# how long before next CRL
default_md	= sha256		# use SHA-256 by default
preserve	= no			# keep passed DN ordering
 
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy		= policy_match
 
# For the CA policy
[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional
 
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName		= optional
stateOrProvinceName	= optional
localityName		= optional
organizationName	= optional
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional
 
####################################################################
[ req ]
default_bits		= 2048
default_md		= sha256
default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
x509_extensions	= v3_ca	# The extentions to add to the self signed cert
 
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
 
# This sets a mask for permitted string types. There are several options. 
# default: PrintableString, T61String, BMPString.
# pkix	 : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only
 
# req_extensions = v3_req # The extensions to add to a certificate request
 
[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_default		= XX
countryName_min			= 2
countryName_max			= 2
 
stateOrProvinceName		= State or Province Name (full name)
#stateOrProvinceName_default	= Default Province
 
localityName			= Locality Name (eg, city)
localityName_default		= Default City
 
0.organizationName		= Organization Name (eg, company)
0.organizationName_default	= Default Company Ltd
 
# we can do this but it is not needed normally :-)
#1.organizationName		= Second Organization Name (eg, company)
#1.organizationName_default	= World Wide Web Pty Ltd
 
organizationalUnitName		= Organizational Unit Name (eg, section)
#organizationalUnitName_default	=
 
commonName			= Common Name (eg, your name or your server\'s hostname)
commonName_max			= 64
 
emailAddress			= Email Address
emailAddress_max		= 64
 
# SET-ex3			= SET extension number 3
 
[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20
 
unstructuredName		= An optional company name
 
[ usr_cert ]
 
# These extensions are added when 'ca' signs a request.
 
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
 
basicConstraints=CA:FALSE
 
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
 
# This is OK for an SSL server.
# nsCertType			= server
 
# For an object signing certificate this would be used.
# nsCertType = objsign
 
# For normal client use this is typical
# nsCertType = client, email
 
# and for everything including object signing:
# nsCertType = client, email, objsign
 
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 
# This will be displayed in Netscape's comment listbox.
nsComment			= "OpenSSL Generated Certificate"
 
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
 
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
 
# Copy subject details
# issuerAltName=issuer:copy
 
#nsCaRevocationUrl		= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
 
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
 
[ v3_req ]
 
# Extensions to add to a certificate request
 
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 
[ v3_ca ]
 
 
# Extensions for a typical CA
 
 
# PKIX recommendation.
 
subjectKeyIdentifier=hash
 
authorityKeyIdentifier=keyid:always,issuer
 
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
 
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
 
# Some might want this also
# nsCertType = sslCA, emailCA
 
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
 
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
 
[ crl_ext ]
 
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
 
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
 
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate
 
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
 
basicConstraints=CA:FALSE
 
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
 
# This is OK for an SSL server.
# nsCertType			= server
 
# For an object signing certificate this would be used.
# nsCertType = objsign
 
# For normal client use this is typical
# nsCertType = client, email
 
# and for everything including object signing:
# nsCertType = client, email, objsign
 
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 
# This will be displayed in Netscape's comment listbox.
nsComment			= "OpenSSL Generated Certificate"
 
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
 
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
 
# Copy subject details
# issuerAltName=issuer:copy
 
#nsCaRevocationUrl		= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
 
# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
 
####################################################################
[ tsa ]
 
default_tsa = tsa_config1	# the default TSA section
 
[ tsa_config1 ]
 
# These are used by the TSA reply generation only.
dir		= ./demoCA		# TSA root directory
serial		= $dir/tsaserial	# The current serial number (mandatory)
crypto_device	= builtin		# OpenSSL engine to use for signing
signer_cert	= $dir/tsacert.pem 	# The TSA signing certificate
					# (optional)
certs		= $dir/cacert.pem	# Certificate chain to include in reply
					# (optional)
signer_key	= $dir/private/tsakey.pem # The TSA private key (optional)
 
default_policy	= tsa_policy1		# Policy if request did not specify it
					# (optional)
other_policies	= tsa_policy2, tsa_policy3	# acceptable policies (optional)
digests		= sha1, sha256, sha384, sha512	# Acceptable message digests (mandatory)
accuracy	= secs:1, millisecs:500, microsecs:100	# (optional)
clock_precision_digits  = 0	# number of digits after dot. (optional)
ordering		= yes	# Is ordering defined for timestamps?
				# (optional, default: no)
tsa_name		= yes	# Must the TSA name be included in the reply?
				# (optional, default: no)
ess_cert_id_chain	= no	# Must the ESS cert id chain be included?
				# (optional, default: no)

Schlüssel für das Serverzertifikat erzeugen

Nachdem wir nun unsere eigene CA erstellt haben, machen wir uns daran, endlich für unseren Server ein Zertifikat herauszugeben. Hierzu erzeugen wir als erstes einen 4096 Bit langen RSA Schlüssel, den wir mit AES 256 verschlüsselt auf der Platte abgelegt lassen. Da OpenSSL keine leere Passphrase zulässt braucht die Passphrase diesmal nicht sonderlich geheim sein, da wir diese im Anschluss ohnehin sofort wieder entfernen werden.

Die Eingaben sind in der Farbe blau und die Rückmeldungen in der Farbe schwarz 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 <serverkey.pem >serverkey_2.pem
Enter pass phrase:
writing RSA key

Wie schon zuvor schützen wir auch hier den Serverschlüssel über die Dateirechte, nachdem wir diesen umbenannt haben.

# mv serverkey_2.pem serverkey.pem -f
# chmod 400 serverkey.pem

Certificate Signing Request erzeugen

Im folgenden Schritt zu unserem eigenen Zertifikat erzeugen wir einen CSR13), 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 Apache-WebServers bzw. des vHosts eingetragen werden, unter dem der Webserver später angesprochen wird!

Auch hier sind die Eingaben in der Farbe blau und die Rückmeldungen in der Farbe schwarz gekennzeichnet.

# openssl req -new -key serverkey.pem -out csr.pem -nodes
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:DE
State or Province Name (full name) []Bayern
Locality Name (eg, city) [Default City]:Pliening
Organization Name (eg, company) [Default Company Ltd]:nausch.org
Organizational Unit Name (eg, section) []:WEB-Office
Common Name (eg, your name or your server's hostname) []:www.sec-mail.guru
Email Address []:webmaster@sec-mail.guru

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Wollen oder müssen wir ein kommerzielles Zertifikat, also von einer in den Browsern und mailclients von Haus aus installierten CAs, nutzen, so lassen wir den CSR der CA zukommen.

 # cat csr.pem
-----BEGIN CERTIFICATE REQUEST-----
MIIE5TCCAs0CAQAwgZ8xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP
BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRMwEQYDVQQLDApX
RUItT2ZmaWNlMRowGAYDVQQDDBF3d3cuc2VjLW1haWwuZ3VydTEmMCQGCSqGSIb3
DQEJARYXd2VibWFzdGVyQHNlYy1tYWlsLmd1cnUwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQCvfVsj0y+ZEbP1zlQX6z+vXXvfQXNfTqKnL97F08Yho423
odUteIcaJGqtUpzmhSGmw+0Z7oyVAUiLuZtsChXk//qzkreR8vGjk8QoREgwp3Yb
GTxclb2cgYVPaEg17OlwYaNAew5Zxv7GYHISgBsr1MRSdJ6lo6lrGxrbDl3fXYrj
TlDZtd9xMIEJ4zh9CuOofNlF0PF2bP/Sa5UDWgpEcNpsBzhzQwFDechvY+LCCYl2
suomiXtk9oojy4+7qqxKJrHB9MV/r3c2WNHSjIbC/SboJtatl458f4ocrHD+TEVf
6urf7KVhoDO121U+5c/yiNOFeILVy3Ih/40Wf6gxxOjdM/mW9hbdyAa8p+lmgbV1
QlBQ6Hq4e5D0712DlHTsNQPVDzZCMNzwwDg0lZrr0WLjnYl2MHRiJnUpjpIaYYVB
hGeb9ZTItpqvRBMjmycW1NMFszZNYD0no8fPvxXn7UyIRRs7jP8rSGwBI5srMXfo
jLiJ6aaUlE3ajXQI9x02OrYbAN96zgb+pI29/I/fRSF6zd1jvADQToP8+ywawWwI
GpbSwFSPfakhMBDNce+8/g3/aZ2o7YM5gl3v0qu2SEYEsBEjHPfmYgv9NFMITAGu
1KXnVMv8jEZQXuAqkXFV708/Iy5mPyeGr+ILztTQxQ3ME2TgfymJPqRASAooSwID
AQABoAAwDQYJKoZIhvcNAQELBQADggIBAIdzPh2e5A9FMgRh3ZCugZDZ1/XXYJTS
9V1shTO9tpGt1SGv4i5jNKWUaPdQrj8OOW8tV29cBKK74gbZNs6iQMHF68TodeLc
nJCDN/FtmZy+nhyue+gVt9DHFxYkQyXv0Q2GDHKv919F1/xKnRluM8/FKTOy7Qbs
kvRhW/4aFykXwvn0UcGDQeXchqJ1wY2/y+K1HZcPHavEM7ISYKzyb8Q89RNk6vd9
4UglboPOBZBvofttN++9v7RNkFCbcAJU+JR738oqSuNgjn6w9IQhPmSjyazY6ZF5
UdEGnnCnpR/2xJZ81uG8wMTfVR/qGDfw09Um+2F6wRAY5qXLRtEcvn18QckUyPel
HB+K7cR/C1y3NnqyjiEyjc6vl7qTHtOx3AAcbK8CRjdySEQV36Txg8JtqZB33BDB
fZZZucmY2bHONtl6q/NnPohEuyuuhC6oIku3+OaHMhOfIy22PICEQKLwSr00w8dJ
f4MKgqUytka+ga/ynn8b1ohjAu047jDxpQk1yjqfleFkYgzK6uwb5J5PdyudtoMG
JyoCweVtz3BCh0mOVU7x2RDqGNtrOopwqKtbA+3SpDQmXFPLvYO38Hspa0712QJh
9Zos5rF0ta/I+fMbn/nDfyUKfbszKBD/4UzzVl43jz9ZakJBKbzF/z3lXUeMBG6K
U56QhSgOCblB
-----END CERTIFICATE REQUEST-----

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

 # openssl req -noout -text -in csr.pem
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=WEB-Office, CN=www.sec-mail.guru/emailAddress=webmaster@sec-mail.guru
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:af:7d:5b:23:d3:2f:99:11:b3:f5:ce:54:17:eb:
                    3f:af:5d:7b:df:41:73:5f:4e:a2:a7:2f:de:c5:d3:
                    c6:21:a3:8d:b7:a1:d5:2d:78:87:1a:24:6a:ad:52:
                    9c:e6:85:21:a6:c3:ed:19:ee:8c:95:01:48:8b:b9:
                    9b:6c:0a:15:e4:ff:fa:b3:92:b7:91:f2:f1:a3:93:
                    c4:28:44:48:30:a7:76:1b:19:3c:5c:95:bd:9c:81:
                    85:4f:68:48:35:ec:e9:70:61:a3:40:7b:0e:59:c6:
                    fe:c6:60:72:12:80:1b:2b:d4:c4:52:74:9e:a5:a3:
                    a9:6b:1b:1a:db:0e:5d:df:5d:8a:e3:4e:50:d9:b5:
                    df:71:30:81:09:e3:38:7d:0a:e3:a8:7c:d9:45:d0:
                    f1:76:6c:ff:d2:6b:95:03:5a:0a:44:70:da:6c:07:
                    38:73:43:01:43:79:c8:6f:63:e2:c2:09:89:76:b2:
                    ea:26:89:7b:64:f6:8a:23:cb:8f:bb:aa:ac:4a:26:
                    b1:c1:f4:c5:7f:af:77:36:58:d1:d2:8c:86:c2:fd:
                    26:e8:26:d6:ad:97:8e:7c:7f:8a:1c:ac:70:fe:4c:
                    45:5f:ea:ea:df:ec:a5:61:a0:33:b5:db:55:3e:e5:
                    cf:f2:88:d3:85:78:82:d5:cb:72:21:ff:8d:16:7f:
                    a8:31:c4:e8:dd:33:f9:96:f6:16:dd:c8:06:bc:a7:
                    e9:66:81:b5:75:42:50:50:e8:7a:b8:7b:90:f4:ef:
                    5d:83:94:74:ec:35:03:d5:0f:36:42:30:dc:f0:c0:
                    38:34:95:9a:eb:d1:62:e3:9d:89:76:30:74:62:26:
                    75:29:8e:92:1a:61:85:41:84:67:9b:f5:94:c8:b6:
                    9a:af:44:13:23:9b:27:16:d4:d3:05:b3:36:4d:60:
                    3d:27:a3:c7:cf:bf:15:e7:ed:4c:88:45:1b:3b:8c:
                    ff:2b:48:6c:01:23:9b:2b:31:77:e8:8c:b8:89:e9:
                    a6:94:94:4d:da:8d:74:08:f7:1d:36:3a:b6:1b:00:
                    df:7a:ce:06:fe:a4:8d:bd:fc:8f:df:45:21:7a:cd:
                    dd:63:bc:00:d0:4e:83:fc:fb:2c:1a:c1:6c:08:1a:
                    96:d2:c0:54:8f:7d:a9:21:30:10:cd:71:ef:bc:fe:
                    0d:ff:69:9d:a8:ed:83:39:82:5d:ef:d2:ab:b6:48:
                    46:04:b0:11:23:1c:f7:e6:62:0b:fd:34:53:08:4c:
                    01:ae:d4:a5:e7:54:cb:fc:8c:46:50:5e:e0:2a:91:
                    71:55:ef:4f:3f:23:2e:66:3f:27:86:af:e2:0b:ce:
                    d4:d0:c5:0d:cc:13:64:e0:7f:29:89:3e:a4:40:48:
                    0a:28:4b
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         87:73:3e:1d:9e:e4:0f:45:32:04:61:dd:90:ae:81:90:d9:d7:
         f5:d7:60:94:d2:f5:5d:6c:85:33:bd:b6:91:ad:d5:21:af:e2:
         2e:63:34:a5:94:68:f7:50:ae:3f:0e:39:6f:2d:57:6f:5c:04:
         a2:bb:e2:06:d9:36:ce:a2:40:c1:c5:eb:c4:e8:75:e2:dc:9c:
         90:83:37:f1:6d:99:9c:be:9e:1c:ae:7b:e8:15:b7:d0:c7:17:
         16:24:43:25:ef:d1:0d:86:0c:72:af:f7:5f:45:d7:fc:4a:9d:
         19:6e:33:cf:c5:29:33:b2:ed:06:ec:92:f4:61:5b:fe:1a:17:
         29:17:c2:f9:f4:51:c1:83:41:e5:dc:86:a2:75:c1:8d:bf:cb:
         e2:b5:1d:97:0f:1d:ab:c4:33:b2:12:60:ac:f2:6f:c4:3c:f5:
         13:64:ea:f7:7d:e1:48:25:6e:83:ce:05:90:6f:a1:fb:6d:37:
         ef:bd:bf:b4:4d:90:50:9b:70:02:54:f8:94:7b:df:ca:2a:4a:
         e3:60:8e:7e:b0:f4:84:21:3e:64:a3:c9:ac:d8:e9:91:79:51:
         d1:06:9e:70:a7:a5:1f:f6:c4:96:7c:d6:e1:bc:c0:c4:df:55:
         1f:ea:18:37:f0:d3:d5:26:fb:61:7a:c1:10:18:e6:a5:cb:46:
         d1:1c:be:7d:7c:41:c9:14:c8:f7:a5:1c:1f:8a:ed:c4:7f:0b:
         5c:b7:36:7a:b2:8e:21:32:8d:ce:af:97:ba:93:1e:d3:b1:dc:
         00:1c:6c:af:02:46:37:72:48:44:15:df:a4:f1:83:c2:6d:a9:
         90:77:dc:10:c1:7d:96:59:b9:c9:98:d9:b1:ce:36:d9:7a:ab:
         f3:67:3e:88:44:bb:2b:ae:84:2e:a8:22:4b:b7:f8:e6:87:32:
         13:9f:23:2d:b6:3c:80:84:40:a2:f0:4a:bd:34:c3:c7:49:7f:
         83:0a:82:a5:32:b6:46:be:81:af:f2:9e:7f:1b:d6:88:63:02:
         ed:38:ee:30:f1:a5:09:35:ca:3a:9f:95:e1:64:62:0c:ca:ea:
         ec:1b:e4:9e:4f:77:2b:9d:b6:83:06:27:2a:02:c1:e5:6d:cf:
         70:42:87:49:8e:55:4e:f1:d9:10:ea:18:db:6b:3a:8a:70:a8:
         ab:5b:03:ed:d2:a4:34:26:5c:53:cb:bd:83:b7:f0:7b:29:6b:
         4e:f5:d9:02:61:f5:9a:2c:e6:b1:74:b5:af:c8:f9:f3:1b:9f:
         f9:c3:7f:25:0a:7d:bb:33:28:10:ff:e1:4c:f3:56:5e:37:8f:
         3f:59:6a:42:41:29:bc:c5:ff:3d:e5:5d:47:8c:04:6e:8a:53:
         9e:90:85:28:0e:09:b9:41

eigene CA: CSR beabeiten - Zertifikat erstellen

Kommen wir zum krönenden Abschluss - wir signieren nun das Server-Zertifikat durch unsere CA, oder anders ausgedrückt, wir erstellen das benötigte X.509-Serverzertifikat.

Wie schon bereits bei den anderen Konfigurationsbeispielen, sind auch hier die Eingaben in der Farbe blau und die Rückmeldungen in der Farbe schwarz 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
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 0 (0x0)
        Validity
            Not Before: Aug 29 21:44:44 2014 GMT
            Not After : Aug 28 21:44:44 2016 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bayern
            organizationName          = nausch.org
            organizationalUnitName    = WEB-Office
            commonName                = www.sec-mail.guru
            emailAddress              = webmaster@sec-mail.guru
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                88:A5:D6:38:7F:2A:1F:27:32:75:C3:3A:AE:0D:40:EE:CB:24:15:FA
            X509v3 Authority Key Identifier: 
                keyid:99:32:8B:E6:2C:6E:B2:95:09:34:96:E5:F4:59:5A:5D:2A:AD:1C:C6

Certificate is to be certified until Aug 28 21:44:44 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

In unserem Arbeitsverzeichnis finden wir nun auch das Serverzertifikat servercert.pem.

Auch hier können wir uns mit hilfe von openssl das Zertifikat genauer ansehen.

 # openssl x509 -noout -text -in servercert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=Zertifizierungsstelle, CN=nausch.org/emailAddress=ca-support@nausch.org
        Validity
            Not Before: Aug 29 21:44:44 2014 GMT
            Not After : Aug 28 21:44:44 2016 GMT
        Subject: C=DE, ST=Bayern, O=nausch.org, OU=WEB-Office, CN=www.sec-mail.guru/emailAddress=webmaster@sec-mail.guru
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:af:7d:5b:23:d3:2f:99:11:b3:f5:ce:54:17:eb:
                    3f:af:5d:7b:df:41:73:5f:4e:a2:a7:2f:de:c5:d3:
                    c6:21:a3:8d:b7:a1:d5:2d:78:87:1a:24:6a:ad:52:
                    9c:e6:85:21:a6:c3:ed:19:ee:8c:95:01:48:8b:b9:
                    9b:6c:0a:15:e4:ff:fa:b3:92:b7:91:f2:f1:a3:93:
                    c4:28:44:48:30:a7:76:1b:19:3c:5c:95:bd:9c:81:
                    85:4f:68:48:35:ec:e9:70:61:a3:40:7b:0e:59:c6:
                    fe:c6:60:72:12:80:1b:2b:d4:c4:52:74:9e:a5:a3:
                    a9:6b:1b:1a:db:0e:5d:df:5d:8a:e3:4e:50:d9:b5:
                    df:71:30:81:09:e3:38:7d:0a:e3:a8:7c:d9:45:d0:
                    f1:76:6c:ff:d2:6b:95:03:5a:0a:44:70:da:6c:07:
                    38:73:43:01:43:79:c8:6f:63:e2:c2:09:89:76:b2:
                    ea:26:89:7b:64:f6:8a:23:cb:8f:bb:aa:ac:4a:26:
                    b1:c1:f4:c5:7f:af:77:36:58:d1:d2:8c:86:c2:fd:
                    26:e8:26:d6:ad:97:8e:7c:7f:8a:1c:ac:70:fe:4c:
                    45:5f:ea:ea:df:ec:a5:61:a0:33:b5:db:55:3e:e5:
                    cf:f2:88:d3:85:78:82:d5:cb:72:21:ff:8d:16:7f:
                    a8:31:c4:e8:dd:33:f9:96:f6:16:dd:c8:06:bc:a7:
                    e9:66:81:b5:75:42:50:50:e8:7a:b8:7b:90:f4:ef:
                    5d:83:94:74:ec:35:03:d5:0f:36:42:30:dc:f0:c0:
                    38:34:95:9a:eb:d1:62:e3:9d:89:76:30:74:62:26:
                    75:29:8e:92:1a:61:85:41:84:67:9b:f5:94:c8:b6:
                    9a:af:44:13:23:9b:27:16:d4:d3:05:b3:36:4d:60:
                    3d:27:a3:c7:cf:bf:15:e7:ed:4c:88:45:1b:3b:8c:
                    ff:2b:48:6c:01:23:9b:2b:31:77:e8:8c:b8:89:e9:
                    a6:94:94:4d:da:8d:74:08:f7:1d:36:3a:b6:1b:00:
                    df:7a:ce:06:fe:a4:8d:bd:fc:8f:df:45:21:7a:cd:
                    dd:63:bc:00:d0:4e:83:fc:fb:2c:1a:c1:6c:08:1a:
                    96:d2:c0:54:8f:7d:a9:21:30:10:cd:71:ef:bc:fe:
                    0d:ff:69:9d:a8:ed:83:39:82:5d:ef:d2:ab:b6:48:
                    46:04:b0:11:23:1c:f7:e6:62:0b:fd:34:53:08:4c:
                    01:ae:d4:a5:e7:54:cb:fc:8c:46:50:5e:e0:2a:91:
                    71:55:ef:4f:3f:23:2e:66:3f:27:86:af:e2:0b:ce:
                    d4:d0:c5:0d:cc:13:64:e0:7f:29:89:3e:a4:40:48:
                    0a:28:4b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                88:A5:D6:38:7F:2A:1F:27:32:75:C3:3A:AE:0D:40:EE:CB:24:15:FA
            X509v3 Authority Key Identifier: 
                keyid:99:32:8B:E6:2C:6E:B2:95:09:34:96:E5:F4:59:5A:5D:2A:AD:1C:C6

    Signature Algorithm: sha256WithRSAEncryption
         64:ba:d4:09:04:c9:1a:67:68:10:82:c8:fb:e1:9b:f5:67:dc:
         dc:8d:40:a8:a5:88:3e:45:31:18:a0:16:1a:f3:e2:c2:8c:64:
         2b:e3:0c:f7:77:94:f3:4a:71:50:86:ac:29:b2:77:c5:d1:71:
         75:e3:5f:2e:9b:ba:54:a0:68:2a:72:43:1b:91:94:00:85:31:
         f3:19:41:80:b5:47:5b:e7:15:5a:1f:81:d4:31:a0:de:1b:15:
         47:a9:1a:61:56:25:e2:db:d9:bd:79:74:6f:85:d5:15:f2:e6:
         0d:f9:47:55:29:7a:88:8b:75:c7:14:32:f1:8b:09:54:59:fe:
         d7:31:8b:1d:44:ff:26:a5:b3:8e:4d:3a:cb:ee:30:04:34:ce:
         b1:b2:87:dd:08:68:ef:cc:b7:eb:9b:49:04:b1:e7:95:d6:8a:
         16:97:b2:ea:41:55:76:be:9e:b9:cc:c6:47:66:c8:43:e8:da:
         e8:ed:22:35:7d:80:91:9d:82:03:d6:a5:fc:07:a6:07:e1:de:
         24:6e:fa:57:87:6e:37:43:b0:bd:23:0e:d3:18:0d:3a:9f:c4:
         1d:d1:85:81:f5:03:80:47:9d:b8:c1:16:46:d4:69:c5:c9:90:
         51:92:96:d1:3e:fd:e3:fb:f2:d0:61:40:8b:22:4b:84:b8:13:
         65:ad:e7:05:cd:37:c8:52:8d:5f:e5:82:97:cb:2e:72:45:8b:
         2e:6f:66:37:c0:2c:01:2e:78:43:a9:08:20:24:12:8d:ab:89:
         9f:41:e7:68:bc:8a:46:96:98:d1:3a:b8:c0:8b:9e:5b:f3:86:
         10:ed:a5:b5:e4:94:3b:51:4a:5d:bb:ba:6f:f0:fc:fb:56:d5:
         22:52:71:ef:83:f8:2e:48:2d:d2:0e:26:d6:ae:bb:c7:e1:ae:
         bd:0d:38:45:64:73:fb:29:87:ed:8d:06:ee:97:1e:f8:67:18:
         9a:5f:09:c5:e6:34:18:49:61:25:89:cb:be:5b:6d:ae:89:55:
         79:52:0e:dc:09:08:72:b4:6c:2d:76:ec:e3:e8:38:f5:9c:a1:
         9b:a6:c8:ce:2b:cf:15:b3:02:14:66:8c:7b:bd:cb:3d:5e:e1:
         05:7b:8a:23:bd:9e:d7:b4:98:15:17:3b:76:4d:cf:9a:7c:8d:
         86:ef:16:d9:b2:7e:6b:b5:3e:d5:5c:41:19:38:b3:45:ca:03:
         37:55:d5:d0:5d:0b:26:8a:de:e3:ae:cc:8c:35:66:bd:89:c6:
         b7:c7:a5:10:9d:42:48:df:f0:24:c3:be:22:cc:40:5a:f1:9e:
         f1:4a:97:5f:5b:fb:f0:e3:eb:1f:d6:b8:b5:1e:d4:79:91:20:
         ce:74:c0:d9:27:8f:d8:9c

Speicherort

Bei der Installation der openssl-libs wurden bereits die Unterordner für das WEB-Server-Zertifikat und der zugehörigen Schlüssel-Datei unter /etc/pki/tls angelegt.

/etc/pki/tls/
├── cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
├── certs
│   ├── 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
│   ├── localhost.crt
│   ├── make-dummy-cert
│   ├── Makefile
│   └── renew-dummy-cert
├── misc
│   ├── CA
│   ├── c_hash
│   ├── c_info
│   ├── c_issuer
│   └── c_name
├── openssl.cnf
└── private
    └── localhost.key

Anschließend legen wir dort die drei benötigten Dateien ab:

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

ssl.conf

Bei der Konfiguration unseres TLS-gesicherten Apache-Webservers benutzen wir nun nicht die (komplette) mitgelieferte Konfigurationsdatei /etc/httpd/conf.d/sssl.conf, sondern verlagern die zum Apache vHost, egal ob name based oder IP based, passende Konfigurationsdatei.

Wir sichern dazu erst einmal die originale Konfigurationsdatei.

 # cp -a /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.orig

Im ersten Schritt werden wir nun bestehende Konfigurationsdatei soweit „ausdünnen und nur den ersten Teil verwenden. Den Abschnitt SSL Virtual Host Context können wir nun entweder komplett löschen oder entsprechend auskommentieren.

 # vim /etc/http/conf.d/ssl.conf
/etc/http/conf.d/ssl.conf
#
# When we also provide SSL we have to listen to the 
# the HTTPS port in addition.
#
Listen 443 https
 
##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##
 
#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
 
#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism 
#   to use and second the expiring timeout (in seconds).
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
 
#   Pseudo Random Number Generator (PRNG):
#   Configure one or more sources to seed the PRNG of the 
#   SSL library. The seed data should be of good random quality.
#   WARNING! On some platforms /dev/random blocks if not enough entropy
#   is available. This means you then cannot use the /dev/random device
#   because it would lead to very long connection times (as long as
#   it requires to make more entropy available). But usually those
#   platforms additionally provide a /dev/urandom device which doesn't
#   block. So, if available, use this one instead. Read the mod_ssl User
#   Manual for more details.
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random  512
#SSLRandomSeed connect file:/dev/random  512
#SSLRandomSeed connect file:/dev/urandom 512
 
#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names.  NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly. 
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec
 
 
##
## SSL Virtual Host Context
##
 
#<VirtualHost _default_:443>
#
## General setup for the virtual host, inherited from global configuration
##DocumentRoot "/var/www/html"
##ServerName www.example.com:443
#
## Use separate log files for the SSL virtual host; note that LogLevel
## is not inherited from httpd.conf.
#ErrorLog logs/ssl_error_log
#TransferLog logs/ssl_access_log
#LogLevel warn
#
##   SSL Engine Switch:
##   Enable/Disable SSL for this virtual host.
#SSLEngine on
#
##   SSL Protocol support:
## List the enable protocol levels with which clients will be able to
## connect.  Disable SSLv2 access by default:
#SSLProtocol all -SSLv2
#
##   SSL Cipher Suite:
##   List the ciphers that the client is permitted to negotiate.
##   See the mod_ssl documentation for a complete list.
#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
#
##   Speed-optimized SSL Cipher configuration:
##   If speed is your main concern (on busy HTTPS servers e.g.),
##   you might want to force clients to specific, performance
##   optimized ciphers. In this case, prepend those ciphers
##   to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
##   Caveat: by giving precedence to RC4-SHA and AES128-SHA
##   (as in the example below), most connections will no longer
##   have perfect forward secrecy - if the server's key is
##   compromised, captures of past or future traffic must be
##   considered compromised, too.
##SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
##SSLHonorCipherOrder on 
#
##   Server Certificate:
## Point SSLCertificateFile at a PEM encoded certificate.  If
## the certificate is encrypted, then you will be prompted for a
## pass phrase.  Note that a kill -HUP will prompt again.  A new
## certificate can be generated using the genkey(1) command.
#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
#
##   Server Private Key:
##   If the key is not combined with the certificate, use this
##   directive to point at the key file.  Keep in mind that if
##   you've both a RSA and a DSA private key you can configure
##   both in parallel (to also allow the use of DSA ciphers, etc.)
#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
#
##   Server Certificate Chain:
##   Point SSLCertificateChainFile at a file containing the
##   concatenation of PEM encoded CA certificates which form the
##   certificate chain for the server certificate. Alternatively
##   the referenced file can be the same as SSLCertificateFile
##   when the CA certificates are directly appended to the server
##   certificate for convinience.
##SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
#
##   Certificate Authority (CA):
##   Set the CA certificate verification path where to find CA
##   certificates for client authentication or alternatively one
##   huge file containing all of them (file must be PEM encoded)
##SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
#
##   Client Authentication (Type):
##   Client certificate verification type and depth.  Types are
##   none, optional, require and optional_no_ca.  Depth is a
##   number which specifies how deeply to verify the certificate
##   issuer chain before deciding the certificate is not valid.
##SSLVerifyClient require
##SSLVerifyDepth  10
#
##   Access Control:
##   With SSLRequire you can do per-directory access control based
##   on arbitrary complex boolean expressions containing server
##   variable checks and other lookup directives.  The syntax is a
##   mixture between C and Perl.  See the mod_ssl documentation
##   for more details.
##<Location />
##SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
##            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
##            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
##            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
##            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
##           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
##</Location>
#
##   SSL Engine Options:
##   Set various options for the SSL engine.
##   o FakeBasicAuth:
##     Translate the client X.509 into a Basic Authorisation.  This means that
##     the standard Auth/DBMAuth methods can be used for access control.  The
##     user name is the `one line' version of the client's X.509 certificate.
##     Note that no password is obtained from the user. Every entry in the user
##     file needs this password: `xxj31ZMTZzkVA'.
##   o ExportCertData:
##     This exports two additional environment variables: SSL_CLIENT_CERT and
##     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
##     server (always existing) and the client (only existing when client
##     authentication is used). This can be used to import the certificates
##     into CGI scripts.
##   o StdEnvVars:
##     This exports the standard SSL/TLS related `SSL_*' environment variables.
##     Per default this exportation is switched off for performance reasons,
##     because the extraction step is an expensive operation and is usually
##     useless for serving static content. So one usually enables the
##     exportation for CGI and SSI requests only.
##   o StrictRequire:
##     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
##     under a "Satisfy any" situation, i.e. when it applies access is denied
##     and no other module can change it.
##   o OptRenegotiate:
##     This enables optimized SSL connection renegotiation handling when SSL
##     directives are used in per-directory context. 
##SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
#<Files ~ "\.(cgi|shtml|phtml|php3?)$">
#    SSLOptions +StdEnvVars
#</Files>
#<Directory "/var/www/cgi-bin">
#    SSLOptions +StdEnvVars
#</Directory>
#
##   SSL Protocol Adjustments:
##   The safe and default but still SSL/TLS standard compliant shutdown
##   approach is that mod_ssl sends the close notify alert but doesn't wait for
##   the close notify alert from client. When you need a different shutdown
##   approach you can use one of the following variables:
##   o ssl-unclean-shutdown:
##     This forces an unclean shutdown when the connection is closed, i.e. no
##     SSL close notify alert is send or allowed to received.  This violates
##     the SSL/TLS standard but is needed for some brain-dead browsers. Use
##     this when you receive I/O errors because of the standard approach where
##     mod_ssl sends the close notify alert.
##   o ssl-accurate-shutdown:
##     This forces an accurate shutdown when the connection is closed, i.e. a
##     SSL close notify alert is send and mod_ssl waits for the close notify
##     alert of the client. This is 100% SSL/TLS standard compliant, but in
##     practice often causes hanging connections with brain-dead browsers. Use
##     this only for browsers where you know that their SSL implementation
##     works correctly. 
##   Notice: Most problems of broken clients are also related to the HTTP
##   keep-alive facility, so you usually additionally want to disable
##   keep-alive for those clients, too. Use variable "nokeepalive" for this.
##   Similarly, one has to force some clients to use HTTP/1.0 to workaround
##   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
##   "force-response-1.0" for this.
#BrowserMatch "MSIE [2-5]" \
#         nokeepalive ssl-unclean-shutdown \
#         downgrade-1.0 force-response-1.0
#
##   Per-Server Logging:
##   The home of a custom SSL log file. Use this when you want a
##   compact non-error SSL logfile on a virtual host basis.
#CustomLog logs/ssl_request_log \
#          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
#
#</VirtualHost> 

Die Hauptkonfiguration beschrängt sich demnach auf folgende sieben Zeilen:

 # egrep -v '(^.*#|^$)' /etc/httpd/conf.d/ssl.conf
Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin

vHost.conf

 # vim  /etc/httpd/conf.d/forum.conf
/etc/httpd/conf.d/forum.conf
#
# Django : 2015-10-30
#          vHost hk-forum
#
 
# Variablen der Hostvariablen
Define vhost hk-forum
Define errors_log logs/${vhost}_error.log
Define access_log logs/${vhost}_access.log
Define ssl_log logs/${vhost}_ssl_request.log
 
<VirtualHost 10.0.0.97:80>
    ServerAdmin webmaster@nausch.org
    ServerName ${vhost}.nausch.org
 
    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 
    # Welche Logdateien sollen beschrieben werden
    SetEnvIf Remote_Addr "10\.0\.0\.20" dontlog
    ErrorLog  ${errors_log}
    CustomLog ${access_log} combined env=!dontlog
</VirtualHost>
<VirtualHost 10.0.0.97:443>
    ServerAdmin webmaster@nausch.org
    ServerName ${vhost}.nausch.org
    ServerPath /
 
    # Wer soll Zugriff auf die Webseite(n) bekommen?
    #<Location />
    #    Options +FollowSymLinks +Multiviews -Indexes
    #    AllowOverride None
    #    AuthType Basic
    #    AuthName "Fuer den Zugriff auf den Webserver bitte Anmeldedaten eingeben!"
    #    AuthBasicProvider ldap
    #    AuthLDAPUrl ldaps://openldap.dmz.nausch.org:636/ou=People,dc=nausch,dc=org?uid
    #    AuthLDAPBindDN cn=Technischeruser,dc=nausch,dc=org
    #    AuthLDAPBindPassword "M52wFn0r0w95z5bn/\EU64FE!" 
    #    AuthLDAPBindAuthoritative on
    #    Require ldap-user accessuser
    #</Location>
 
    # Welcher Inhalt soll angezeigt bzw. auf welchen Server sollen die HTTP-Requests 
    #weitergeleitet werden?
    DocumentRoot   "/srv/www/html/${vhost}/"
    DirectoryIndex index.php
 
    <Directory /srv/www/html/${vhost}/>
        Options none
        AllowOverride Limit
        Require all granted
    </Directory>
 
    <LocationMatch "/(config.inc.php|configs|scripts|tests|users|VIRTUALVACATIONS)/">
        Require all denied
    </LocationMatch>
 
    # Welche Logdateien sollen beschrieben werden
    SetEnvIf Remote_Addr "10\.0\.0\.20" dontlog
    ErrorLog  ${errors_log}
    CustomLog ${access_log} combined env=!dontlog
    CustomLog ${ssl_log} "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
 
    # Absicherung der Übertragung mit Hilfe von TLS
    # Django : 2015-10-04 - TLS-Verschlüsselung mit Hilfe von mod_ssl
    SSLEngine on
    # Definition der anzubietenden Protokolle
    SSLProtocol All -SSLv2 -SSLv3
    # Definition der Cipher
    SSLCipherSuite "AES256+EECDH +AEAD"
    # Schlüsseldatei, mit der der CSR erstellt wurde
    SSLCertificateKeyFile /etc/pki/tls/private/${vhost}.nausch.org.serverkey.pem
    # Zertifikatsdatei , die von der CA signiert wurde
    SSLCertificateFile /etc/pki/tls/certs/${vhost}.nausch.org.certificate.pem
    # Zertifikatsdatei des bzw. der Intermediate-Zertifikate(s)
    SSLCertificateChainFile /etc/pki/tls/certs/Intermediate.certificate.pem
    # Änderung der Cipherorder der Clienets verneinen 
    SSLHonorCipherOrder on
    # TLS 1.0 Kompremmierung deaktivieren (CRIME attacks)
    SSLCompression off
    # Online Certificate Status Protocol stapling zum Prüfen des
    # Gültigkeitsstatus des Serverzertifikats.
    SSLUseStapling      on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    # ist in der ssl.conf 
    # SSLStaplingCache        shmcb:/var/run/ocsp(128000)
 
    # special stuff ###
 
    # HTTP Strict Transport Security (HSTS), bei dem der Server dem Client im HTTP-Header 
    # mitteilt, dass dieser nur noch verschlüsselt mit dem Server kommunizieren soll.
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
 
    # This header enables the Cross-site scripting (XSS) filter built into most recent 
    # web browsers. It's usually enabled by default anyway, so the role of this header 
    # is to re-enable the filter for this particular website if it was disabled by the 
    # user. https://www.owasp.org/index.php/List_of_useful_HTTP_headers
    Header set X-XSS-Protection "1; mode=block"
 
    # when serving user-supplied content, include a X-Content-Type-Options: nosniff 
    # header along with the Content-Type: header, to disable content-type sniffing on 
    # some browsers. https://www.owasp.org/index.php/List_of_useful_HTTP_headers
    # currently suppoorted in IE > 8 
    # http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
    # http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
    # 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
    Header set X-Content-Type-Options nosniff
 
    # config to don't allow the browser to render the page inside an frame or iframe
    # and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking
    # if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with 
    # ALLOW-FROM uri https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
    header set X-Frame-Options DENY
 
    # hide server header (apache and php version)
    Header unset Server
 
    # Only allow JavaScript from the same domain to be run.
    # don't allow inline JavaScript to run.
    Header set X-Content-Security-Policy "allow 'self';"
 
    # Add Secure and HTTP only attributes to cookies
    Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
 
    # prevent Clickjacking Attack
    #Header always append X-Frame-Options SAMEORIGIN
    Header set Content-Security-Policy "default-src 'self';"
</VirtualHost>

FIXME

 # vim /etc/httpd/conf.d/ssl.conf
/etc/httpd/conf.d/ssl.conf
#
# When we also provide SSL we have to listen to the 
# the HTTPS port in addition.
#
Listen 443 https
 
##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##
 
#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
 
#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism 
#   to use and second the expiring timeout (in seconds).
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
 
#   Pseudo Random Number Generator (PRNG):
#   Configure one or more sources to seed the PRNG of the 
#   SSL library. The seed data should be of good random quality.
#   WARNING! On some platforms /dev/random blocks if not enough entropy
#   is available. This means you then cannot use the /dev/random device
#   because it would lead to very long connection times (as long as
#   it requires to make more entropy available). But usually those
#   platforms additionally provide a /dev/urandom device which doesn't
#   block. So, if available, use this one instead. Read the mod_ssl User
#   Manual for more details.
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random  512
#SSLRandomSeed connect file:/dev/random  512
#SSLRandomSeed connect file:/dev/urandom 512
 
#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names.  NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly. 
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec
 
##
## SSL Virtual Host Context
##
 
<VirtualHost _default_:443>
 
# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443
 
    ServerAdmin webmaster@sec-mail.guru
    ServerName www.sec-mail.guru
    ServerPath /
    DocumentRoot "/var/www/default"
 
    <Directory "/var/www/default">
        Options FollowSymLinks
        AllowOverride none
        Order allow,deny
        Allow from All
    </Directory>
 
    <LocationMatch "/(data|conf|bin|inc)/">
        Order allow,deny
        Deny from all
        Satisfy All
    </LocationMatch>
 
    DirectoryIndex index.php
 
 
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
# Django : 2014-08-30
# default: ErrorLog logs/ssl_error_log
#          TransferLog logs/ssl_access_log
ErrorLog logs/default-host_sec-mail.guru_error.log
TransferLog logs/default-host_sec-mail.guru_access.log
LogLevel warn
 
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on
 
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
# Django : 2014-08-30 Nur die beiden folgenden Protokolle SSLv3 und TLSv1 anbieten: 
# default: SSLProtocol all -SSLv2
SSLProtocol All -SSLv2 -SSLv3
 
#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
# Django : 2014-08-30 
# default: SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
# Docu   : http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
SSLCipherSuite EECDH+AES256:DHE+AES256:EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
 
#   Speed-optimized SSL Cipher configuration:
#   If speed is your main concern (on busy HTTPS servers e.g.),
#   you might want to force clients to specific, performance
#   optimized ciphers. In this case, prepend those ciphers
#   to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
#   Caveat: by giving precedence to RC4-SHA and AES128-SHA
#   (as in the example below), most connections will no longer
#   have perfect forward secrecy - if the server's key is
#   compromised, captures of past or future traffic must be
#   considered compromised, too.
#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
# Django : 2014-8-30
# default: #SSLHonorCipherOrder on 
SSLHonorCipherOrder on
 
#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
# Django : 2014-08-30
# default: SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile /etc/pki/tls/certs/servercert.pem
 
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
# Django : 2014-08-30
# default: SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/pki/tls/private/serverkey.pem
 
#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
 
#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# Django : 2014-08-30
# default: unset
SSLCACertificateFile /etc/pki/tls/certs/cacert.pem
 
#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth  10
 
#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives.  The syntax is a
#   mixture between C and Perl.  See the mod_ssl documentation
#   for more details.
#<Location />
#SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
#            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
#            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
#            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
#            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
#           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
 
#   SSL Engine Options:
#   Set various options for the SSL engine.
#   o FakeBasicAuth:
#     Translate the client X.509 into a Basic Authorisation.  This means that
#     the standard Auth/DBMAuth methods can be used for access control.  The
#     user name is the `one line' version of the client's X.509 certificate.
#     Note that no password is obtained from the user. Every entry in the user
#     file needs this password: `xxj31ZMTZzkVA'.
#   o ExportCertData:
#     This exports two additional environment variables: SSL_CLIENT_CERT and
#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
#     server (always existing) and the client (only existing when client
#     authentication is used). This can be used to import the certificates
#     into CGI scripts.
#   o StdEnvVars:
#     This exports the standard SSL/TLS related `SSL_*' environment variables.
#     Per default this exportation is switched off for performance reasons,
#     because the extraction step is an expensive operation and is usually
#     useless for serving static content. So one usually enables the
#     exportation for CGI and SSI requests only.
#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.
#   o OptRenegotiate:
#     This enables optimized SSL connection renegotiation handling when SSL
#     directives are used in per-directory context. 
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
 
#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is send or allowed to received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is send and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly. 
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
 
#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
 
</VirtualHost>
 # systemctl start httpd.service
[Sat Aug 30 15:51:04.835612 2014] [suexec:notice] [pid 2696] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Aug 30 15:51:04.877767 2014] [auth_digest:notice] [pid 2696] AH01757: generating secret for digest authentication ...
[Sat Aug 30 15:51:04.878617 2014] [lbmethod_heartbeat:notice] [pid 2696] AH02282: No slotmem from mod_heartmonitor
[Sat Aug 30 15:51:04.896281 2014] [mpm_prefork:notice] [pid 2696] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations
[Sat Aug 30 15:51:04.896317 2014] [core:notice] [pid 2696] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
 # less /var/log/httpd/default-host_sec-mail.guru_access.log
10.0.0.20 - - [30/Aug/2014:16:17:26 +0200] "GET / HTTP/1.1" 302 -
10.0.0.20 - - [30/Aug/2014:16:17:26 +0200] "GET /doku.php HTTP/1.1" 200 9748
10.0.0.20 - - [30/Aug/2014:16:17:27 +0200] "GET /lib/exe/indexer.php?id=start&1409408246 HTTP/1.1" 200 42
 # less /var/log/httpd/ssl_request_log
[30/Aug/2014:16:17:26 +0200] 10.0.0.20 TLSv1 ECDHE-RSA-RC4-SHA "GET / HTTP/1.1" -
[30/Aug/2014:16:17:26 +0200] 10.0.0.20 TLSv1 ECDHE-RSA-RC4-SHA "GET /doku.php HTTP/1.1" 9748
[30/Aug/2014:16:17:27 +0200] 10.0.0.20 TLSv1 ECDHE-RSA-RC4-SHA "GET /lib/exe/indexer.php?id=start&1409408246 HTTP/1.1" 42

https://addons.mozilla.org/de/firefox/addon/calomel-ssl-validation/

https://mozilla.github.io/server-side-tls/ssl-config-generator/

HSTS

In der vHost-Definition unseres Apache-vHOST ergänzen wir folgende Zeile Header always set Strict-Transport-Security „max-age=63072000; includeSubDomains; preload“.

 # vim /etc/httpd/conf.d/forum.conf
...
 
# HTTP Strict Transport Security (HSTS), bei dem der Server dem Client im 
# HTTP-Header mitteilt, dass dieser nur noch verschlüsselt mit dem Server 
# kommunizieren soll.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
 
...

OCSP Stapling

In der /etc/httpd/conf.d/ssl.conf folgende Konfigurationszeile nachtragen SSLStaplingCache „shmcb:/var/run/httpd/stapling_cache(128000)“.

 # vim /etc/httpd/conf.d/ssl.conf
...
 
# Django : 2015-11-11
# Chache-Definition für Online Certificate Status Protocol stapling
SSLStaplingCache "shmcb:/var/run/httpd/stapling_cache(128000)"
 
...

In der vHost-Definition unseres Apache-vHOST ergänzen wir folgende drei Zeilen.

 # vim /etc/httpd/conf.d/forum.conf
...
 
    # Online Certificate Status Protocol stapling zum Prüfen des Gültigkeitsstatus 
    # des Serverzertifikats.
    SSLUseStapling      on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
 
...
 $ openssl s_client -connect forum.nausch.org:443 -servername forum.nausch.org -status < /dev/null
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 OU = Domain Control Validated, CN = forum.nausch.org
verify return:1
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: EE5EFFFE85DB26C626FBD3698410AD1D0DD3EF58
    Produced At: Nov 29 18:16:05 2016 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 84D56BF8098BD307B766D8E1EBAD6596AA6B6761
      Issuer Key Hash: F5CDD53C0850F96A4F3AB797DA5683E669D268F7
      Serial Number: 6922D213277B49AC169E77A9
    Cert Status: good
    This Update: Nov 29 18:16:05 2016 GMT
    Next Update: Dec  3 18:16:05 2016 GMT

...

Werden keine OCSP-Response Daten angezeigt, ist dies ein Hinweis, dass die OCSP_Konfiguration nnoch nicht richtig abgeschlossen wurde!

Zum Testen kann man alternativ auch den Test bei Qualys SSL Labs oder Observatory by Mozilla nutzen.

In der vHost-Definition unseres Apache-vHOST ergänzen wir folgende Zeile Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure .

 # vim /etc/httpd/conf.d/forum.conf
...
 
# Add Secure and HTTP only attributes to cookies
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
 
...

https://tools.geekflare.com/web-tools/http-header-analyzer

set-cookie: Forum=rtg65np1t1cvnrg7n30l8mad67; path=/; secure;
HttpOnly;HttpOnly;SecureDW7fa065a06cb74b536c124cfbe56ac6d3=deleted;
expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; secure; httponly;HttpOnly;Secure

HttpOnly und Secure kennzeichnen die erfolgreiche Änderung!

HPKP

RFC 7469

 # openssl rsa -pubout -in /etc/pki/tls/private/forum.nausch.org.serverkey.pem \
               -outform der | openssl dgst -sha256 -binary | base64
writing RSA key
nMiOpb6vUnjCoWCkPkDaG4ND8SNWzFTsQf2ZfruLno0=

pin-sha256=„nMiOpb6vUnjCoWCkPkDaG4ND8SNWzFTsQf2ZfruLno0=“

 # openssl rsa -pubout -in /etc/pki/tls/private/forum.nausch.org._BACKUP_serverkey.pem \
               -outform der | openssl dgst -sha256 -binary | base64
writing RSA key
INhxSQ38nCS6ijaAAyo4xAhAZj9xeL3Xaak+GGiM2fo=

Zum Löschen von outdated bzw. falschen key-hashes beim Firefox zuerst einam den Browser stoppen. Anschließend bearbeiten wir die Einträge in der Datei SiteSecurityServiceState.txt im profile-Pafd unserer Installation.

 # vim ~/.mozilla/firefox/[unique-id].default/SiteSecurityServiceState.txt

Nach dem Speichern unserer Änderungen starten wir den Browser neu und können wieder auf die zuvor blockierten Seiten zugreifen.


1)
Perfect Forward Secrecy
2)
Secure Sockets Layer
3)
Transport Layer Security
4)
Sammlung von standardisierten kryptographischer Algorithmen
5)
Ausgabe in formatierter Tabelle
6)
Diffie Hellmann
7)
Elliptic Curve Diffie Hellmann
8) , 9)
Certificate Authority
10)
Common Name
11) , 13)
Certificate Signing Request
12)
Certification Authority
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/web_c7/apache_2.txt
  • Zuletzt geändert: 02.02.2018 09:39.
  • von django