Fedora directory users - Apr 2006 - Hostname does not match CN....

Hi, 
After with your help, succesfully  configured replication between server
I take a look to configure client''s authentication  through ldap
server...I have 2 question:

1) Is it possible add a user directly from fedora ds as posix user using
groups from server?..I don''t know is groups is integrated with
system...is it possible to add server groups to Fedora DS groups?

2) Reading ssl howto I export CA certificate to client(fedora core5)
in /etc/openldap/cacerts....(some of steps in ssl howto are
automatically generated from fedora core 5 as installing in cacerts
directory in x509 mode) but when I try to check if ssl is enable the
answer is:

[root@test]# ldapsearch -x -ZZ ''(uid=testuser)''
ldap_start_tls: Connect error (-11)
        additional info: TLS:hostname does not match CN in peer
certificate


How can I solve ?

Alex

>
> [root@test]# ldapsearch -x -ZZ ''(uid=testuser)''
> ldap_start_tls: Connect error (-11)
>         additional info: TLS:hostname does not match CN in peer
> certificate
>
>
> How can I solve ?
The server hostname you pass to ldapsearch must exactly match the CN in 
the certificate you signed for the server.

So, if you signed the certificate with a fully-qualified domainname 
(e.g. ldaphost.example.com),
use "-h ldaphost.example.com" instead of "-h ldaphost".


Alex aka Magobin wrote:
> Hi, 
> After with your help, succesfully  configured replication between server
> I take a look to configure client''s authentication  through ldap
> server...I have 2 question:
>
> 1) Is it possible add a user directly from fedora ds as posix user using
> groups from server?..I don''t know is groups is integrated with
> system...is it possible to add server groups to Fedora DS groups?
>
> 2) Reading ssl howto I export CA certificate to client(fedora core5)
> in /etc/openldap/cacerts....(some of steps in ssl howto are
> automatically generated from fedora core 5 as installing in cacerts
> directory in x509 mode) but when I try to check if ssl is enable the
> answer is:
>
> [root@test]# ldapsearch -x -ZZ ''(uid=testuser)''
> ldap_start_tls: Connect error (-11)
>         additional info: TLS:hostname does not match CN in peer
> certificate
>
>
> How can I solve ?
>
> Alex
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>

2006/4/3, George Holbert <gholbert@broadcom.com>:
>
> >
> > [root@test]# ldapsearch -x -ZZ ''(uid=testuser)''
> > ldap_start_tls: Connect error (-11)
> >         additional info: TLS:hostname does not match CN in peer
> > certificate
> >
> >
> > How can I solve ?
>
> The server hostname you pass to ldapsearch must exactly match the CN in
> the certificate you signed for the server.
>
> So, if you signed the certificate with a fully-qualified domainname
> (e.g. ldaphost.example.com),
> use "-h ldaphost.example.com" instead of "-h ldaphost".



Sigh...I found the problem...so:

I set up Fedora DS in cluster scenario with two node..nodo1 and nodo2...with
their real ip address and I make a multimaster replication; taking advantage
of ldap protocol I set up an floating ip address and an entry to dns that
point to ldap.domain.example.com with that ip...therefore if I make a query
to ldap.domain.example.com, depending if floating ip is up on nodo1 or nodo2
the DS server answer to query taking advantage to multimaster
replication...this scenario works very well in clear mode....but I saw that
if I set up ssl encryption and try to verify it, the answer is:

[root@test]# ldapsearch -h ldap.domain.example.com -x -ZZ
''(ObjectClass=*:)''
-d 1

-CUT-

TLS: hostname(ldap.domain.example.com) does not match common name in

certificate (nodo1.domain.example.com)



...now...how can I solve it??

>
>
> TLS: hostname(ldap.domain.example.com 
> <http://ldap.domain.example.com>) does not match common name in
>
> certificate (nodo1.domain.example.com
<http://nodo1.domain.example.com>)
>
> ...now...how can I solve it??
>
For the setup you described, you''d probably want to use a single 
certificate, signed with a CN of ''ldap.domain.example.com''.

This will make it possible for your server cert CNs and hostnames to 
match consistently, regardless of which machine (nodo1 or nodo2) the 
clients end up talking to.

Alessandro Binarelli wrote:
>
>
> 2006/4/3, George Holbert <gholbert@broadcom.com 
> <mailto:gholbert@broadcom.com>>:
>
>     >
>     > [root@test]# ldapsearch -x -ZZ ''(uid=testuser)''
>     > ldap_start_tls: Connect error (-11)
>     >         additional info: TLS:hostname does not match CN in peer
>     > certificate
>     >
>     >
>     > How can I solve ?
>
>     The server hostname you pass to ldapsearch must exactly match the
>     CN in
>     the certificate you signed for the server.
>
>     So, if you signed the certificate with a fully-qualified domainname
>     (e.g. ldaphost.example.com <http://ldaphost.example.com>),
>     use "-h ldaphost.example.com
<http://ldaphost.example.com>"
>     instead of "-h ldaphost".
>
>  
>  
>
> Sigh...I found the problem...so:
>
> I set up Fedora DS in cluster scenario with two node..nodo1 and 
> nodo2...with their real ip address and I make a multimaster 
> replication; taking advantage of ldap protocol I set up an floating ip 
> address and an entry to dns that point to ldap.domain.example.com 
> <http://ldap.domain.example.com> with that ip...therefore if I make a
> query to ldap.domain.example.com <http://ldap.domain.example.com>, 
> depending if floating ip is up on nodo1 or nodo2 the DS server answer 
> to query taking advantage to multimaster replication...this scenario 
> works very well in clear mode....but I saw that if I set up ssl 
> encryption and try to verify it, the answer is:
>
> [root@test]# ldapsearch -h ldap.domain.example.com 
> <http://ldap.domain.example.com> -x -ZZ
''(ObjectClass=*:)'' -d 1
>
> -CUT-
>
> TLS: hostname(ldap.domain.example.com 
> <http://ldap.domain.example.com>) does not match common name in
>
> certificate (nodo1.domain.example.com
<http://nodo1.domain.example.com>)
>
>  
>
> ...now...how can I solve it??
>
>
>  
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

> For the setup you described, you''d probably want to use a
> single certificate, signed with a CN of
''ldap.domain.example.com''.
>
> This will make it possible for your server cert CNs and
> hostnames to match consistently, regardless of which machine
> (nodo1 or nodo2) the clients end up talking to.
>
Uhm...I can try, but in that case, is it possible that I''ve a problem
with
replication ?

Nodes use server ca with only difference....CN

I maked 2 server CA with the same CA

Thanks

Alex

> Uhm...I can try, but in that case, is it possible that I''ve a
problem
> with replication ?
I don''t think so.  I''ve noticed that replication agreements
over SSL
don''t seem to care about hostname / CN matching, although they do check
that the CA is trusted.  If I have the wrong impression on this, someone 
please say so :).

In your replication agreements, you''d still want to use the 
''nodo1.domain.example.com'' or
''nodo2.domain.example.com'' names, as
''ldap.domain.example.com'' would obviously not be specific
enough.



Alessandro Binarelli wrote:
>  
>
> > For the setup you described, you''d probably want to use a
>
> > single certificate, signed with a CN of
''ldap.domain.example.com
> <http://ldap.domain.example.com>''.
>
> >
>
> > This will make it possible for your server cert CNs and
>
> > hostnames to match consistently, regardless of which machine
>
> > (nodo1 or nodo2) the clients end up talking to.
>
> >
>
> Uhm...I can try, but in that case, is it possible that I''ve a
problem
> with replication ?
>
> Nodes use server ca with only difference....CN
>
> I maked 2 server CA with the same CA
>
> Thanks
>
> Alex
>
>
>  
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

On lun, 2006-04-03 at 14:18 -0700, George Holbert wrote:
> > Uhm...I can try, but in that case, is it possible that I''ve a
problem
> > with replication ?
> 
> I don''t think so.  I''ve noticed that replication
agreements over SSL
> don''t seem to care about hostname / CN matching, although they do
check
> that the CA is trusted.  If I have the wrong impression on this, someone 
> please say so :).
> 
> In your replication agreements, you''d still want to use the 
> ''nodo1.domain.example.com'' or
''nodo2.domain.example.com'' names, as
> ''ldap.domain.example.com'' would obviously not be specific
enough.
> 
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?

alex

I make an ssl fresh install and I rename nodo1 CN in
ldap.domain.example.com...now, exporting CA to test client, it
works..but only if I put floating ip where CA was maked...obviously.

Now, How can I set up SSL so that it works to prescind from which server
I ''m connected?  

My goal is authenticate clients with SSl using fedora DS...using both
server indifferently

Thanks in advance

Alex

Alex aka Magobin wrote:
> On lun, 2006-04-03 at 14:18 -0700, George Holbert wrote:
> 
>>>Uhm...I can try, but in that case, is it possible that I''ve
a problem
>>>with replication ?
>>
>>I don''t think so.  I''ve noticed that replication
agreements over SSL
>>don''t seem to care about hostname / CN matching, although they
do check
>>that the CA is trusted.  If I have the wrong impression on this, someone
>>please say so :).
>>
>>In your replication agreements, you''d still want to use the 
>>''nodo1.domain.example.com'' or
''nodo2.domain.example.com'' names, as
>>''ldap.domain.example.com'' would obviously not be
specific enough.
>>
> 
> 
> 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.

It makes no difference if the data on the wire is encrypted if it is 
going to be decrypted at the wrong place on the other end. Just remember 
that there is a trade-off between security and convenience.

rob

--- George Holbert <gholbert@broadcom.com> wrote:
> > Uhm...I can try, but in that case, is it possible that I''ve a
problem
> > with replication ?
> 
> I don''t think so.  I''ve noticed that replication
agreements over SSL
> don''t seem to care about hostname / CN matching, although they do
check
> that the CA is trusted.  If I have the wrong impression on this, someone 
> please say so :).
Guys,

you shouldn''t have to do this.  This is what I have in my cert DB:

[root@cnyldap01 alias]# ../shared/bin/certutil -L -d .
CA certificate                                               CTu,u,u
NJ-Server-Cert                                               u,u,u
NJ-admin-server-cert                                         u,u,u
NY-Server-Cert                                               u,u,u
NY-admin-server-cert                                         u,u,u

I then sent the cert8.db & key3.db over to the other server, setup the
replication agreements back
& forth and voila!  Basically, I shoved all my certs in 1 DB and blasted
that everywhere.

Now, for the floating IP.  If you''ve two nodes, node1 & node2 and a
VIP, ldap.com and your outside
clients talk to ldap.com and your certs are signed with node1 & node2 then
I''m guessing SSL
verification will fail.  You''re trying to talk to ldap.com but your
certs are signed with node1/2
-- no go.  For this end to end SSL to work, you''d need an SSL
terminator IN FRONT of the FDS
servers, something that will impersonate ldap.com, return a cert for ldap.com
and then turn around
and encrypt the traffic again, passing it to either node1 or node2.  A cute
little problem is what
to do when the ssl proxy fails?  :)

The thing is like this.  What is the problem you are trying to solve?  Why have
two FDS servers in
1 location?  Why have the virtual IP?  It really doesn''t buy you a
whole lot.  Have 2 FDSs if you
insist but then list all of them in the clients'' ldap.conf -- no
problem.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

> 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.
Yes...but I thought that someone have implemented 2 ldap server on a
cluster system; 
> 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.
> 
uhm..very dangerous
> 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.
> 
This maybe a solution...if it''s possible...but I''m a newbe
about SSL

Ok...omit cluster...if I have a server Fedora DS (A) that it''s ssl
server too...until A is alone I configure my clients to point at this
server for authentication and I tested it works perfectly..now I want
another server for load balancing replicated in
multimaster(B)...now...how can I set up ssl for this scenario ? This
scenario is normal for example in windows Active Directory...I think
that it''s impossible that nobody has never made a test like this or
implemented something like this

--- Alex aka Magobin <magobin@gmail.com> wrote:
> Ok...omit cluster...if I have a server Fedora DS (A) that it''s ssl
> server too...until A is alone I configure my clients to point at this
> server for authentication and I tested it works perfectly..now I want
> another server for load balancing replicated in
> multimaster(B)...now...how can I set up ssl for this scenario ? This
I have this exact setup.  2 FDSs, MMR over SSL.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

> [root@cnyldap01 alias]# ../shared/bin/certutil -L -d .
> CA certificate                                               CTu,u,u
> NJ-Server-Cert                                               u,u,u
> NJ-admin-server-cert                                         u,u,u
> NY-Server-Cert                                               u,u,u
> NY-admin-server-cert                                         u,u,u
> 
yes, more or less like me..I didn''t configure admin
> Now, for the floating IP.  If you''ve two nodes, node1 & node2
and a VIP, ldap.com and your outside
> clients talk to ldap.com and your certs are signed with node1 & node2
then I''m guessing SSL
> verification will fail.  You''re trying to talk to ldap.com but
your certs are signed with node1/2
> -- no go.  For this end to end SSL to work, you''d need an SSL
terminator IN FRONT of the FDS
> servers, something that will impersonate ldap.com, return a cert for
ldap.com and then turn around
> and encrypt the traffic again, passing it to either node1 or node2.  A cute
little problem is what
> to do when the ssl proxy fails?  :)
Unfortunately too much complicated for me at this moment :-(

> The thing is like this.  What is the problem you are trying to solve?  Why
have two FDS servers in
> 1 location?  Why have the virtual IP?  It really doesn''t buy you a
whole lot.
> 
Ok Susan..the problem is configuring Fedora DS in cluster scenario; I
have two options:

1) Configuring Fedora DS in GFS file system so I can move DS from nodo1
to nodo2 if it for some reason fails

2) Taking advantage to multi master replication to make the same
thing...but in this case I have to configure floating IP and an entry in
dns that point to ip because I don''t want that client points directly
to
nodes

...Second option is better because in this way I can make a load
balancing...but even if I use real name and real ip address of nodo1 and
nodo2 the problem is SSL....of course, I can use wildcards as Rob
says...but in that case is a whole security

 
> Have 2 FDSs insist but then list all of them in the clients''
ldap.conf -- no problem.
Please can U explain this?...how can I configure clients'' ldap.conf to
listen both server in SSL mode?

thanks...like always

Alex

On mar, 2006-04-04 at 06:59 -0700, Susan wrote:
> 
> --- Alex aka Magobin <magobin@gmail.com> wrote:
> > Ok...omit cluster...if I have a server Fedora DS (A) that
it''s ssl
> > server too...until A is alone I configure my clients to point at this
> > server for authentication and I tested it works perfectly..now I want
> > another server for load balancing replicated in
> > multimaster(B)...now...how can I set up ssl for this scenario ? This
> 
> I have this exact setup.  2 FDSs, MMR over SSL.
> 
yes, you have this scenario like me...I maked my test with your help
too...but how can you authenticate clients?....They always point to cn
that exports CA...so if you maked CA on A...and you shutdown it DS is
still up in B but clients never login using B because CN is different
and they report that hostname does not match CN in peer certificate...

Alex

--- Alex aka Magobin <magobin@gmail.com> wrote:
> On mar, 2006-04-04 at 06:59 -0700, Susan wrote:
> > 
> > --- Alex aka Magobin <magobin@gmail.com> wrote:
> > > Ok...omit cluster...if I have a server Fedora DS (A) that
it''s ssl
> > > server too...until A is alone I configure my clients to point at
this
> > > server for authentication and I tested it works perfectly..now I
want
> > > another server for load balancing replicated in
> > > multimaster(B)...now...how can I set up ssl for this scenario ?
This
> > 
> > I have this exact setup.  2 FDSs, MMR over SSL.
> > 
> 
> yes, you have this scenario like me...I maked my test with your help
> too...but how can you authenticate clients?....They always point to cn
> that exports CA...so if you maked CA on A...and you shutdown it DS is
> still up in B but clients never login using B because CN is different
> and they report that hostname does not match CN in peer certificate...
If A is down, the clients go to B because of this entry:  (in the
client''s
/etc/openldap/ldap.conf):

HOST cnyldap01 cnjldap01

Now, I''m not verifying the FDS identity so I''m not using FQDN
but that''s a minor point.  If
cnyldap01 is down, it goes to cnjldap01 immediately.  There''s about a
half a second delay.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com