Hi there guys.
Well, I'm making some progress securing my ldap server by reading the list and the oficial how-to, but I'm facing a new problem. So, I've created the certificates using this link.
http://www.openldap.org/faq/index.cgi?_highlightWords=self%20signed&file...
Then in my slapd.conf I've got. (server side )
#security ssf=128 update_ssf=128 simple_bind=128 #TLSCipherSuite HIGH:MEDIUM:+SSLv3:+SSLv2:+RSA:+TLSv1
security ssf=1 update_ssf=112 simple_bind=64 TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /etc/ssl/cacert.pem TLSCertificateFile /etc/ssl/servercrt.pem TLSCertificateKeyFile /etc/ssl/serverkey.pem TLSVerifyClient never
ldap.conf (server side )
/etc/openldap/ldap.conf
BASE dc=netwarrior,dc=com URI ldaps://linux:636 HOST linux:636
#BINDDN dc=netwarrior,dc=netwarrior
#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never
TLS_CACERT /etc/ssl/cacert.pem TLS_REQCERT never
With this configuration everything seems to work fine, but now, what I want to do is to force my clients to use a certificate to connect, so, if I did not misundestrand it wrong, the demand options is a must.
So, when I change TLSVerifyClient never to demand. I've get the following ( alway on my server )
linux:/etc/ssl # openssl s_client -connect localhost:636 -state -showcerts -CAfile 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=AU/ST=Some State/L=City/O=Internet Widgits Pty Ltd/OU=Section/CN=localhost/emailAddress= test@company.com verify return:1 depth=0 /C=AU/ST=Some Even State/L=City/O=Internet Widgits Pty Ltd/OU=Section/CN=localhost/emailAddress=test@company.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate 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 SSL3 alert read:fatal:handshake failure SSL_connect:failed in SSLv3 read finished A 6274:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 6274:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:
Making some searches in the mailing list I found a guy who had the same problem, and he was told that with the demand option we force slapd to ask for a client certificate, and that the client certificate is a must. Well, now, I do not get it, cuz I'm authenticating against myself, with teh certificates I generated before, maybe ai have to generate a separate pair of certificates, do not know.
With never, and always it works as suggested by someone in the list, who said that first we need try a lower option (never, allow ) to test if the server works ) my problem is with the demand option.
What am I mising here? Sorry for my stupidity, I do not get it yet.
Thanks in advance and or your valuable time.
Greets.
Net Warrior wrote:
With this configuration everything seems to work fine, but now, what I want to do is to force my clients to use a certificate to connect, so, if I did not misundestrand it wrong, the demand options is a must.
So, when I change TLSVerifyClient never to demand. I've get the following ( alway on my server )
linux:/etc/ssl # openssl s_client -connect localhost:636 -state -showcerts -CAfile cacert.pem
This invocation of s_client didn't provide the -cert or -key options, so no client certificate was used. Naturally the handshake fails.
Learn to use the OpenSSL tools.
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=AU/ST=Some State/L=City/O=Internet Widgits Pty Ltd/OU=Section/CN=localhost/emailAddress= test@company.com mailto:test@company.com verify return:1 depth=0 /C=AU/ST=Some Even State/L=City/O=Internet Widgits Pty Ltd/OU=Section/CN=localhost/emailAddress=test@company.com mailto:test@company.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate 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 SSL3 alert read:fatal:handshake failure SSL_connect:failed in SSLv3 read finished A 6274:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 6274:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:
Making some searches in the mailing list I found a guy who had the same problem, and he was told that with the demand option we force slapd to ask for a client certificate, and that the client certificate is a must. Well, now, I do not get it, cuz I'm authenticating against myself, with teh certificates I generated before, maybe ai have to generate a separate pair of certificates, do not know.
With never, and always it works as suggested by someone in the list, who said that first we need try a lower option (never, allow ) to test if the server works ) my problem is with the demand option.
What am I mising here? Sorry for my stupidity, I do not get it yet.
Thanks in advance and or your valuable time.
Greets.
Hi.
Using the -cert or -key options returns the same error, this error arises only when I use the TLSClientVerify demand option as I explained before.
Any clues?
Thanks for your time.
2006/11/6, Howard Chu hyc@symas.com:
Net Warrior wrote:
With this configuration everything seems to work fine, but now, what I want to do is to force my clients to use a certificate to connect, so, if I did not misundestrand it wrong, the demand options is a must.
So, when I change TLSVerifyClient never to demand. I've get the following ( alway on my server )
linux:/etc/ssl # openssl s_client -connect localhost:636 -state -showcerts -CAfile cacert.pem
This invocation of s_client didn't provide the -cert or -key options, so no client certificate was used. Naturally the handshake fails.
Learn to use the OpenSSL tools.
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=AU/ST=Some State/L=City/O=Internet Widgits Pty Ltd/OU=Section/CN=localhost/emailAddress= test@company.com mailto:test@company.com verify return:1 depth=0 /C=AU/ST=Some Even State/L=City/O=Internet Widgits Pty Ltd/OU=Section/CN=localhost/emailAddress=test@company.com mailto:test@company.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate 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 SSL3 alert read:fatal:handshake failure SSL_connect:failed in SSLv3 read finished A 6274:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 6274:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:
Making some searches in the mailing list I found a guy who had the same problem, and he was told that with the demand option we force slapd to ask for a client certificate, and that the client certificate is a must. Well, now, I do not get it, cuz I'm authenticating against myself, with teh certificates I generated before, maybe ai have to generate a separate pair of certificates, do not know.
With never, and always it works as suggested by someone in the list, who said that first we need try a lower option (never, allow ) to test if the server works ) my problem is with the demand option.
What am I mising here? Sorry for my stupidity, I do not get it yet.
Thanks in advance and or your valuable time.
Greets.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
openldap-software@openldap.org