Hey Maxim,

> 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
SSL_get_verify_result().

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
possible.

> 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
wrong?

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.

Best regards,
Piotr Sikora

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel