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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
