[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Last attempt at TLS/SSL
Well I am just about at the end of my rope with openldap and SSL/TLS. I've
tried
tweaking, rebuilding, generated tons of certs and I am about to call it
quits and
switch over to using the Sun One/iPlanet directory server. I'll see if
anyone can
make sense out of the current situation I am in because I would prefer to
stay
with openldap, but the SSL/TLS component with no commercial support is just
about to scare me away.
Here is what I'm using:
Solaris 8
padl pam_ldap and nss_ldap
openldap 2.1.21
openssl 0.9.7
The goal for now is to get users' /etc/passwd and /etc/shadow information
into ldap and use it to authenticate against in ssh sessions, and to have
the
ldap part of those transactions be encrypted.
Here is what is happening. I generated new certs as follows:
mkdir /var/tmp/certs
cd /var/tmp/certs
/usr/local/ssl/misc/CA.pl -newca
/usr/local/ssl/misc/CA.pl -newreq
/usr/local/ssl/misc/CA.pl -signreq
The CN I used matches the FQDN of the host I'm using.
Then I renamed the newreq.pem to ldapkey.pem and newcert.pem to
ldapcert.pem.
The lines I then added to slapd.conf were:
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /var/tmp/certs/ldapcert.pem
TLSCertificateKeyFile /var/tmp/certs/ldapkey.pem
TLSCACertificateFile /var/tmp/certs/demoCA/cacert.pem
TLSVerifyClient never
Now I would really like to see just once openldap actually decide one of the
certs I've
made is acceptable. It would make my week. What is happening now though
makes
me believe that something is definitely fishy in terms of how openldap
decides a cert
is valid or not. As far as openssl is concerned, this cert is OK (well at
least it is if
I run ldaps):
openssl s_client -connect localhost:636 -showcerts -state -CAfile
/var/tmp/certs/demoCA/cacert.pem
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=New York/L=White
Plains/O=Starwood/OU=IT/CN=wp-app-3.webtech.com
verify return:1
depth=0 /C=US/ST=New York/L=White
Plains/O=Starwood/OU=IT/CN=wp-app-3.webtech.com
verify return:1
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=New York/L=White
Plains/O=Starwood/OU=IT/CN=wp-app-3.webtech.com
i:/C=US/ST=New York/L=White
Plains/O=Starwood/OU=IT/CN=wp-app-3.webtech.com
-----BEGIN CERTIFICATE-----
MIIDYTCCAsqgAwIBAgIBATANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJVUzER
MA8GA1UECBMITmV3IFlvcmsxFTATBgNVBAcTDFdoaXRlIFBsYWluczERMA8GA1UE
ChMIU3Rhcndvb2QxCzAJBgNVBAsTAklUMR0wGwYDVQQDExR3cC1hcHAtMy53ZWJ0
ZWNoLmNvbTAeFw0wMzA2MjUyMDMyMTlaFw0wNDA2MjQyMDMyMTlaMHYxCzAJBgNV
BAYTAlVTMREwDwYDVQQIEwhOZXcgWW9yazEVMBMGA1UEBxMMV2hpdGUgUGxhaW5z
MREwDwYDVQQKEwhTdGFyd29vZDELMAkGA1UECxMCSVQxHTAbBgNVBAMTFHdwLWFw
cC0zLndlYnRlY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOH2bi
A0Nx8zSv0JuC421TjBLYZQ25StoSFDSWMHR3/x2JtxtuT7XdmR8sPhjZD5Cam5zE
dbpmRjJJgNzSrBfSfPc2EeQ49uOXahjuIYqdrlaxRDs/WW2bDIXLtAjD78wVPQIf
cZa+y/Vl1LtiQ+YbNJPARn1lkYB9mfmd2SEqFQIDAQABo4H+MIH7MAkGA1UdEwQC
MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl
MB0GA1UdDgQWBBT0CRxiTTQy9YUZYuoP0dKFbNMYxjCBoAYDVR0jBIGYMIGVgBTv
KfA/Ea6UIBbqWBACzDPOPbDekqF6pHgwdjELMAkGA1UEBhMCVVMxETAPBgNVBAgT
CE5ldyBZb3JrMRUwEwYDVQQHEwxXaGl0ZSBQbGFpbnMxETAPBgNVBAoTCFN0YXJ3
b29kMQswCQYDVQQLEwJJVDEdMBsGA1UEAxMUd3AtYXBwLTMud2VidGVjaC5jb22C
AQAwDQYJKoZIhvcNAQEEBQADgYEAaKtlVLxpg09nyOZlONFV8XikvXWe2KfzqRuj
IQcAag+/++BPUD+R8+JVMzrAVRCXPK/kVYN6ijSTDcJl5K9ZJW55EX6M6OBGzQTf
K251iYS64vok8SmKoFcIe0zHpWEI5AibbspOAeaiGM3cc5Z1kCi6qFbL0f+TNg8b
zd+87PA=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=New York/L=White
Plains/O=Starwood/OU=IT/CN=wp-app-3.webtech.com
issuer=/C=US/ST=New York/L=White
Plains/O=Starwood/OU=IT/CN=wp-app-3.webtech.com
---
No client certificate CA names sent
---
SSL handshake has read 1031 bytes and written 346 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
C980AAE50D6D47D6B9F09AE6483A9566A298E758AC7CE14172513AFBFAEF6867
Session-ID-ctx:
Master-Key:
C7E6EFF159AAF1016A5F98F34C40E2A6755B13D724BE2E76210A84C44C6B469905E4D5C0C077
7E9B5EEA5A3B669B7050
Key-Arg : None
Start Time: 1056643058
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
So there's one piece of software, openssl, saying "your cert is cool". Now
if I try to run ldapsearch
and pass it -H "ldaps://wp-app-3.webtech.com", it will fail with this error:
ldap_bind: Can't contact LDAP server (81)
additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
If I add the line "tls_reqcert never" to ldap.conf, then the ldapsearches
will work. What could
be causing openldap to think the cert can't be verified when openssl says
it's fine? I've tried turning
on tls_checkpeer and pointing tls_cacertfile to my demoCA cacert.pem and it
still fails (it also fails
with tls_checkpeer turned off).
Regardless, I would actually be perfectly happy to leave "tls_reqcert" set
to "never" if everything would
work. But even with ldapsearches working, people can't log in with ssh, and
the errors I see when I
run slapd with -d9 -h "ldaps:///" are:
TLS trace: SSL_accept:before/accept initialization
TLS trace: SSL_accept:error in SSLv2/v3 read client hello A
TLS: can't accept.
TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
s23_srvr.c:585
connection_read(8): TLS accept error error=-1 id=1, closing
What's wrong with this picture? I've never been so frustrated with a piece
of software as I am with
openldap and TLS/SSL. Any advice would be greatly appreciated!
This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged.
The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be
aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received
this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field.