Aleksander Adamowski wrote:
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.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?
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=comThen 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@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_NAMEOther 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 also not sure if that applies to cert based auth.
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.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.See the RHDS 8.0 Admin Guide, Chapter 12 - http://www.redhat.com/docs/manuals/dir-server/ag/8.0/ and http://tinyurl.com/688w9yI 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 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.
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.
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
