RE: SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
So this is some minor debugging I did to get to this problem.
Modified the following methods to add two printf lines:
ssl_lib.c:
X509 *SSL_get_peer_certificate(const SSL *s)
{
X509 *r;
if ((s == NULL) || (s-session == NULL))
{
printf(SSL_get_peer_certificate: s or session was null. returning
null x509\n);
r=NULL;
}
else
{
printf(SSL_get_peer_certificate: returning session-peer:
%p\n, s-session-peer);
r=s-session-peer;
}
...
d1-srvr.c:
int dtls1_accept(SSL *s)
{
...
case SSL3_ST_SW_CERT_REQ_A:
case SSL3_ST_SW_CERT_REQ_B:
if (/* don't request cert unless asked for it: */
...
else
{
s-s3-tmp.cert_request=1;
dtls1_start_timer(s);
ret=dtls1_send_certificate_request(s);
printf(ssl_accept: sent cert request; rc=%d\n, ret);
...
Recompiled and re-linked. When a call comes from the client I see the
following two lines:
ssl_accept: sent cert request; rc=1
...
SSL_get_peer_certificate: returning session-peer: (nil)
The same client and the same server, moments later, have the following
printouts:
...
ssl_accept: sent cert request; rc=1
...
SSL_get_peer_certificate: returning session-peer: 0xd74258
I cannot be 100% sure what changes on the client or on the server in
between. But the low-level client socket and ssl connections are exactly
the same in both scenarios. Also both use OpenSSL 1.0a
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
On Fri, Dec 17, 2010 at 01:24:40PM -0500, Jeff Saremi wrote: d1-srvr.c: int dtls1_accept(SSL *s) I cannot be 100% sure what changes on the client or on the server in between. But the low-level client socket and ssl connections are exactly the same in both scenarios. Also both use OpenSSL 1.0a DTLS is a substantially different beast from TLS, I am not at all familiar with when a client cert is expected to be visible with DTLS, perhaps someone else can help you... You likely need to present a much more detailed problem description, ideally with detailed instructions of how to reproduce your observations. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
We have some intermittent problems which seem to go away after restarting our server. The problem is that the client's certificate disappears on the server, even though SSL_VERIFY_PEER is set in the context using SSL_CTX_set_verify(). So under situations that are not entirely clear, a call to SSL_get_peer_certificate() returns null after a successful SSL accept is done on the server. My question is if there are conditions under which one cannot rely on the presence of the peer certificate even if SSL_VERIFY_PEER is set? thanks Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
From: owner-openssl-us...@openssl.org On Behalf Of Jeff Saremi Sent: Wednesday, 15 December, 2010 11:15 We have some intermittent problems which seem to go away after restarting our server. The problem is that the client's certificate disappears on the server, even though SSL_VERIFY_PEER is set in the context using SSL_CTX_set_verify(). Is the SSL_CTX* always set before you create (any) SSL* from it? (Or (re)set in the SSL* before you handshake?) Could you have a bug in (any!) other code that clobbers memory? (These are often very hard to debug, at least in C and C++ G. Maybe you can put in monitoring/debug code that checks every H hours or C connections or M messages or somesuch that settings are still correct.) So under situations that are not entirely clear, a call to SSL_get_peer_certificate() returns null after a successful SSL accept is done on the server. My question is if there are conditions under which one cannot rely on the presence of the peer certificate even if SSL_VERIFY_PEER is set? *On server* just SSL_VERIFY_PEER only causes it to *allow* client auth, by sending CertReq and processing the response(s). accept still succeeds if the client chooses not to auth. Add SSL_VERIFY_FAIL_IF_NO_PEER_CERT to make accept fail. But I see no reason that should be changed by server restart, if you have the same clients attempting the same connections. (Maybe you don't; maybe clients differ from one week to the next, or at different times of day or seasons of the year or something. Or maybe you have one or a few bad client(s) who only connect every 2 weeks, so it usually happens to be more than a week since the last server (re)start. Etcetera Yul Brynner.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_VERIFY_PEER and the presence of client's X509 certificate after the handshake
On Wed, Dec 15, 2010 at 11:14:59AM -0500, Jeff Saremi wrote: So under situations that are not entirely clear, a call to SSL_get_peer_certificate() returns null after a successful SSL accept is done on the server. My question is if there are conditions under which one cannot rely on the presence of the peer certificate even if SSL_VERIFY_PEER is set? If the client signed the handshake with a private key and presented the corresponding certificate chain, then on an initial handshake you'll see the client cert and the full trust chain and your verification callback will be invoked. If the client resumes a previously established session, your verification callback will not be called, rather only the leaf certificate will be saved in the resumed session, and its verification status will be cached. Under these conditions, whether the session is resumed or not, SSL_get_peer_certificate() should return the leaf client certificate. Have never run into any surprised with missing client certs. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
