Re: [Fedora-directory-users] Re: Hostname does not match CN
Someone should file a bug report with Sun then, since LDAP RFC2830 defines support for subjectAltName and not for wildcard certs. The LDAPbis specifications will be pretty much the same here. I.e., Sun's LDAP library is not LDAPv3 compliant. RHEL uses OpenLDAP libraries, which are fully LDAPv3 compliant. I think 2830 does mention wildcards as acceptable, but I would prefer to use subjectAltNames if possible. So I agree it would be great if Sun would add this support to their Solaris LDAP name service client. I believe part of the problem is that the Solaris client uses a fairly ancient version of the NSS toolkit (although Sun DS, like Fedora DS, uses a much more recent version). Howard Chu wrote: Date: Tue, 04 Apr 2006 11:30:30 -0700 From: "George Holbert" <[EMAIL PROTECTED]> Does Directory Server support the subjectAltName extension on SSL certs? Yes, the NSS toolkit which Directory Server uses can handle these certs. The next question is, do your SSL-enabled LDAP clients support these certs? I need to support both Solaris and RedHat Linux LDAP name service clients (i.e., passwd, group, automount, etc.). I've found that: - Solaris clients can handle wildcard certs. RHEL 3 clients can't. - RHEL 3 clients can handle subjectAltName certs. Solaris clients can't. So, while the server can present either of these cert types, your clients' limitations will also influence how you sign your certs. Someone should file a bug report with Sun then, since LDAP RFC2830 defines support for subjectAltName and not for wildcard certs. The LDAPbis specifications will be pretty much the same here. I.e., Sun's LDAP library is not LDAPv3 compliant. RHEL uses OpenLDAP libraries, which are fully LDAPv3 compliant. -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Re: Hostname does not match CN
Date: Tue, 04 Apr 2006 11:30:30 -0700 From: "George Holbert" <[EMAIL PROTECTED]> Does Directory Server support the subjectAltName extension on SSL certs? Yes, the NSS toolkit which Directory Server uses can handle these certs. The next question is, do your SSL-enabled LDAP clients support these certs? I need to support both Solaris and RedHat Linux LDAP name service clients (i.e., passwd, group, automount, etc.). I've found that: - Solaris clients can handle wildcard certs. RHEL 3 clients can't. - RHEL 3 clients can handle subjectAltName certs. Solaris clients can't. So, while the server can present either of these cert types, your clients' limitations will also influence how you sign your certs. Someone should file a bug report with Sun then, since LDAP RFC2830 defines support for subjectAltName and not for wildcard certs. The LDAPbis specifications will be pretty much the same here. I.e., Sun's LDAP library is not LDAPv3 compliant. RHEL uses OpenLDAP libraries, which are fully LDAPv3 compliant. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Re: Hostname does not match CN
Does Directory Server support the subjectAltName extension on SSL certs? Yes, the NSS toolkit which Directory Server uses can handle these certs. The next question is, do your SSL-enabled LDAP clients support these certs? I need to support both Solaris and RedHat Linux LDAP name service clients (i.e., passwd, group, automount, etc.). I've found that: - Solaris clients can handle wildcard certs. RHEL 3 clients can't. - RHEL 3 clients can handle subjectAltName certs. Solaris clients can't. So, while the server can present either of these cert types, your clients' limitations will also influence how you sign your certs. Steven Bonneville wrote: Rob Crittenden <[EMAIL PROTECTED]> wrote: Alex aka Magobin wrote: [...] today I tried to issue 2 server certs using the same CA...using the same CN...I can make correctly the certs and in Manage Certificate I can see both server certs with the same name...but when I try to establish ssl encryption between servers: NSMMReplicationPlugin -agmt="cn="Replication to nodo1.domain.example.com""(nodo1:636): Simple bind failed, LDAP sdk error 81 (Can't contact LDAP server), Netscape Portable Runtime error- 12276 (Unable to communicate securely with peer: requested domain name does not match the server's certificate.) Is there someone that use two server Fedora DS to authenticate clients? Even if I can browse in clear mode FDS both on nodo1 and nodo2...in encrypt mode only one can certificate my clients? This isn't an SSL problem, it's a problem with the way you are trying to use it. You are trying to present the world with a single directory server and behind the scenes have 2 physical servers. Nothing wrong with this but you were told a while back that this could be a problem. You basically need your machine to answer to 2 separate things: its "real" hostname and the "cluster" hostname. As I see it, there are 2 ways to resolve this. I'm not a DS engineer so I can't say which one is more plausible/possible, and there may be other ways that I'm not seeing. 1. The easiest solution is to use a wildcard in the SSL server certificate hostname: CN=*.example.com. This is super ugly but should work. Note that you'll never get a CA like Verisign to issue you a wildcard server certificate. So if you are using your own self-signed CA during testing and plan to get server certs later from another CA beware. 2. I wonder if it is possible to set up multiple listeners and assign a separate SSL certificate to each one. Then you could have CN=host1.example.com on say port 638 for replication and CN=ldap.example.com on 636 for general use. I don't know of #2 is even possible right now. #1 definitely is but has issues. One of the reasons for SSL is to prevent man-in-the-middle attacks. This is preceisely the problem you are having. SSL is detecting that things aren't lining up like they should and preventing you from continuing. While a wildcard certificate will get around this you must understand that you are also giving up a certain amount of security. Does Directory Server support the subjectAltName extension on SSL certs? If it does, then you could create a certificate with a subject of cn=ldap.domain.example.com,... and a subjectAltName of something like DNS:nodo1.domain.example.com. I think you can have multiple subjectAltName extensions on one certificate. See /usr/share/doc/openssl-0.9.7a/openssl.txt for some more details. I'm not a DS engineer either, and while it's on my "to do" list, I haven't tried this myself yet. -- Steve Bonneville -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Re: Hostname does not match CN
Rob Crittenden <[EMAIL PROTECTED]> wrote: > Alex aka Magobin wrote: [...] > > today I tried to issue 2 server certs using the same CA...using the same > > CN...I can make correctly the certs and in Manage Certificate I can see > > both server certs with the same name...but when I try to establish ssl > > encryption between servers: > > > > NSMMReplicationPlugin -agmt="cn="Replication to > > nodo1.domain.example.com""(nodo1:636): Simple bind failed, LDAP sdk > > error 81 (Can't contact LDAP server), Netscape Portable Runtime error- > > 12276 (Unable to communicate securely with peer: requested domain name > > does not match the server's certificate.) > > > > Is there someone that use two server Fedora DS to authenticate clients? > > Even if I can browse in clear mode FDS both on nodo1 and nodo2...in > > encrypt mode only one can certificate my clients? > > This isn't an SSL problem, it's a problem with the way you are trying to > use it. You are trying to present the world with a single directory > server and behind the scenes have 2 physical servers. Nothing wrong with > this but you were told a while back that this could be a problem. > > You basically need your machine to answer to 2 separate things: its > "real" hostname and the "cluster" hostname. > > As I see it, there are 2 ways to resolve this. I'm not a DS engineer so > I can't say which one is more plausible/possible, and there may be other > ways that I'm not seeing. > > 1. The easiest solution is to use a wildcard in the SSL server > certificate hostname: CN=*.example.com. This is super ugly but should > work. Note that you'll never get a CA like Verisign to issue you a > wildcard server certificate. So if you are using your own self-signed CA > during testing and plan to get server certs later from another CA beware. > > 2. I wonder if it is possible to set up multiple listeners and assign a > separate SSL certificate to each one. Then you could have > CN=host1.example.com on say port 638 for replication and > CN=ldap.example.com on 636 for general use. > > I don't know of #2 is even possible right now. #1 definitely is but has > issues. One of the reasons for SSL is to prevent man-in-the-middle > attacks. This is preceisely the problem you are having. SSL is detecting > that things aren't lining up like they should and preventing you from > continuing. While a wildcard certificate will get around this you must > understand that you are also giving up a certain amount of security. Does Directory Server support the subjectAltName extension on SSL certs? If it does, then you could create a certificate with a subject of cn=ldap.domain.example.com,... and a subjectAltName of something like DNS:nodo1.domain.example.com. I think you can have multiple subjectAltName extensions on one certificate. See /usr/share/doc/openssl-0.9.7a/openssl.txt for some more details. I'm not a DS engineer either, and while it's on my "to do" list, I haven't tried this myself yet. -- Steve Bonneville -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
