[Fedora-directory-users] SOLVED: NSPR "Certificate type not approved for application" error when a TLS-enabled proxy LDAP OpenLDAP server connects to Fedora Directory Server

[Rich Megginson]

Aleksander Adamowski wrote:
> Rich Megginson wrote:
>> That should be fine.  Fedora DS can do the same thing e.g. with 
>> server-to-server chaining and replication, using the server cert for 
>> client cert auth.  It just depends on the type of cert issued and/or 
>> the trust flags on the cert.
> If I understand correctly you're implying that server2server ssl 
> connections are handled with the same logic that client2server ssl?
What I meant was that the server handles any client cert based auth the 
same way, regardless of whether the "client" is a user or another server.
>
> Then it's strange, since I'm using multi-master replication with all 
> s2s connections using SSL (port 636). I've generated all the 
> certificates (for FDS servers and for OpenLDAP servers) using the same 
> OpenSSL CA openssl.cnf config file (but a slightly different 
> configuration section WRT subjectAltName field - see below).
>
> The relevant fields of the OpenLDAP server's certificate are:
>
>        X509v3 extensions:
>            X509v3 Basic Constraints:
>                CA:FALSE
>            Netscape Cert Type:
>                SSL Server
> ...
>            X509v3 Subject Alternative Name:
>                email:postmaster at MY_DOMAIN_NAME
>
> While the same fields of the FDS certificate are:
>
>        X509v3 extensions:
>            X509v3 Basic Constraints:
>                CA:FALSE
>            Netscape Cert Type:
>                SSL Server
> ...
>            X509v3 Subject Alternative Name:
>                DNS:servername2.MY_DOMAIN_NAME, 
> DNS:servername3.MY_DOMAIN_NAME
>
> Other differences are only in key length, crypto algorithms and values 
> of serial numbers, fingerprint etc.
>
> So the only one possibly relevant difference is that in OpenLDAP's 
> cert the subjectAltName field contains an e-mail address and in Fedora 
> Directory Server's it contains alternative DNS host names of the FDS 
> server. Might it be the cause?
I'm not sure how NSS handles certificate verification with 
subjectAltName.  I know that in order for the validation to work without 
subjectAltName, the leftmost RDN in the subjectDN must be cn=FQDN of the 
server e.g. cn=ldap1.example.com, ou=Fedora Directory Server, 
dc=example, dc=com

I'm also not sure if that applies to cert based auth.
>>
>>>
>>> I thought that there might be a similar method to tweak behaviour of 
>>> dirsrv (although not through nss.conf since dirsrv doesn't use 
>>> mod_nss and doesn't contain a http server in any part ), like some 
>>> undocumented setting in dse.ldif. However, more correct fix turned 
>>> out to be disallow certificate-based client authentication.
>> See the RHDS 8.0 Admin Guide, Chapter 12 - 
>> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/ and 
>> http://tinyurl.com/688w9y
>>
>> See also the detailed information for all of the security/encryption 
>> configuration entries and attributes - http://tinyurl.com/35qddb - 
>> there is also an apparently undocumented entry cn=RSA, cn=encryption, 
>> cn=config.
> Yup, I've read that but there isn't anything conclusive over there. I 
> was counting on some undocumented configuration attribute that would 
> control which usages are allowed in client x.509 certs.
>
Ok.  I'm not sure what NSS is complaining about here.  If NSS is 
complaining about the hostname in the subjectDN or the subjectAltName 
doesn't match the actual server, I don't think that makes sense in the 
context of cert based auth, since a client will usually not have an 
associated FQDN.  So I believe it's complaining that the cert was not 
issued as an SSL client cert.  I do know that you can issue a cert that 
can be used for both SSL server and SSL client use.  I'm not sure if you 
can use certutil -M to modify the trust flags of a server cert after 
issuance to allow it to be used for SSL client use.  The guys at 
news.mozilla.org:mozilla.dev.tech.crypto would know for sure.

Finally, there doesn't appear to be a way in Fedora DS to allow other 
types of certificates to be used for client cert auth, or to ignore 
problems of this nature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20080414/16166e36/attachment.bin>