centos:ca-trust

Dies ist eine alte Version des Dokuments!


Vertrauensmodelle in Public-Key-Infrastrukturen

Aktuell in der Bearbeitung!

Bei der asymetrischen Verschlüsselung, wie sie bei SSL/TLS gesicherter Kommunikation zum Einsatz kommt, benötigt der sendende Kommunikationspartner den öffentlichen Schlüssel (public key) des Empfängers. Bei dieser Kommunikation ist es äußerst wichtig, dass die Echtheit des Schlüssels gewährleistet, sprich auch überprüft werden kann. Diese Überprüfung erfolgt mit digitalen Zertifikaten, die die Echtheit eines öffentlichen Schlüssels sowie den Geltungsbereich und die Anwendungsbereich für das Zertifikat bestätigen.

BILD: schematische Darstellung des Vertrauensverhältnis beim PKI Modell

Bei einer reinen 1:1 Kommunikation können sich beide Kommunikationspartner, oder der Client mit dem Server dieses Vertrauen selbst gegenseitig aussprechen. In den allermeisten Fällen wird es aber bei der verschlüsselten und vertraulichen Kommunikation um eine 1:n Kommunikation handeln; d.h. ein Server wird mit unter sehr vielen Clients Daten austauschen. 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 CA1) 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 zugrundeliegender 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!

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

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 mit dem eigentlichem Importvorgang fortfahren!

Zum Importieren des CAcert-Root-Zertifikates benutzen wir nun den Befehl update-ca-trust.

 # update-ca-trust

Ist der Importvorgang abgeschlossen, findet sich am Ende der Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem das gerade importierte Root-Zertifikat. Dies können wir auch mit folgendem Befehl überprüfen.

 # openssl x509 -noout -issuer -in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 issuer= /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org

1)
Certificate Authority
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • centos/ca-trust.1423514624.txt.gz
  • Zuletzt geändert: 09.02.2015 20:43.
  • von django