[389-users] Re: TLS Error -8179
On Tue, 2018-02-13 at 00:06 +, Eric Wheeler wrote: > Thanks for the response. I think I've gotten this resolved. My > primary problem was lack of understanding of issuer root and > intermediate files. I was strictly using the files sent to me by the > certificate authority when what appears to be needed is the publicly > available intermediate CA file (which neither of my issuers have sent > me). Up until now, almost all of my experience with certificates has > been over HTTPS, and I've never had to deal with intermediate files > to achieve secure connections. The weird thing is that prior to my > implementation of the correct file, ldapsearch was showing a good > LDAPS connection while restarting dirsrv continuously failed. > > In response to your question, what was consistently showing the -8179 > error was restarting dirsrv. I was getting good LDAPS connections > with ldapsearch and openssl s_client -connect :636. Once I > imported the intermediate file into the database as ca_cert, then > dirsrv showed good TLS connections. Ahhh I didn't realise this. For NSS to serve the certificate (and openssl for that matter) you have to present the entire *chain*. So if you have: CA -> intermediate -> your cert You need both CA + intermediate in your DB to present the whole chain so that clients can validate back to the CA. This is true of webservers two, and you often can just include the chain as a series of pem certs in a single file. So that makes sense why you were having this trouble. I wonder if there is a way we can report the error better in DS? Can you raise a but that this error should give better output to the admin so you can diagnose the issue faster? Thanks! > > > -Original message- > > From: William Brown > > Sent: Sunday, February 11 2018, 6:37 pm > > To: General discussion list for the 389 Directory server project. > > Subject: [389-users] Re: TLS Error -8179 > > > > Sorry for the very late response, I have been unwell on away from > > the > > computer. > > > > On Tue, 2018-02-06 at 05:34 +, Eric Wheeler wrote: > > > Greetings, > > > > > > 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. > > > > What showed this error? ldapsearch? > > > > Restarting dirsrv showed the error, i.e. > > > > > > > > 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://:389 -D 'cn=Directory Manager' -W -Z > > -b > > > 'cn=encryption,cn=config' -x -d1 > > > openssl s_client -connect :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 > > > > You need to configure openldap libs with a CA: check > > /etc/openldap/ldap.conf and the TLS_CACERT parameter for a single > > pem > > file to trust as the root, or TLS_CACERTDIR for a hashed directory > > of > > certificates (IE put the .pem files in the CACERTDIR then run > > "openssl > > rehash /path/to/cacertdir") > > > > ldapsearch/ldapwhoami generally takes a -d flag too which can help > > debug these issues too. > > > > > > > > > > > > > > In order to get 389 DS over LDAPS working, I followed a > > combination > > > of instructions I found on pages http://directory.fedoraproject.o > > rg/d > > > ocs/389ds/howto/howto-ssl.html and http://directory.fedoraprojec > > t.or > > > g/docs/389ds/FAQ/faq.html. > > > > > > Here are my steps. > > > > > > 1. Stop dirsrv > > > > > > service dirsrv stop > > > > > > 2. Reset the database: > > > > > > certutil -N -d /etc/dirsrv/slapd- > > > > > > 3. Import my CA file > > > > > > certutil -A -d /etc/dirsrv/slapd- -n "ca_cert" -t > > "CT,," > > > -i /etc/pki/tls/certs/ca-bundle.crt -a > > > > > > 4. T
[389-users] Re: TLS Error -8179
Thanks for the response. I think I've gotten this resolved. My primary problem was lack of understanding of issuer root and intermediate files. I was strictly using the files sent to me by the certificate authority when what appears to be needed is the publicly available intermediate CA file (which neither of my issuers have sent me). Up until now, almost all of my experience with certificates has been over HTTPS, and I've never had to deal with intermediate files to achieve secure connections. The weird thing is that prior to my implementation of the correct file, ldapsearch was showing a good LDAPS connection while restarting dirsrv continuously failed. In response to your question, what was consistently showing the -8179 error was restarting dirsrv. I was getting good LDAPS connections with ldapsearch and openssl s_client -connect :636. Once I imported the intermediate file into the database as ca_cert, then dirsrv showed good TLS connections. -Original message- From: William Brown Sent: Sunday, February 11 2018, 6:37 pm To: General discussion list for the 389 Directory server project. Subject: [389-users] Re: TLS Error -8179 Sorry for the very late response, I have been unwell on away from the computer. On Tue, 2018-02-06 at 05:34 +, Eric Wheeler wrote: > Greetings, > > 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. What showed this error? ldapsearch? Restarting dirsrv showed the error, i.e. > > 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://:389 -D 'cn=Directory Manager' -W -Z -b > 'cn=encryption,cn=config' -x -d1 > openssl s_client -connect :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 You need to configure openldap libs with a CA: check /etc/openldap/ldap.conf and the TLS_CACERT parameter for a single pem file to trust as the root, or TLS_CACERTDIR for a hashed directory of certificates (IE put the .pem files in the CACERTDIR then run "openssl rehash /path/to/cacertdir") ldapsearch/ldapwhoami generally takes a -d flag too which can help debug these issues too. > > > > In order to get 389 DS over LDAPS working, I followed a combination > of instructions I found on pages http://directory.fedoraproject.org/d > <http://directory.fedoraproject.org/d> > ocs/389ds/howto/howto-ssl.html and http://directory.fedoraproject.or > <http://directory.fedoraproject.or> > g/docs/389ds/FAQ/faq.html. > > Here are my steps. > > 1. Stop dirsrv > > service dirsrv stop > > 2. Reset the database: > > certutil -N -d /etc/dirsrv/slapd- > > 3. Import my CA file > > certutil -A -d /etc/dirsrv/slapd- -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- -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- >
[389-users] Re: TLS Error -8179
Sorry for the very late response, I have been unwell on away from the computer. On Tue, 2018-02-06 at 05:34 +, Eric Wheeler wrote: > Greetings, > > 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. What showed this error? ldapsearch? > > 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://:389 -D 'cn=Directory Manager' -W -Z -b > 'cn=encryption,cn=config' -x -d1 > openssl s_client -connect :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 You need to configure openldap libs with a CA: check /etc/openldap/ldap.conf and the TLS_CACERT parameter for a single pem file to trust as the root, or TLS_CACERTDIR for a hashed directory of certificates (IE put the .pem files in the CACERTDIR then run "openssl rehash /path/to/cacertdir") ldapsearch/ldapwhoami generally takes a -d flag too which can help debug these issues too. > > > > In order to get 389 DS over LDAPS working, I followed a combination > of instructions I found on pages http://directory.fedoraproject.org/d > ocs/389ds/howto/howto-ssl.html and http://directory.fedoraproject.or > g/docs/389ds/FAQ/faq.html. > > Here are my steps. > > 1. Stop dirsrv > > service dirsrv stop > > 2. Reset the database: > > certutil -N -d /etc/dirsrv/slapd- > > 3. Import my CA file > > certutil -A -d /etc/dirsrv/slapd- -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- -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- > 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: > > 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? > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
