Re: Client authentication problem
Hi Again., This is what I found from the log file you sent..is this pointing to the same CA cert itcilo-ca.crt, I put it in ssl.crt ? debug] ssl_engine_init.c(1112): CA certificate: /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_init.c(703): Configuring server certificate chain (1 CA certificate) You will not find that option SSL_VERIFY_FAIL_IF_NO_PEER_CERT thats openssl macro..I thought you had written your own server.. found this link http://httpd.apache.org/docs-2.0/mod/mod_ssl.html perhaps your already aware of this..but sorry no idea abt apache mod ssl :) Thanks Gayathri Hi. Hi, Thanks for the reply Have you imported the CA of the client cert on the server side? Yes, it's the itcilo-ca.crt, I put it in ssl.crt (self-signed) A verify depth of 1 has been set, which could mean that the client cert is self signed? Can you set it to some higher value and try? Yes, it's a self signed certificate, I tried with a higher values (5) without any success Also can you check whether the option SSL_VERIFY_FAIL_IF_NO_PEER_CERT? I searched for the string on my server but can not find it. In which should I find it? Can you retry the same thing from Mozilla or something. I tried with firefox with the same result is your server mod_ssl? Yes, apache 2 on suse includes it by default. I turned the loglevel to debug and attached the log file below, just in case There are a lot of Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: Handshake: start [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: before/accept initialization [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_io.c(1518): OpenSSL: I/O error, 11 bytes expected to read on BIO#836ffc8 [mem: 8377648] [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1830): OpenSSL: Exit: error in SSLv2/v3 read client hello A [Wed Jul 13 11:48:34 2005] [info] (70014)End of file found: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 closed with abortive shutdown(server tomcat-ssl.itcilo.org:443, client ::1) [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 established (server tomcat-ssl.itcilo.org:443, client ::1) [Wed Jul 13 11:48:34 2005] [info] Seeding PRNG with 136 bytes of entropy and then [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: Handshake: start [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: before/accept initialization [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: read 11/11 bytes from BIO#8372060 [mem: 83776d8] (BIO dump follows) [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 80 67 01 03 00 00 4e 00-00 00 10 .gN | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: read 94/94 bytes from BIO#8372060 [mem: 83776e3] (BIO dump follows) [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 01 00 80 03 00 80 07 00-c0 06 00 40 02 00 80 04 [EMAIL PROTECTED] | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0010: 00 80 00 00 39 00 00 38-00 00 35 00 00 33 00 00 9..8..5..3.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0020: 32 00 00 04 00 00 05 00-00 2f 00 00 16 00 00 13 2/.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0030: 00 fe ff 00 00 0a 00 00-15 00 00 12 00 fe fe 00 | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0040: 00 09 00 00 64 00 00 62-00 00 03 00 00 06 69 13 d..b..i. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0050: 73 ff 86 72 4e 7d 52 4a-fe 9a b9 38 b9 1es..rN}RJ...8.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 read client hello A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write server hello A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write certificate A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1185): handing out temporary 1024 bit DH key [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write key exchange A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write certificate request A [Wed Jul 13 11:48:42 2005] [debug]
Re: Client authentication problem
Hey can you try setting verify depth to Zero and not pointing to any CA cert i.e SSLCACertificatePath pointing to null? Thanks --Gayathri Hi Again., This is what I found from the log file you sent..is this pointing to the same CA cert itcilo-ca.crt, I put it in ssl.crt ? debug] ssl_engine_init.c(1112): CA certificate: /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_init.c(703): Configuring server certificate chain (1 CA certificate) You will not find that option SSL_VERIFY_FAIL_IF_NO_PEER_CERT thats openssl macro..I thought you had written your own server.. found this link http://httpd.apache.org/docs-2.0/mod/mod_ssl.html perhaps your already aware of this..but sorry no idea abt apache mod ssl :) Thanks Gayathri Hi. Hi, Thanks for the reply Have you imported the CA of the client cert on the server side? Yes, it's the itcilo-ca.crt, I put it in ssl.crt (self-signed) A verify depth of 1 has been set, which could mean that the client cert is self signed? Can you set it to some higher value and try? Yes, it's a self signed certificate, I tried with a higher values (5) without any success Also can you check whether the option SSL_VERIFY_FAIL_IF_NO_PEER_CERT? I searched for the string on my server but can not find it. In which should I find it? Can you retry the same thing from Mozilla or something. I tried with firefox with the same result is your server mod_ssl? Yes, apache 2 on suse includes it by default. I turned the loglevel to debug and attached the log file below, just in case There are a lot of Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: Handshake: start [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: before/accept initialization [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_io.c(1518): OpenSSL: I/O error, 11 bytes expected to read on BIO#836ffc8 [mem: 8377648] [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1830): OpenSSL: Exit: error in SSLv2/v3 read client hello A [Wed Jul 13 11:48:34 2005] [info] (70014)End of file found: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 closed with abortive shutdown(server tomcat-ssl.itcilo.org:443, client ::1) [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 established (server tomcat-ssl.itcilo.org:443, client ::1) [Wed Jul 13 11:48:34 2005] [info] Seeding PRNG with 136 bytes of entropy and then [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: Handshake: start [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: before/accept initialization [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: read 11/11 bytes from BIO#8372060 [mem: 83776d8] (BIO dump follows) [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 80 67 01 03 00 00 4e 00-00 00 10 .gN | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: read 94/94 bytes from BIO#8372060 [mem: 83776e3] (BIO dump follows) [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 01 00 80 03 00 80 07 00-c0 06 00 40 02 00 80 04 [EMAIL PROTECTED] | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0010: 00 80 00 00 39 00 00 38-00 00 35 00 00 33 00 00 9..8..5..3.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0020: 32 00 00 04 00 00 05 00-00 2f 00 00 16 00 00 13 2/.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0030: 00 fe ff 00 00 0a 00 00-15 00 00 12 00 fe fe 00 | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0040: 00 09 00 00 64 00 00 62-00 00 03 00 00 06 69 13 d..b..i. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0050: 73 ff 86 72 4e 7d 52 4a-fe 9a b9 38 b9 1es..rN}RJ...8.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 read client hello A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write server hello A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write certificate A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1185): handing out temporary 1024 bit DH key [Wed Jul 13 11:48:42 2005]
Re: Client authentication problem
The above indicates that. Make sure client cert processing is done correctly on the server side. If it is a program failure, then you need to get the programmer to debug the program. Thank you for your answer. I'm not sure what you intend with program failure: the pages served by this virtual host are for the time being only static html pages. The only programs involed are apache, openssl and the browser I tried the following command found in the openssl faq openssl s_client -connect tomcat-ssl.itcilo.org:443 -state -debug and it finished with the following error: SSL_connect:SSLv3 write client key exchange A write to 080B07A0 [080BFFC0] (6 bytes = -1 (0x)) SSL_connect:error in SSLv3 write finished A SSL_connect:error in SSLv3 write finished A I've googled a little bit but didn't really find something that allowed me to solve my problem. host:~/CA # openssl s_client -connect myhost:443 -showcerts -CAfile /root/CA/itcilo-ca.crt CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17680:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 17680:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: I also tried passing to openssl s_client the client certificate and key, with also an error, as you can see below: dolphin:~/CA # openssl s_client -cert lams.crt -key lams.key -CAfile itcilo-ca.crt -ssl3 -showcerts -connect myhost:443 CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17910:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:529: I tried with ssl2 with same exit. I'm searching but really don't understand the problem. I also created again all the certificates with the same result. Any help would be appreciated as I'm pretty baffled Regards, Gaël __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client authentication problem
Hi. Have you imported the CA of the client cert on the server side? A verify depth of 1 has been set, which could mean that the client cert is self signed? Can you set it to some higher value and try? Also can you check whether the option SSL_VERIFY_FAIL_IF_NO_PEER_CERT? It looks to me a definitive server side issue.. Can you retry the same thing from Mozilla or something. FYI: I implemented the exacy same thing recently and didnt see such problems..is your server mod_ssl? Thanks --Gayathri The above indicates that. Make sure client cert processing is done correctly on the server side. If it is a program failure, then you need to get the programmer to debug the program. Thank you for your answer. I'm not sure what you intend with program failure: the pages served by this virtual host are for the time being only static html pages. The only programs involed are apache, openssl and the browser I tried the following command found in the openssl faq openssl s_client -connect tomcat-ssl.itcilo.org:443 -state -debug and it finished with the following error: SSL_connect:SSLv3 write client key exchange A write to 080B07A0 [080BFFC0] (6 bytes = -1 (0x)) SSL_connect:error in SSLv3 write finished A SSL_connect:error in SSLv3 write finished A I've googled a little bit but didn't really find something that allowed me to solve my problem. host:~/CA # openssl s_client -connect myhost:443 -showcerts -CAfile /root/CA/itcilo-ca.crt CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17680:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 17680:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: I also tried passing to openssl s_client the client certificate and key, with also an error, as you can see below: dolphin:~/CA # openssl s_client -cert lams.crt -key lams.key -CAfile itcilo-ca.crt -ssl3 -showcerts -connect myhost:443 CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17910:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:529: I tried with ssl2 with same exit. I'm searching but really don't understand the problem. I also created again all the certificates with the same result. Any help would be appreciated as I'm pretty baffled Regards, Gaël __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Client authentication problem
Hi all, I'm trying to configure client authentication for one of my sites (SuSe 9.0, apache 2.0.48, openssl-0.9.7b-133 distribution's rpm). You will find below the steps I'm following, the problem I have is that, when I go to the page, it first asks me to accept the server's certificate, then ask me to select one of the client certificate imported in the browser, and then: - on IE, it gives me the error Cannot find server or DNS Error - on Firefox, it gives me a blank page In the apache log file [Tue Jul 12 15:03:41 2005] [error] Re-negotiation handshake failed: Not accepted by client!? [Tue Jul 12 15:03:43 2005] [notice] child pid 9192 exit signal Segmentation fault (11) If I remove SSLVerifyCLient require and authenticate only the server, I can see the right web page. After several unsuccessful test, I'm wondering whether I'm missing something Here are the steps I follow: 1 Generate my own Certificate Authority: openssl genrsa -out itcilo-ca.key 2048 openssl req -new -x509 -days 3650 -key itcilo-ca.key -out itcilo-ca.crt 2 Generate the server key and request for signing openssl genrsa -out tomcat-server.key 1024 openssl req -new -key tomcat-server.key -out tomcat-server.csr 3 Sign the certificate signing request with the self-created certificate authority openssl x509 -req -in tomcat-server.csr -out tomcat-server.crt -sha1 -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 I had to create an itcilo-ca.srl file (echo 01 itcilo-ca.srl) 4 Create a new private key and a certificate request for the user: openssl genrsa -out lams.key 1024 openssl req -new -key lams.key -out lams.csr 5 Sign the certificate request, thereby creating the client certificate: openssl x509 -req -in lams.csr -out lams.crt -sha1 -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 6 Generate the PKCS#12 certificate: openssl pkcs12 -export -in lams.crt -inkey lams.key -name Lams Gael Cert -out lams.p12 7 Import the certificate into the browser And here is my virtual host configuration: VirtualHost *:443 ServerAdmin myemailaddress DocumentRoot /srv/www/vhosts/myfqdn ServerName myfqdn SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/tomcat-server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/tomcat-server.key SSLCACertificateFile /etc/apache2/ssl.crt/itcilo-ca.crt /VirtualHost Directory /srv/www/vhosts/myfqdn SSLRequireSSL SSLVerifyCLient require SSLVerifyDepth 1 Options Indexes AllowOverride None Order allow,deny Allow from all /Directory Any help, pointer would be greatly appreciated Regards, gaël __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client authentication problem
Looks to me that client authentication failed. And this is most likely due to client cert processing on the server side: [notice] child pid 9192 exit signal Segmentation fault (11) The above indicates that. Make sure client cert processing is done correctly on the server side. If it is a program failure, then you need to get the programmer to debug the program. Regards, Dr. Wu --- Gaël Lams [EMAIL PROTECTED] wrote: Hi all, I'm trying to configure client authentication for one of my sites (SuSe 9.0, apache 2.0.48, openssl-0.9.7b-133 distribution's rpm). You will find below the steps I'm following, the problem I have is that, when I go to the page, it first asks me to accept the server's certificate, then ask me to select one of the client certificate imported in the browser, and then: - on IE, it gives me the error Cannot find server or DNS Error - on Firefox, it gives me a blank page In the apache log file [Tue Jul 12 15:03:41 2005] [error] Re-negotiation handshake failed: Not accepted by client!? [Tue Jul 12 15:03:43 2005] [notice] child pid 9192 exit signal Segmentation fault (11) If I remove SSLVerifyCLient require and authenticate only the server, I can see the right web page. After several unsuccessful test, I'm wondering whether I'm missing something Here are the steps I follow: 1 Generate my own Certificate Authority: openssl genrsa -out itcilo-ca.key 2048 openssl req -new -x509 -days 3650 -key itcilo-ca.key -out itcilo-ca.crt 2 Generate the server key and request for signing openssl genrsa -out tomcat-server.key 1024 openssl req -new -key tomcat-server.key -out tomcat-server.csr 3 Sign the certificate signing request with the self-created certificate authority openssl x509 -req -in tomcat-server.csr -out tomcat-server.crt -sha1 -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 I had to create an itcilo-ca.srl file (echo 01 itcilo-ca.srl) 4 Create a new private key and a certificate request for the user: openssl genrsa -out lams.key 1024 openssl req -new -key lams.key -out lams.csr 5 Sign the certificate request, thereby creating the client certificate: openssl x509 -req -in lams.csr -out lams.crt -sha1 -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 6 Generate the PKCS#12 certificate: openssl pkcs12 -export -in lams.crt -inkey lams.key -name Lams Gael Cert -out lams.p12 7 Import the certificate into the browser And here is my virtual host configuration: VirtualHost *:443 ServerAdmin myemailaddress DocumentRoot /srv/www/vhosts/myfqdn ServerName myfqdn SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/tomcat-server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/tomcat-server.key SSLCACertificateFile /etc/apache2/ssl.crt/itcilo-ca.crt /VirtualHost Directory /srv/www/vhosts/myfqdn SSLRequireSSL SSLVerifyCLient require SSLVerifyDepth 1 Options Indexes AllowOverride None Order allow,deny Allow from all /Directory Any help, pointer would be greatly appreciated Regards, gaël __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Eric Rescorla wrote: Götz Babin-Ebell [EMAIL PROTECTED] writes: And how gets he the connection IP-Address - FQDN ? -He uses DNS. I think you need to reread his message since that's not what he says. Hm: snip client authentication. After a successful SSL_accept() I have some logic that verifies that the Common Name in the client certificate matches the client's DNS name. This works just fine. However, if the /snip snip It seems to me that if one private key becomes compromised, and I don't validate the DNS name in certificates then an attacker can pretend to be any system in the network until the CRL gets updated. So if I'm understanding things correctly, validation of the DNS name in certificates is quite important. /snip I read this as: 1. client connects to his server 2. server extracts FQDN from cert 3. to be shure the client is really the client for the allowed tasks he does a DNS match for FQDN - IP and point 3 is only meaningfull for the client side: you must be shure the server is really the server you wanted to connect, so you know to which host the connection should go. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
Eric Rescorla wrote: There are a number of situations where one wishes to authenticate clients based on their DNS names: (1) SMTP/TLS. (2) Secure remote backup. In such cases the clients often (though not always) have fixed IPs. Well, I'll be happy when IPv6 is ubiquitous (coming any day now since 1996!). Then we can dispense with kludges like DHCP and give globally unique identifiers as addresses. And what about multi-homed hosts? Or many IP addresses per host (using IP aliasing)? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Eric Rescorla wrote: Götz Babin-Ebell [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (7bit)] Don Zick wrote: Hello Don, I'm not actually using DNS at all. For the application I'm working with the TLS clients and servers must be statically configured with a Fully Qualified Domain Name. I match up the statically configured FQDN for a client with the DNS name from the client's certificate. You are using DNS. On the network layer you only have the IP address. To get the FQDN you need to use DNS. And compared with certificate / private key authentication it is trivial to forge a wrong DNS answer. (At least if you don't use DNSSEC on all your clients and servers...) When an attacker is able to steal a private key, he is also able to poison your DNS... I think you're misreading Don's message. He's not looking up the client's FQDN from the IP, he's extracting it from the verified certificate. It's perfectly legitimate to use this for authentication decisions and this doesn't relay on trusting the DNS. And how gets he the connection IP-Address - FQDN ? -He uses DNS. Why should he use the FQDN in the cert for any other uses ? If he wants to allow user XYZ presenting certificate C_XYZ to do some things, all he has to do is look in an internal table to map the cert to the allowed tasks. Introducing the FQDN into this is a useless layer of complexity... Note that HTTPS behaves essentially this way: you use the DNS to resolve the IP to connect to the server. You then compare the server's FQDN (as found in the certificate) against the URL. But this is to avoid trust in a possible poisoned DNS. This needs the private key secure on the server. His plan was to do it the other way round: If an attacker has obtained the private key he wants to prevent missuse with DNS. And that is broken. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
Michael Sierchio [EMAIL PROTECTED] writes: Eric Rescorla wrote: There are a number of situations where one wishes to authenticate clients based on their DNS names: (1) SMTP/TLS. (2) Secure remote backup. In such cases the clients often (though not always) have fixed IPs. Well, I'll be happy when IPv6 is ubiquitous (coming any day now since 1996!). Then we can dispense with kludges like DHCP and give globally unique identifiers as addresses. And what about multi-homed hosts? Or many IP addresses per host (using IP aliasing)? I don't see that any of these are really an issue here. The client's IP address isn't being examined at all. The DNS name is simply being used as a unique identifier. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Götz Babin-Ebell [EMAIL PROTECTED] writes: And how gets he the connection IP-Address - FQDN ? -He uses DNS. I think you need to reread his message since that's not what he says. If he wants to allow user XYZ presenting certificate C_XYZ to do some things, all he has to do is look in an internal table to map the cert to the allowed tasks. Introducing the FQDN into this is a useless layer of complexity... This is exactly what he's doing but he wants to use the FQDN as the lookup key. If he knows that the FQDN is in the certificate, this is perfectly reasonable. Consider the case of SMTP-relaying. You wish to ensure that only certain hosts can relay through you which requires determining which each client is. In the old days you'd get their IP and do a reverse lookup. If you require clients to have certificates then you can just ignore the IP, get the certificate and make your access decision off the DN. It's extremely convenient to be able to express these decisions in the language of hostnames, so it's convenient to have the FQDN in the DN and use that for your access control decisions. This has the added advantage that you can express expressions, e.g. allow connections from *.example.com. Provided that you can trust the CA to only issue certificates with correct FQDNs in them (which people do, since that's required for SSL security) then this is quite a useful procedure. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
On Wed, 26 Sep 2001 09:43:02 -0700, Michael Sierchio wrote: Don Zick wrote: I have recently started using OpenSSL. (I have found the SSL and TLS book by Eric Rescorla to be invaluable.) I am having a problem with client authentication. After a successful SSL_accept() I have some logic that verifies that the Common Name in the client certificate matches the client's DNS name. This works just fine. However, if the Common Name does not contain the client's DNS name, I would like to check for the client's DNS name in the subjectAltName extension. This is where I'm having a problem. I attempt to check the subjectAltName extension as follows: Why bother binding client certs to a DNS name? In a mutually authenticated SSL connection, IP addresses may not be important. That each party is in possession of the private key and the certs are not revoked should be sufficient. Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Don Zick wrote: Hello Don, I'm not actually using DNS at all. For the application I'm working with the TLS clients and servers must be statically configured with a Fully Qualified Domain Name. I match up the statically configured FQDN for a client with the DNS name from the client's certificate. You are using DNS. On the network layer you only have the IP address. To get the FQDN you need to use DNS. And compared with certificate / private key authentication it is trivial to forge a wrong DNS answer. (At least if you don't use DNSSEC on all your clients and servers...) When an attacker is able to steal a private key, he is also able to poison your DNS... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
David Schwartz wrote: Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. There's confusion in the PKI realm about what constitutes trust and authority. My assumption is that the certificate issuer does due diligence -- presumably, that's YOU if you are developing an application using client auth. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. You're talking about connecting to a server via HTTP, which has little if anything to do with SSL and mutual authentication. I maintain that it is far easier to poison a DNS cache than to recover someone else's private key (if reasonably secured). Client certs should bind public keys to identity -- however that is defined by the application. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
On Wed, 26 Sep 2001 15:21:09 -0700, Michael Sierchio wrote: David Schwartz wrote: Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. There's confusion in the PKI realm about what constitutes trust and authority. My assumption is that the certificate issuer does due diligence -- presumably, that's YOU if you are developing an application using client auth. No, the application developer may not be the certificate issuer. The application developer (or whoever configured the application to accept certificates signed by a particular authority) must trust the certificate issuer to at least some extent. That extent could vary from total trust to do anything down to trust only for proof of identity. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. You're talking about connecting to a server via HTTP, which has little if anything to do with SSL and mutual authentication. I maintain that it is far easier to poison a DNS cache than to recover someone else's private key (if reasonably secured). Huh? A secure HTTP connection does use SSL and can use mutual authentication. Client certs should bind public keys to identity -- however that is defined by the application. And the application can reasonably do that by checking the name in the certificate and comparing it to the name of the thing the application wanted to send data to. (Assuming the certificate issues is trusted at least to provide accurate identities.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
