[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

[Aleksander Adamowski]

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?

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 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.

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    tel. brak
    kom. +48 601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete all copies of this message.