[Date Prev][Date Next]
New problem is ports I think
OK, I think I have some of my SSL woes fixed now. As it turns out few
of my problems were actually SSL problems rather they were with
Directory Adminstrator's poor management of group and uid numbers. That
and there was a bug in either /etc/pam.d/passwd or
/etc/pam.d/system-auth. I replaced both and a problem or two went away.
Anyway the new problem is ports I think.
My ldap server is configured to use port 389 for both encrypted and
Is there a way to split the encrypted traffic off to port 636?
The OpenLDAP FAQ-O-MATIC had this to say on the subject:
Start TLS [RFC 2830] is LDAPv3's mechanism for enabling TLS (SSL)
data confidentiality protection. The mechanism uses an extended
operation to coordinate the starting of TLS. While the mechanism is
designed for use with TLSv1, most implementations will fallback to
SSLv2 (and SSLv1) if necessary.
ldaps:// is a mechanism for coordinating use of SSL (TLS) with LDAP.
It requires use of special port, commonly 636, to coordinate
starting of SSL. Though originally designed for use with LDAPv2 and
SSLv2, many implementations support its use with LDAPv3 and TLSv1.
ldaps:// is deprecated in favor of Start TLS [RFC2830]. OpenLDAP 2.0
So the implication is that there might be a way to do it but that there
soon wont be. pGINA, as far as I can tell will not use the same port for
both encrypted and unencrypted communications. Right now the Windows
ldp utility connects and binds on port 389... I think it may even be
encrypted though since the utility reports the collection of base RSA
information. This and the Linux clients connect just fine with StartTLS