On Tue, Jun 22, 2010 at 2:17 AM, Marcel Fransen <marcel.fran...@quintiq.com>wrote:
> Hi, > > I want to do some additional checks on the peer certificate, like a > hostname check. > > My first question is how should I get access to the peer certificate in the > verify callback: > The documentation for X509_STORE_CTX_get_current_cert(ctx); > states that in case of no error this may return NULL so I guess I should > not just call this one at depth 0, as the certificate does not need to be in > an error state (although that seems to work). > I guess using SSL_CTX_set_verify(ssl) is also a bad idea and should only be > called after the verify (so not from the callback), although I did not test > this. > I now use X509_STORE_CTX_get_chain when at depth 0 and use the certificate > at entry 0 in this stack. Is the correct way to get access to the peer > certificate? > > My second question is on when to do this check in the callback. > I now do it when at depth 0 and preverify_ok was 1. This used to work ok > until I added an "accept an expired certificate" option in the callback > (when a certain command line option is set). In case of the expired > certificate (the initial preverify_ok is 0 in this case) I do the check and > return 1. > What I now see that after this return the callback now gets called another > time for the same certificate but with preverify_ok is 1. So now the > additional verification is done twice (still works but is not what I had in > mind ;-). So now I guess that I should change the code to only do the > additional check when the INITIAL preverify_ok was 1, is this correct? And > it is intended behaviour that it works like this (calling the callback again > for a certificate that was originally not ok but is made ok by the return > code of the callback) so my changes won't break in a future version? > > Kind regards, > > Marcel Fransen > SSL calls your callback function for two reasons 1) The momen it finds something has gone wrong. This is when your callback was called with preverify set to 0. It is the responsibility of the callback function to decide if that is a fatal error or not. In your case, your callback can get the SSL error and see if it is "certificate expired" and choose to ignore it by returning 1. When the callback returns 1, then SSL would go ahead with doing further checks on the certificate 2) Once all the internal verifications are done, SSL finally calls your callback with preverify set to 1. This is when you should be doing your additional checks on the certificate like verifying host name etc. Current certificate at depth zero is the peer certificate which is same as getting the chain and querying for certificate at depth zero. Regards, Arun
