[Fedora-directory-users] Hostname does not match CN....

[Rob Crittenden]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20060404/6ac33920/attachment.bin>