Re: client/server verify problems
Lutz Jaenicke wrote: Do we need to resort to a verify callback to permit an 0.9.6b server to accept server certs from the client? Yes. You can globally set the purposed to be checked for, but this is only possible before the handshake is started (SSL_set_purpose()). This is however a pretty bad idea, as you could only switch from client to server, so that real client certificates now would fail. We did a callback function, and it works. Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: client/server verify problems
On Fri, Dec 14, 2001 at 01:18:24PM -0500, Chris Lewis wrote: When we use our client with a verisign-signed server cert, our server side successfully verifies. When we use openssl s_client (or our client) with our entrust cert, our server spits out: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned When we use openssl s_client we get: 29776:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:964:SSL alert number 46 The missing text has been added in the upcoming 0.9.6c released. The alert is of the certificate unknown type. 29776:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:490: when running openssl verify with our root_certs, -purpose sslclient returns: error 26 at 0 depth lookup:unsupported certificate purpose OK Whereas with -purpose sslserver returns just OK. Obviously the certificate was issued for SSL server use. I _assume_ this has something to do with the purpose. openssl's code _apepars_ to verify that the cert has the right purpose. Right? Yes. Our SSL_CTX_set_verify call has SSL_VERIFY_PEER and SSL_VERIFY_FAIL_IF_NO_PEER_CERT. [I get confused around here, because I can't see anything that implies it would generate a no certificate returned message. If purpose was the real problem, wouldn't it say something more specific?] Hmm. Yes? Actually, if the certificate verification fails, the no certificate returned error occurs. That's what the verify_callback is good for: to check out the details of the failure. For various (mostly political) reasons, we can't [re]generate the certs we use with sslclient. Do we need to resort to a verify callback to permit an 0.9.6b server to accept server certs from the client? Yes. You can globally set the purposed to be checked for, but this is only possible before the handshake is started (SSL_set_purpose()). This is however a pretty bad idea, as you could only switch from client to server, so that real client certificates now would fail. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
client/server verify problems
We're porting some (previously) working code from an ancient version of ssleay to openssl 0.9.6b (HPUX). We're having a problem (apparently) with the server-side of a client-server application, both ends using openssl 0.9.6b. We're using locally generated certificates (Entrust PKI) for both the client and server, which according to openssl verify are only given the purpose of server. One Verisign server cert we played with appears to not have a purpose set, or at least permit both sslclient and sslserver. The client side doesn't have any trouble with talking to web servers (in particular, Stronghold 2.2) with the Entrust certs, and the web server is successfully able to retrieve the client cert. Tho, 2.2 of course uses ssleay internally. Yeah, once this mess is over, we're going to upgrade to Stronghold 3. When we use our client with a verisign-signed server cert, our server side successfully verifies. When we use openssl s_client (or our client) with our entrust cert, our server spits out: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned When we use openssl s_client we get: 29776:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:964:SSL alert number 46 29776:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:490: when running openssl verify with our root_certs, -purpose sslclient returns: error 26 at 0 depth lookup:unsupported certificate purpose OK Whereas with -purpose sslserver returns just OK. I _assume_ this has something to do with the purpose. openssl's code _apepars_ to verify that the cert has the right purpose. Right? Our SSL_CTX_set_verify call has SSL_VERIFY_PEER and SSL_VERIFY_FAIL_IF_NO_PEER_CERT. [I get confused around here, because I can't see anything that implies it would generate a no certificate returned message. If purpose was the real problem, wouldn't it say something more specific?] For various (mostly political) reasons, we can't [re]generate the certs we use with sslclient. Do we need to resort to a verify callback to permit an 0.9.6b server to accept server certs from the client? Or is something else going wrong? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
