Ambiente: Mac OS X 10.6.3 instalação / importação de um servidor MacOS X 10.5.8 Open Directory Master. Após essa atualização, o LDAP + TLS falha em nossos clientes MacOS X 10.5, 10.6, CentOS, Debian e FreeBSD (Apache2 e PAM).
Teste usando ldapsearch:
ldapsearch -ZZ -H ldap://gnome.darkhorse.com -v -x -b "dc=darkhorse,dc=com" '(uid=donaldr)' uid
... falha com:
ldap_start_tls: Protocol error (2)
O teste adicionando "-d 9" falha com:
res_errno: 2, res_error: <unsupported extended operation>, res_matched: <>
Teste sem exigir STARTTLS ou com LDAPS:
ldapsearch -H ldap://gnome.darkhorse.com -v -x -b "dc=darkhorse,dc=com" '(uid=donaldr)' uid
ldapsearch -H ldaps://gnome.darkhorse.com -v -x -b "dc=darkhorse,dc=com" '(uid=donaldr)' uid
... tem sucesso com:
# donaldr, users, darkhorse.com
dn: uid=donaldr,cn=users,dc=darkhorse,dc=com
uid: donaldr
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
result: 0 Success
(Estamos especificando "TLS_REQCERT nunca" em /etc/openldap/ldap.conf)
Teste com o openssl:
openssl s_client -connect gnome.darkhorse.com:636 -showcerts -state
... é bem-sucedido:
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department
verify error:num=19:self signed certificate in certificate chain
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=MIS/CN=gnome.darkhorse.com
i:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department
1 s:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department
i:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department
---
Server certificate
-----BEGIN CERTIFICATE-----
<deleted for brevity>
-----END CERTIFICATE-----
subject=/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=MIS/CN=gnome.darkhorse.com
issuer=/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department
---
No client certificate CA names sent
---
SSL handshake has read 2640 bytes and written 325 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: D3F9536D3C64BAAB9424193F81F09D5C53B7D8E7CB5A9000C58E43285D983851
Session-ID-ctx:
Master-Key: E224CC065924DDA6FABB89DBCC3E6BF89BEF6C0BD6E5D0B3C79E7DE927D6E97BF12219053BA2BB5B96EA2F6A44E934D3
Key-Arg : None
Start Time: 1271202435
Timeout : 300 (sec)
Verify return code: 0 (ok)
Portanto, acreditamos que o daemon slapd está lendo nosso certificado e o está escrevendo para clientes LDAP.
O Apple Server Admin adiciona ProgramArguments ("-h ldaps: ///") a /System/Library/LaunchDaemons/org.openldap.slapd.plist e TLSCertificateFile, TLSCertificateKeyFile, TLSCACertificateFile e TLSCertificatePassphraseTool a / etc / openldap / slapd_macosxserver .conf ao ativar SSL na seção LDAP do serviço Open Directory. Embora isso pareça ser suficiente para LDAPS, parece que isso não é suficiente para o TLS. Comparar nossos arquivos de configuração 10.6 e 10.5 slapd.conf e slapd_macosxserver.conf não gera pistas. Substituir nosso certificado (gerado com um ca auto-assinado) por um certificado autoassinado gerado pelo Apple Server Admin resulta em nenhuma alteração nos resultados do ldapsearch.
Definindo -d para 256 em /System/Library/LaunchDaemons/org.openldap.slapd.plist logs:
4/13/10 5:23:35 PM org.openldap.slapd[82162] conn=384 op=0 EXT oid=1.3.6.1.4.1.1466.20037
4/13/10 5:23:35 PM org.openldap.slapd[82162] conn=384 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037"
4/13/10 5:23:35 PM org.openldap.slapd[82162] conn=384 op=0 RESULT tag=120 err=2 text=unsupported extended operation
Qualquer conselho de depuração é muito apreciado.
- Tom Kishel
P.S.
O e-mail da Apple confirma que eles podem reproduzir isso (LDAP + STARTLS falha, mas o LDAPS é bem-sucedido no 10.6, mas ambos funcionam no 10.5) e abriram um relatório interno de bugs.