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.

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 CA¹⁾ 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.

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.

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

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)

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.

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

 # 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

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

 # 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

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

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

~~AUTOTWEET:~~