[Date Prev][Date Next]
Solved one, new problem - RE: SSL Connection problems
Aha, finally, figured it out :) I just discoevred the tip of using -d127
with ldapsearch, and that gave me the missing piece of the puzzle.
Indeed, looks like the TLS subsystem not only wants the CN to match exactly
the name *I* provide, but ALSO the name obtained from a reverse lookup!
Here's the problem now:
When I connect locally from the same box as the server, the TLS subsystem
seems to reverse lookup only the hostname, as "grumbler" ... But from other
machines, the hostname is "grumbler.ccrs.nrcan.gc.ca"! So now it seems like
I can't have a certificate to satisfy both conditions! I can use "grumbler"
in the certificate, but that will only work for connections that come from
that same host, or from Netscape Directory SDK connections, that don't seem
to look at the reverse lookup issue. If I change the certificate to use the
FQDN, how I can't do local connections, because it doesn't match "grumbler"
Oh and BTW the "hostname" command on the box does return the FQDN, not just
The chicken and the egg problem ...
Anybody have any ideas on how to get around this one?
From: D.M.Lewney@sussex.ac.uk [mailto:D.M.Lewney@sussex.ac.uk]
Sent: Wednesday, October 31, 2001 4:50 AM
To: Doyon, Jean-Francois
Subject: Re: SSL Connection problems
"Doyon, Jean-Francois" wrote:
> Yes, it is! I use self signed certificates which I completely generated
> myself, so I'm aware of this issue, and yes I always use just "grumbler"
> instead of the FQDN.
> is "grumbler" the EXACT host name you are specifying on the
> command line? If not, then that your problem.
In an earlier message you said that you did not import the certificate
to a cert7.db file. I can't see how it would work unless you do this.
Also, (not sure about this but) I would change the CN of grumbler to the
string that is returned with a reverse DNS lookup of the machine.
Principal Systems Programmer, Computing Service
University of Sussex, Brighton BN1 9QJ. Tel: 01273 678354 Fax: 01273