[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP and SSL
- To: Openldap list <openldap-software@OpenLDAP.org>
- Subject: Re: LDAP and SSL
- From: Chasecreek Systemhouse <chasecreek.systemhouse@gmail.com>
- Date: Wed, 1 Dec 2004 13:15:06 -0500
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qA/CWljcDR85t/eWDKNIfI0jIxgB9bHWKBZo8mGsn9cAh0cKsjg3mNyIephXette6aniMErTkY37tivaBPdbBjcOvuOkvpB/J0FsT7cz2dImwwYPj1FKNKGeuLcc6EmUh355q4oVhO0qsAOePP7ml85sumRkU2JZMSdKola2CWc=
- In-reply-to: <1101920759.12496.23.camel@localhost>
- References: <91f88ee204112810284d745e7f@mail.gmail.com> <91f88ee204113008267b58d0d5@mail.gmail.com> <1101843349.4634.22.camel@localhost> <91f88ee2041130133053273c4f@mail.gmail.com> <91f88ee2041130133526288008@mail.gmail.com> <91f88ee2041130141335739ad@mail.gmail.com> <91f88ee2041130154229e592e0@mail.gmail.com> <1101896882.9372.54.camel@localhost> <41ADDB8E.30808@symas.com> <1101920759.12496.23.camel@localhost>
On Wed, 01 Dec 2004 18:05:59 +0100, Tony Earnshaw <tonye@billy.demon.nl> wrote:
> ons, 01.12.2004 kl. 15.56 skrev Howard Chu:
> > The fact that the server hangs cannot be caused by any content of the
> > certificate. This whole line of pursuit is pointless.
I agree with this as I have many years experience with SSL (mod and
open) with-in the Apache realm. My own inexperience with OpenLDAP was
contributory and likely is *still* the primary factor in my troubles
with OpenLDAP.
> is working, it's still hanging.
Actually, it is not hanging at present, but I believe correcting the
DN while creation of the LDAP database and using SubjectAltName (509)
-
subjectAltName=IP:68.214.83.106,IP:192.168.2.2,DNS:debian.insecurity.org,DNS:*.insecurity.org
has helped me band-aide it into working.
> The fact remains that Bill is defining insecurity.org in 2 discrete
> zones and that, in any sysadmin's language, is a no-no.
>
That is very likely true as I have two completely separate internet
hosting sites. However, I believe that you are referring to my use of
a privately seen 192.168.x.x and publically seen server. I'm no
expert by any stretch but I feel that whether the host file points to
debian.internal and the the cert points to debian.external would only
affect things if I would to use TLS_REQCERT "demand" instead of
"allow" ?
Granted, I'm not an expert and I can only do sysadmin work and
research issues to the best of my limited abilities.
A bit of history:
The insecurity.org server/domain is very likely *spammed* world-wide
as it is a domain originally owned by some developers who were very
verbal in the earlier days (I have owned insecurity.org since 1998 -
when I was the webmaster/data security specialist at FCCJ.EDU - but it
has only been publically accessible since 2003.)
No e-mail *ever* originates from there (I get hundred of complaints
per day however which state otherwise.) In summary, insecurity.org
is NOT to be trusted =) (I mean hey, it is *insecurity*, after all.)
It is by definition my own personal play ground for testing and anyone
who believes it (the domain) to be trusted (beyond key projects I work
on for various clients) should stop trusting it and revoke any
certificates or CAs they may be using or in possession of.
In regards to *why* the server would only hang during the transition
from TLS to SSL -- this is likely an unknown/undefined bug of usg
OpenLDAP/ TLS-SSL on the Debian Ultrasparc architecture and very
likely directly related to version levels used during the packaging
process (now I am gonna get beat up by the Debian developers. I hope
not anyway.)
Linux itself may be open, but (all software developers -- in general)
*our* development efforts have been somewhat proprietary in respect to
platforms and compatibility...
Cheers =)
--
WC -Sx- Jones
http://insecurity.org/