FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 04-14-2008, 06:08 PM
Rich Megginson
 
Default SOLVED: NSPR "Certificate type not approved for application" error when a TLS-enabled proxy LDAP OpenLDAP server connects to Fedora Directory Server

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:
emailostmaster@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.
--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
 
Old 04-14-2008, 09:57 PM
Michael Str÷der
 
Default SOLVED: NSPR "Certificate type not approved for application" error when a TLS-enabled proxy LDAP OpenLDAP server connects to Fedora Directory Server

Aleksander Adamowski wrote:


The relevant fields of the OpenLDAP server's certificate are:


What about the keyUsage and extendedKeyUsage extensions?

Ciao, Michael.

--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
 
Old 04-15-2008, 11:41 AM
Aleksander Adamowski
 
Default SOLVED: NSPR "Certificate type not approved for application" error when a TLS-enabled proxy LDAP OpenLDAP server connects to Fedora Directory Server

Michael Str├Âder wrote:

Aleksander Adamowski wrote:


The relevant fields of the OpenLDAP server's certificate are:


What about the keyUsage and extendedKeyUsage extensions?

Ciao, Michael.

These aren't present, unfortunately.

I didn't place keyUsage in the openssl.cnf section used for server
certificates...


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


--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
 

Thread Tools




All times are GMT. The time now is 01:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org