On 12/16/2011 08:28 AM, Aaron Bennett wrote:
So, I did manage to make it work using a .pem file, but I really think it ought to work using the NSS library. I have a self-signed certificate in /etc/openldap/nssdb. It starts and almost works, except when I try to access it via ldaps which produces this (-d1) output:
slap_listener(ldaps:///)
connection_get(16): got connid=1000 connection_read(16): checking for input on id=1000 TLS: using moznss security dir /etc/openldap/nssdb prefix . TLS: certificate [CN=animal.clarku.edu,OU=ITS,O=Clark University,L=Worcester,ST=Massachusetts,C=US] is not valid - error -8171:Unknown code ___f 21. TLS: error: unable to find and verify server's cert and key for certificate animal.clarku.edu TLS: error: could not initialize moznss security context - error -8171:Unknown code ___f 21
21 is this: SEC_ERROR_UNTRUSTED_CERT = SEC_ERROR_BASE + 21,
This means CN=animal.clarku.edu,OU=ITS,O=Clark University,L=Worcester,ST=Massachusetts,C=US is not trusted.
TLS: can't create ssl handle. connection_read(16): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=16
I wonder if I'm doing something obvious wrong generating my cert -- here's the commands I used:
[root@animal nssdb]# certutil -N -d /etc/openldap/nssdb/ Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character.
Enter new password: Re-enter password: (I put no password in)
[root@animal nssdb]# certutil -R -s "CN=animal.clarku.edu, O=Clark University ITS, L=Worcester, ST=Massachusetts, C=US" -p "(508) 793-7745" -o animal-self-signed.req -d /etc/openldap/nssdb/
[root@animal nssdb]# certutil -S -s "CN=ITS Self Signed" -n its -x -t "C,C,C" -1 -2 -5 -d /etc/openldap/nssdb/
Generating key. This may take a few moments...
0 - Digital Signature 1 - Non-repudiation 2 - Key encipherment 3 - Data encipherment 4 - Key agreement 5 - Cert signing key 6 - CRL signing key Other to finish5
0 - Digital Signature 1 - Non-repudiation 2 - Key encipherment 3 - Data encipherment 4 - Key agreement 5 - Cert signing key 6 - CRL signing key Other to finish7
Is this a critical extension [y/N]? n Is this a CA certificate [y/N]? y Enter the path length constraint, enter to skip [<0 for unlimited path]:> Is this a critical extension [y/N]? n 0 - SSL Client 1 - SSL Server 2 - S/MIME 3 - Object Signing 4 - Reserved for future use 5 - SSL CA 6 - S/MIME CA 7 - Object Signing CA Other to finish
3
0 - SSL Client 1 - SSL Server 2 - S/MIME 3 - Object Signing 4 - Reserved for future use 5 - SSL CA 6 - S/MIME CA 7 - Object Signing CA Other to finish8
Is this a critical extension [y/N]? n [root@animal nssdb]# certutil -d . -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
its Cu,Cu,Cu [root@animal nssdb]# certutil -d . -C -i animal-self-signed.req -t "p,p,p" -o animal-self-signed.crt -c its [root@animal nssdb]# certutil -d . -A -n animal.clarku.edu -t "p,p,p" -i animal-self-signed.crt [root@animal openldap]# chown -R ldap:ldap /etc/openldap/nssdb/
And to verify that the ldap user can see the new certs: [root@animal openldap]# sudo -u ldap certutil -L -d /etc/openldap/nssdb/
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
its Cu,Cu,Cu animal.clarku.edu pu,pu,pu
This is the problem. I don't know if setting the trust flags is documented anywhere - certutil -H gives some information, and there might be more on the mozilla.org site.
This is what the trust should look like: Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
CA certificate CTu,u,u Server-Cert u,u,u
That is - the CA certificate is trusted c valid CA T trusted CA to issue client certs (implies c) C trusted CA to issue server certs (implies c) u user cert The u is optional here - you probably won't use your CA cert as a user cert.
The server cert is trusted as a user cert which, for a server cert, means it is trusted as an SSL server cert. You can also use this server cert as a client cert for doing server to server cert client auth.
The certutil -H lists the trust flag information under the documentation for the -E flag.
Use certutil -M to change the trust flags: certutil -d /etc/openldap/nssdb/ -M -n "its" -t CT,, certutil -d /etc/openldap/nssdb/ -M -n "animal.clarku.edu" -t u,u,u
I've also updated the faq-o-matic with this information. http://www.openldap.org/faq/index.cgi?file=1514
[root@animal openldap]#
I see no failures in /var/log/audit/audit.log either.
Thanks for taking time to look this over.
- Aaron
-----Original Message----- From: Rich Megginson [mailto:rich.megginson@gmail.com] Sent: Monday, December 12, 2011 3:31 PM To: Aaron Bennett Cc: openldap-technical@openldap.org Subject: Re: Mozilla NSS / OpenLdap 2.4.23 cert not readable?
On 12/12/2011 01:16 PM, Aaron Bennett wrote:
-----Original Message----- From: Rich Megginson [mailto:rich.megginson@gmail.com]
What am I missing?
not sure - start slapd and add "-d 1" to your slapd argument list (see /etc/sysconfig/ldap? or slapd? for the argument list)
Doesn't yield anything, or rather, the copious debugging information it prints
doesn't show any failure except for "animal.clarku.edu is not readable by "ldap"" That's really strange. I'd like to take a look at that output.
Also, please confirm that you are running slapd as the userid "ldap" and that /etc/pki/nssdb is readable by "ldap".
- confirmed. Slapd is running as userid ldap.
- /etc/pki/nssdb is readable by "ldap": "sudo -u ldap certutil -L -n
animal.clarku.edu -d /etc/pki/nssdb/" works as expected.
Thanks for your time,
Aaron