Monday, February 5, 2018

[389-users] TLS Error -8179



I'm a new 389 Directory Server user on an Amazon Linux 1 EC2 platform. I got the server launched without much issue, but then hit a wall when I imported certificates and turned on SSL. Essentially I'm getting the error message.


TLS error -8179: Peer's Certificate issuer is not recognized.


I'm fairly convinced it's an issue with certificate importation and/or configuration because the certificate I'm using is a valid and current one. The following commands both resolve successfully.


ldapsearch -H ldap://<FQDN>:389 -D 'cn=Directory Manager' -W -Z -b 'cn=encryption,cn=config' -x -d1

openssl s_client -connect <FQDN>:636


The ldapsearch command shows a valid certificate and openssl resolves to "Verify return code: 0 (ok)."


These are authenticating against the pem file at /etc/pki/tls/certs/ca-bundle.crt 




In order to get 389 DS over LDAPS working, I followed a combination of instructions I found on pages  and


Here are my steps.


1. Stop dirsrv


service dirsrv stop


2. Reset the database:


certutil -N -d /etc/dirsrv/slapd-<myinstance>


3. Import my CA file


certutil -A -d /etc/dirsrv/slapd-<myinstance> -n "ca_cert" -t "CT,," -i /etc/pki/tls/certs/ca-bundle.crt -a


4. Transfer my pem cert and key files to pkcs12 format for importation


openssl pkcs12 -export -inkey /etc/pki/tls/private/mykey.key -in /etc/pki/tls/certs/mycert.crt -out /home/diradmin/mykeycert.p12 -name "Server-Cert"


5. Use pk12util to import


pk12util -d /etc/dirsrv/slapd-<myinstance> -n "Server-Cert" -i /home/diradmin/mykeycert.p12


6. Edit dse.ldif


Add the following line to the object dn: cn=config.

     nsslapd-security: on


The object dn: cn=encryption,cn=config should contain the following lines. Remove any of the parameters sslVersionMin, sslVersionMax, and nsSSL3Ciphers.

     dn: cn=encryption,cn=config
     objectClass: top
     objectClass: nsEncryptionConfig
     cn: encryption
     nsSSLSessionTimeout: 0
     nsSSLClientAuth: off
     nsSSL3: off
    nsSSL2: off


If it doesn’t exist, add the object dn: cn=RSA,cn=encryption,cn=config and give it the following lines. The value of nsSSLPersonalitySSL must equal the nickname of the certificate file you imported above.

     dn: cn=RSA,cn=encryption,cn=config
     objectClass: top
     objectClass: nsEncryptionModule
     nsSSLPersonalitySSL: Server-Cert 
     nsSSLActivation: on
     nsSSLToken: Internal (Software)
     cn: RSA


7. Create a new file in the main Directory Server directory.


cd /etc/dirsrv/slapd-<instance name>

touch pin.txt

vi pin.txt


Add the following line to it. The phrase "Internal (Software)" in the line below must match the value of the attribute nsSSLToken above.


Internal (Software) Token:<password of Directory Server database>


8. Change the owner and group of pin.txt to the main Directory Server user (in my case diradmin) and set permissions to 400


chown diradmin:diradmin pin.txt

chmod 400 pin.txt


9. Restart the Directory Server


service dirsrv start



Based on my admittedly limited understanding of 389 DS, this should result in successful LDAPS connections, but it doesn't. Restarting dirsrv results in "TLS error -8179: Peer's Certificate issuer is not recognized."


So, either I'm importing the wrong certificates or something about my importation process is flawed.


Oh and by the way, I tried a different approach and started with a certificate signing request using certutil with the intention of requesting a new certificate. However certutil will not show me the public key for the csr, only the request. So, it seems I'm stuck. Anyone have any ideas?

No comments:

Post a Comment