Authentification auf Userebene und Webseiten gegen OpenLDAP unter CentOS 7.x

OpenLDAP Logo Natürlich wollen wir bei der Authentifikation unserer Cleints auf unseren zentralen OpenLDAP-Verzeichnisdienst zurückgreifen. Nachfolgend werden wir auf einige Beispiele eingehen.

  1. lokale Benutzer
    Bei den betreffenden Clients wollen wir nun die Authentifizierung der einzelnen User nicht mehr gegen die lokale /etc/shadow laufen lassen, denn dazu müssten wir nun auf jedem Host die User manuell (nach)pflegen. Schließlich sollen die User, egal an welchem Host sie sich anmelden, immer auch das gleiche Passwort benutzen können. Nicht zuletzt aus diesem Gründen, haben wir uns für einen zentralen OpenLDAP-Server entschieden.
  2. remote Benutzer
    Melden sich unsere Nutzer an unseren Webseiten an, die eine Authentifikation zum Abruf der Seiten notwendig machen, sollen die User sich mit Ihrem bekannten Nutzerkennung und Passwort aus dem zentralen OpenLDAP-Verzeichnisdienst tun. Hierzu betrachetn wir die nötigen Konfigurationsmaßnahmen an den beiden Webservern Apache und NGiNX.

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

Wir haben nun in der Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem die nötigen Root-Zertifikate und müssen nun nur noch unserem openldap-client mitteilen, diesen auch zu nutzen. Hierzu editieren wir nun die Konfigurationsdatei des openldap-clients.

 # vim /etc/openldap/ldap.conf
/etc/openldap/ldap.conf
#
# LDAP Defaults
#
 
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
 
#BASE           dc=example,dc=com
#URI            ldap://ldap.example.com ldap://ldap-master.example.com:666
 
# Django: 2015-07-17
# defaul: unset
#         Definition des standardmässig abgefragten Teilbaums / Searchbase
#         Anfragen werden unterhalb von dc=nausch, dc=org ausgeführt
BASE            dc=nausch, dc=org
 
#         Definition des LDAP-Servers 
URI             ldap://openldap.dmz.nausch.org
 
 
#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never
 
# Django : 2015-07-17
# default:      TLS_CACERTDIR   /etc/openldap/certs
 
# Django : 2015-07-16
#          Pfad und Datei mit den vertrauenswürdigen Root-Zertifikaten
# default: unset
TLS_CACERT      /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON    on

Zum Testen richten wir erneut eine Anfrage an unseren OpenLDP-Server.

 # ldapsearch -W -x -b "dc=nausch,dc=org" "uid=django" \
              -D "cn=Technischeruser,dc=nausch,dc=org" -LLL \
              -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password: 
dn: uid=django,ou=People,dc=nausch,dc=org
uid: django
cn: django
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 16617
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/django
gecos: django
userPassword:: RGQ0bWRkMyE=

Installation

Als erstes installieren wir uns die benötigten Pakete, sofern diese nicht schon bei der initialen Installation unseres CentOS 7-Clients erfolgt ist.

 # yum install nscd nss-pam-ldapd authconfig -y

Paketinhalte

Welche Pfade angelegt und welche Dateien bei der Installation der RPM-Pakete ins System kopiert wurden, sehen wir uns bei Bedarf und Interesse mit Hilfe des Befehls rpm und der passenden Option -qil an.

nscd

 # rpm -qil nscd
Name        : nscd
Version     : 2.17
Release     : 78.el7
Architecture: x86_64
Install Date: Mo 20 Jul 2015 16:30:11 CEST
Group       : System Environment/Daemons
Size        : 183104
License     : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+
Signature   : RSA/SHA256, Sa 14 Mär 2015 09:20:11 CET, Key ID 24c6a8a7f4a80eb5
Source RPM  : glibc-2.17-78.el7.src.rpm
Build Date  : Do 05 Mär 2015 22:50:19 CET
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.gnu.org/software/glibc/
Summary     : A Name Service Caching Daemon (nscd).
Description :
Nscd caches name service lookups and can dramatically improve
performance with NIS+, and may help with DNS as well.
/etc/nscd.conf
/etc/sysconfig/nscd
/lib/systemd/system/nscd.service
/lib/systemd/system/nscd.socket
/usr/lib/tmpfiles.d/nscd.conf
/usr/sbin/nscd
/var/db/nscd
/var/db/nscd/group
/var/db/nscd/hosts
/var/db/nscd/passwd
/var/db/nscd/services
/var/run/nscd
/var/run/nscd/group
/var/run/nscd/hosts
/var/run/nscd/nscd.pid
/var/run/nscd/passwd
/var/run/nscd/services
/var/run/nscd/socket

nss-pam-ldapd

 # rpm -qil nss-pam-ldapd
Name        : nss-pam-ldapd
Version     : 0.8.13
Release     : 8.el7
Architecture: x86_64
Install Date: Mo 20 Jul 2015 16:30:14 CEST
Group       : System Environment/Base
Size        : 416576
License     : LGPLv2+
Signature   : RSA/SHA256, Fr 04 Jul 2014 05:58:15 CEST, Key ID 24c6a8a7f4a80eb5
Source RPM  : nss-pam-ldapd-0.8.13-8.el7.src.rpm
Build Date  : Di 10 Jun 2014 08:03:46 CEST
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://arthurdejong.org/nss-pam-ldapd/
Summary     : An nsswitch module which uses directory servers
Description :
The nss-pam-ldapd daemon, nslcd, uses a directory server to look up name
service information (users, groups, etc.) on behalf of a lightweight
nsswitch module.
/etc/nslcd.conf
/etc/tmpfiles.d/nss-pam-ldapd.conf
/usr/lib/systemd/system/nslcd.service
/usr/lib64/libnss_ldap.so
/usr/lib64/libnss_ldap.so.2
/usr/lib64/security/pam_ldap.so
/usr/sbin/nslcd
/usr/share/doc/nss-pam-ldapd-0.8.13
/usr/share/doc/nss-pam-ldapd-0.8.13/AUTHORS
/usr/share/doc/nss-pam-ldapd-0.8.13/COPYING
/usr/share/doc/nss-pam-ldapd-0.8.13/ChangeLog
/usr/share/doc/nss-pam-ldapd-0.8.13/HACKING
/usr/share/doc/nss-pam-ldapd-0.8.13/NEWS
/usr/share/doc/nss-pam-ldapd-0.8.13/README
/usr/share/doc/nss-pam-ldapd-0.8.13/TODO
/usr/share/man/man5/nslcd.conf.5.gz
/usr/share/man/man8/nslcd.8.gz
/usr/share/man/man8/pam_ldap.8.gz
/var/run/nslcd

authconfig

 # rpm -qil authconfig
Name        : authconfig               
Version     : 6.2.8                    
Release     : 9.el7                    
Architecture: x86_64                   
Install Date: Do 30 Apr 2015 22:33:35 CEST
Group       : System Environment/Base     
Size        : 2215055                     
License     : GPLv2+                      
Signature   : RSA/SHA256, Sa 14 Mär 2015 08:37:03 CET, Key ID 24c6a8a7f4a80eb5
Source RPM  : authconfig-6.2.8-9.el7.src.rpm                                  
Build Date  : Do 05 Mär 2015 23:01:30 CET                                     
Build Host  : worker1.bsys.centos.org                                         
Relocations : (not relocatable)                                               
Packager    : CentOS BuildSystem <http://bugs.centos.org>                     
Vendor      : CentOS                                                          
URL         : https://fedorahosted.org/authconfig                             
Summary     : Command line tool for setting up authentication from network services
Description :                                                                      
Authconfig is a command line utility which can configure a workstation             
to use shadow (more secure) passwords.  Authconfig can also configure a            
system to be a client for certain networked user information and                   
authentication schemes.                                                            
/etc/pam.d/fingerprint-auth-ac                                                     
/etc/pam.d/password-auth-ac                                                        
/etc/pam.d/postlogin-ac                                                            
/etc/pam.d/smartcard-auth-ac                                                       
/etc/pam.d/system-auth-ac                                                          
/etc/sysconfig/authconfig                                                          
/usr/lib64/python2.7/site-packages/acutilmodule.so                                 
/usr/sbin/authconfig                                                               
/usr/sbin/authconfig-tui                                                           
/usr/sbin/cacertdir_rehash                                                         
/usr/share/authconfig                                                              
/usr/share/authconfig/authconfig-tui.py                                            
/usr/share/authconfig/authconfig-tui.pyc                                           
/usr/share/authconfig/authconfig-tui.pyo                                           
/usr/share/authconfig/authconfig.py                                                
/usr/share/authconfig/authconfig.pyc                                               
/usr/share/authconfig/authconfig.pyo                                               
/usr/share/authconfig/authinfo.py                                                  
/usr/share/authconfig/authinfo.pyc                                                 
/usr/share/authconfig/authinfo.pyo                                                 
/usr/share/authconfig/dnsclient.py                                                 
/usr/share/authconfig/dnsclient.pyc                                                
/usr/share/authconfig/dnsclient.pyo                                                
/usr/share/authconfig/msgarea.py                                                   
/usr/share/authconfig/msgarea.pyc                                                  
/usr/share/authconfig/msgarea.pyo                                                  
/usr/share/authconfig/shvfile.py                                                   
/usr/share/authconfig/shvfile.pyc                                                  
/usr/share/authconfig/shvfile.pyo                                                  
/usr/share/doc/authconfig-6.2.8                                                    
/usr/share/doc/authconfig-6.2.8/COPYING                                            
/usr/share/doc/authconfig-6.2.8/NOTES                                              
/usr/share/doc/authconfig-6.2.8/README.samba3                                      
/usr/share/doc/authconfig-6.2.8/TODO                                               
/usr/share/locale/ar/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/as/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/ast/LC_MESSAGES/authconfig.mo                                    
/usr/share/locale/bal/LC_MESSAGES/authconfig.mo                                    
/usr/share/locale/bg/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/bn/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/bn_IN/LC_MESSAGES/authconfig.mo                                  
/usr/share/locale/bs/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/ca/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/cs/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/cy/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/da/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/de/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/el/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/en_GB/LC_MESSAGES/authconfig.mo                                  
/usr/share/locale/es/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/et/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/eu/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/fa/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/fi/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/fr/LC_MESSAGES/authconfig.mo                                     
/usr/share/locale/gl/LC_MESSAGES/authconfig.mo
/usr/share/locale/gu/LC_MESSAGES/authconfig.mo
/usr/share/locale/he/LC_MESSAGES/authconfig.mo
/usr/share/locale/hi/LC_MESSAGES/authconfig.mo
/usr/share/locale/hr/LC_MESSAGES/authconfig.mo
/usr/share/locale/hu/LC_MESSAGES/authconfig.mo
/usr/share/locale/hy/LC_MESSAGES/authconfig.mo
/usr/share/locale/id/LC_MESSAGES/authconfig.mo
/usr/share/locale/is/LC_MESSAGES/authconfig.mo
/usr/share/locale/it/LC_MESSAGES/authconfig.mo
/usr/share/locale/ja/LC_MESSAGES/authconfig.mo
/usr/share/locale/ka/LC_MESSAGES/authconfig.mo
/usr/share/locale/kn/LC_MESSAGES/authconfig.mo
/usr/share/locale/ko/LC_MESSAGES/authconfig.mo
/usr/share/locale/ku/LC_MESSAGES/authconfig.mo
/usr/share/locale/lo/LC_MESSAGES/authconfig.mo
/usr/share/locale/lv/LC_MESSAGES/authconfig.mo
/usr/share/locale/mai/LC_MESSAGES/authconfig.mo
/usr/share/locale/mk/LC_MESSAGES/authconfig.mo
/usr/share/locale/ml/LC_MESSAGES/authconfig.mo
/usr/share/locale/mr/LC_MESSAGES/authconfig.mo
/usr/share/locale/ms/LC_MESSAGES/authconfig.mo
/usr/share/locale/my/LC_MESSAGES/authconfig.mo
/usr/share/locale/nb/LC_MESSAGES/authconfig.mo
/usr/share/locale/nds/LC_MESSAGES/authconfig.mo
/usr/share/locale/nl/LC_MESSAGES/authconfig.mo
/usr/share/locale/nn/LC_MESSAGES/authconfig.mo
/usr/share/locale/or/LC_MESSAGES/authconfig.mo
/usr/share/locale/pa/LC_MESSAGES/authconfig.mo
/usr/share/locale/pl/LC_MESSAGES/authconfig.mo
/usr/share/locale/pt/LC_MESSAGES/authconfig.mo
/usr/share/locale/pt_BR/LC_MESSAGES/authconfig.mo
/usr/share/locale/ro/LC_MESSAGES/authconfig.mo
/usr/share/locale/ru/LC_MESSAGES/authconfig.mo
/usr/share/locale/si/LC_MESSAGES/authconfig.mo
/usr/share/locale/sk/LC_MESSAGES/authconfig.mo
/usr/share/locale/sl/LC_MESSAGES/authconfig.mo
/usr/share/locale/sq/LC_MESSAGES/authconfig.mo
/usr/share/locale/sr/LC_MESSAGES/authconfig.mo
/usr/share/locale/sr@latin/LC_MESSAGES/authconfig.mo
/usr/share/locale/sv/LC_MESSAGES/authconfig.mo
/usr/share/locale/ta/LC_MESSAGES/authconfig.mo
/usr/share/locale/te/LC_MESSAGES/authconfig.mo
/usr/share/locale/tg/LC_MESSAGES/authconfig.mo
/usr/share/locale/tr/LC_MESSAGES/authconfig.mo
/usr/share/locale/uk/LC_MESSAGES/authconfig.mo
/usr/share/locale/ur/LC_MESSAGES/authconfig.mo
/usr/share/locale/vi/LC_MESSAGES/authconfig.mo
/usr/share/locale/zh_CN/LC_MESSAGES/authconfig.mo
/usr/share/locale/zh_HK/LC_MESSAGES/authconfig.mo
/usr/share/locale/zh_TW/LC_MESSAGES/authconfig.mo
/usr/share/man/man5/fingerprint-auth-ac.5.gz
/usr/share/man/man5/password-auth-ac.5.gz
/usr/share/man/man5/postlogin-ac.5.gz
/usr/share/man/man5/smartcard-auth-ac.5.gz
/usr/share/man/man5/system-auth-ac.5.gz
/usr/share/man/man8/authconfig-tui.8.gz
/usr/share/man/man8/authconfig.8.gz
/usr/share/man/man8/cacertdir_rehash.8.gz
/var/lib/authconfig

Dokumentation

Bei der nachfolgenden Konfiguration der Authentifikationsmechanismen greifen wir vor allem auf den Befehl authconfig zurück. Ein Blick in dessen Man-Page sollte hier also von großer Hilfe sein.

 # man authconfig
AUTHCONFIG(8)                      System Manager's Manual                      AUTHCONFIG(8)

NAME
       authconfig,  authconfig-tui  -  an  interface  for  configuring  system authentication
       resources

SYNOPSIS
       authconfig
              [options]  {--update|--updateall|--test|--probe|--restorebackup  <name>|--save‐
              backup <name>|--restorelastbackup}

DESCRIPTION
       authconfig  provides  a  simple method of configuring /etc/sysconfig/network to handle
       NIS, as well as /etc/passwd and /etc/shadow, the files used for shadow  password  sup‐
       port.  Basic LDAP, Kerberos 5, and Winbind client configuration is also provided.

       If --test action is specified, the authconfig just reads the current settings from the
       various configuration files and prints their values.  If --update action is specified,
       authconfig  must be run by root (or through console helper), and configuration changes
       are saved. Only the files affected by the configuration changes are  overwritten.   If
       --updateall  action  is  specified, authconfig must be run by root (or through console
       helper), and all configuration files are written.  The --probe action instructs  auth‐
       config  to  use DNS and other means to guess at configuration information for the cur‐
       rent host, print its guesses if it finds them, to standard output, and exit.

       The --restorebackup, --savebackup, and --restorelastbackup actions provide a possibil‐
       ity  to  save and later restore a backup of configuration files which authconfig modi‐
       fies. Authconfig also saves an automatic backup of configuration  files  before  every
       configuration  change.  This special backup can be restored by the --restorelastbackup
       action.

       If --nostart is specified (which is what the install program does),  ypbind  or  other
       daemons  will  not  be started or stopped immediately following program execution, but
       only enabled to start or stop at boot time.

       The --enablenis, --enableldap, --enablewinbind, and --enablehesiod options are used to
       configure user information services in /etc/nsswitch.conf, the --enablecache option is
       used to configure naming services caching, and the  --enableshadow,  --enableldapauth,
       --enablekrb5,  and  --enablewinbindauth  options  are used to configure authentication
       functions via /etc/pam.d/system-auth.  Each --enable has a matching  --disable  option
       that  disables  the  service  if  it  is already enabled. The respective services have
       parameters which configure their server names etc.

       The algorithm used for storing new password hashes can be specified by the  --passalgo
       option  which  takes  one  of  the following possible values as a parameter: descrypt,
       bigcrypt, md5, sha256, and sha512.

       The --enablelocauthorize option allows to bypass checking network authentication  ser‐
       vices  for  authorization  and  the --enablesysnetauth allows authentication of system
       accounts (with uid < 500) by these services.

       When the configuration settings allow use of SSSD for user  information  services  and
       authentication, SSSD will be automatically used instead of the legacy services and the
       SSSD configuration will be set up so there is a default domain populated with the set‐
       tings  required to connect the services. The --enablesssd and --enablesssdauth options
       force adding SSSD to /etc/nsswitch.conf and /etc/pam.d/system-auth, but  they  do  not
       set  up  the  domain in the SSSD configuration files. The SSSD configuration has to be
       set up manually. The allowed configuration of services for SSSD  are:  LDAP  for  user
       information   (--enableldap)   and   either   LDAP   (--enableldapauth),  or  Kerberos
       (--enablekrb5) for authentication.

       In case SSSD does not support some feature of the legacy services  that  are  required
       for  the  site  configuration, the use of the legacy services can be forced by setting
       FORCELEGACY=yes in /etc/sysconfig/authconfig.

       The list of options mentioned here in the manual page is not exhaustive, please  refer
       to authconfig --help for the complete list of the options.

       The  authconfig-tui  supports all options of authconfig but it implies --update as the
       default action. Its window contains a Cancel button by default. If  --back  option  is
       specified  at  run  time, a Back button is presented instead. If --kickstart is speci‐
       fied, no interactive screens will be seen. The values the program  will  use  will  be
       those specified by the other options (--passalgo, --enableshadow, etc.).

       For  namelist  you  may  substitute  either a single name or a comma-separated list of
       names.

NOTES
       The authconfig-tui is deprecated. No new configuration settings will be  supported  by
       its  text user interface. Use system-config-authentication GUI application or the com‐
       mand line options instead.

       The /usr/bin/authconfig uses the consolehelper to  authenticate  as  the  system  user
       before  it starts up. If you want to run it directly without the authentication as the
       system user, run the /usr/sbin/authconfig command.

       The SSSD service is enabled and possibly started by authconfig when at  least  two  of
       the following three conditions are met:
       1) /etc/sssd/sssd.conf file exists (or is configured via the implicit SSSD support)
       2) SSSD authentication is enabled (pam_sss.so is used in PAM configuration)
       3) SSSD is enabled for user identity (nsswitch.conf contains sss)

       When  --update  action  is  used the enablement or disablement and possible restart of
       services happens only in case the changed configuration options affect the service  to
       be  restarted. This means that if for example the ypbind service is enabled with auth‐
       config --update --nostart --enablenis but not started and you  run  the  same  command
       without the --nostart later the ypbind service will not be started because no configu‐
       ration change affecting ypbind happened.

RETURN CODES
       authconfig returns 0 on success, 1 on backup operation errors, 2 if not  running  with
       sufficient  privileges, 3 if unknown password hash algorithm is specified or incorrect
       values are set for password strength checking (this error is non fatal), 4 if download
       of CA certificate fails, 5 if writing configuration files fails on --updateall action,
       6 if writing fails on --update action, 7 if Winbind or IPA domain join fails.

       authconfig-tui returns 0 on success, 2 on error, and 1 if the user cancelled the  pro‐
       gram (by using either the Cancel or Back button). It can also return the same codes as
       authconfig.

FILES
       /etc/sysconfig/authconfig
              Used to track whether or not particular  authentication  mechanisms  are
              enabled.   Currently includes variables named USESHADOW, USEMD5, USEKER‐
              BEROS, USELDAPAUTH, USESMBAUTH, USEWINBIND,  USEWINBINDAUTH,  USEHESIOD,
              USENIS, USELDAP, and others.
       /etc/passwd
       /etc/shadow
              Used for shadow password support.
       /etc/yp.conf
              Configuration file for NIS support.
       /etc/sysconfig/network
              Another configuration file for NIS support.
       /etc/ldap.conf
       /etc/nss_ldap.conf
       /etc/pam_ldap.conf
       /etc/nslcd.conf
       /etc/openldap/ldap.conf
              Used  to  configure nss_ldap, pam_ldap, nslcd, and the OpenLDAP library.
              Only the files already existing on the system are modified.
       /etc/krb5.conf
              Used to configure Kerberos 5.
       /etc/hesiod.conf
              Used to configure Hesiod.
       /etc/samba/smb.conf
              Used to configure winbind authentication.
       /etc/nsswitch.conf
              Used to configure user information services.
       /etc/login.defs
              Used to configure parameters of user accounts (minimum UID of a  regular
              user, password hashing algorithm).
       /etc/pam.d/system-auth
              Common  PAM configuration for system services which include it using the
              include directive. It is created as  symlink  and  not  relinked  if  it
              points to another file.
       /etc/pam.d/system-auth-ac
              Contains  the  actual  PAM  configuration for system services and is the
              default target of the /etc/pam.d/system-auth symlink. If a local config‐
              uration  of  PAM  is  created (and symlinked from system-auth file) this
              file can be included there.

SEE ALSO
       authconfig-gtk(8), system-auth-ac(5), passwd(5), shadow(5), pwconv(1),  domain‐
       name(1), ypbind(8), nsswitch.conf(5), smb.conf(5), sssd(8)

AUTHORS
       Nalin Dahyabhai <nalin@redhat.com>, Preston Brown <pbrown@redhat.com>,
       Matt Wilson <msw@redhat.com>, Tomas Mraz <tmraz@redhat.com>

Red Hat, Inc.                            22 July 2011                           AUTHCONFIG(8)

Mindestens genau so interessant, vor allem wegen der vielen möglichen Optionen(!), ist die Hilfefunktion des Befehls authconfig, die wir wie folgt erreichen.

 # authconfig --help
Usage: Aufruf: authconfig [Optionen] {--update|--updateall|--test|--probe|--restorebackup <name>|--savebackup <name>|--restorelastbackup}

Options:
    -h, --help              Diesen Hilfetext anzeigen und beenden
  --enableshadow, --useshadow
                        Shadow-Passwörter standardmäßig aktivieren
    --disableshadow         Shadow-Passwörter standardmäßig deaktivieren
  --enablemd5, --usemd5
                        MD5-Passwörter standardmäßig aktivieren
    --disablemd5            MD5-Passwörter standardmäßig deaktivieren
  --passalgo=<descrypt|bigcrypt|md5|sha256|sha512>
                        hash/crypt-Algorithmus für neue Passwörter
    --enablenis             NIS für Benutzerinformationen standardmäßig aktivieren
    --disablenis            NIS für Benutzerinformationen standardmäßig deaktivieren
    --nisdomain=<Domain>    Standard-NIS-Domain
    --nisserver=<Server>    Standard-NIS-Server
    --enableldap            LDAP für Benutzerinformationen standardmäßig aktivieren
    --disableldap           LDAP für Benutzerinformationen standardmäßig deaktivieren
    --enableldapauth        LDAP zur Authentifizierung standardmäßig aktivieren
    --disableldapauth       LDAP zur Authentifizierung standardmäßig deaktivieren
  --ldapserver=<Server>
                        Standard LDAP-Server-Hostnamen oder URI
    --ldapbasedn=<dn>       Standard LDAP Basis-DN
  --enableldaptls, --enableldapstarttls
                        Verwendung von TLS mit LDAP (RFC-2830) aktivieren
  --disableldaptls, --disableldapstarttls
                        Verwendung von TLS mit LDAP (RFC-2830) deaktivieren
    --enablerfc2307bis      Verwendung des RFC-2307bis-Schemas für Suchen nach Benutzerinformation via LDAP aktivieren
    --disablerfc2307bis     Verwendung des RFC-2307bis-Schemas für Suchen nach Benutzerinformation via LDAP deaktivieren
  --ldaploadcacert=<URL>
                        CA-Zertifikat von URL laden
    --enablesmartcard       Smartcard-Authentifizierung standardmäßig aktivieren
    --disablesmartcard      Smartcard-Authentifizierung standardmäßig deaktivieren
  --enablerequiresmartcard
                        Smartcard-Authentifizierung standardmäßig voraussetzen
  --disablerequiresmartcard
                        Smartcard-Authentifizierung nicht standardmäßig voraussetzen
  --smartcardmodule=<Modul>
                        Standardmäßig zu verwendendes Smartcard-Modul
  --smartcardaction=<0=Sperren|1=Ignorieren>
                        Beim Entfernen einer Smartcard folgende Aktion ausführen
    --enablefingerprint     Fingerabdruck-Authentifizierung mit Fingerabdruck-Leser standardmäßig aktivieren
    --disablefingerprint    Fingerabdruck-Authentifizierung mit Fingerabdruck-Leser standardmäßig deaktivieren
    --enableecryptfs        Automatisches ecryptfs für Benutzer aktivieren
    --disableecryptfs       Automatisches ecryptfs für Benutzer deaktivieren
    --enablekrb5            Kerberos-Authentifizierung standardmäßig aktivieren
    --disablekrb5           Kerberos-Authentifizierung standardmäßig deaktivieren
    --krb5kdc=<Server>      Standard-Kerberos-KDC
  --krb5adminserver=<Server>
                        Standard-Kerberos-Admin-Server
  --krb5realm=<Bereich>
                        Standard-Kerberos-Bereich
    --enablekrb5kdcdns      Verwendung von DNS für Ermittlung von Kerberos-KDCs aktivieren
    --disablekrb5kdcdns     Verwendung von DNS für Ermittlung von Kerberos-KDCs deaktivieren
    --enablekrb5realmdns    Verwendung von DNS für die Ermittlung von Kerberos-Bereichen aktivieren
  --disablekrb5realmdns
                        Verwendung von DNS für die Ermittlung von Kerberos-Bereichen deaktivieren
    --enablewinbind         Winbind für die Benutzerinformationen standardmäßig aktivieren
    --disablewinbind        Winbind für die Benutzerinformationen standardmäßig deaktivieren
    --enablewinbindauth     Winbind für die Authentifizierung standardmäßig aktivieren
    --disablewinbindauth    Winbind für die Authentifizierung standardmäßig deaktivieren
  --smbsecurity=<user|server|domain|ads>
                        Von Samba und Winbind zu verwendender Sicherheitsmodus
    --smbrealm=<Bereich>    Standard-Bereich für Samba und Winbind, wenn security=ads
  --smbservers=<Server>
                        Namen der Server, gegen die authentifiziert wird
  --smbworkgroup=<Arbeitsgruppe>
                        Arbeitsgruppen-Authentifizierungsserver sind in
  --smbidmaprange=<niedrigste-höchste>, --smbidmapuid=<niedrigste-höchste>, --smbidmapgid=<niedrigste-höchste>
                        uid-Bereich, den Winbind Domain- oder ADS-Benutzern zuteilen wird
  --winbindseparator=<\>
                        Das Zeichen, das zur Trennung von Domain und Benutzer in von Winbind erzeugten Benutzernamen verwendet wird, sofern winbindusedefaultdomain nicht aktiviert ist
  --winbindtemplatehomedir=</home/%D/%U>
                        Der Ordner, den von Winbind erzeugte Benutzer als persönlichen Ordner haben
  --winbindtemplateprimarygroup=<nobody>
                        Die Gruppe, die von Winbind erzeugte Benutzer als primäre Gruppe haben
  --winbindtemplateshell=</bin/false>
                        Die Shell, die von Winbind erzeugte Benutzer als Login-Shell haben
  --enablewinbindusedefaultdomain
                        Winbind soll annehmen, dass Benutzer ohne Domain im Benutzernamen Domain-Benutzer sind
  --disablewinbindusedefaultdomain
                        Winbind soll annehmen, dass Benutzer, ohne Domain im Benutzernamen keine Domain-Benutzer sind
  --enablewinbindoffline
                        Konfiguriert Winbind, um Offline-Anmeldung zu ermöglichen
  --disablewinbindoffline
                        Konfiguriert Winbind, um Offline-Anmeldung zu verhindern
    --enablewinbindkrb5     winbind wird Kerberos 5 zur Legitimation verwenden
    --disablewinbindkrb5    winbind wird die Standard Legitimations-Methode verwenden
  --winbindjoin=<Administrator>
                        Jetzt der Winbind-Domäne oder dem ADS-Bereich mit diesem Administrator beitreten
    --enableipav2           Aktiviere IPAv2 für Benutzerinformationen und Authentifizierung standardmässig
    --disableipav2          Deaktiviere IPAv2 für Benutzerinformationen und Authentifizierung standardmässig
  --ipav2domain=<Domain>
                        Die IPAv2 Domäne, bei der das System enthalten sein soll
  --ipav2realm=<Bereich>
                        Der Bereich für die IPAv2-Domäne
  --ipav2server=<Server>
                        Server der IPAv2 Domäne
    --enableipav2nontp      NTP für die IPAv2-Domain nicht einrichten
    --disableipav2nontp     NTP für die IPAv2-Domain einrichten (Standard)
  --ipav2join=<account>
                        Mit diesem Konto der IPAv2-Domäne beitreten
    --enablewins            WINS zur Auflösung von Hostnamen aktivieren
    --disablewins           WINS zur Auflösung von Hostnamen deaktivieren
    --enablepreferdns       DNS über WINS oder NIS zur Hostnamen-Auflösung bevorzugen
    --disablepreferdns      DNS über WINS oder NIS zur Hostnamen-Auflösung nicht bevorzugen
    --enablehesiod          Hesiod für die Benutzerinformationen standardmäßig aktivieren
    --disablehesiod         Hesiod für die Benutzerinformationen standardmäßig deaktivieren
    --hesiodlhs=<lhs>       Standard-Hesiod-LHS
    --hesiodrhs=<rhs>       Standard-Hesiod-RHS
    --enablesssd            SSSD für Benutzerinformationen als Vorgabe mit manuell verwalteter Konfiguration aktivieren
    --disablesssd           SSSD für Benutzerinformationen als Vorgabe deaktivieren (wird noch für unterstützte Konfigurationen verwendet)
    --enablesssdauth        SSSD für Authentifizierung als Vorgabe mit manuell verwalteter Konfiguration aktivieren
    --disablesssdauth       SSSD für Authentifizierung als Vorgabe deaktivieren (wird noch für unterstützte Konfigurationen verwendet)
    --enableforcelegacy     SSSD ausdrücklich nie verwenden, auch nicht für unterstützte Konfigurationen
    --disableforcelegacy    SSSD unbedingt nur benutzen, wenn es die Konfiguration unterstützt
    --enablecachecreds      Zwischenspeicherung von Benutzerinformation in SSSD standardmäßig aktivieren
    --disablecachecreds     Zwischenspeicherung von Benutzerinformation in SSSD standardmäßig deaktivieren
    --enablecache           Zwischenspeicherung von Benutzerinformation standardmäßig aktivieren (bei der Verwendung von SSSD automatisch deaktiviert)
    --disablecache          Zwischenspeicherung von Benutzerinformation standardmäßig deaktivieren
    --enablelocauthorize    Lokale Autorisierung ist ausreichend für lokale Benutzer
  --disablelocauthorize
                        Lokale Benutzer auch über Fernzugriff autorisieren
    --enablepamaccess       access.conf während der Autorisierung des Benutzerkontos überprüfen
    --disablepamaccess      access.conf während der Autorisierung des Benutzerkontos nicht überprüfen
    --enablesysnetauth      Systembenutzer über Netzwerkdienste authentifizieren
    --disablesysnetauth     Systembenutzer nur über lokale Dateien authentifizieren
    --enablemkhomedir       Persönliche Benutzerordner bei der ersten Anmeldung erzeugen
    --disablemkhomedir      Keine persönlichen Benutzerordner bei der ersten Anmeldung erzeugen
  --passminlen=<Nummer>
                        Minimale Passwortlänge
  --passminclass=<Nummer>
                        Mindestanzahl von Charakter-Klassen in einem Kennwort
  --passmaxrepeat=<Nummer>
                        Maximalanzahl gleicher Zeichen in einem Passwort
  --passmaxclassrepeat=<Nummer>
                        Maximale Anzahl von aufeinanderfolgenden Zeichen derselben Klasse in einem Kennwort
    --enablereqlower        Erzwinge mindestens einen Kleinbuchstaben im Passwort
    --disablereqlower       Benötie keine Kleinbuchstaben im Passwort
    --enablerequpper        Erzwinge mindestens einen Grossbuchstaben im Passwort
    --disablerequpper       Keine Grossbuchstaben in einem Kennwort verlangen
    --enablereqdigit        Erzwinge mindestens eine Zahl im Passwort
    --disablereqdigit       Benötige keine Zahlen im Passwort
    --enablereqother        Mindestens ein anderes Zeichen in einem Passwort verlangen
    --disablereqother       Keine anderen Zeichen in einem Kennwort verlangen
    --nostart               portmap, ypbind und nscd nicht starten/anhalten
    --test                  Konfigurationsdateien nicht aktualisieren, stattdessen nur die neuen Einstellungen ausgeben
  --update, --kickstart
                        Im Gegensatz zu --test die Konfigurationsdateien mit geänderten Einstellungen aktualisieren
    --updateall             Alle Konfigurationsdateien aktualisieren
    --probe                 Im Netzwerk nach Standards suchen und diese ausgeben
    --savebackup=<Name>     Eine Sicherung aller Konfigurationsdateien speichern
  --restorebackup=<Name>
                        Eine Sicherung der Konfigurationsdateien wiederherstellen
    --restorelastbackup     Die vor der letzten Konfigurationsänderung gesicherten Konfigurationsdateien wiederherstellen

Konfiguration

authconfig

Die Konfiguration unseres Clients nehmen wir am einfachsten mit Hilfe des Programmes authconfig aus dem RPM-Paket authconfig vor. Hierzu rufen wir authconfig mit den nötigen Optionen für unsere (Test-)Umgebung auf. Eine ausführliche Beschreibung der Optionen erhält man, wie schon erwähnt, über die Manpage von authconfig oder beim Aufruf der Option –help.

  • disablesssd SSSD für Benutzerinformationen als Vorgabe deaktivieren
  • disablesssdauth SSD für Authentifizierung als Vorgabe deaktivieren
  • disablemd5 MD5 Passworter abschalten
  • passalgo Definition des Passworthash-Algoritmuses
  • enablemkhomedir Homedirectory beim ersten Login eines neuen Users automatisch anlegen
  • enableldap LDAP User Informationen aktivieren
  • enableldapauth LDAP Authentifizierung aktivieren
  • ldapserver LDAP Servername oder URI Definition
  • ldapbasedn LDAP Basde DN Definition
  • enableldaptls Verwendung von TLS mit LDAP (RFC-2830) über Port 636 verwenden
  • enableldapstarttls Verwendung von StartTLS mit LDAP über Port 389 verwenden
  • update Update der Konfigurationsdateien mit den gesetzten Werten.

Wir Konfigurieren nun also unsere LDAP-Client-Authentifizierung wie folgt.

 # authconfig --disablesssd \
              --disablesssdauth \
              --disablemd5 \
              --passalgo=sha256 \
              --enablemkhomedir \
              --enableldap \
              --enableldapauth \
              --ldapserver="ldap://openldap.dmz.nausch.org" \
              --ldapbasedn="dc=nausch,dc=org" \
              --enableldaptls \
              --enableldapstarttls \
              --update

Die einzelnen Konfigurationsdateien, die mit dem vorgenannten Programmaufruf angepasst wurden, werden wir uns im Detail betrachten, ggf. anpassen und mit Bearbeitungsvermerken versehen, damit wir später noch nachvollziehen können, welche Änderungen im Detail notwendig waren, damit die LDAPs Client Authentifizierung aktiviert werden konnte.

Zur Dokumentation und ggf. spätere weitere Dokumentationsschritte versehen wir am Besten optional alle Änderungen mit einem Kommentar, ala: # Django : Datum (YYY-MM-DD) [optionaler Grund].

nslcd.conf

Die erste Datei, die wir uns nun genauer ansehen, ist die Konfigurationsdatei /etc/nslcd.conf.

 # vim /etc/nslcd.conf
/etc/nslcd.conf
# This is the configuration file for the LDAP nameservice
# switch library's nslcd daemon. It configures the mapping
# between NSS names (see /etc/nsswitch.conf) and LDAP     
# information in the directory.                           
# See the manual page nslcd.conf(5) for more information. 
 
# The user and group nslcd should run as.
uid nslcd                                
gid ldap                                 
 
# The uri pointing to the LDAP server to use for name lookups.
# Multiple entries may be specified. The address that is used 
# here should be resolvable without using LDAP (obviously).   
#uri ldap://127.0.0.1/                                        
#uri ldaps://127.0.0.1/                                       
#uri ldapi://%2fvar%2frun%2fldapi_sock/                       
# Note: %2f encodes the '/' used as directory separator       
# Django : 2015-07-20                                         
# default: uri ldap://127.0.0.1/                              
uri ldap://openldap.dmz.nausch.org                            
 
# The LDAP version to use (defaults to 3
# if supported by client library)       
#ldap_version 3                         
 
# The distinguished name of the search base.
# Django : 2015-07-20                       
# default: base dc=example,dc=com           
base dc=nausch,dc=org                       
 
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.         
#binddn cn=proxyuser,dc=example,dc=com              
# Django : 2015-07-20                               
# default: unset                                    
binddn cn=Technischeruser,dc=nausch,dc=org         
 
# The credentials to bind with.
# Optional: default is no credentials.
# Note that if you set a bindpw you should check the permissions of this file.
#bindpw secret                                                                
# Django : 2015-07-20                                                         
# default: unset                                                              
bindpw YpKKoS1lV1AdAX1StGe1lTembvZW4XagnkLdWZ2Y4Xkw                                       
 
# The distinguished name to perform password modifications by root by.
#rootpwmoddn cn=admin,dc=example,dc=com                               
 
# The default search scope.
#scope sub                 
#scope one                 
#scope base                
 
# Customize certain database lookups.
#base   group  ou=Groups,dc=example,dc=com
#base   passwd ou=People,dc=example,dc=com
#base   shadow ou=People,dc=example,dc=com
#scope  group  onelevel                   
#scope  hosts  sub                        
 
# Bind/connect timelimit.
#bind_timelimit 30       
 
# Search timelimit.
#timelimit 30      
 
# Idle timelimit. nslcd will close connections if the
# server has not been contacted for the number of seconds.
#idle_timelimit 3600                                      
 
# Use StartTLS with verifying the server certificate.
# Django : 2015-07-20
ssl start_tls
tls_cacertfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 
# Use StartTLS without verifying the server certificate.
#ssl start_tls                                           
#tls_reqcert never                                      
 
# CA certificates for server certificate verification
#tls_cacertdir /etc/ssl/certs                        
#tls_cacertfile /etc/ssl/ca.cert                     
 
# Seed the PRNG if /dev/urandom is not provided
#tls_randfile /var/run/egd-pool                
 
# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1          
 
# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert                                                  
#tls_key                                                   
 
# Mappings for Services for UNIX 3.5
#filter passwd (objectClass=User)   
#map    passwd uid              msSFU30Name
#map    passwd userPassword     msSFU30Password
#map    passwd homeDirectory    msSFU30HomeDirectory
#map    passwd homeDirectory    msSFUHomeDirectory
#filter shadow (objectClass=User)
#map    shadow uid              msSFU30Name
#map    shadow userPassword     msSFU30Password
#filter group  (objectClass=Group)
#map    group  member           msSFU30PosixMember
 
# Mappings for Services for UNIX 2.0
#filter passwd (objectClass=User)
#map    passwd uid              msSFUName
#map    passwd userPassword     msSFUPassword
#map    passwd homeDirectory    msSFUHomeDirectory
#map    passwd gecos            msSFUName
#filter shadow (objectClass=User)
#map    shadow uid              msSFUName
#map    shadow userPassword     msSFUPassword
#map    shadow shadowLastChange pwdLastSet
#filter group  (objectClass=Group)
#map    group  member           posixMember
 
# Mappings for Active Directory
#pagesize 1000
#referrals off
#idle_timelimit 800
#filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
#map    passwd uid              sAMAccountName
#map    passwd homeDirectory    unixHomeDirectory
#map    passwd gecos            displayName
#filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
#map    shadow uid              sAMAccountName
#map    shadow shadowLastChange pwdLastSet
#filter group  (objectClass=group)
 
# Alternative mappings for Active Directory
# (replace the SIDs in the objectSid mappings with the value for your domain)
#pagesize 1000
#referrals off
#idle_timelimit 800
#filter passwd (&(objectClass=user)(objectClass=person)(!(objectClass=computer)))
#map    passwd uid           cn
#map    passwd uidNumber     objectSid:S-1-5-21-3623811015-3361044348-30300820
#map    passwd gidNumber     objectSid:S-1-5-21-3623811015-3361044348-30300820
#map    passwd homeDirectory "/home/$cn"
#map    passwd gecos         displayName
#map    passwd loginShell    "/bin/bash"
#filter group (|(objectClass=group)(objectClass=person))
#map    group gidNumber      objectSid:S-1-5-21-3623811015-3361044348-30300820
 
# Mappings for AIX SecureWay
#filter passwd (objectClass=aixAccount)
#map    passwd uid              userName
#map    passwd userPassword     passwordChar
#map    passwd uidNumber        uid
#map    passwd gidNumber        gid
#filter group  (objectClass=aixAccessGroup)
#map    group  cn               groupName
#map    group  gidNumber        gid
# This comment prevents repeated auto-migration of settings.

Anschließend passen wir noch die Dateiberechtigungen an, so wie es bei der Option bindpw angeraten wurde.

 # chown nslcd:ldap /etc/nslcd.conf

nsswitch.conf

In der Konfigurationsdatei /etc/nsswitch.conf ergänzen wir nun händisch die Optionen ldap. Änderungen wurden in dem Beispiel wie iimmer entsprechend gekennzeichnet:

  • passwd: files ldap sss
  • shadow: files ldap sss
  • group: files ldap sss
  • netgroup: files ldap sss
  • automount: files ldap sss
 # vim /etc/nsswitch.conf
/etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#       nisplus                 Use NIS+ (NIS version 3)
#       nis                     Use NIS (NIS version 2), also called YP
#       dns                     Use DNS (Domain Name Service)
#       files                   Use the local files
#       db                      Use the local database (.db) files
#       compat                  Use NIS on compat mode
#       hesiod                  Use Hesiod for user lookups
#       [NOTFOUND=return]       Stop searching if not found so far
#
 
# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis
 
# Django : 2015-07-21 LDAP Client Authentication
# default: passwd:     files sss
#          shadow:     files sss
#          group:      files sss
passwd:     files ldap sss
shadow:     files ldap sss
group:      files ldap sss
#initgroups: files
 
#hosts:     db files nisplus nis dns
hosts:      files dns
 
# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files
 
bootparams: nisplus [NOTFOUND=return] files
 
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
 
# Django : 2015-07-21 LDAP Client Authentication
# default: netgroup:   files sss
netgroup:   files ldap sss
 
publickey:  nisplus
 
# Django : 2015-07-21 LDAP Client Authentication
# default: automount:  files sss
automount:  files ldap sss
aliases:    files nisplus

password-auth-ac

Damit sich unsere Nutzer auch anmelden können, ist es notwendig in der Konfigurationsdatei /etc/pam.d/password-auth-ac die option pam_sss.so durch ein pam_ldap.so zu ersetzen.

 # vim /etc/pam.d/password-auth-ac
/etc/pam.d/password-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
# Django : 2015-07-21
# default: auth        sufficient    pam_sss.so use_first_pass
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so
 
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
# Django : 2015-07-21
# default: account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so
 
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha256 nullok try_first_pass use_authtok
# Django : 2015-07-21
# default: password    sufficient    pam_sss.so use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so
 
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
# Django : 2015-07-21
# default: session     optional      pam_sss.so
session     optional      pam_ldap.so

Start des Naming services LDAP client daemon

Nun ist es an der Zeit, den NSLCD2) zu starten.

 # systemctl restart nslcd.service

Den erfolgreichen Start des Daemon fragen wir wie folgt ab.

 # systemctl status nslcd.service -l

nslcd.service - Naming services LDAP client daemon.
   Loaded: loaded (/usr/lib/systemd/system/nslcd.service; disabled)
   Active: active (running) since Mo 2015-07-20 17:06:44 CEST; 34s ago
  Process: 8771 ExecStart=/usr/sbin/nslcd (code=exited, status=0/SUCCESS)
 Main PID: 8774 (nslcd)
   CGroup: /system.slice/nslcd.service
           └─8774 /usr/sbin/nslcd

Jul 20 17:06:44 vml010052.intra.nausch.org systemd[1]: Starting Naming services LDAP client daemon....
Jul 20 17:06:44 vml010052.intra.nausch.org systemd[1]: PID file /var/run/nslcd/nslcd.pid not readable (yet?) after start.
Jul 20 17:06:44 vml010052.intra.nausch.org nslcd[8774]: version 0.8.13 starting
Jul 20 17:06:44 vml010052.intra.nausch.org systemd[1]: Started Naming services LDAP client daemon..
Jul 20 17:06:44 vml010052.intra.nausch.org nslcd[8774]: accepting connections

Damit der Daemin automatisch gestartet wird, wenn der Clientrechner hochfährt, aktivieren wir den NSLCD entsprechend.

# systemctl enable nslcd.service
ln -s '/usr/lib/systemd/system/nslcd.service' '/etc/systemd/system/multi-user.target.wants/nslcd.service'

Wollen wir abfragen, ob der Daemon automatisch beim Systemstart gestartet wird benutzen wir nachfolgenden Befehl/Aufruf.

# systemctl is-enabled nslcd.service
enabled

Ein enabled signalisiert, dass der Daemon einen Autostart macht, ein disabled steht dafür, dass der Daemon nichtautomatisch beim Starten des Rechners hochfährt.

LDAP Abfrage

Zur Abfrage eines LDAP-Users können wir folgenden Aufruf verwenden:

$ ldapsearch -x -LLL -H ldaps://openldap.dmz.nausch.org -b "dc=nausch,dc=org" "uid=django" -W -D "cn=Technischeruser,dc=nausch,dc=org"
Enter LDAP Password: 
dn: uid=django,ou=People,dc=nausch,dc=org
uid: django
cn: django
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 16617
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/django
gecos: django
userPassword:: RGQ0bWRkMyE=

Das nächste Beispiel zeigt eine LDAP-Abfrage mit dem User django aber mit falschem Passwort:

 $ ldapsearch -x -LLL -H ldaps://openldap.dmz.nausch.org -b "dc=nausch,dc=org" "uid=inge" -W -D "uid=inge,ou=People,dc=nausch,dc=org"
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

Hingegen eine Abfrage mit einer richtigen Kombination von Benutzer und Passwort, sieht entsprechend wie folgt aus:

 $ ldapsearch -x -LLL -H ldaps://openldap.dmz.nausch.org -b "dc=nausch,dc=org" "uid=inge" -W -D "uid=inge,ou=People,dc=nausch,dc=org"
Enter LDAP Password:
dn: uid=inge,ou=People,dc=nausch,dc=org
uid: inge
cn: inge
objectClass: account
objectClass: posixAccount
objectClass: top
loginShell: /bin/bash
uidNumber: 1002
gidNumber: 1002
homeDirectory: /home/inge
gecos: inge
userPassword:: e0NSWVBasdfaUJ1fM3101d3XJ1J19UR21TUjhpMWc=

Client-Abfragen

Die erfolgreiche Konfiguration unseres Rechners überprüfen wir so:

  1. Mit getent lassen wir uns die Informationen eines Users anzeigen, der sowohl in der /etc/shadow wie auch im zentralen LDAP-Verzeichnisdienst hinterlegt ist. Wenn alles gut gelaufen ist, werden uns zwei Einträge präsentiert.

    $ getent passwd | grep django
    django:$6$RG6zR$2RbzR$wDvit.DnWHSYGEFCrn0LXyEleQkOuJQ5mQLiVRHNEnm5svSCrn0LXyEleQkOuflVHvMkKnAEdQCCVU9Gc9nPe1:1000:1000:Django [BOfH]:/home/django:/bin/bash
    django:x:1000:1000:django:/home/django:/bin/bash
  2. Als nächstes wählen wir einen Nutzer der nur im LDAP-Verzeichnisdienst einen Account hat, nicht aber auf der lokalen Maschine.

    $ getent passwd | grep michael
    michael:*:1001:1001:michael:/home/michael:/bin/bash
  3. Dann melden wir uns nun an unserem Client als ein Benutzer an, der lokal auf der Maschine nicht existiert, werden wir beim Login nach dem Passwort gefragt, welches gegen den zentralen OpenLDAP-Server verifiziert wird. Ist das Passwort richtig wird auch gleich das zugehörige Nutzer-Homeverzeichnis angelegt.

    [django@vml010008 ~]$ ssh -l ruben 10.0.10.52
    Password:
    Creating home directory for ruben.

Bildschirmhardcopy bei der Anmeldung am Client (mit LDAP auth)

Nachdem sich unsere Nutzer an ihren Arbeitsplatzrechner erfolgreich anmelden können, wollen sie mit unter auch von unterwegs aus auf Ihre eMail oder andere WEB-Dienste zugreifen. Auch dort sollen sich unsere User mit deren Anmeldedaten anmelden können.

Im folgenden gehen wir auf Konfigurationslösungen bei den beiden Webservern Apache und NGiNX im Detail eingehen.

Apache Webserver

In der Regel haben wir zur Verwaltung der Nutzerdaten ein Backendsystem zur Verwaltung im Einsatz. Im folgendem Konfigurationsbeispiel werden wir uns nun gegen einen vorhandenen LDAP-Server authentifizieren.

Damit sich unser Client mit dem OpenLDAP-Server verbinden kann, sind ein paar Vorkehrungen zu treffen.

Installation

openldap-clients

Als erstes installieren wir uns das RPM-Paket openldap-clients, wie soll es anders sein, verwenden wir hierzu das Programmverwaltungs-Tool YUM unter CentOS 7.x.

 # yum install openldap-clients -y

Das was uns das Paket alles mitbrachte, können wir uns wie folgt ausgeben lassen.

 # rpm -qil openldap-clients
Name        : openldap-clients
Version     : 2.4.39
Release     : 6.el7
Architecture: x86_64
Install Date: Fri 17 Jul 2015 07:29:06 PM CEST
Group       : Applications/Internet
Size        : 588433
License     : OpenLDAP
Signature   : RSA/SHA256, Sat 14 Mar 2015 09:22:43 AM CET, Key ID 24c6a8a7f4a80eb5
Source RPM  : openldap-2.4.39-6.el7.src.rpm
Build Date  : Fri 06 Mar 2015 05:36:42 AM CET
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.openldap.org/
Summary     : LDAP client utilities
Description :
OpenLDAP is an open-source suite of LDAP (Lightweight Directory Access
Protocol) applications and development tools. LDAP is a set of
protocols for accessing directory services (usually phone book style
information, but other information is possible) over the Internet,
similar to the way DNS (Domain Name System) information is propagated
over the Internet. The openldap-clients package contains the client
programs needed for accessing and modifying OpenLDAP directories.
/usr/bin/ldapadd
/usr/bin/ldapcompare
/usr/bin/ldapdelete
/usr/bin/ldapexop
/usr/bin/ldapmodify
/usr/bin/ldapmodrdn
/usr/bin/ldappasswd
/usr/bin/ldapsearch
/usr/bin/ldapurl
/usr/bin/ldapwhoami
/usr/share/man/man1/ldapadd.1.gz
/usr/share/man/man1/ldapcompare.1.gz
/usr/share/man/man1/ldapdelete.1.gz
/usr/share/man/man1/ldapexop.1.gz
/usr/share/man/man1/ldapmodify.1.gz
/usr/share/man/man1/ldapmodrdn.1.gz
/usr/share/man/man1/ldappasswd.1.gz
/usr/share/man/man1/ldapsearch.1.gz
/usr/share/man/man1/ldapurl.1.gz
/usr/share/man/man1/ldapwhoami.1.gz

Konfiguration

openldap-clients

Versuchen wir uns jetzt schon mit unserem LDAP-Server zu verbinden, schlägt dies unweigerlich fehl. Beispiel:

 # ldapsearch -W -x -b "dc=nausch,dc=org" "uid=django" \
              -D "cn=Technischeruser,dc=nausch,dc=org" -LLL \
              -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password: 
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Die Verbindung schlägt fehl, da der Client dem Zertifikat des OpenLDAP-Servers (noch) nicht vertraut!

Wir müssen als erst noch die zum Serverzertifikat passenden Root-Zertifikate der CA3) CAcert als vertrauenswürdige Root-Zertifikate importieren.

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

Wir haben nun in der Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem die nötigen Root-Zertifikate und müssen nun nur noch unserem openldap-client mitteilen, diesen auch zu nutzen. Hierzu editieren wir nun die Konfigurationsdatei des openldap-clients.

 # vim /etc/openldap/ldap.conf
/etc/openldap/ldap.conf
#
# LDAP Defaults
#
 
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
 
#BASE           dc=example,dc=com
#URI            ldap://ldap.example.com ldap://ldap-master.example.com:666
 
# Django: 2015-07-17
# defaul: unset
#         Definition des standardmässig abgefragten Teilbaums / Searchbase
#         Anfragen werden unterhalb von dc=nausch, dc=org ausgeführt
BASE            dc=nausch, dc=org
 
#         Definition des LDAP-Servers 
URI             ldap://openldap.dmz.nausch.org
 
 
#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never
 
# Django : 2015-07-17
# default:      TLS_CACERTDIR   /etc/openldap/certs
 
# Django : 2015-07-16
#          Pfad und Datei mit den vertrauenswürdigen Root-Zertifikaten
# default: unset
TLS_CACERT      /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
 
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON    on

Zum Testen richten wir erneut eine Anfrage an unseren OpenLDP-Server.

 # ldapsearch -W -x -b "dc=nausch,dc=org" "uid=django" \
              -D "cn=Technischeruser,dc=nausch,dc=org" -LLL \
              -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password: 
dn: uid=django,ou=People,dc=nausch,dc=org
uid: django
cn: django
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 16617
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/django
gecos: django
userPassword:: RGQ0bWRkMyE=
mod_ldap

Im Gegensatz zum Konfigurationsbeispiel der Basic Authentifikation mit Hilfe von PasswordBasicAuth, benötigen wir das zusätzliche RPM-Paket mod_ldap, welches die beiden notwendigen Module mod_authnz_ldap und mod_ldap zur LDAP-Authentifikation benötigt werden. Das RPM installieren wir uns nun mit Hilfe von yum.

 # yum install mod_ldap -y
Konfiguration

Was nun noch fehlt, ist die Konfiguration unseres vHOSTs. In der Konfigurationsdatei des betreffenden vHOSTs tragen wir nun folgende Zeilen nach.

 # vim /etc/httpd/conf.d/vhost_443_postfixadmin.conf
...
 
	# Django : 2015-07-17 Konfigurationsbeispiel zur LDAP Authenifikation mit Hilfe
	# der beiden Module mod_authnz_ldap und mod_ldap aus dem RPM mod_ldap.
        <Location />
                Options +FollowSymLinks +Multiviews +Indexes
                AllowOverride None
                AuthType Basic
                AuthName "PostfixAdmin-Webserver"
                AuthBasicProvider ldap
                AuthLDAPUrl ldaps://openldap.dmz.nausch.org:389/ou=People,dc=nausch,dc=org?uid
                AuthLDAPBindDN cn=Technischeruser,dc=nausch,dc=org
                AuthLDAPBindPassword e1n531f!D4xIi57n393I1354u!
                AuthLDAPBindAuthoritative on
                Require ldap-user django bigchief nagios
        </Location>
...

Damit unsere Änderungen aktiv werden bedarf es noch eines reloads unseres HTTP-Deamon.

 # systemctl reload httpd.service

WICHTIG:
Damit die Anmeldedaten nicht von Dritten mitgelesen und abgefischt werden können, nutzen wir natürlich einen SSL-geschützten vHOST!

Test

Der Webserver wird nun den Zugang erst gestatten, sobald die Daten richtig eingegeben wurden.

Bild: Eingabe-Fenster bei einer zugriffsgeschützten WEB-Anwendung

Wird über den Menüpunkt [ Cancel ] die Eingabe abgebrochen, verweigert der Webserver den Zutritt zur betreffenden Anwendung!

NGiNX Webserver

In der Regel haben wir zur Verwaltung der Nutzerdaten ein Backendsystem zur Verwaltung im Einsatz. Im folgendem Konfigurationsbeispiel werden wir uns nun gegen einen vorhandenen LDAP-Server authentifizieren.

Der Webserver NGiNX stellt von Haus aus keine Möglichkeit zur LDAP-Authentifikation zur Verfügung. Mit Hilfe der Erweiterung nginx-auth-ldap von Valery Komarov kann diese aber nachgerüstet werden. Eine entsprechende aktuell Version von NGiNX mit LDAP-Authentifizierungsunterstützung ist im Repository mailserver.guru enthalten:

WICHTIG:

Im Gegensatz zur LDAPs Authentifikation beim Apache Webserver, vertraut das LDAP-Modul für NGiNX jedem Server-Zertifikat. Das bedeutet, wir brauchen hier nicht die Root-Zertifikate der genutzten CA5) importieren und diesen unser Vertrauen aussprechen.

Dies ist beim Einsatz von NGiNX im sicherheitskritischen Umfeld zu beachten!

Konfiguration

Die Konfiguration der LDAPs Authentifikation beim Webserver NGiNX ist aufgeteilt, in zwei Abschnitte. Der erste Abschnitt definiert den Zugang zum LDAP-Server, der zweite Teil ist dann im Abschnitt server der NGiNX-Konfiguration und verweist dann auf einen Eiintrag des „ersten Abschnitts“.

Sehen wir uns das an folgendem Beispiel genauer an.

 # vim /etc/nginx/conf.d/1st_ldap.conf
/etc/nginx/conf.d/1st_ldap.conf
# Django : 2015-07-18
# Definition für die Anbindung unseres nginx Servers an den
# OpenLDAP-Server für die Authentifikation des Users django
 
ldap_server ldap_group_1 {
  url ldaps://openldap.dmz.nausch.org:636/ou=People,dc=nausch,dc=org?uid?sub?(objectClass=posixAccount);
  binddn "cn=Technischeruser,dc=nausch,dc=org";
  binddn_passwd "e1n531f!D4xIi57n393I1354u!";
  group_attribute uniquemember;
  group_attribute_is_dn on;
  #parse_require user "uid=django,ou=People,dc=nausch,dc=org";
  require user "uid=django,ou=People,dc=nausch,dc=org";
  require user "uid=icinga2_checkuser,ou=Daemon,dc=nausch,dc=org";
}
 
# Definition für die Anbindung unseres nginx Servers an den
# OpenLDAP-Server für die Authentifikation des Users michael
ldap_server ldap_group_2 {
  url ldaps://10.0.0.37:636/ou=People,dc=nausch,dc=org?uid?sub?(objectClass=posixAccount);
  binddn "cn=Technischeruser,dc=nausch,dc=org";
  binddn_passwd "e1n531f!D4xIi57n393I1354u!";
  group_attribute uniquemember;
  group_attribute_is_dn on;
  require user "uid=michael,ou=People,dc=nausch,dc=org";
}

Wichtig:

Der Name der Konfigurationsdatei 1st_ldap.conf wurde mit Absicht so gewählt, da nginx beim Starten die Dateien in alphabetischer Reihenfolge einliest. Die Definition des ldap_server muss vor dem verweisen der Serverkonfiguration erfolgen, andernfalls würde bei einem Test der Konfiguration, z.B. folgender Fehler auftreten:

 # nginx -t
nginx: [emerg] http_auth_ldap: Using "auth_ldap_servers" when no "ldap_server" has been previously defined (make sure that "auth_ldap_servers" goes after "ldap_server"s in your configuration file) in /etc/nginx/conf.d/default.conf:29
nginx: configuration file /etc/nginx/nginx.conf test failed

Nun können wir in der Serverkonfiguration auf die gerade eben angelegten ldap_server rückverweisen.

 # vim /etc/nginx/conf.d/betterawstats.conf
/etc/nginx/conf.d/betterawstats.conf
server {
                                # Django : 2015-05-28
                                # auf welchem Port soll der Server lauschen (HTTP: 80)?
        listen                  80;
 
                                # auf welchen Servernamen (vHOST) soll der Server reagieren?
        server_name             betterawstats.nausch.org;
 
                                # Welches Access- und Error-Logfile soll beschrieben werden?
        access_log              /var/log/nginx/betterawstats_access.log;
        error_log               /var/log/nginx/betterawstats_errors.log;
 
                                # HTTP auf HTTPS mit Statuscode 301 "moved permanently" umleiten
        return                  301     https://$server_name$request_uri;
}
 
 
server {
                                # Django : 2015-05-28
                                # auf welchem Port soll der Server lauschen (HTTPS: 443)?
                                # neben TLS soll auch SPDY (http://de.wikipedia.org/wiki/SPDY) 
                                # angeboten werden.
        listen                  443 ssl spdy;
 
                                # auf welchen Servernamen (vHOST) soll der Server reagieren?
        server_name             betterawstats.nausch.org;
 
                                # Welches Access- und Error-Logfile soll beschrieben werden?
        access_log              /var/log/nginx/betterawstats_access.log;
        error_log               /var/log/nginx/betterawstats_errors.log;
 
                                # Standard-Parameter für TLS-Verschlüsselung inkludieren
        include                 /etc/nginx/ssl_params;
                                # Zertifikatsdatei inkl. ggf. notwendiger Zwischen- und Root-Zertifikaten
                                # 1) Server-Zertifikat, 2) Intermediate-Root-Zertifikat und 
                                # 3) Root-Zertifikat der CA
        ssl_certificate         /etc/pki/tls/certs/betterawstats.nausch.org.certificatechain_150113.pem;
                                # Schlüsseldatei, mit der der CSR erstellt wurde
        ssl_certificate_key     /etc/pki/tls/private/betterawstats.nausch.org.serverkey.pem;
 
                                # Zugriffe erst nach erfolreicher Authentifizierung gestatten
                                # Authentifikation des Benutzers django gegen den zentralen
                                # OpenLDAP-Verzeichnisdienst
        auth_ldap               "gesperrter Bereich bei nausch.org";
        auth_ldap_servers       ldap_group_2;
 
                                # Welcher Inhalt soll angezeigt bzw. auf welchen Server sollen 
                                # die HTTP-Requests
                                # weitergeleitet werden?
        root                    /usr/share/betterawstats/;
        index                   index.php index.html;
 
        location ~ \.php {
                                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                                fastcgi_index           index.php;
                                fastcgi_param           SCRIPT_FILENAME         $document_root$fastcgi_script_name;
                                include                 fastcgi_params;
        }
 
        location ~* ^/(.+\.(gif|jp?eg|png|css|js|cgi|pl|ico|swf|flv|s?html|php|xap|py|xml|txt))$ {
                                expires                 1y;
                                root                    /usr/share/betterawstats;
                                allow                   all;
        }
 
        location ~ icons {
                                allow                   all;
        }
}

Achtung:

Prüft man mit Hilfe des Befehls nginx -t die Konfiguration, wird der folgende Fehler angezeigt.

 # nginx -t
nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:12
nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:13
nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:24
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Dies ist ein bekannter Fehler6). NGiNX kann aber wie gewohnt ge(re)startet werden!

Damit unsere Änderungen aktiv werden bedarf es noch eines reloads unseres HTTP-Deamon.

 # systemctl reload nginx.service

WICHTIG:
Damit die Anmeldedaten nicht von Dritten mitgelesen und abgefischt werden können, nutzen wir natürlich einen SSL-geschützten vHOST!

Test

Der Webserver wird nun den Zugang erst gestatten, sobald die Daten richtig eingegeben wurden. Bild: Eingabe-Fenster bei einer zugriffsgeschützten WEB-Anwendung

Wird über den Menüpunkt [ Cancel ] die Eingabe abgebrochen, verweigert der Webserver den Zutritt zur betreffenden Anwendung!

Links


1) , 3) , 4) , 5)
Certificate Authority
2)
Naming Services LDAP Client Daemon
6)
Stand: Juli 2015
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/ldap_c7/clientauth.txt
  • Zuletzt geändert: 20.04.2018 10:49.
  • (Externe Bearbeitung)