[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 unencrypted traffic.
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
   supports both.


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 enabled.