[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RHEL 5 will not do TLS/SSL authentication
- To: Dat Duong <datduong2000@yahoo.com>
- Subject: Re: RHEL 5 will not do TLS/SSL authentication
- From: Buchan Milne <bgmilne@staff.telkomsa.net>
- Date: Wed, 3 Sep 2008 09:29:01 +0200
- Cc: openldap-technical@openldap.org
- Content-disposition: inline
- In-reply-to: <807196.70822.qm@web54606.mail.re2.yahoo.com>
- References: <807196.70822.qm@web54606.mail.re2.yahoo.com>
- User-agent: KMail/1.10.0 (Linux/2.6.26.3-desktop-1mnb; KDE/4.1.0; x86_64; ; )
On Tuesday 02 September 2008 21:26:10 Dat Duong wrote:
> Also I did the certs test on the client RHEL5:
And it failed for some reason, meaning this isn't an OpenLDAP problem, but an
OpenSSL problem.
>
> # openssl s_client -connect xxx.xxx.xxx.xxx:636 -showcerts -state -CAfile
> /etc/openldap/cacerts/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=California/O=/OU=/CN=ldap01.example.com/emailAddress=dduong@yahoo.
>com verify return:1
> depth=0 /C=US/ST=California/L=Mountain
> View/O=/OU=/CN=ldap01.example.com/emailAddress=dduong@yahoo.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
At this point, I get:
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/C=ZA ....
> SSL3 alert read:fatal:bad record mac
> SSL_connect:failed in SSLv3 read finished A
> 29751:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record
> mac:s3_pkt.c:1057:SSL alert number 20 29751:error:140790E5:SSL
> routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
>
So it looks like a problem with the certificate.
>
>
> ----- Original Message ----
> From: Dat Duong <datduong2000@yahoo.com>
> To: Buchan Milne <bgmilne@staff.telkomsa.net>;
> openldap-technical@openldap.org Sent: Tuesday, September 2, 2008 12:14:12
> PM
> Subject: Re: RHEL 5 will not do TLS/SSL authentication
>
>
> I'm using ldapsearch from openldap-2.4.xx on Solaris 10. I can do the
> ldapsearch with -ZZ option and I can get the result back just fine.
> However, on my RHEL 5 using the native ldapsearch with -ZZ and a -d1
> options for debug, will give some errors below. I can do a ldapsearch
> without the -ZZ and it just run fine.
>
> ERROR:
>
> TLS trace: SSL_connect:before/connect initialization
> TLS trace: SSL_connect:SSLv2/v3 write client hello A
> TLS trace: SSL_connect:SSLv3 read server hello A
> TLS certificate verification: depth: 1, err: 19, subject:
> /C=US/ST=California/O=/OU=/CN=ldap01.example.com/emailAddress=dduong@yahoo.
>com, issuer:
> /C=US/ST=California/O=/OU=/CN=ldap01.example.com/emailAddress=dduong@yahoo.
>com TLS certificate verification: Error, self signed certificate in
> certificate chain TLS trace: SSL3 alert write:fatal:unknown CA
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS: can't connect.
> ldap_perror
> ldap_start_tls: Connect error (-11)
> additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
>
> **** Here is how I setup the TLS:
>
> On the Client side, I copied over the cacert.pem from the server to
> /etc/openldap/cacerts/cacert.pem. A look at the cacert.pem show:
>
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> b1:fe:10:70:c6:7e:fe:24
> Signature Algorithm: sha1WithRSAEncryption
> Issuer: C=US, ST=California, O=, OU=ODIN,
> CN=ldap01.example.com/emailAddress=dduong@yahoo.com Validity
> Not Before: Sep 2 17:31:55 2008 GMT
> Not After : Sep 2 17:31:55 2011 GMT
> Subject: C=US, ST=California, O=, OU=,
> CN=ldap01.example.com/emailAddress=dduong@yahoo.com Subject Public Key
> Info:
> Public Key Algorithm: rsaEncryption
> RSA Public Key: (1024 bit)
> Modulus (1024 bit):
> 00:bf:eb:3e:89:2b:aa:4f:2f:31:0e:45:8f:7e:1b:
> c6:3f:49:ae:62:ea:1b:fe:4a:71:60:38:b9:a8:02:
> eb:7e:e4:3b:a6:cb:bb:9c:bb:23:b7:86:11:87:b4:
> 2d:59:99:33:20:f4:90:dd:90:52:b0:59:1d:e4:e4:
> 68:03:7f:d2:7f:0b:9d:e7:10:81:9d:d0:ef:d8:98:
> dc:49:a0:2b:c1:71:5d:2c:63:34:e5:38:7c:13:11:
> f4:cf:bd:0b:4a:2b:2c:03:23:9a:e1:67:6d:d9:ae:
> c6:60:ac:85:41:98:43:03:28:fa:e1:e6:76:3e:69:
> 8f:66:de:ca:56:ff:de:33:4d
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> 7C:49:79:29:08:EE:77:8D:C0:93:9B:44:62:63:F6:3F:FD:26:1E:E9
> X509v3 Authority Key Identifier:
>
> keyid:7C:49:79:29:08:EE:77:8D:C0:93:9B:44:62:63:F6:3F:FD:26:1E:E9
> DirName:/C=US/ST=California/O=/OU=ODIN/CN=ldap01.example.com/emailAddress=d
>duong@yahoo.com serial:B1:FE:10:70:C6:7E:FE:24
>
> X509v3 Basic Constraints:
> CA:TRUE
> Signature Algorithm: sha1WithRSAEncryption
> 4f:c5:42:62:d2:75:38:0f:cd:8c:18:a3:6f:d5:9b:92:23:4b:
> a6:74:f9:e1:fd:9a:2f:43:ee:25:d6:f4:33:cb:2c:e1:f9:f2:
> 1c:13:87:f4:cf:1c:68:ef:99:a3:5e:8c:4c:73:bd:e1:43:80:
> 14:bb:dc:96:12:bf:93:4c:03:f3:f5:0d:bb:2f:92:26:fb:ae:
> 54:62:de:cc:0a:d5:f1:cf:9a:b0:61:53:eb:6c:76:a4:f5:f2:
> 9a:90:a6:a8:cc:db:f6:ba:aa:8c:ad:f5:4d:63:d2:3a:4b:e9:
> 45:41:73:ac:5b:a8:ab:7f:8f:41:07:5d:02:73:a2:b9:9d:27:
> 87:67
> -----BEGIN CERTIFICATE-----
> .
> .
> .
> .
> .
> -----END CERTIFICATE-----
>
>
> *****On the client RHEL5, /etc/openldap/ldap.conf look like this:
>
> #
> # LDAP Defaults
> #
>
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
>
> #BASE dc=example, dc=com
> #URI ldap://ldap.example.com ldap://ldap-master.example.com:666
>
> #SIZELIMIT 12
> #TIMELIMIT 15
> #DEREF never
> URI ldap://xxx.xxx.xxx.xxx/
> BASE dc=foobar,dc=example,dc=com
> TLS_CACERTDIR /etc/openldap/cacerts
If you use this directive (and not TLS_CACERT), then you must have created the
hashes in /etc/openldap/cacerts, using c_rehash (on RHEL, you must install
openssl-perl to get this), e.g.
c_rehash /etc/openldap/cacerts
>
>
> ***** On Client RHEL5, the ldap.conf located at /etc/ldap.conf look like
> this:
I've removed the useless lines of commented defaults ....
> base dc=example,dc=com
>
> timelimit 120
>
> bind_timelimit 120
>
> idle_timelimit 3600
>
> nss_base_passwd ou=People,dc=foobar,dc=example,dc=com?one
> nss_base_shadow ou=People,dc=foobar,dc=example,dc=com?one
> nss_base_group ou=Group,dc=foobar,dc=example,dc=com?one
> nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon
> ssl start_tls
> tls_checkpeer yes
> tls_cacertfile /etc/openldap/cacerts/cacert.pem
>
> uri ldap://ldap01.example.com/
> #ssl no
> tls_cacertdir /etc/openldap/cacerts
> pam_password crypt
This should work, if your certificate wasn't broken.
> On the LDAP server, This is how I create CA and certificates:
>
> #openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout
> server.pem -days 365
I'm wondering if some files left over by the order in which you did things
caused a problem.
> ## create self signed certs
>
> ## generate root signing cert:
> /usr/share/ssl/misc/CA.pl -newca
Did you really give your CA the subject: C=US, ST=California, O=,
OU=,CN=ldap01.example.com/emailAddress=dduong@yahoo.com
? Why did you make it so close to that of the LDAP server's certificate ?
>
> ## create a signing req for the server
> openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem
>
> ## sign it with root CA
> # /usr/local/ssl/misc/CA.sh -sign
>
> ## call the cert/key something useful
> mv newcert.pem ldap01-cert.pem
> mv newreq.pem ldap01-key.pem
>
> Copy ldap01-cert.pem and ldap01-key.pem and the root CA (in
> demoCA/cacert.pem) to server:/opt/openldap/keys
>
> chmod 400 *
>
> Add these config params:
>
> TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3
> TLSCACertificateFile /usr/local/etc/openldap/keys/cacert.pem
> TLSCertificateFile /opt/openldap/keys/ldap01-cert.pem
> TLSCertificateKeyFile /opt/openldap/keys/ldap01-key.pem
> TLSVerifyClient never
Can you verify the certificate on the server? E.g.:
# openssl verify -CAfile /usr/local/etc/openldap/keys/cacert.pem
/opt/openldap/keys/ldap01-cert.pem
Regards,
Buchan