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
<FQDN>: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 +0000, 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://<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
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-<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?
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
rg
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
<mailto:389-users-leave@lists.fedoraproject.org>