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.pem
Aus 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