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 finish
> 5
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 finish
> 7
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 finish
> 8
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:[email protected]]
Sent: Monday, December 12, 2011 3:31 PM
To: Aaron Bennett
Cc: [email protected]
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:[email protected]]
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
