[PATCH] SSL: fix order of checks during SSL certificate verification
piotrsikora at google.com
Fri Sep 2 23:18:53 UTC 2016
> You are misreading the BUGS section. It doesn't say that
> SSL_get_peer_certificate() must be always called when
> SSL_get_verify_result() is called. It says that SSL_get_verify_result() is
> only useful in connection with SSL_get_peer_certificate().
Those 2 sentences are mutually exclusive, if result of
SSL_get_verify_result() is useless without SSL_get_peer_certificate(),
then those two should be called together, or more precisely,
SSL_get_peer_certificate() should be called before
Also, for what it's worth, NGINX & netty-tcnative are the only two
consumers of this OpenSSL API (that we link against BoringSSL) that
use those functions in this order.
> The difference between ngx_ssl_error() and what you've suggested
> is that ngx_ssl_error() doesn't try to cast errors to an nginx rc
> value. Instead, it uses the error stack saved in the relevant
> connection object.
Except that SSL_get_verify_result() doesn't save its result on the
error stack, so what I suggested is as close to ngx_ssl_error() as
> As previously suggested, it might be a good solution to use "peer", as
> already used in serveral error messages in ngx_event_openssl.c
Again, could you elaborate why the use of "client" in
ngx_ssl_verify_client() and "upstream" in ngx_ssl_verify_host() is
IMHO, the only case in which "peer" would make sense is if we wanted
to introduce common ngx_ssl_verify_peer() function that handles both
cases, which I don't think is a good idea.
More information about the nginx-devel