¿Cómo importar certificado para Apache + LDAPS?

2024-6-19 • tag-icon

¿Cómo importar certificado para Apache + LDAPS?

Estoy intentando que ldaps funcione a través de Apache 2.2.17 (Windows Server 2008). Si uso ldap (texto sin formato), mi configuración funciona muy bien.

LDAPTrustedGlobalCert CA_DER C:/wamp/certs/Trusted_Root_Certificate.cer
LDAPVerifyServerCert Off
<Location />
    AuthLDAPBindDN "CN=corpsvcatlas,OU=Service Accounts,OU=u00958,OU=00958,DC=hca,DC=corpad,DC=net"
    AuthLDAPBindPassword ..removed..
    AuthLDAPURL "ldaps://gc-hca.corpad.net:3269/dc=hca,dc=corpad,dc=net?sAMAccountName?sub"
    AuthType Basic
    AuthName "USE YOUR WINDOWS ACCOUNT"
    AuthBasicProvider ldap
    AuthUserFile /dev/null
    require valid-user
</Location>

También probé otras opciones de cifrado además de CA_DER solo para estar seguro, sin suerte.

Finalmente, también necesitaba esto con Apache Tomcat. Para Tomcat utilicé Tomcat JRE y ejecuté una línea como esta:

keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias mycert -file Trusted_Root_Certificate.cer

Después de hacer la línea anterior, ldaps funcionó mejor a través de Tomcat. Esto me permite saber que mi certificado está bien.

Actualización: Ambos módulos ldap están activados, ya que usar ldap en lugar de ldap funciona bien.

Cuando ejecuto un clon de git, se devuelve este error:

C:\Temp>git clone http://eqb9718@localhost/git/Liferay.git
Cloning into Liferay...
Password:
error: The requested URL returned error: 500 while accessing http://eqb9718@loca
lhost/git/Liferay.git/info/refs
fatal: HTTP request failed

access.log tiene esto:

127.0.0.1 - eqb9718 [23/Nov/2011:18:25:12 -0600] "GET /git/Liferay.git/info/refs service=git-upload-pack HTTP/1.1" 500 535
127.0.0.1 - eqb9718 [23/Nov/2011:18:25:33 -0600] "GET /git/Liferay.git/info/refs HTTP/1.1" 500 535

apache_error.log no tiene nada. ¿Hay algún registro más detallado que pueda activar o mejores pruebas que realizar?

Actualización 2: Puedo ejecutar Wireshark en el servidor Apache y puedo ver claramente la conexión saliente, pero realmente no puedo entender nada más. No soy un gurú de Wireshark, solo parece jerga.

Además, utilicé el navegador ldap para verificar que ldap esté funcionando perfectamente desde la máquina.

Actualización 3: activé el registro de Apache para depurar y este es el error que aparece:

[3016] auth_ldap authenticate: user eqb9718 authentication failed; URI /git/Liferay.git/info/refs [LDAP: ldap_simple_bind_s() failed][Server Down]

Ahora tenga en cuenta que en esta misma máquina Server 2008 puedo usar el navegador LDAP para conectarme mediante ldaps al puerto 3269 y no hay nada "inactivo". ¿Qué nos dice ese error?

Actualización 4: Aquí están los resultados de ejecutar openssl s_client -connect gc-hca.corpad.net: 3269 -showcerts:http://pastebin.com/2yEGN4C1

También probé el comando openssl yendo directamente a un controlador de dominio en el puerto 636 que funciona y lo probé en mi httpd.conf que produce el mismo error. No sé si es importante tener en cuenta que cuando voy directamente a un controlador (389 o 636) tengo que agregar un contenedor a la URL como ou=group,dc=hca,etc. Eso hace que el uso del GC sea imprescindible. Debe ser un error en mod_ldap ya que encontré esa solución en muchas otras publicaciones.

Actualización 5: inicié Apache manualmente en lugar de mediante un servicio y esta es la depuración de ldap que se está imprimiendo:

C:\wamp\bin\apache\Apache2.2.17\bin>httpd
[Thu Nov 24 19:19:08 2011] [debug] util_ldap.c(1769): LDAP: SSL verify server ce
rtificate - FALSE
[Thu Nov 24 19:19:08 2011] [debug] mod_authnz_ldap.c(1010): [3144] auth_ldap url
parse: `ldaps://gc-hca.corpad.net:3269/dc=hca,dc=corpad,dc=net?sAMAccountName?s  
ub?(objectClass=*)', Host: gc-hca.corpad.net:3269, Port: 3269, DN: dc=hca,dc=cor
pad,dc=net, attrib: sAMAccountName, scope: subtree, filter: (objectClass=*), con
nection mode: using SSL

Respuesta1

Estás LDAPVerifyServerCert Offvolviendo inerte la configuración raíz confiable, por lo que la confianza no es un problema.

¿Existe realmente esa cantidad de espacios OU=Service Accounts?

¿Y tienes mod_ldapy mod_authnz_ldaphabilitado?

Si ninguno de estos es el problema, ¿puedes consultar tus registros de errores en busca de algo útil?

Respuesta1

información relacionada