Inhaltsverzeichnis
TLS-Absicherung des OpenLDAP-Servers - LDAPs-Konfiguration unter CentOS 7.x
Dass das Internet systembedingt unsicher ist, hat sich in aller Regel herumgesprochen. Daten durchlaufen von der Quelle bis zum Ziel zahlreiche Server und Systeme, an denen die Daten, abgegriffen und/oder manipuliert werden können und das nicht nur bei Übertragungen im Internet , sondern auch im Intranet! Persönliche und vertrauliche Daten, wie z.B. Anmeldenamen und Passwörter, können so einfach Dritten in die Hände fallen, die mit grosser krimineller Energie versuchen an diese Daten zu kommen.
Inwieweit staatliche Stellen den Datenverkehr abhören, protokollieren und abgreifen und zu manipulieren bzw. zensieren versuchen, weiss
- keiner so genau und
- was mit den gewonnen Daten angestellt wird, wird sich niemand öffentlich sagen trauen.
Tja, das war Stand der Dinge vor 2013, denn was bisher in den Bereich der Spekulation fiel,
findet nun Bestätigung durch die Erkenntnisse des Whistleblowers Edward Snowden zu den Projekten PRISM aus den USA und TEMPORA aus England.
Seit Jahren werden unschuldige Bürgerinnen und Bürger von staatlichen Institutionen unter Generalverdacht gestellt und überwacht! Regierungen scheuen keinen Aufwand um in die Privatsphäre unschuldiger Bürgerinnen und Bürger einzudringen, Daten auszulesen und auszuwerten!
Was lernen wir aus dieser Tatsache? Unsere Kommunikation ist nach besten Wissen und Gewissen, so zu gestalten, damit andere unsere Daten nicht mitlesen und manipulieren können. Ferner ist sicherzustellen, dass Empfänger vertrauen können, dass Informationen tatsächlich von dem versandt wurden, von dem wir glauben, diese zu bekommen.
Für die vertrauliche Kommunikation zwischen unseren Usern und unserm OpenLDAP-Server bietet sich eine verschlüsselte Kommunikation mit Hilfe von SSL/TLS an.
Mit Hilfe von PFS1) können wir leicht und einfach sicherstellen, dass aufgezeichnete Datenströme im nach hinein nicht entschlüsselt werden können. Dies wird erreicht, da die beiden Kommunikationspartner, einen separaten und individuellen temporären Schlüssel zur Datensicherung verwenden. Dieser Schlüssel ist dabei nicht fix, sondern wird bei jeder Verbindung neu ausgehandelt. Da aber der Schlüssel an sich nicht ausgetauscht werden muss, ist es auch nicht möglich, den eventuell aufgezeichneten Datenstrom zu entschlüsseln, da der dazu benötigte Schlüssel nicht im Datenstrom enthalten war.
Perfect Forward Secrecy (PFS) basiert auf der Idee, dass Client und Server ihre Kommunikation über einen zusätzlichen temporären Schlüssel absichern, der wechselt. Da der Verbindungsaufbau so gestrickt ist, daß der Schlüssel selbst gar nicht ausgetauscht werden muß, kann der jeweils benutzte Sitzungsschlüssel selbst auch nicht aufgezeichnet werden. Eine nachträgliche Entschlüsselung einer früher aufgezeichneten Session ist damit nicht mehr möglich.
Die für die Verschlüsselung notwendigen Schlüssel und Zertifikate erstellen wir mittels OpenSSL, einer freien Implementierung von SSL2). SSL oder TLS3) ist ein hybrides Verschlüsselungsprotokoll zur Datenübertragung im Internet. Unter TLS 1.0, 1.1 und 1.2 versteht man die standardisierten Weiterentwicklungen von SSL 3.0 (TLS 1.0 steht neu für SSL 3.1). Dies bedeutet also, SSL wird nun unter dem Namen TLS weiterentwickelt.
OpenSSL
Bei der Standardinstallation unseres Systems wurde in der Regel bereits das Paket openssl installiert. Ein kurzer Blick in die RPMdatenbank schafft hierzu Gewissheit.
# yum list openssl
Installed Packages openssl.x86_64 1:1.0.1e-42.el7_0.6
Sollte das Paket noch fehlen, installieren wir dies einfach via:
# yum install openssl
Was uns das Paket openssl alles mitbringt und wohin die Programme und Konfigurationsdateien kopiert werden, offenbart uns das System wie folgt.
# rpm -qil openssl
Name : openssl Epoch : 1 Version : 1.0.1e Release : 42.el7.9 Architecture: x86_64 Install Date: Sat 11 Jul 2015 01:25:02 AM CEST Group : System Environment/Libraries Size : 1611138 License : OpenSSL Signature : RSA/SHA256, Mon 29 Jun 2015 03:00:26 PM CEST, Key ID 24c6a8a7f4a80eb5 Source RPM : openssl-1.0.1e-42.el7.9.src.rpm Build Date : Mon 29 Jun 2015 02:49:07 PM CEST Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.openssl.org/ Summary : Utilities from the general purpose cryptography library with TLS implementation Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. /etc/pki/CA /etc/pki/CA/certs /etc/pki/CA/crl /etc/pki/CA/newcerts /etc/pki/CA/private /etc/pki/tls/certs/Makefile /etc/pki/tls/certs/make-dummy-cert /etc/pki/tls/certs/renew-dummy-cert /etc/pki/tls/misc/CA /etc/pki/tls/misc/c_hash /etc/pki/tls/misc/c_info /etc/pki/tls/misc/c_issuer /etc/pki/tls/misc/c_name /usr/bin/openssl /usr/share/doc/openssl-1.0.1e /usr/share/doc/openssl-1.0.1e/CHANGES /usr/share/doc/openssl-1.0.1e/FAQ /usr/share/doc/openssl-1.0.1e/INSTALL /usr/share/doc/openssl-1.0.1e/LICENSE /usr/share/doc/openssl-1.0.1e/NEWS /usr/share/doc/openssl-1.0.1e/README /usr/share/doc/openssl-1.0.1e/README.FIPS /usr/share/doc/openssl-1.0.1e/c-indentation.el /usr/share/doc/openssl-1.0.1e/openssl.txt /usr/share/doc/openssl-1.0.1e/openssl_button.gif /usr/share/doc/openssl-1.0.1e/openssl_button.html /usr/share/doc/openssl-1.0.1e/ssleay.txt /usr/share/man/man1/asn1parse.1ssl.gz /usr/share/man/man1/ca.1ssl.gz /usr/share/man/man1/ciphers.1ssl.gz /usr/share/man/man1/cms.1ssl.gz /usr/share/man/man1/crl.1ssl.gz /usr/share/man/man1/crl2pkcs7.1ssl.gz /usr/share/man/man1/dgst.1ssl.gz /usr/share/man/man1/dhparam.1ssl.gz /usr/share/man/man1/dsa.1ssl.gz /usr/share/man/man1/dsaparam.1ssl.gz /usr/share/man/man1/ec.1ssl.gz /usr/share/man/man1/ecparam.1ssl.gz /usr/share/man/man1/enc.1ssl.gz /usr/share/man/man1/errstr.1ssl.gz /usr/share/man/man1/gendsa.1ssl.gz /usr/share/man/man1/genpkey.1ssl.gz /usr/share/man/man1/genrsa.1ssl.gz /usr/share/man/man1/md2.1ssl.gz /usr/share/man/man1/md4.1ssl.gz /usr/share/man/man1/md5.1ssl.gz /usr/share/man/man1/mdc2.1ssl.gz /usr/share/man/man1/nseq.1ssl.gz /usr/share/man/man1/ocsp.1ssl.gz /usr/share/man/man1/openssl.1ssl.gz /usr/share/man/man1/pkcs12.1ssl.gz /usr/share/man/man1/pkcs7.1ssl.gz /usr/share/man/man1/pkcs8.1ssl.gz /usr/share/man/man1/pkey.1ssl.gz /usr/share/man/man1/pkeyparam.1ssl.gz /usr/share/man/man1/pkeyutl.1ssl.gz /usr/share/man/man1/req.1ssl.gz /usr/share/man/man1/ripemd160.1ssl.gz /usr/share/man/man1/rsa.1ssl.gz /usr/share/man/man1/rsautl.1ssl.gz /usr/share/man/man1/s_client.1ssl.gz /usr/share/man/man1/s_server.1ssl.gz /usr/share/man/man1/s_time.1ssl.gz /usr/share/man/man1/sess_id.1ssl.gz /usr/share/man/man1/sha.1ssl.gz /usr/share/man/man1/sha1.1ssl.gz /usr/share/man/man1/smime.1ssl.gz /usr/share/man/man1/speed.1ssl.gz /usr/share/man/man1/spkac.1ssl.gz /usr/share/man/man1/sslpasswd.1ssl.gz /usr/share/man/man1/sslrand.1ssl.gz /usr/share/man/man1/ts.1ssl.gz /usr/share/man/man1/tsget.1ssl.gz /usr/share/man/man1/verify.1ssl.gz /usr/share/man/man1/version.1ssl.gz /usr/share/man/man1/x509.1ssl.gz /usr/share/man/man5/config.5ssl.gz /usr/share/man/man5/openssl.cnf.5ssl.gz /usr/share/man/man5/x509v3_config.5ssl.gz /usr/share/man/man7/des_modes.7ssl.gz
Cipher-Suites und Diffie-Hellmann
Möchte man in Erfahrung bringen, welche Cipher-Suites4) (Chiffrensammlung) unser installiertes OpenSSL-Paket mitbringt, können wir wie folgt abfragen5).
# openssl ciphers -v
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1 KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1 KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1 KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5 KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
Wir haben also mit der aktuellen Version von OpenSSL, den für Perfect Forward Secrecy benötigten kryptographischen Algorithmus DH6) sowie den weiterentwickelten ECDH7).
Zertifikatserstellung
Technisch gesehen unterscheiden sich Zertifikate einer „offiziellen“ oder besser gesagt einer kommerziellen CA nicht von Zertifikaten einer eigenen „self signed“ Zertifikaten. In aller Regel wird dies abhängig davon sein, ob die verwendeten Zertifikate anstandslos von den Clientprogrammen (Mailclients und ggf. Browser) beim Endnutzer akzeptiert werden, also von einer vertrauenswürdigen CA stammen.
Egal welchen Weg wir hier gehen können oder müssen, zur Absicherung unserer Kommunikation benötigen wir drei Dinge:
- unseren Private Key, den wir hüten wie unseren Augapfel
- unseren Public Key mit zusätzlichen Daten , auch bekannt als CSR8), den wir von einer CA9) signieren lassen. Dies ist das Zertifikat, welches wir von unserer eigenen CA oder auch eine der vielen kommerziellen erhalten, und
- den Public Key der unterschreibenden CA, um deren Unterschrift zu prüfen, auch als Root-Zertifikat bekannt.
Nutzt man ein kommerzielle CA können wir die nächsten Kapitel getrost überspringen und gleich damit starten, den nötigen Schlüssel für unser Zertifikat/CSR zu erstellen.
CA Erstellung
scriptgesteuert
Dem Paket openssl liegt zwar ein Bash-Script bei, mit dessen Hilfe die nachfolgenden Installationsschritte automatisiert ablaufen sollen, aber zum besseren Verständnis, gehen wir die Schritte kurz manuell durch. Das vorgenante Script aus dem Jahre '96 
findet man im Übrigen sonderbarer Weise unter /etc/pki/tls/misc/CA.
# cat /etc/pki/tls/misc/CA
- /etc/pki/tls/misc/CA
#!/bin/sh # # CA - wrapper around ca to make it easier to use ... basically ca requires # some setup stuff to be done before you can use it and this makes # things easier between now and when Eric is convinced to fix it :-) # # CA -newca ... will setup the right stuff # CA -newreq ... will generate a certificate request # CA -sign ... will sign the generated request and output # # At the end of that grab newreq.pem and newcert.pem (one has the key # and the other the certificate) and cat them together and that is what # you want/need ... I'll make even this a little cleaner later. # # # 12-Jan-96 tjh Added more things ... including CA -signcert which # converts a certificate to a request and then signs it. # 10-Jan-96 eay Fixed a few more bugs and added the SSLEAY_CONFIG # environment variable so this can be driven from # a script. # 25-Jul-96 eay Cleaned up filenames some more. # 11-Jun-96 eay Fixed a few filename missmatches. # 03-May-96 eay Modified to use 'ssleay cmd' instead of 'cmd'. # 18-Apr-96 tjh Original hacking # # Tim Hudson # tjh@cryptsoft.com # # default openssl.cnf file has setup as per the following # demoCA ... where everything is stored cp_pem() { infile=$1 outfile=$2 bound=$3 flag=0 exec <$infile; while read line; do if [ $flag -eq 1 ]; then echo $line|grep "^-----END.*$bound" 2>/dev/null 1>/dev/null if [ $? -eq 0 ] ; then echo $line >>$outfile break else echo $line >>$outfile fi fi echo $line|grep "^-----BEGIN.*$bound" 2>/dev/null 1>/dev/null if [ $? -eq 0 ]; then echo $line >$outfile flag=1 fi done } usage() { echo "usage: $0 -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify" >&2 } if [ -z "$OPENSSL" ]; then OPENSSL=openssl; fi if [ -z "$DAYS" ] ; then DAYS="-days 365" ; fi # 1 year CADAYS="-days 1095" # 3 years REQ="$OPENSSL req $SSLEAY_CONFIG" CA="$OPENSSL ca $SSLEAY_CONFIG" VERIFY="$OPENSSL verify" X509="$OPENSSL x509" PKCS12="openssl pkcs12" if [ -z "$CATOP" ] ; then CATOP=/etc/pki/CA ; fi CAKEY=./cakey.pem CAREQ=./careq.pem CACERT=./cacert.pem RET=0 while [ "$1" != "" ] ; do case $1 in -\?|-h|-help) usage exit 0 ;; -newcert) # create a certificate $REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS RET=$? echo "Certificate is in newcert.pem, private key is in newkey.pem" ;; -newreq) # create a certificate request $REQ -new -keyout newkey.pem -out newreq.pem $DAYS RET=$? echo "Request is in newreq.pem, private key is in newkey.pem" ;; -newreq-nodes) # create a certificate request $REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS RET=$? echo "Request (and private key) is in newreq.pem" ;; -newca) # if explicitly asked for or it doesn't exist then setup the directory # structure that Eric likes to manage things NEW="1" if [ "$NEW" -o ! -f ${CATOP}/serial ]; then # create the directory hierarchy mkdir -p ${CATOP} mkdir -p ${CATOP}/certs mkdir -p ${CATOP}/crl mkdir -p ${CATOP}/newcerts mkdir -p ${CATOP}/private touch ${CATOP}/index.txt fi if [ ! -f ${CATOP}/private/$CAKEY ]; then echo "CA certificate filename (or enter to create)" read FILE # ask user for existing CA certificate if [ "$FILE" ]; then cp_pem $FILE ${CATOP}/private/$CAKEY PRIVATE cp_pem $FILE ${CATOP}/$CACERT CERTIFICATE RET=$? if [ ! -f "${CATOP}/serial" ]; then $X509 -in ${CATOP}/$CACERT -noout -next_serial \ -out ${CATOP}/serial fi else echo "Making CA certificate ..." $REQ -new -keyout ${CATOP}/private/$CAKEY \ -out ${CATOP}/$CAREQ $CA -create_serial -out ${CATOP}/$CACERT $CADAYS -batch \ -keyfile ${CATOP}/private/$CAKEY -selfsign \ -extensions v3_ca \ -infiles ${CATOP}/$CAREQ RET=$? fi fi ;; -xsign) $CA -policy policy_anything -infiles newreq.pem RET=$? ;; -pkcs12) if [ -z "$2" ] ; then CNAME="My Certificate" else CNAME="$2" fi $PKCS12 -in newcert.pem -inkey newreq.pem -certfile ${CATOP}/$CACERT \ -out newcert.p12 -export -name "$CNAME" RET=$? exit $RET ;; -sign|-signreq) $CA -policy policy_anything -out newcert.pem -infiles newreq.pem RET=$? cat newcert.pem echo "Signed certificate is in newcert.pem" ;; -signCA) $CA -policy policy_anything -out newcert.pem -extensions v3_ca -infiles newreq.pem RET=$? echo "Signed CA certificate is in newcert.pem" ;; -signcert) echo "Cert passphrase will be requested twice - bug?" $X509 -x509toreq -in newreq.pem -signkey newreq.pem -out tmp.pem $CA -policy policy_anything -out newcert.pem -infiles tmp.pem RET=$? cat newcert.pem echo "Signed certificate is in newcert.pem" ;; -verify) shift if [ -z "$1" ]; then $VERIFY -CAfile $CATOP/$CACERT newcert.pem RET=$? else for j do $VERIFY -CAfile $CATOP/$CACERT $j if [ $? != 0 ]; then RET=$? fi done fi exit $RET ;; *) echo "Unknown arg $i" >&2 usage exit 1 ;; esac shift done exit $RET
Wichtig:
Zum besseren Verständnis der Zertifikatsthematik, gehen wir die Schritte kurz manuell durch und nutzen nicht das fast 20 jahre alte Script.
manuell
fehlende Dateien anlegen
Als erstes legen wir die noch fehlenden Dateien an.
# echo "00" > /etc/pki/CA/serial
# touch /etc/pki/CA/index.txt
Somit befindet sich in unserem Pfad /etc/pki/CA nun folgender Inhalt:
# ll /etc/pki/CA
total 4 drwxr-xr-x 2 root root 6 Jun 24 14:57 certs drwxr-xr-x 2 root root 6 Jun 24 14:57 crl -rw-r--r-- 1 root root 0 Jul 23 14:03 index.txt drwxr-xr-x 2 root root 6 Jun 24 14:57 newcerts drwx------ 2 root root 6 Jun 24 14:57 private -rw-r--r-- 1 root root 3 Jul 23 14:03 serial
CA-Erstellung mit Hilfe von openssl
Die Gültigkeit setzen wir mit 25 Jahren bewusst sehr hoch an. Nach dem Ablauf der Gültigkeit der CA werden nämlich auch alle damit signierten Serverzertifikate ungültig! Bei der nun folgenden Generierung unserer CA wird automatisch ein Schlüssel (private key), mit einer Länge von 2048 Bit, erzeugt und in der Datei cakey.pem abgespeichert. Das CA-Zertifikat selbst wird nach cacert.pem geschrieben.
Zur Sicherheit schützen wir den private key unserer CA mit einer Passphrase! Denn wer den geheimen Schlüssel der CA hat/kennt, könnte damit beliebige Serverzertifikate signieren. Daher legen wir dieses Keyfile nicht im Klartext auf der Festplatte ab, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigen wir immer dann, wenn wir mit unser eigenen CA neue Zertifikate ausstellen wollen. Im nachfolgenden Dialog akzetieren wir die Vorgaben in eckigen Klammern, geben unsere individuellen Daten an, oder quittieren ein leeres Feld mittels eines Punktes .. Beim Feld Common Name (CN) geben wir den Domain-Namen unserer Zertifizierungsstelle ein.
Diese Daten werden dem Client angezeigt, sobald dieser aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen.
Die Eingaben sind in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl req -new -x509 -newkey rsa:4096 -keyout cakey.pem -out cacert.pem -days 9125
Generating a 4096 bit RSA private key ..................................................++ ....................++ writing new private key to 'cakey.pem' Enter PEM pass phrase: des-woas-blos-I-und-sundst-koana Verifying - Enter PEM pass phrase: des-woas-blos-I-und-sundst-koana ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:DE State or Province Name (full name) []:Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:Zertifizierungsstelle Common Name (eg, your name or your server's hostname) []:nausch.org Email Address []:ca-support@nausch.org
Als Ergebnis erhalten wir zwei Dateien:
- cakey.pem den private key unserer CA und
- cacert.pem das CA-Certifikat unserer CA.
# ll *.pem
- rw-r–r– 1 root root 2171 Jul 23 14:07 cacert.pem
- rw-r–r– 1 root root 3394 Jul 23 14:07 cakey.pem
Sichtshalber ändern wir die Rechte so, dass die Schlüsseldateien nur für root lesbar sind:
# chmod 400 *.pem
Bei Bedarf kann man mit openssl rsa -in <keyfile> -noout -text die Schlüsseldatei öffnen und ausgeben lassen.
# openssl rsa -in cakey.pem -noout -text
Enter pass phrase for cakey.pem: des-woas-blos-I-und-sundst-koana
Private-Key: (4096 bit)
modulus:
00:a6:c0:e4:4a:c5:be:6c:c7:fe:8d:20:34:3d:58:
f5:40:3c:4b:b6:8a:df:3f:2b:cf:c2:9a:d6:0e:1e:
78:25:93:b1:6e:d4:fe:c4:41:0a:3a:f4:7e:f9:f1:
f1:a3:2a:b9:c2:b7:86:39:94:4a:16:be:97:e6:92:
4a:3d:e7:f3:63:46:d4:fb:66:b1:cb:f6:d0:0a:9e:
04:fd:cc:d0:7f:bd:af:40:01:cb:86:ab:c7:e8:25:
d8:58:72:66:a7:6e:ab:af:70:a6:07:06:df:a8:86:
d9:53:75:74:d5:55:a7:4c:7e:4a:55:96:39:0a:97:
98:eb:b3:58:57:bc:5d:ef:7b:6c:8c:a0:ba:9f:10:
67:14:f0:4f:2b:7b:b9:72:b9:ff:e2:99:3f:a7:d2:
91:2c:a2:db:94:e9:bb:90:06:e2:91:06:c7:26:fb:
23:06:83:b0:60:30:a2:d5:7d:22:95:62:99:42:c3:
8e:58:44:32:52:29:ad:68:27:bb:ae:5d:99:67:0e:
10:a0:3c:c0:a6:d4:d5:44:a8:c9:c4:a4:45:12:19:
46:c3:aa:dc:e5:61:a2:0c:cf:2f:38:f3:6f:5c:13:
f9:fe:86:c0:4a:ba:2a:9a:4f:25:4d:63:85:e4:6a:
9d:f1:53:a0:31:64:aa:77:98:b9:0e:63:5c:de:d9:
04:ed:d0:b7:fa:5b:5d:cc:e4:1e:c4:5b:e3:05:dd:
79:21:ae:e1:a3:6d:0b:9e:78:fb:d7:67:cc:a4:b2:
21:44:e1:0a:bc:e1:e9:ab:1d:f2:c8:a9:59:51:3c:
dd:d9:e4:de:e5:a3:c7:95:83:5a:f5:c1:b1:cb:69:
f5:fe:a6:8d:91:11:c4:5d:cd:b5:cc:fc:77:60:68:
aa:3e:92:dc:6f:ac:55:03:82:7a:7d:77:17:00:14:
4f:e2:b9:d8:87:bc:30:f1:b7:28:1d:a9:6b:25:2c:
22:28:29:6b:9e:ba:ad:2f:12:77:be:e4:43:69:0f:
fd:a7:f9:03:21:05:df:f4:eb:90:1c:8e:1e:82:d2:
81:0d:a1:a9:00:cb:3e:b8:73:39:19:4f:32:cc:dc:
4e:ea:ab:1c:1b:a1:6d:63:68:a8:3a:67:65:22:ec:
0c:ea:f7:e6:38:9c:5e:0c:8c:e7:d1:30:fa:53:2d:
80:2f:19:84:d2:49:17:7f:6d:d5:63:d2:20:3d:ec:
e6:d7:74:65:e6:cc:be:cb:1b:07:76:96:aa:05:16:
4e:26:89:ab:42:f1:39:58:2c:af:44:fb:e6:c9:ea:
46:34:19:8f:6a:d4:59:55:d8:40:d5:a2:39:8e:80:
ce:9b:6e:42:8f:2f:49:93:24:b5:6c:a5:07:b0:9c:
f9:25:eb
publicExponent: 65537 (0x10001)
privateExponent:
45:42:50:8f:8d:da:2d:ac:53:59:a2:4a:90:40:66:
7c:ab:8e:76:de:ef:22:79:bb:ed:04:0a:6c:0a:d3:
b4:27:c7:c6:54:c9:0c:12:47:81:7d:13:50:14:e1:
5b:f7:de:f7:b4:ea:16:f8:34:5d:86:03:e9:4c:51:
71:ac:e9:36:0e:b1:5f:49:a4:07:27:17:f9:90:f0:
59:c9:bb:bf:92:b5:3b:4c:83:90:07:c1:1b:f6:bc:
08:e0:5b:2a:a7:98:bf:61:76:53:ec:d2:f0:58:31:
e3:ac:21:3e:8a:38:d6:58:8d:df:46:69:a2:b0:9c:
5f:29:3a:44:16:84:9d:77:11:fa:c6:b7:3c:61:bf:
ae:be:b0:e3:4a:9c:17:be:91:3d:38:91:6b:ce:d5:
65:48:af:13:06:91:54:9c:c7:75:9c:ef:12:8d:b4:
5a:7c:4f:c1:63:f1:fd:e1:df:7f:54:58:7b:96:65:
84:db:ae:5a:d9:dc:a0:2a:00:95:c7:62:73:9f:2f:
e0:9d:db:16:6f:c7:b4:a0:b6:4c:ea:3d:95:ea:d1:
ad:6b:46:1c:2f:94:f2:e5:0a:a4:08:d7:f3:d2:88:
3e:e3:10:f2:f8:a7:c1:37:a6:32:a2:67:76:1b:a2:
46:1d:89:a7:7a:3c:23:38:57:84:56:58:b8:66:42:
d9:27:95:61:cb:1b:39:61:a4:f1:cb:c1:71:ea:3f:
3b:a3:44:ea:84:77:eb:f6:bb:3e:9e:08:1d:27:91:
b5:89:cd:ba:97:fc:6a:de:f9:43:9d:e4:a0:b2:b5:
bd:b7:ea:d7:84:2e:9e:78:5b:fc:27:73:6c:51:40:
c0:bd:0c:69:3e:4a:c5:ac:15:cb:a8:7c:4a:fa:ee:
bc:64:94:02:af:da:56:e5:56:9f:79:93:8d:f1:42:
f7:39:99:dc:82:ab:4b:20:e9:10:da:01:2c:94:be:
fa:d6:9d:59:e9:fb:b9:b8:af:79:10:25:f9:a4:22:
1e:4b:03:ac:e7:a1:57:35:d8:e4:49:1b:78:c5:b9:
1c:3f:30:1c:19:20:2a:b9:0f:90:aa:c1:60:19:ba:
b5:de:98:c4:68:81:ef:8a:c7:fc:c7:64:85:3a:47:
a7:97:b7:ec:4d:fe:f9:ce:e9:9a:2f:76:ea:77:0e:
3e:ac:48:f9:f2:c4:c0:fa:af:f7:09:a6:cb:35:14:
c6:30:fe:ba:7d:b2:d9:ba:50:9a:84:5c:17:11:65:
c4:b9:86:c7:db:52:05:b6:66:df:05:e9:17:03:c1:
02:5b:77:06:0b:7f:5a:a9:f9:01:b7:8d:4a:c3:42:
d7:cd:80:f3:12:c1:36:e2:bf:08:36:52:d8:c6:79:
6d:a1
prime1:
00:dd:13:5d:14:12:93:0e:aa:0b:5f:b2:a7:a8:10:
5b:0c:cc:41:46:bb:ac:3a:d1:e1:e8:76:4b:1a:49:
0e:d4:0c:5e:51:75:c4:77:f5:68:dd:26:f2:d1:b6:
02:77:e2:cf:53:37:a6:f4:a5:b3:dc:26:56:bd:8f:
3e:b2:22:67:67:dc:a1:70:40:6b:57:33:b4:08:e6:
d0:f3:a4:dd:b3:0c:17:bc:57:2a:47:9a:fc:c8:0d:
03:41:b7:56:d6:ce:69:bf:7a:45:5a:72:6c:02:b3:
70:a7:fa:62:ac:a4:5d:5a:c6:92:5d:84:f4:8f:90:
3a:d2:4a:79:89:d7:6a:50:41:12:ea:b9:24:e0:96:
e5:70:62:0a:50:3e:82:cf:56:08:99:47:ba:bf:7b:
8f:b7:b0:89:b6:06:ea:0e:78:86:5b:e1:32:2f:49:
61:88:62:29:c3:db:c0:a1:89:1a:66:48:c4:c1:07:
12:11:2a:ad:73:0a:c2:f3:fa:75:66:88:87:c0:66:
cc:70:7c:29:96:e1:4b:36:36:7e:73:4c:ba:65:5b:
c6:07:c1:e1:d0:43:e6:c8:6e:83:ed:67:c2:ce:b4:
2c:a9:e2:5c:87:24:bb:ad:f0:3c:d7:7a:c7:86:aa:
d3:e3:f1:24:12:8b:b1:55:3e:a7:77:65:80:75:fe:
b6:37
prime2:
00:c1:18:a8:42:3e:47:be:ac:a1:5a:82:06:24:ff:
15:d6:07:dc:79:94:25:6a:f9:de:63:18:d9:93:ca:
d8:88:94:8a:d3:7f:f3:2e:6f:1c:64:40:86:e7:3d:
34:8e:45:c9:f4:dd:1a:17:bb:7f:55:9d:ed:d6:d3:
73:7e:c5:9d:a8:0f:cd:00:eb:78:9c:0c:4d:77:b5:
f7:80:e4:5c:ee:84:1b:aa:9f:b9:82:24:b3:e9:cd:
7e:ee:bb:bf:ce:a0:82:cf:cc:fa:2c:b8:07:fe:79:
ab:00:41:6a:55:3b:88:6e:5c:53:64:07:c2:2a:78:
29:a6:c2:5c:5d:77:1d:a1:83:d5:d1:4b:3d:ce:88:
e4:6f:e8:ff:0b:cb:9e:79:51:63:00:02:5e:2f:fc:
2d:14:9d:02:e0:eb:88:8b:35:76:94:a9:da:da:a9:
b6:5b:eb:b2:ff:ad:72:a6:4e:6a:1d:08:36:99:fc:
63:8b:92:66:c9:0b:af:6d:64:f0:d0:0e:8b:10:2c:
45:7f:2e:e3:6d:7d:e0:60:69:65:30:0e:25:5b:d8:
06:00:77:cb:1e:d5:9b:72:34:49:e8:9c:c6:a8:61:
2d:e0:f8:fe:c7:57:ae:47:79:14:07:22:38:9e:bf:
44:ec:28:b5:73:73:a4:c1:26:89:b0:71:ee:4e:4e:
b3:ed
exponent1:
69:79:e7:9a:c0:11:f1:99:27:bc:0c:dc:f8:ce:74:
e2:72:41:62:a1:ff:d6:40:74:ec:18:24:54:f2:2e:
64:f5:51:ba:c3:d9:6c:f2:65:89:be:1f:73:f6:c6:
ce:b4:23:fe:ac:3a:b7:d6:a7:2d:8e:0d:2c:7b:bf:
89:f5:e8:28:21:97:d4:9a:a7:9b:ff:4b:12:44:2d:
c5:51:0f:85:71:6b:91:ac:74:bb:9d:32:a5:af:af:
b2:16:eb:13:a9:7f:c2:9f:6f:9f:6b:a0:24:d9:c0:
12:24:e0:17:46:84:53:df:11:ce:14:b5:2a:19:c2:
36:ba:d9:a9:ee:61:06:d1:45:59:3f:e4:5c:53:22:
3c:b0:4a:03:67:0f:ba:24:6e:0d:d3:af:41:d4:8e:
09:31:ed:42:2f:a2:54:2d:24:cd:89:70:0c:27:92:
a5:23:50:91:e5:b2:ce:5f:3f:7d:35:92:ca:15:b9:
84:ff:3b:a9:fb:a4:70:0b:3b:20:24:5b:c0:6c:4b:
76:0f:87:38:39:5d:4d:0c:4a:e0:6f:e7:2e:9c:ce:
aa:bc:d2:24:2f:81:58:77:81:f2:2e:e3:3f:03:af:
9b:8e:28:5f:42:23:59:25:99:a1:a5:2e:b5:0d:a3:
f2:c9:06:50:e2:dd:44:b2:93:eb:df:3d:9f:0e:5b:
99
exponent2:
0f:3d:16:ea:43:67:fe:10:39:9b:9e:ef:45:34:2c:
50:fb:c5:d6:82:6e:81:86:be:9a:2b:77:e0:45:fd:
d8:a9:80:5b:38:99:c4:6c:58:5d:41:0a:64:6d:5c:
1c:6e:3d:85:e9:7d:09:aa:6e:5e:1f:5c:89:bb:9e:
3d:be:f2:b6:34:a9:05:0d:90:33:20:75:6c:a1:1b:
ab:3c:5a:69:28:5b:d6:97:4c:58:8c:f4:f5:da:95:
cd:d9:5b:45:bf:3d:13:91:25:9d:29:d8:d7:a8:5a:
6a:66:bf:31:82:c5:3d:90:63:b4:5d:38:61:89:a2:
1f:da:ee:d7:21:73:61:2f:ba:4c:0e:18:0e:98:97:
0e:8d:e0:b2:d9:9a:e4:10:1c:33:ff:fb:d6:e5:9b:
d9:28:9a:f5:8d:20:f5:7b:7e:a4:34:d3:64:b6:48:
01:f1:13:eb:41:90:ee:b6:f9:80:d9:09:16:15:e8:
f5:36:d4:8d:c1:32:52:fb:c8:55:63:10:6e:72:4f:
f9:bd:85:8d:3a:85:de:95:f2:ba:5c:23:6e:a0:19:
b9:27:bb:0b:ef:e7:98:97:af:cd:7f:b1:dd:cf:ed:
82:f7:a3:83:af:d3:bd:28:3d:00:63:1e:fc:c8:33:
74:3f:b2:32:2e:4a:2e:44:10:51:b0:6c:12:19:fb:
f1
coefficient:
00:a6:96:2f:62:1b:35:35:c6:20:ef:a9:8e:66:ac:
5b:2c:a4:cc:ff:ed:a6:53:ad:9d:e1:cb:73:4e:3c:
df:08:f8:7a:10:ee:f1:3b:51:52:6a:ba:eb:60:3a:
72:ee:89:d5:ce:f3:64:bb:44:97:0a:94:25:7f:ce:
0e:f5:13:33:1e:2c:ba:7e:7e:ec:39:4a:ea:8c:05:
76:48:59:f2:19:e5:16:37:1f:1d:dc:9e:06:cb:20:
31:9c:00:61:40:ba:8b:94:c2:68:2c:54:04:a4:5b:
36:d5:36:dd:cc:64:d8:15:d1:14:0e:de:23:9a:59:
c3:b3:1d:7c:6d:29:98:6d:b3:11:71:d1:6e:d2:9d:
01:9a:12:aa:f9:1f:54:f1:d6:0a:b3:ea:1c:b4:cb:
fb:91:f3:dd:e4:a7:3c:f0:74:f1:c9:e5:42:f2:2d:
03:b6:a4:ba:34:92:f5:70:f0:ae:34:b3:6f:c4:69:
3d:14:76:ec:a6:e6:c6:d2:a4:d3:05:30:0e:f8:de:
46:f1:f6:bc:4d:ba:7c:fe:fa:5d:fa:35:54:df:be:
b5:08:92:ea:ba:b6:9c:cc:06:77:40:1e:c3:cc:f7:
6a:4f:56:a7:b3:a9:9a:55:91:55:e0:aa:8e:f7:8d:
6e:59:26:d7:8e:ea:c8:e1:19:a9:12:c0:43:f7:7d:
82:f5
Will man die Passphrase eines Schlüssels entfernen, geht man wie folgt vor:
# openssl rsacakey_ohne_passphrase.pem
Enter pass phrase: des-woas-blos-I-und-sundst-koana writing RSA key
Auch hier sind die Eingaben sind in der Farbe blau, sowie die Rückmeldungen in der Farbe grün gekennzeichnet.
Laufzeit der Zertifikate anpassen
Da wir die Laufzeit der erzeugten Zertifikate nicht auf der Kommandozeile beim Aufruf von openssl angeben können, passen wir in der OpenSSL-Konfigurationsdatei die Laufzeit default_days an.
# vim /etc/pki/tls/openssl.cnf
- /etc/pki/tls/openssl.cnf
# # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. # # This definition stops the following lines choking if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) [ new_oids ] # We can add new OIDs in here for use by 'ca', 'req' and 'ts'. # Add a simple OID like this: # testoid1=1.2.3.4 # Or use config file substitution like this: # testoid2=${testoid1}.5.6 # Policies used by the TSA examples. tsa_policy1 = 1.2.3.4.1 tsa_policy2 = 1.2.3.4.5.6 tsa_policy3 = 1.2.3.4.5.7 #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir = /etc/pki/CA # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. #unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = usr_cert # The extentions to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options # Extension copying option: use with caution. # copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # crlnumber must also be commented out to leave a V1 CRL. # crl_extensions = crl_ext # Django : 2014-07-23 # default: default_days = 365 # how long to certify for (one year) default_days = 730 # how long to certify for (two years) default_crl_days= 30 # how long before next CRL default_md = sha256 # use SHA-256 by default preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### [ req ] default_bits = 2048 default_md = sha256 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert # Passwords for private keys if not present they will be prompted for # input_password = secret # output_password = secret # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK:XXXX a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only # req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = XX countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) #stateOrProvinceName_default = Default Province localityName = Locality Name (eg, city) localityName_default = Default City 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Default Company Ltd # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = Organizational Unit Name (eg, section) #organizationalUnitName_default = commonName = Common Name (eg, your name or your server\'s hostname) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 # SET-ex3 = SET extension number 3 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name [ usr_cert ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. # nsCertType = server # For an object signing certificate this would be used. # nsCertType = objsign # For normal client use this is typical # nsCertType = client, email # and for everything including object signing: # nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectAltName=email:move # Copy subject details # issuerAltName=issuer:copy #nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName # This is required for TSA certificates. # extendedKeyUsage = critical,timeStamping [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer # This is what PKIX recommends but some broken software chokes on critical # extensions. #basicConstraints = critical,CA:true # So we do this instead. basicConstraints = CA:true # Key usage: this is typical for a CA certificate. However since it will # prevent it being used as an test self-signed certificate it is best # left out by default. # keyUsage = cRLSign, keyCertSign # Some might want this also # nsCertType = sslCA, emailCA # Include email address in subject alt name: another PKIX recommendation # subjectAltName=email:copy # Copy issuer details # issuerAltName=issuer:copy # DER hex encoding of an extension: beware experts only! # obj=DER:02:03 # Where 'obj' is a standard or added object # You can even override a supported extension: # basicConstraints= critical, DER:30:03:01:01:FF [ crl_ext ] # CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. # issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always [ proxy_cert_ext ] # These extensions should be added when creating a proxy certificate # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. # nsCertType = server # For an object signing certificate this would be used. # nsCertType = objsign # For normal client use this is typical # nsCertType = client, email # and for everything including object signing: # nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # This stuff is for subjectAltName and issuerAltname. # Import the email address. # subjectAltName=email:copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectAltName=email:move # Copy subject details # issuerAltName=issuer:copy #nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName # This really needs to be in place for it to be a proxy certificate. proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo #################################################################### [ tsa ] default_tsa = tsa_config1 # the default TSA section [ tsa_config1 ] # These are used by the TSA reply generation only. dir = ./demoCA # TSA root directory serial = $dir/tsaserial # The current serial number (mandatory) crypto_device = builtin # OpenSSL engine to use for signing signer_cert = $dir/tsacert.pem # The TSA signing certificate # (optional) certs = $dir/cacert.pem # Certificate chain to include in reply # (optional) signer_key = $dir/private/tsakey.pem # The TSA private key (optional) default_policy = tsa_policy1 # Policy if request did not specify it # (optional) other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional) digests = sha1, sha256, sha384, sha512 # Acceptable message digests (mandatory) accuracy = secs:1, millisecs:500, microsecs:100 # (optional) clock_precision_digits = 0 # number of digits after dot. (optional) ordering = yes # Is ordering defined for timestamps? # (optional, default: no) tsa_name = yes # Must the TSA name be included in the reply? # (optional, default: no) ess_cert_id_chain = no # Must the ESS cert id chain be included? # (optional, default: no)
Schlüssel für das Serverzertifikat erzeugen
Nachdem wir nun unsere eigene CA erstellt haben, machen wir uns daran, endlich für unseren Server ein Zertifikat zu erstellen. Hierzu erzeugen wir als erstes einen 4096 Bit langen RSA Schlüssel, den wir mit AES 256 verschlüsselt auf der Platte abgelegt lassen. Da OpenSSL keine leere Passphrase zulässt braucht die Passphrase diesmal nicht sonderlich geheim sein, da wir diese im Anschluss ohnehin sofort wieder entfernen werden.
Die Eingaben sind in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl genrsa -out serverkey.pem -aes256 4096 -days 7300
Generating RSA private key, 4096 bit long modulus .......................................................................................................................................................................................................................++ ........................................................................................................................................................................................++ e is 65537 (0x10001) Enter pass phrase for serverkey.pem: 12qwasyx Verifying - Enter pass phrase for serverkey.pem: 12qwasyx
Wie schon erwähnt, entfernen wir die Passphrase nun wieder, in dem wir bei der Frage Enter pass phrase: einfach die Taste [ENTER] drücken.
# openssl rsa -in serverkey.pem -out serverkey_2.pem
Enter pass phrase: writing RSA key
Wie schon zuvor schützen wir auch hier den Serverschlüssel über die Dateirechte, nachdem wir diesen umbenannt haben.
# mv serverkey_2.pem openldap_serverkey.pem -f
# chmod 400 openldap_serverkey.pem
Zum Schluss schreddewrn wir noch den initial erstellten Server-Key.
# shred -u serverkey.pem
Certificate Signing Request erzeugen
Im folgenden Schritt zu unserem eigenen Zertifikat erzeugen wir einen CSR10), den wir dann in einem weiteren Schritt von unserer eigenen CA signieren lassen werden, oder bei der ausgewählten kommerziellen CA einkippen.
Wichtig: Bei unserem Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name unseres OpenLDAP-Servers eingetragen werden, unter dem der Mailserver angesprochen wird!
Auch hier sind die Eingaben in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl req -new -key serverkey.pem -out csr.pem -nodes
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:DE State or Province Name (full name) []Bayern Locality Name (eg, city) [Default City]:Pliening Organization Name (eg, company) [Default Company Ltd]:nausch.org Organizational Unit Name (eg, section) []:IT-Services Common Name (eg, your name or your server's hostname) []:openldap.dmz.nausch.org Email Address []:dbmaster@nausch.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Wollen oder müssen wir ein kommerzielles Zertifikat, also von einer in den Browsern und mailclients von Haus aus installierten CAs, nutzen, so lassen wir den CSR der CA zukommen.
# cat openldap.dmz.nausch.org.csr.pem
-----BEGIN CERTIFICATE REQUEST----- MIIE6DCCAtACAQAwgaIxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAP BgNVBAcMCFBsaWVuaW5nMRMwEQYDVQQKDApuYXVzY2gub3JnMRQwEgYDVQQLDAtJ VC1TZXJ2aWNlczEgMB4GA1UEAwwXb3BlbmxkYXAuZG16Lm5hdXNjaC5vcmcxIjAg BgkqhkiG9w0BCQEWE2RibWFzdGVyQG5hdXNjaC5vcmcwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQDFHbHyjyKa9zGtIKUyXSHShSfVo6HO7UTuQ+u1oF5u E8cHde8CudQZArFz3O7TRx003xCde1D36oHuGx+ZB/lX4OHQGwxtMQ7XCYm0NJOH W2RInUxE+NSKndpusYBjgHxDqWZklANgMJ+BgShR44N0c2emBp+gkwk2ghokbEVo hqtCgZOJV5r3wMvv3QAV1sDJULLnzMLzcWKe38v9Su2TIkn0bMjLqjFjjvnt2HFG rmVYaoSpXB9gFovPleo+MKdhu9n7rsTqWZFNryXDSh97B2I/Rqfme1R5s4A5c+2N NH/dzOlVZwvdUYQwcIEMxgzDUU0i8hJzhcO67R4Af/UJA/HXPPZJXsv/i0C+JCJt WvFb5usHn4kikDr7qBTeZTd8euSa6z/AAdypoWPvQAyPMOD9kLD77D7f2URKgepo MvyAxHUYJTGWJToXmnD533vySwariHVtJFNyiokUWZ7oL5IbYhltLibVqTXL38dB SD8hXw1AHAi4gZ18pvuBOHpFxBx/WmcS4DYV/NXcPZQcwJr9SAALdkzG8JO+FnnW FTzdJ06BpEybt4r9WOrCkK2wpaaeMZeN25ddVhRxbySNKOwgvNuuTYgGH187U16s ZSRDqJbU2gF4fWaPKjWoK85RjjP9pSU+E+9tJs5girTbsczKhfmd2MyLk7c+oAh8 DwIDAQABoAAwDQYJKoZIhvcNAQELBQADggIBAHDaCo8g0EeISZ7yixwLwhXPlGXx naghda2wPeWoO9Dm4lWV03KARFovalAmhFOM/AOMNn0zRrlEW8BVqF9VWMrU3z7r FyzBtqbXNxqw5EEpMem9OlCd7h7VValz2RxVfJuSoC5TV99Hi4P2crQE16rTn17A NtDyLI2c8bH1sbOUlCCOY08hSP6m24h/fJe4LMDkzSQjo8fargcphVFrCFca3o/H WMwzt6iK+4avSo6oznbYVVWKmxdi5k9Iwcehg6NQP5cuW6TMEU3G9L/gHNLJgkxr 9DGjlKCgHNtOJpjDvAzYqFwrlF03EFzQbKfX7GLM2DJKlNIcSoAi52Q5j+Km+HhX a5Jf7C9SVHrZgagI4mzcZeW+abG6j/9HJz5zsDWGKpek30nyhXCRTtcs4coyLLo7 pOdWgf1QZIPnATO4jS3HI5eTD89LB0aAgRoKkDG16TBRhM/2hGlEwex927Z+kkBJ 2U0ATYzNpcCjGlS4lNcIvdeBwHQlUTKrG+nas8MpygDC2zRQuC6XNHtO+YXCc+Ba v7fFYy6F9ccSUho06y7zbZBhaexL/EZVjk6DmdpZ37WKd/LN1pqftPW1SKwafzGy zu4ajILL48bLxNLDWZax+O3gVRbdABjBPzpgACFfx2JomnqeP82dtzV1yVtQ/jd8 DfZR/2pQNpYHjjsZ -----END CERTIFICATE REQUEST-----
Bei Interesse können wir uns unseren CSR auch ansehen, dazu benutzen wir folgenden Befehl:
# openssl req -noout -text -in openldap.dmz.nausch.org.csr.pem
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=DE, ST=Bayern, L=Pliening, O=nausch.org, OU=IT-Services, CN=openldap.dmz.nausch.org/emailAddress=dbmaster@nausch.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:c5:1d:b1:f2:8f:22:9a:f7:31:ad:20:a5:32:5d:
21:d2:85:27:d5:a3:a1:ce:ed:44:ee:43:eb:b5:a0:
5e:6e:13:c7:07:75:ef:02:b9:d4:19:02:b1:73:dc:
ee:d3:47:1d:34:df:10:9d:7b:50:f7:ea:81:ee:1b:
1f:99:07:f9:57:e0:e1:d0:1b:0c:6d:31:0e:d7:09:
89:b4:34:93:87:5b:64:48:9d:4c:44:f8:d4:8a:9d:
da:6e:b1:80:63:80:7c:43:a9:66:64:94:03:60:30:
9f:81:81:28:51:e3:83:74:73:67:a6:06:9f:a0:93:
09:36:82:1a:24:6c:45:68:86:ab:42:81:93:89:57:
9a:f7:c0:cb:ef:dd:00:15:d6:c0:c9:50:b2:e7:cc:
c2:f3:71:62:9e:df:cb:fd:4a:ed:93:22:49:f4:6c:
c8:cb:aa:31:63:8e:f9:ed:d8:71:46:ae:65:58:6a:
84:a9:5c:1f:60:16:8b:cf:95:ea:3e:30:a7:61:bb:
d9:fb:ae:c4:ea:59:91:4d:af:25:c3:4a:1f:7b:07:
62:3f:46:a7:e6:7b:54:79:b3:80:39:73:ed:8d:34:
7f:dd:cc:e9:55:67:0b:dd:51:84:30:70:81:0c:c6:
0c:c3:51:4d:22:f2:12:73:85:c3:ba:ed:1e:00:7f:
f5:09:03:f1:d7:3c:f6:49:5e:cb:ff:8b:40:be:24:
22:6d:5a:f1:5b:e6:eb:07:9f:89:22:90:3a:fb:a8:
14:de:65:37:7c:7a:e4:9a:eb:3f:c0:01:dc:a9:a1:
63:ef:40:0c:8f:30:e0:fd:90:b0:fb:ec:3e:df:d9:
44:4a:81:ea:68:32:fc:80:c4:75:18:25:31:96:25:
3a:17:9a:70:f9:df:7b:f2:4b:06:ab:88:75:6d:24:
53:72:8a:89:14:59:9e:e8:2f:92:1b:62:19:6d:2e:
26:d5:a9:35:cb:df:c7:41:48:3f:21:5f:0d:40:1c:
08:b8:81:9d:7c:a6:fb:81:38:7a:45:c4:1c:7f:5a:
67:12:e0:36:15:fc:d5:dc:3d:94:1c:c0:9a:fd:48:
00:0b:76:4c:c6:f0:93:be:16:79:d6:15:3c:dd:27:
4e:81:a4:4c:9b:b7:8a:fd:58:ea:c2:90:ad:b0:a5:
a6:9e:31:97:8d:db:97:5d:56:14:71:6f:24:8d:28:
ec:20:bc:db:ae:4d:88:06:1f:5f:3b:53:5e:ac:65:
24:43:a8:96:d4:da:01:78:7d:66:8f:2a:35:a8:2b:
ce:51:8e:33:fd:a5:25:3e:13:ef:6d:26:ce:60:8a:
b4:db:b1:cc:ca:85:f9:9d:d8:cc:8b:93:b7:3e:a0:
08:7c:0f
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
70:da:0a:8f:20:d0:47:88:49:9e:f2:8b:1c:0b:c2:15:cf:94:
65:f1:9d:a8:21:75:ad:b0:3d:e5:a8:3b:d0:e6:e2:55:95:d3:
72:80:44:5a:2f:6a:50:26:84:53:8c:fc:03:8c:36:7d:33:46:
b9:44:5b:c0:55:a8:5f:55:58:ca:d4:df:3e:eb:17:2c:c1:b6:
a6:d7:37:1a:b0:e4:41:29:31:e9:bd:3a:50:9d:ee:1e:d5:55:
a9:73:d9:1c:55:7c:9b:92:a0:2e:53:57:df:47:8b:83:f6:72:
b4:04:d7:aa:d3:9f:5e:c0:36:d0:f2:2c:8d:9c:f1:b1:f5:b1:
b3:94:94:20:8e:63:4f:21:48:fe:a6:db:88:7f:7c:97:b8:2c:
c0:e4:cd:24:23:a3:c7:da:ae:07:29:85:51:6b:08:57:1a:de:
8f:c7:58:cc:33:b7:a8:8a:fb:86:af:4a:8e:a8:ce:76:d8:55:
55:8a:9b:17:62:e6:4f:48:c1:c7:a1:83:a3:50:3f:97:2e:5b:
a4:cc:11:4d:c6:f4:bf:e0:1c:d2:c9:82:4c:6b:f4:31:a3:94:
a0:a0:1c:db:4e:26:98:c3:bc:0c:d8:a8:5c:2b:94:5d:37:10:
5c:d0:6c:a7:d7:ec:62:cc:d8:32:4a:94:d2:1c:4a:80:22:e7:
64:39:8f:e2:a6:f8:78:57:6b:92:5f:ec:2f:52:54:7a:d9:81:
a8:08:e2:6c:dc:65:e5:be:69:b1:ba:8f:ff:47:27:3e:73:b0:
35:86:2a:97:a4:df:49:f2:85:70:91:4e:d7:2c:e1:ca:32:2c:
ba:3b:a4:e7:56:81:fd:50:64:83:e7:01:33:b8:8d:2d:c7:23:
97:93:0f:cf:4b:07:46:80:81:1a:0a:90:31:b5:e9:30:51:84:
cf:f6:84:69:44:c1:ec:7d:db:b6:7e:92:40:49:d9:4d:00:4d:
8c:cd:a5:c0:a3:1a:54:b8:94:d7:08:bd:d7:81:c0:74:25:51:
32:ab:1b:e9:da:b3:c3:29:ca:00:c2:db:34:50:b8:2e:97:34:
7b:4e:f9:85:c2:73:e0:5a:bf:b7:c5:63:2e:85:f5:c7:12:52:
1a:34:eb:2e:f3:6d:90:61:69:ec:4b:fc:46:55:8e:4e:83:99:
da:59:df:b5:8a:77:f2:cd:d6:9a:9f:b4:f5:b5:48:ac:1a:7f:
31:b2:ce:ee:1a:8c:82:cb:e3:c6:cb:c4:d2:c3:59:96:b1:f8:
ed:e0:55:16:dd:00:18:c1:3f:3a:60:00:21:5f:c7:62:68:9a:
7a:9e:3f:cd:9d:b7:35:75:c9:5b:50:fe:37:7c:0d:f6:51:ff:
6a:50:36:96:07:8e:3b:19
Diesen CSR kippen wir nun entweder bei der hauseigenen CA ein oder entsprechend bei einer kommerziellen CA.
eigene CA: CSR beabeiten - Zertifikat erstellen
Kommen wir zum krönenden Abschluss - wir signieren nun das Server-Zertifikat durch unsere CA, oder anders ausgedrückt, wir erstellen das benötigte X.509-Serverzertifikat.
Wie schon bereits bei den anderen Konfigurationsbeispielen, sind auch hier die Eingaben in der Farbe blau und die Rückmeldungen in der Farbe grün gekennzeichnet.
# openssl ca -in csr.pem -notext -out servercert.pem
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem: des-woas-blos-I-und-sundst-koana
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 0 (0x0)
Validity
Not Before: Jul 15 13:42:21 2015 GMT
Not After : Jul 14 13:42:20 2017 GMT
Subject:
countryName = DE
stateOrProvinceName = Bayern
organizationName = nausch.org
organizationalUnitName = IT-services
commonName = openldap.dmz.nausch.org
emailAddress = dbmaster@nausch.org
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
43:98:32:9B:BA:65:AD:14:08:67:FB:B0:B1:BD:BD:57:A8:B4:3D:C9
X509v3 Authority Key Identifier:
keyid:19:F5:FD:B1:D1:98:4B:E3:E8:26:CD:55:CB:14:08:19:67:9E:78:16
Certificate is to be certified until Oct 19 13:23:33 2016 GMT (730 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
fremde CA: CSR hochladen - Zertifikat erstellen
Nutzen wir eine fremde oder kommerzielle CA, müssen wir unseren CSR meist in einem WEB-Formular einfügen oder hochladen.
Server-Zertifikat
Als Ergebnis erhalten wir dann von unserer eigenen CA bzw. von der fremden CA unseres Vertrauns unser Serverzertifikat im gewünschten Format zurück.
-----BEGIN CERTIFICATE----- MIIGBzCCA++gAwIBAgIDAm8BMA0GCSqGSIb3DQEBDQUAMFQxFDASBgNVBAoTC0NB Y2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNV BAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcNMTUwNzE1MTgzOTUxWhcNMTcwNzE0 MTgzOTUxWjAiMSAwHgYDVQQDExdvcGVubGRhcC5kbXoubmF1c2NoLm9yZzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMUdsfKPIpr3Ma0gpTJdIdKFJ9Wj oc7tRO5D67WgXm4Txwd17wK51BkCsXPc7tNHHTTfEJ17UPfqge4bH5kH+Vfg4dAb DG0xDtcJibQ0k4dbZEidTET41Iqd2m6xgGOAfEOpZmSUA2Awn4GBKFHjg3RzZ6YG n6CTCTaCGiRsRWiGq0KBk4lXmvfAy+/dABXWwMlQsufMwvNxYp7fy/1K7ZMiSfRs yMuqMWOO+e3YcUauZVhqhKlcH2AWi8+V6j4wp2G72fuuxOpZkU2vJcNKH3sHYj9G p+Z7VHmzgDlz7Y00f93M6VVnC91RhDBwgQzGDMNRTSLyEnOFw7rtHgB/9QkD8dc8 9kley/+LQL4kIm1a8Vvm6wefiSKQOvuoFN5lN3x65JrrP8AB3KmhY+9ADI8w4P2Q sPvsPt/ZREqB6mgy/IDEdRglMZYlOheacPnfe/JLBquIdW0kU3KKiRRZnugvkhti GW0uJtWpNcvfx0FIPyFfDUAcCLiBnXym+4E4ekXEHH9aZxLgNhX81dw9lBzAmv1I AAt2TMbwk74WedYVPN0nToGkTJu3iv1Y6sKQrbClpp4xl43bl11WFHFvJI0o7CC8 265NiAYfXztTXqxlJEOoltTaAXh9Zo8qNagrzlGOM/2lJT4T720mzmCKtNuxzMqF +Z3YzIuTtz6gCHwPAgMBAAGjggESMIIBDjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB /wQEAwIDqDA0BgNVHSUELTArBggrBgEFBQcDAgYIKwYBBQUHAwEGCWCGSAGG+EIE AQYKKwYBBAGCNwoDAzAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmNhY2VydC5vcmcvMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwu Y2FjZXJ0Lm9yZy9jbGFzczMtcmV2b2tlLmNybDBJBgNVHREEQjBAghdvcGVubGRh cC5kbXoubmF1c2NoLm9yZ6AlBggrBgEFBQcIBaAZDBdvcGVubGRhcC5kbXoubmF1 c2NoLm9yZzANBgkqhkiG9w0BAQ0FAAOCAgEAQpFKrP2/1/iGFUyC6Sjz4JPI93xN qoWhRMZM/SkpwarzBMwsGQ6yKHEoim9Zo4owb38q4yurlUgMcJ2XtNoB0uZK/jZQ dVJysG+VbCh9YD5poHRVPMC5zAHWQ13m4BhaOcSXu1Vvh7lb/BcbIA2hlnuRtoOR eyY28nTD1fLjTMfp6PbYFTK+asxq0TPqrP9j0qSy1M+0SQnLvlLkr1/bPWDeGH9k L5c7FlTQAYE0q6sTdpAPNX2icGHECtylCohlnpNoLCchboH9y9s7FtPzMbDENWvA FM1gooanqbo66adN7psnw2gXJbDLShaIwgjRzM8+82I4nXVO5CcD3FWqQIPwYpec Rqk/iSB7UobY5h0/R1oQSCqrpGdMwXq7dwGMvyWlxWDikQrR2ptDWO9HENrUpwCN LBvmGZedITZ3+NqmJTbSp3R4bEYESmznNUdD8BnBvg3alkzjb6Cinnb30TJtehbQ yBaEhzq8KsOZpzcLT7ldN3Y6dxu8qj+p67nGD+A8brrII1s4TIcnEvnPBCWuku/r a5iSsSt3US1dOocFJM3CJyuaNfWIqDbutE702fREPriNPxqRSdTkH5Ub4Rb4CiRW bHHSqh0QekUMpNi6n7+thG46EKJk1WgeNhhsqRKqy5MDLth7iN5gHE2CCbSIe4qW g2KkrggW2eBNzv42= -----END CERTIFICATE-----
Dieses Zertifikat legen wir dann am einfachsten im Verzeichnis /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate_150104.pem ab.
# vim /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate_150104.pem
-----BEGIN CERTIFICATE----- MIIGBzCCA++gAwIBAgIDAm8BMA0GCSqGSIb3DQEBDQUAMFQxFDASBgNVBAoTC0NB Y2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNV BAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcNMTUwNzE1MTgzOTUxWhcNMTcwNzE0 MTgzOTUxWjAiMSAwHgYDVQQDExdvcGVubGRhcC5kbXoubmF1c2NoLm9yZzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMUdsfKPIpr3Ma0gpTJdIdKFJ9Wj oc7tRO5D67WgXm4Txwd17wK51BkCsXPc7tNHHTTfEJ17UPfqge4bH5kH+Vfg4dAb DG0xDtcJibQ0k4dbZEidTET41Iqd2m6xgGOAfEOpZmSUA2Awn4GBKFHjg3RzZ6YG n6CTCTaCGiRsRWiGq0KBk4lXmvfAy+/dABXWwMlQsufMwvNxYp7fy/1K7ZMiSfRs yMuqMWOO+e3YcUauZVhqhKlcH2AWi8+V6j4wp2G72fuuxOpZkU2vJcNKH3sHYj9G p+Z7VHmzgDlz7Y00f93M6VVnC91RhDBwgQzGDMNRTSLyEnOFw7rtHgB/9QkD8dc8 9kley/+LQL4kIm1a8Vvm6wefiSKQOvuoFN5lN3x65JrrP8AB3KmhY+9ADI8w4P2Q sPvsPt/ZREqB6mgy/IDEdRglMZYlOheacPnfe/JLBquIdW0kU3KKiRRZnugvkhti GW0uJtWpNcvfx0FIPyFfDUAcCLiBnXym+4E4ekXEHH9aZxLgNhX81dw9lBzAmv1I AAt2TMbwk74WedYVPN0nToGkTJu3iv1Y6sKQrbClpp4xl43bl11WFHFvJI0o7CC8 265NiAYfXztTXqxlJEOoltTaAXh9Zo8qNagrzlGOM/2lJT4T720mzmCKtNuxzMqF +Z3YzIuTtz6gCHwPAgMBAAGjggESMIIBDjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB /wQEAwIDqDA0BgNVHSUELTArBggrBgEFBQcDAgYIKwYBBQUHAwEGCWCGSAGG+EIE AQYKKwYBBAGCNwoDAzAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmNhY2VydC5vcmcvMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwu Y2FjZXJ0Lm9yZy9jbGFzczMtcmV2b2tlLmNybDBJBgNVHREEQjBAghdvcGVubGRh cC5kbXoubmF1c2NoLm9yZ6AlBggrBgEFBQcIBaAZDBdvcGVubGRhcC5kbXoubmF1 c2NoLm9yZzANBgkqhkiG9w0BAQ0FAAOCAgEAQpFKrP2/1/iGFUyC6Sjz4JPI93xN qoWhRMZM/SkpwarzBMwsGQ6yKHEoim9Zo4owb38q4yurlUgMcJ2XtNoB0uZK/jZQ dVJysG+VbCh9YD5poHRVPMC5zAHWQ13m4BhaOcSXu1Vvh7lb/BcbIA2hlnuRtoOR eyY28nTD1fLjTMfp6PbYFTK+asxq0TPqrP9j0qSy1M+0SQnLvlLkr1/bPWDeGH9k L5c7FlTQAYE0q6sTdpAPNX2icGHECtylCohlnpNoLCchboH9y9s7FtPzMbDENWvA FM1gooanqbo66adN7psnw2gXJbDLShaIwgjRzM8+82I4nXVO5CcD3FWqQIPwYpec Rqk/iSB7UobY5h0/R1oQSCqrpGdMwXq7dwGMvyWlxWDikQrR2ptDWO9HENrUpwCN LBvmGZedITZ3+NqmJTbSp3R4bEYESmznNUdD8BnBvg3alkzjb6Cinnb30TJtehbQ yBaEhzq8KsOZpzcLT7ldN3Y6dxu8qj+p67nGD+A8brrII1s4TIcnEvnPBCWuku/r a5iSsSt3US1dOocFJM3CJyuaNfWIqDbutE702fREPriNPxqRSdTkH5Ub4Rb4CiRW bHHSqh0QekUMpNi6n7+thG46EKJk1WgeNhhsqRKqy5MDLth7iN5gHE2CCbSIe4qW g2KkrggW2eBNzv42= -----END CERTIFICATE-----
CA Trust
Zertifizierungspfad beim SSL Zertificate (trusted chain)
Bei der asymmetrischen Verschlüsselung, wie sie bei SSL/TLS gesicherter Kommunikation zum Einsatz kommt, benötigt der sendende Kommunikationspartner den öffentlichen Schlüssel (public key) des Empfängers. Bei dieser Kommunikation ist es äußerst wichtig, dass die Echtheit des Schlüssels gewährleistet, sprich auch überprüft werden kann. Diese Überprüfung erfolgt mit digitalen Zertifikaten, die die Echtheit eines öffentlichen Schlüssels sowie den Geltungsbereich und die Anwendungsbereich für das Zertifikat bestätigen.
Bei einer reinen 1:1 Kommunikation können sich beide Kommunikationspartner, oder der Client mit dem Server dieses Vertrauen selbst gegenseitig aussprechen. In den allermeisten Fällen wird es aber bei der verschlüsselten und vertraulichen Kommunikation um eine 1:n Kommunikation handeln; d.h. ein Server wird mit unter sehr vielen Clients Daten austauschen. Eine gegenseitige Vertrauensbildung ist hier in den allermeisten Fällen nicht realistisch und praktikabel durchführbar.
Für die Überprüfung der Echtheit der zur Verschlüsselung verwendeten X.509-Zertifikates wird wiederum ein digitales Zertifikat einer CA11) oder kurz Zertifizierungsstelle verwendet. Diese CA bestätigt somit die Echtheit des Zertifikates. Eine Zertifikat (Root Zertifikat) einer CA selbst kann wiederum durch eine weitere CA beglaubigt worden sein. Somit ergibt sich eine Kette von Zertifikaten, bei der jedes Zertifikat mit dem Zertifikat der übergeordneten Stelle authentifiziert werden kann. Diese Vertrauenskette wird auch Zertifizierungspfad oder trusted chain bezeichnet.
Die nachfolgende Graphik zeigt den Zertifizierungspfad eines Zertifikats mit dem CN12) dokuwiki.nausch.org.
Der Publickey in dem Zertifikat dokuwiki.nausch.org wurde mit dem Zertifikat CAcert Class 3 Root unterschrieben. Der Publickey dieses Root-Zertifikates CAcert Class 3 Root wurde wiederum mit dem Root-Zertifikat CA Cert Signing Authority unterschrieben.
Damit ein Client die Vertrauenskette (trusted chain) überprüfen kann, muss der Server diese beim TLS-Verbindungshandshake mit ausliefern! Normaler Weise wird die ausstellende CA von sich aus immer die benötigten Zwischen- und Root-Zertifikate der (Sub)CAs zur Verfügung stellen. Nutzt man einen sehr preisgünstigen Anbieter von Zertifikaten kann, die Suche nach den richtigen und passenden Zertifikaten zuweilen doch recht aufwändig werden.
Wir werden nun darauf eingehen, wie wir die trusted chain ermitteln, die Zertifikate besorgen und überprüfen können.
Im folgenden Beispiel orientieren wir uns am vorliegendem Zertifikat des Mailservers mx1.nausch.org. Das Zertifikat haben wir von der CA unseres Vertrauens erhalten.
- Als erstes ermitteln wir, wer genau unser Zertifikat unterschrieben hat.
# openssl x509 -subject -issuer -noout -in mx1.nausch.org.servercert.pem
subject= /serialNumber=3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP/OU=GT49447951/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.nausch.org issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Der CN bei der Zeile issuer beschreibt nun das Zertifikat, mit dem unser Serverzertifikat unterschrieben wurde.
- Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat RapidSSL_CA.pem auf unseren Rechner.
- Auch bei diesem Root-Zertifikat RapidSSL_CA.pem ermitteln wir nun den issuer.
# openssl x509 -subject -issuer -noout -in RapidSSL_CA.pem
subject= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Das Root Zertifikat der RapidSSL CA wurde also mit dem Root-Zertifikat der GeoTrust Global CA signiert.
- Wir benötigen also ein weiteres Root-Zertifikat. Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat GeoTrust_Global_CA.pem auf unseren Rechner.
- Nun können wir ermitteln, wer dieses Zertifikat unterschrieben hat.
# openssl x509 -subject -issuer -noout -in GeoTrust_Global_CA.pem
subject= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Das Root Zertifikat der GeoTrust Global CA wurde also mit dem Root-Zertifikat der Equifax Secure Certificate Authority unterschrieben.
- Wir werden uns also auch dieses Root-Zertifikat besorgen müssen. Erneiut gehen wir auf die Suche nach dem Root-Zertifikat und laden uns das betreffende Zertifikat Equifax_Secure_Certificate_Authority.pem auf unseren Rechner.
- Auch hier überprüfen wir nun, wer dieses Zertifikat nun unterschrieben hat.
# openssl x509 -subject -issuer -noout -in Equifax_Secure_Certificate_Authority.pem
subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Hier sehen wir nun, dass das subject und der issuer identisch sind, das Zertifikat wurde also selbst signiert (self signed certificate). Wir haben hier also das Wurzelzertifikat unserer Zertifizierungskette.
Somit ergibt sich für unser Zertifikat folgende komplette Zertifizierungskette.
── (1) Equifax Secure Certificate Authority │ └── (2) GeoTrust Global CA │ └── (3) RapidSSL CA │ └── (4) mx1.nausch.org.servercert.pemAus Interoperabilitätsgründen sollte vom Server immer die komplette Zertifikatskette zur Verfügung gestellt werden!
- Wir erstellen uns nun eine Datei in der die Root-Zertifikaten vom Serverzertifikat beginnend zum ersten Rootzertifikat beinhaltet, also in unserem Beispiel in der Reihenfolge (3) → (2) → (1).
# cat RapidSSL_CA.pem GeoTrust_Global_CA.pem Equifax_Secure_Certificate_Authority.pem > rapid_geotrust_equifax_bundle.pem
- Zum Schluss überprüfen wir noch ob nun alle benötigten Zertifikate in der richtigen Reihenfolge vorliegen.
# openssl verify -verbose -purpose sslserver -CAfile rapid_geotrust_equifax_bundle.pem mx1.nausch.org.servercert.pem
mx01.nausch.org.servercert.pem: OK
Wir haben also bei diesem Konfigurationsbeispiel nun neben unserem Zertifikat mx1.nausch.org.servercert.pem die zugehörige Zertifikatskette rapid_geotrust_equifax_bundle.pem vorliegen!
LDAPs konfigurieren
Viele wertvolle Informationen zur TLS-Konfiguration finden sich im Kapitel 16. Using TLS des OpenLDAP Software 2.4 Administrator's Guide zu finden.
slapd
Damit unser OpenLDAP-Server zukünftig LDAPS auf Port 636 zur Verfügung stellen kann, bearbeiten wir nun die systemweite Konfigurationsdatei /etc/sysconfig/slapd.
# vim /etc/sysconfig/slapd
- /etc/sysconfig/slapd
# OpenLDAP server configuration # see 'man slapd' for additional information # Where the server will run (-h option) # - ldapi:/// is required for on-the-fly configuration using client tools # (use SASL with EXTERNAL mechanism for authentication) # - default: ldapi:/// ldap:/// # - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:/// # Django : 2015-07-15 - LDAPs Konfiguration für Port 636 # default: SLAPD_URLS="ldapi:/// ldap:///" SLAPD_URLS="ldapi:/// ldap:/// ldaps:///" # Any custom options #SLAPD_OPTIONS="" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
Nähere Informationen zu den möglichen Parametern entnehmen wir der zugehörigen Manpage.
# man slapd
SLAPD(8C) SLAPD(8C)
NAME
slapd - Stand-alone LDAP Daemon
SYNOPSIS
slapd [-4|-6] [-T {acl|a[dd]|auth|c[at]| d[n]|i[ndex]|p[asswd]|s[chema]|t[est]}]
[-d debug-level] [-f slapd-config-file] [-F slapd-config-directory] [-h URLs]
[-n service-name] [-s syslog-level] [-l syslog-local-user] [-o option[=value]]
[-r directory] [-u user] [-g group] [-c cookie]
DESCRIPTION
Slapd is the stand-alone LDAP daemon. It listens for LDAP connections on any number
of ports (default 389), responding to the LDAP operations it receives over these
connections. slapd is typically invoked at boot time, usually out of /etc/rc.local.
Upon startup, slapd normally forks and disassociates itself from the invoking tty.
If configured in the config file (or config directory), the slapd process will print
its process ID (see getpid(2)) to a .pid file, as well as the command line options
during invocation to an .args file (see slapd.conf(5)). If the -d flag is given,
even with a zero argument, slapd will not fork and disassociate from the invoking
tty.
See the "OpenLDAP Administrator's Guide" for more details on slapd.
OPTIONS
-4 Listen on IPv4 addresses only.
-6 Listen on IPv6 addresses only.
-T tool
Run in Tool mode. The tool argument selects whether to run as slapadd, slap‐
cat, slapdn, slapindex, slappasswd, slapschema, or slaptest (slapacl and sla‐
pauth need the entire acl and auth option value to be spelled out, as a is
reserved to slapadd). This option should be the first option specified when
it is used; any remaining options will be interpreted by the corresponding
slap tool program, according to the respective man pages. Note that these
tool programs will usually be symbolic links to slapd. This option is pro‐
vided for situations where symbolic links are not provided or not usable.
-d debug-level
Turn on debugging as defined by debug-level. If this option is specified,
even with a zero argument, slapd will not fork or disassociate from the
invoking terminal. Some general operation and status messages are printed
for any value of debug-level. debug-level is taken as a bit string, with
each bit corresponding to a different kind of debugging information. See
<ldap_log.h> for details. Comma-separated arrays of friendly names can be
specified to select debugging output of the corresponding debugging informa‐
tion. All the names recognized by the loglevel directive described in
slapd.conf(5) are supported. If debug-level is ?, a list of installed debug-
levels is printed, and slapd exits.
Remember that if you turn on packet logging, packets containing bind pass‐
words will be output, so if you redirect the log to a logfile, that file
should be read-protected.
-s syslog-level
This option tells slapd at what debug-level debugging statements should be
logged to the syslog(8) facility. The value syslog-level can be set to any
value or combination allowed by the -d switch. Slapd logs all messages
selected by syslog-leveli at the syslog(3) severity debug-level DEBUG, on the
unit specified with -l.
-n service-name
Specifies the service name for logging and other purposes. Defaults to base‐
name of argv[0], i.e.: "slapd".
-l syslog-local-user
Selects the local user of the syslog(8) facility. Value can be LOCAL0,
through LOCAL7, as well as USER and DAEMON. The default is LOCAL4. However,
this option is only permitted on systems that support local users with the
syslog(8) facility. Logging to syslog(8) occurs at the "DEBUG" severity
debug-level.
-f slapd-config-file
Specifies the slapd configuration file. The default is /etc/openl‐
dap/slapd.conf.
-F slapd-config-directory
Specifies the slapd configuration directory. The default is /etc/openl‐
dap/slapd.d. If both -f and -F are specified, the config file will be read
and converted to config directory format and written to the specified direc‐
tory. If neither option is specified, slapd will attempt to read the default
config directory before trying to use the default config file. If a valid
config directory exists then the default config file is ignored. All of the
slap tools that use the config options observe this same behavior.
-h URLlist
slapd will by default serve ldap:/// (LDAP over TCP on all interfaces on
default LDAP port). That is, it will bind using INADDR_ANY and port 389.
The -h option may be used to specify LDAP (and other scheme) URLs to serve.
For example, if slapd is given -h "ldap://127.0.0.1:9009/ ldaps:///
ldapi:///", it will listen on 127.0.0.1:9009 for LDAP, 0.0.0.0:636 for LDAP
over TLS, and LDAP over IPC (Unix domain sockets). Host 0.0.0.0 represents
INADDR_ANY (any interface). A space separated list of URLs is expected. The
URLs should be of the LDAP, LDAPS, or LDAPI schemes, and generally without a
DN or other optional parameters (excepting as discussed below). Support for
the latter two schemes depends on selected configuration options. Hosts may
be specified by name or IPv4 and IPv6 address formats. Ports, if specified,
must be numeric. The default ldap:// port is 389 and the default ldaps://
port is 636.
For LDAP over IPC, name is the name of the socket, and no port is required,
nor allowed; note that directory separators must be URL-encoded, like any
other characters that are special to URLs; so the socket
/usr/local/var/ldapi
must be specified as
ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi
The default location for the IPC socket is /var/run/ldapi
The listener permissions are indicated by "x-mod=-rwxrwxrwx", "x-mod=0777" or
"x-mod=777", where any of the "rwx" can be "-" to suppress the related per‐
mission, while any of the "7" can be any legal octal digit, according to
chmod(1). The listeners can take advantage of the "x-mod" extension to apply
rough limitations to operations, e.g. allow read operations ("r", which
applies to search and compare), write operations ("w", which applies to add,
delete, modify and modrdn), and execute operations ("x", which means bind is
required). "User" permissions apply to authenticated users, while "other"
apply to anonymous users; "group" permissions are ignored. For example,
"ldap:///????x-mod=-rw-------" means that read and write is only allowed for
authenticated connections, and bind is required for all operations. This
feature is experimental, and requires to be manually enabled at configure
time.
-r directory
Specifies a directory to become the root directory. slapd will change the
current working directory to this directory and then chroot(2) to this direc‐
tory. This is done after opening listeners but before reading any configura‐
tion file or initializing any backend. When used as a security mechanism, it
should be used in conjunction with -u and -g options.
-u user
slapd will run slapd with the specified user name or id, and that user's sup‐
plementary group access list as set with initgroups(3). The group ID is also
changed to this user's gid, unless the -g option is used to override. Note
when used with -r, slapd will use the user database in the change root envi‐
ronment.
Note that on some systems, running as a non-privileged user will prevent
passwd back-ends from accessing the encrypted passwords. Note also that any
shell back-ends will run as the specified non-privileged user.
-g group
slapd will run with the specified group name or id. Note when used with -r,
slapd will use the group database in the change root environment.
-c cookie
This option provides a cookie for the syncrepl replication consumer. The
cookie is a comma separated list of name=value pairs. Currently supported
syncrepl cookie fields are rid, sid, and csn. rid identifies a replication
thread within the consumer server and is used to find the syncrepl specifica‐
tion in slapd.conf(5) or slapd-config(5) having the matching replication
identifier in its definition. The rid must be provided in order for any other
specified values to be used. sid is the server id in a multi-master/mirror-
mode configuration. csn is the commit sequence number received by a previous
synchronization and represents the state of the consumer replica content
which the syncrepl engine will synchronize to the current provider content.
In case of mirror-mode or multi-master replication agreement, multiple csn
values, semicolon separated, can appear. Use only the rid part to force a
full reload.
-o option[=value]
This option provides a generic means to specify options without the need to
reserve a separate letter for them.
It supports the following options:
slp={on|off|slp-attrs}
When SLP support is compiled into slapd, disable it (off),
enable it by registering at SLP DAs without specific SLP attributes
(on), or with specific SLP attributes slp-attrs that must be an SLP
attribute list definition according to the SLP standard.
For example, "slp=(tree=production),(server-type=OpenL‐
DAP),(server-version=2.4.15)" registers at SLP DAs with the three SLP
attributes tree, server-type and server-version that have the values
given above. This allows to specifically query the SLP DAs for LDAP
servers holding the production tree in case multiple trees are avail‐
able.
EXAMPLES
To start slapd and have it fork and detach from the terminal and start serving the
LDAP databases defined in the default config file, just type:
slapd
To start slapd with an alternate configuration file, and turn on voluminous debug‐
ging which will be printed on standard error, type:
slapd -f /var/tmp/slapd.conf -d 255
To test whether the configuration file is correct or not, type:
slapd -Tt
SEE ALSO
ldap(3), slapd.conf(5), slapd-config(5), slapd.access(5), slapacl(8), slapadd(8),
slapauth(8), slapcat(8), slapdn(8), slapindex(8), slappasswd(8), slapschema(8),
slaptest(8).
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
BUGS
See http://www.openldap.org/its/
ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project
<http://www.openldap.org/>. OpenLDAP Software is derived from University of Michi‐
gan LDAP 3.3 Release.
OpenLDAP 2.4.39 2014/01/26 SLAPD(8C)
ldap.conf
Wollen wir von unserem Server aus, mittels ldapsearch muss natürlich der Client auch wissen, wie er das bzw. die Zertifikate auf das Vertrauen hin prüfen soll.
Wir werden daher in der Konfigurationsdatei des LDAP-Clients vermerken, dass die im Abschnitt CA Trust Vertrauensmodelle in Public-Key-Infrastrukturen erstellte Datei mit den vertrauenswürdigen Root-Zertifikaten verwenden soll.
# 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-14 BASE dc=nausch, dc=org # Definition des standardmäßig abgefragten Teilbaums / Searchbase # Anfragen werden unterhalb von dc=nausch, dc=org ausgeführt. URI ldap://openldap.dmz.nausch.org # Definition des LDAP-Servers #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # Django : 2015-07-16 # default: TLS_CACERTDIR /etc/openldap/certs TLS_CACERTDIR /etc/pki/tls/certs/CAcert_chain.pem # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on
LDAPs-Konfiguration via LDIF
(TLS-)Zertifikate und Schlüssel
Wie schon bei der Grundkonfiguration unseres OpenLDAP-Servers, erfolgt die eigentliche Konfiguration an Hand von einzelnen ldif-Dateien aus dem Verzeichnis /etc/openldap/ldif/.
Folgende Parameter werden wir unserem OpenLDAP-Server über eine passende LDIF-Datei bekannt geben.
- olcTLSCipherSuite:
Definition der Verschlüsselungsstärke bzw. der Verschlüsselungsmechanismen - olcTLSCertificateFile:
Die zuvor generierte Zertifikatsdatei /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate.pem - olcTLSCertificateKeyFile:
Der zum Zertifikat gehörende private Serverkey /etc/pki/tls/private/openldap_serverkey.pem - olcTLSCACertificateFile:
Das ROOT-Zertifikat bzw. die Zertifikatschain der verwendeten Certificate Authority (CA)
Zur Definition unserer TLS-Konfiguration legen wir uns nun eine passende zugehörige Datei an.
# vim /etc/openldap/ldif/cn\=config_TLS.ldif
- /etc/openldap/ldif/cn=config_TLS.ldif
# Django : 2015-07-15 # TLS-Konfiguration unseres OpenLDAP-Servers. # https://dokuwiki.nausch.org/doku.php/centos:ldap_c7:ldaps?&#tls_konfigurieren_via_ldif dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: HIGH - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/pki/tls/private/openldap_serverkey.pem - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/pki/tls/certs/CAcert_chain.pem
Die Konfigurationsänderungen aktivieren wir wieder wie gehabt mit Aufruf des Befehls ldapmodify.
# ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/openldap/ldif/cn\=config_TLS.ldif
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config"
Ob unsere Änderungen entsprechend unserer ldif-Datei angelegt und geändert wurden, können wir wie folgt überprüfen.
# ldapsearch -W -x -D cn=config -b cn=config "(objectclass=olcGlobal)"
Enter LDAP Password:
# extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: (objectclass=olcGlobal) # requesting: ALL # # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs olcReferral: ldap://openldap.dmz.nausch.org olcIdleTimeout: 30 olcTLSCipherSuite: HIGH olcTLSCertificateFile: /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate.pem olcTLSCertificateKeyFile: /etc/pki/tls/private/openldap_serverkey.pem olcTLSCACertificateFile: /etc/pki/tls/certs/CAcert_chain.pem # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
Damit unser OpenLDAP-Daemon slapd den TCP-Port 636 (LDAP over SSL) binden kann, müssen wir diesen einmal durchstarten.
# systemctl restart slapd.service
Den erfolgreichen restart können wir bei Bedarf natürlich auch abfragen.
# systemctl status slapd.service
slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled)
Active: active (running) since Wed 2015-07-15 22:51:49 CEST; 54s ago
Docs: man:slapd
man:slapd-config
man:slapd-hdb
man:slapd-mdb
file:///usr/share/doc/openldap-servers/guide.html
Process: 20954 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
Process: 20924 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS)
Main PID: 20956 (slapd)
CGroup: /system.slice/slapd.service
└─20956 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// ldaps:///
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20945]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20945]: pam_unix(runuser:session): session closed for user ldap
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20947]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20947]: pam_unix(runuser:session): session closed for user ldap
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20949]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20949]: pam_unix(runuser:session): session closed for user ldap
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20951]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
Jul 15 22:51:49 vml000037.dmz.nausch.org runuser[20951]: pam_unix(runuser:session): session closed for user ldap
Jul 15 22:51:49 vml000037.dmz.nausch.org slapd[20954]: @(#) $OpenLDAP: slapd 2.4.39 (Mar 6 2015 04:35:49) $
mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/servers/slapd
Jul 15 22:51:49 vml000037.dmz.nausch.org slapd[20956]: slapd starting
Jul 15 22:51:49 vml000037.dmz.nausch.org systemd[1]: Started OpenLDAP Server Daemon.
Den geöffneten Port 636 können wir auch mit folgendem Aufruf überprüfen:
# lsof -i :636
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME slapd 20956 ldap 10u IPv4 323839 0t0 TCP *:ldaps (LISTEN) slapd 20956 ldap 11u IPv6 323840 0t0 TCP *:ldaps (LISTEN)
An statt lsof zu nutzen, können wir natürlich auch den Befehl netstat dazu bemühen.
# netstat -tulpen | grep slapd
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 0 744033 31165/slapd tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 0 744037 31165/slapd tcp6 0 0 :::389 :::* LISTEN 0 744034 31165/slapd tcp6 0 0 :::636 :::* LISTEN 0 744038 31165/slapd
TLS Protokollversion
Auf Grund einer Sicherheitslücke in der SSLv3 Implementierung (Poodle-Lücke), ist aus Sicherheitsgründen der Support der beiden Protokolle zu unterbinden. Im Dokument Resolution for POODLE SSLv3.0 vulnerability (CVE-2014-3566) for components that do not allow SSLv3 to be disabled via configuration settings finden sich hierzu wertvolle Hinweise zur Konfiguration unseres OpenLDAP-Servers.
Die Festlegung des TLS Protokolls bzw. dem Ausschluss von SSLv3 nehmen wir an Hand der nachfolgenden ldif-Datei vor. # vim /etc/openldap/ldif/cn\=config_TLS_olcTLSProtocolMin.ldif
- /etc/openldap/ldif/cn=config_TLS_olcTLSProtocolMin.ldif
# Django : 2015-07-15 # Ausschliessen der TLS-Protokolls SSLv3 auf Grund der Poodle Lücke # https://dokuwiki.nausch.org/doku.php/centos:ldap_c7:ldaps?&#tls_protokoll-version_via_ldif dn: cn=config changetype: modify add: olcTLSProtocolMin olcTLSProtocolMin: 3.1
Mittels ldapmodify führen wir nun die Änderungen unserer ldif-Datei aus.
# ldapmodify -W -x -D cn=config -f /etc/openldap/ldif/cn\=config_TLS_olcTLSProtocolMin.ldif
Enter LDAP Password:
modifying entry "cn=config"
Ob unsere Änderungen auch wirklich entsprechend unserer ldif-Datei angelegt und geändert wurden, können wir wie folgt überprüfen.
# ldapsearch -W -x -D cn=config -b cn=config "(objectclass=olcGlobal)"
Enter LDAP Password:
# extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: (objectclass=olcGlobal) # requesting: ALL # # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcIdleTimeout: 30 olcPidFile: /var/run/openldap/slapd.pid olcReferral: ldap://openldap.dmz.nausch.org olcTLSCACertificateFile: /etc/pki/tls/certs/CAcert_chain.pem olcTLSCACertificatePath: /etc/openldap/certs olcTLSCertificateFile: /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate. pem olcTLSCertificateKeyFile: /etc/pki/tls/private/openldap_serverkey.pem olcTLSCipherSuite: HIGH olcTLSProtocolMin: 3.1 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
TLS Diffie-Hellman Parameter
Will man Perfect Forward Secrecy benutzen, so ist laut der „How do I use TLS/SSL?“ die Directive TLSDHParamFile zu setzen. Dieser Parameter spezifiziert eine Datei mit den Parametern zum Diffie-Hellman Ephemeral Schlüssel Austausch.
Zunächst werden wir uns nun erst einmal eine zu unserem 4096-RSA-Key passende Diffie-Hellmann-Schlüsselparameterdatei generieren.
Die Erstellung einer 4096 Diffie-Hellman-Parameterdatei wird einige Zeit in Anspruch nehmen, also genügend Zeit für ein paar Kaffee oder CLUB-MATE, die einem Admin natürlich immer in ausreichenden Mengen zur Verfügung stehen sollten. Dauert die Erstellung auf dem Evaluierungssystem bis zu 60 Minuten! ;)
# openssl dhparam -out /etc/pki/tls/private/dh_4096.pem 4096
Generating DH parameters, 4096 bit long safe prime, generator 2 ...............................+............+..............
Da wir die Diffie-Hellman-Parameterdatei im Betrieb regelmäßig austauschen wollen, legen wir uns kurzer Hand einfach ein passendes Shell-Script an. Zuvor legen wir aber noch ein Verzeichnis an, in dem die Schlüssel vorübergehend abgelegt werden können.
# mkdir /etc/pki/tls/tmp
# vim edh_keygen
- edh_keygen
#!/bin/bash # Script zum Erstellen der Diffie Hellman Schlüsselparameterdatei # Django <django@mnausch.org> (c) 2015 # ins Arbeitsverzeichnis wechseln cd /etc/pki/tls/tmp umask 022 # Diffie-Hellman Parameter Datei erzeugen openssl dhparam -out dh_4096.pem 4096 chmod 640 dh_4096.pem # Hostname und Datum holen NAME=`hostname -s` DATUM=`date +'%b %e %H:%M:%S'` # Parameterdatei für OpenLDAP bereitstellen /usr/bin/rsync /etc/pki/tls/tmp/dh_4096.pem /etc/pki/tls/private/ # Informationen zur neuen Parameterdatei im OPenLDAP-Log vermerken echo "$DATUM" "$NAME" "openssl: ssl-params: renewed diffie-hellman parameters 4096bit" >> /var/log/ldap.log # OpenLDAP-Server restarten /usr/bin/systemctl restart slapd # Temporäre Arbeitsdatei schreddern /usr/bin/shred -u /etc/pki/tls/tmp/dh_4096.pem
Damit das Script auch ausgeführt werdden kann, versehen wir es noch mit den benötigten Rechten.
# chmod +x edh_keygen
Warum das ganze in ein Shellsript packen, wird nun sich der ein oder andere gefragt haben. Ganz einfach: Wenn wir das Script nun nach /etc/cron.weekly verschieben, können wir einfach stündlich neu generierte Schlüssel generieren und auch verwenden!
# mv edh_keygen /etc/cron.weekly/
Das regelmäßige Erneuern der DH-Parameterdatei erfolgt nun regelmäßig und wir im Log unseres OpenLDAP-Verzeichnisservers entsprechend dokumentiert.
# less /var/log/ldap.log
Jul 16 14:43:38 vml000037 openssl: ssl-params: renewed diffie-hellman parameters 4096bit
Jul 16 14:43:38 vml000037 slapd[5002]: daemon: shutdown requested and initiated.
Jul 16 14:43:38 vml000037 slapd[5002]: slapd shutdown: waiting for 0 operations/tasks to finish
Jul 16 14:43:38 vml000037 slapd[5002]: slapd stopped.
Jul 16 14:43:39 vml000037 slapd[7344]: @(#) $OpenLDAP: slapd 2.4.39 (Mar 6 2015 04:35:49) $
mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/servers/slapd
Jul 16 14:43:39 vml000037 slapd[7346]: slapd starting
Nun müssen wir nur noch über die Directive olcTLSDHParamFile unserem OpenLDAP-Server beibringen, die Parameterdatei auch zu verwenden.
Wir legen uns also eine passende Konfigurationsdatei an und weisem dem Parameter dem Wert zu.
# vim /etc/openldap/ldif/cn\=config_olcTLSDHParamFile.ldif
- /etc/openldap/ldif/cn=config_olcTLSDHParamFile.ldif
# Django : 2015-07-16 # Definition der Parameterdatei für den Diffie-Hellman Ephemeral Schlüssel Austausch # https://dokuwiki.nausch.org/doku.php/centos:ldap_c7:ldaps?&#tls_diffie-hellman_parameter_via_ldif dn: cn=config changetype: modify replace: olcTLSDHParamFile olcTLSDHParamFile: /etc/pki/tls/private/dh_4096.pem
Die Änderung unserer OpenLDAP-Konfiguration, aktivieren wir wie folgt:
# ldapmodify -W -x -D cn=config -f /etc/openldap/ldif/cn\=config_olcTLSDHParamFile.ldif
Enter LDAP Password:
modifying entry "cn=config"
Auch hier können wir überprüfen, ob der zusätzliche Konfigurationsparameter richtig gesetzt wurde.
# ldapsearch -W -x -D cn=config -b cn=config "(objectclass=olcGlobal)"
Enter LDAP Password:
# extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: (objectclass=olcGlobal) # requesting: ALL # # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcIdleTimeout: 30 olcPidFile: /var/run/openldap/slapd.pid olcReferral: ldap://openldap.dmz.nausch.org olcTimeLimit: 15 olcTLSCACertificateFile: /etc/pki/tls/certs/CAcert_chain.pem olcTLSCACertificatePath: /etc/openldap/certs olcTLSCertificateFile: /etc/pki/tls/certs/openldap.dmz.nausch.org.certificate. pem olcTLSCertificateKeyFile: /etc/pki/tls/private/openldap_serverkey.pem olcTLSCipherSuite: HIGH olcTLSProtocolMin: 3.1 olcTLSDHParamFile: /etc/pki/tls/private/dh_4096.pem # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
LDAPs Verbindungstests
openssl
Beim ersten Test bauen wir eine Verbindung mit Hilfe des Befehls openssl auf und prüfen, ob auch wirklich das angegebene Protokoll verwendet wurde und welcher Cipher zum Einsatz kam.
# openssl s_client -connect openldap.dmz.nausch.org:636 -showcerts -tls1_2
CONNECTED(00000003)
depth=2 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing Authority, emailAddress = support@cacert.org
verify return:1
depth=1 O = CAcert Inc., OU = http://www.CAcert.org, CN = CAcert Class 3 Root
verify return:1
depth=0 CN = openldap.dmz.nausch.org
verify return:1
---
Certificate chain
0 s:/CN=openldap.dmz.nausch.org
i:/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
-----BEGIN CERTIFICATE-----
MIIGBzCCA++gAwIBAgIDAm8BMA0GCSqGSIb3DQEBDQUAMFQxFDASBgNVBAoTC0NB
Y2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNV
BAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcNMTUwNzE1MTgzOTUxWhcNMTcwNzE0
MTgzOTUxWjAiMSAwHgYDVQQDExdvcGVubGRhcC5kbXoubmF1c2NoLm9yZzCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMUdsfKPIpr3Ma0gpTJdIdKFJ9Wj
oc7tRO5D67WgXm4Txwd17wK51BkCsXPc7tNHHTTfEJ17UPfqge4bH5kH+Vfg4dAb
DG0xDtcJibQ0k4dbZEidTET41Iqd2m6xgGOAfEOpZmSUA2Awn4GBKFHjg3RzZ6YG
n6CTCTaCGiRsRWiGq0KBk4lXmvfAy+/dABXWwMlQsufMwvNxYp7fy/1K7ZMiSfRs
yMuqMWOO+e3YcUauZVhqhKlcH2AWi8+V6j4wp2G72fuuxOpZkU2vJcNKH3sHYj9G
p+Z7VHmzgDlz7Y00f93M6VVnC91RhDBwgQzGDMNRTSLyEnOFw7rtHgB/9QkD8dc8
9kley/+LQL4kIm1a8Vvm6wefiSKQOvuoFN5lN3x65JrrP8AB3KmhY+9ADI8w4P2Q
sPvsPt/ZREqB6mgy/IDEdRglMZYlOheacPnfe/JLBquIdW0kU3KKiRRZnugvkhti
GW0uJtWpNcvfx0FIPyFfDUAcCLiBnXym+4E4ekXEHH9aZxLgNhX81dw9lBzAmv1I
AAt2TMbwk74WedYVPN0nToGkTJu3iv1Y6sKQrbClpp4xl43bl11WFHFvJI0o7CC8
265NiAYfXztTXqxlJEOoltTaAXh9Zo8qNagrzlGOM/2lJT4T720mzmCKtNuxzMqF
+Z3YzIuTtz6gCHwPAgMBAAGjggESMIIBDjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB
/wQEAwIDqDA0BgNVHSUELTArBggrBgEFBQcDAgYIKwYBBQUHAwEGCWCGSAGG+EIE
AQYKKwYBBAGCNwoDAzAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmNhY2VydC5vcmcvMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwu
Y2FjZXJ0Lm9yZy9jbGFzczMtcmV2b2tlLmNybDBJBgNVHREEQjBAghdvcGVubGRh
cC5kbXoubmF1c2NoLm9yZ6AlBggrBgEFBQcIBaAZDBdvcGVubGRhcC5kbXoubmF1
c2NoLm9yZzANBgkqhkiG9w0BAQ0FAAOCAgEAQpFKrP2/1/iGFUyC6Sjz4JPI93xN
qoWhRMZM/SkpwarzBMwsGQ6yKHEoim9Zo4owb38q4yurlUgMcJ2XtNoB0uZK/jZQ
dVJysG+VbCh9YD5poHRVPMC5zAHWQ13m4BhaOcSXu1Vvh7lb/BcbIA2hlnuRtoOR
eyY28nTD1fLjTMfp6PbYFTK+asxq0TPqrP9j0qSy1M+0SQnLvlLkr1/bPWDeGH9k
L5c7FlTQAYE0q6sTdpAPNX2icGHECtylCohlnpNoLCchboH9y9s7FtPzMbDENWvA
FM1gooanqbo66adN7psnw2gXJbDLShaIwgjRzM8+82I4nXVO5CcD3FWqQIPwYpec
Rqk/iSB7UobY5h0/R1oQSCqrpGdMwXq7dwGMvyWlxWDikQrR2ptDWO9HENrUpwCN
LBvmGZedITZ3+NqmJTbSp3R4bEYESmznNUdD8BnBvg3alkzjb6Cinnb30TJtehbQ
yBaEhzq8KsOZpzcLT7ldN3Y6dxu8qj+p67nGD+A8brrII1s4TIcnEvnPBCWuku/r
a5iSsSt3US1dOocFJM3CJyuaNfWIqDbutE702fREPriNPxqRSdTkH5Ub4Rb4CiRW
bHHSqh0QekUMpNi6n7+thG46EKJk1WgeNhhsqRKqy5MDLth7iN5gHE2CCbSIe4qW
g2KkrggW2eBNzv4=
-----END CERTIFICATE-----
1 s:/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
-----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-----
2 s:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
-----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-----
---
Server certificate
subject=/CN=openldap.dmz.nausch.org
issuer=/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 6065 bytes and written 399 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-SHA
Session-ID: 1CB2A6EEF8A21B2239B011CFA0FF156F76A477FE8F883550762FDB0B2DACDBEC
Session-ID-ctx:
Master-Key: FFA99DDC9829B6171367B7428647D13F6D7BFA65582810158A10CEDF8B38C2295A4E6C3F8B3212672EC1974DCD1DDAB3
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1437051157
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Mit der Tastenkombination Strg + c beenden wir die Verbindung.
Im obigen Beispiel sehen wir, dass:
- Protokoll: TLSv1.2
- Cipher : ECDHE-RSA-AES128-SHA
und als temporärer Server-Key ECDH, prime256v1, 256 bits verwendet wurden.
In der Logdatei unseres OpenLDAP-Servers wird der Connect entsprechend vermerkt.
# less /var/log/ldap.log
Jul 16 14:53:37 vml000037 slapd[7346]: conn=1002 fd=13 ACCEPT from IP=10.0.0.37:41958 (IP=0.0.0.0:636) Jul 16 14:53:37 vml000037 slapd[7346]: conn=1002 fd=13 TLS established tls_ssf=128 ssf=128 Jul 16 14:53:45 vml000037 slapd[7346]: conn=1002 fd=13 closed (connection lost)
ldapsearch
Beim nächsten Test verwenden wir den Befehl ldapsearch und richten über eine geschützte TLS-Verbindung eine Anfrage an unseren OpenLDAP-Verzeichnisdienst.
# ldapsearch -W -x -D cn=config -b cn=config "(objectclass=olcGlobal)" -LLL -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password:
dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcIdleTimeout: 30 olcPidFile: /var/run/openldap/slapd.pid olcReferral: ldap://openldap.dmz.nausch.org olcTimeLimit: 15 olcTLSCACertificateFile: /etc/pki/tls/certs/CAcert_chain.pem olcTLSCACertificatePath: /etc/openldap/certs olcTLSCertificateFile: /etc/pki/tls/certs/openldap.dmz.nausch.org.pem olcTLSCertificateKeyFile: /etc/pki/tls/private/openldap_serverkey.pem olcTLSCipherSuite: HIGH olcTLSDHParamFile: /etc/pki/tls/private/dh_4096.pem olcTLSProtocolMin: 3.1
Der Verbindungsauf- wie auch -abbau und natürlich auch die Abfrage an sich, wird im LDAP-Log /var/log/ldap.log dokumentiert.
# less /var/log/ldap.log
Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 fd=13 ACCEPT from IP=10.0.0.37:43011 (IP=0.0.0.0:636) Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 fd=13 TLS established tls_ssf=128 ssf=128 Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 op=0 BIND dn="cn=config" method=128 Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 op=0 RESULT tag=97 err=0 text= Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=olcGlobal)" Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 op=2 UNBIND Jul 16 15:49:32 vml000037 slapd[11436]: conn=1006 fd=13 closed