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://lists.fedoraproject.org/pipermail/389-users/attachments/20080414/16166e36/attachment.bin
