Client certificate verification failed if use Nginx with Openssl 1.1.1

[isbcholding@…]

Hi,

We use Nginx to access internal server and verify clients by corporate certificates stored on their USB tokens or smart-cards.
Now, we want to move openssl 1.1.1 to add support TLSv1.3 in Nginx. After we had compiled Nginx with the latest openssl 1.1.1, we faced that Nginx failed to verify some client certificates with 495 error. The same client certificates worked fine when Nginx was built with openssl 1.0.2.

However, verification failed certificates by openssl 1.1.1 console cmd works fine:

openssl verify -crl_check -CRLfile crl.pem -CAfile root-ca.crt user.crt

shows

user.crt : OK

Environment:
1) SLES12 SP4 -
2) OpenSSL 1.1.1c
3) Nginx 1.17.3

[Maxim Dounin]

When certificate verification fails, nginx logs the reason to the error log, at the info level. Check the logs, likely there is an explanation there. In particular, in the past we've seen problems due to certificate purpose checking as introduced in OpenSSL 1.1.0, see #1760.

[isbcholding@…]

There is no error at all in error logs.
We have a lot of issued certificates by the same CA. Some of them failed verified by Nginx, other ones passed.
But openssl verify cli cmd passed for certificates which one failed in Nginx.

[Maxim Dounin]

There is no error at all in error logs.

This means that error log in your setup is not configured to log messages at the info level. Adjust your configuration to see relevant messages.

But openssl verify cli cmd passed for certificates which one failed in Nginx.

The most obvious difference of the openssl verify command is that it doesn't use certificate purpose by default. Try with -purpose sslclient, as suggested in the ticket referenced.

[isbcholding@…]

Thank you!
I've configured info logging, here the errors:

2019/09/11 11:28:29 [info] 14709#0: *10 peer closed connection in SSL handshake while SSL handshaking, client: 172.20.20.126, server: 0.0.0.0:443
2019/09/11 11:28:30 [info] 14710#0: *11 peer closed connection in SSL handshake while SSL handshaking, client: 172.20.20.126, server: 0.0.0.0:443
2019/09/11 11:28:31 [info] 14708#0: *12 peer closed connection in SSL handshake while SSL handshaking, client: 172.20.20.126, server: 0.0.0.0:443
2019/09/11 11:28:37 [info] 14707#0: *14 peer closed connection in SSL handshake while SSL handshaking, client: 172.20.20.126, server: 0.0.0.0:443
2019/09/11 11:28:37 [info] 14710#0: *13 client SSL certificate verify error: (66:EE certificate key too weak) while reading client request headers, client: 172.20.20.126, server: sale-php7.corp.isbc.ru, request: "GET /_partners/index.php HTTP/2.0", host: "sale-php7.corp.isbc.ru", referrer: "https://sale-php7.corp.isbc.ru/_index/task_my.php"
2019/09/11 11:28:37 [info] 14710#0: *13 client SSL certificate verify error: (66:EE certificate key too weak) while reading client request headers, client: 172.20.20.126, server: sale-php7.corp.isbc.ru, request: "GET /_index/task_my.php HTTP/2.0", host: "sale-php7.corp.isbc.ru"
2019/09/11 11:28:37 [info] 14710#0: *13 client SSL certificate verify error: (66:EE certificate key too weak) while reading client request headers, client: 172.20.20.126, server: sale-php7.corp.isbc.ru, request: "GET /_pay/list.php HTTP/2.0", host: "sale-php7.corp.isbc.ru", referrer: "https://sale-php7.corp.isbc.ru/_sklad/order_items.php"

Anyway, -purpose sslclient passed

openssl verify -crl_check -purpose sslclient -CRLfile crl.pem -CAfile root-ca.crt user.crt
user.crt: OK

[Maxim Dounin]

The EE certificate key too weak error suggests that keys you are trying to use are too weak. OpenSSL starting with OpenSSL 1.1.0 uses security level 1 by default, which is as follows (quoting man SSL_CTX_set_security_level):

The security level corresponds to a minimum of 80 bits of security. Any
parameters offering below 80 bits of security are excluded. As a result RSA,
DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits
are prohibited. All export cipher suites are prohibited since they all offer
less than 80 bits of security. SSL version 2 is prohibited. Any cipher suite
using MD5 for the MAC is also prohibited.

You can instruct OpenSSL to accept keys it generally considers to be too week by using @SECLEVEL=0 in the cipher string (as set by ssl_ciphers nginx directive, see man ciphers for syntax details), though usually it is better idea to replace weak certificates with stronger ones.

Just in case, openssl verify accepts security level in the -auth_level argument, and you can replicate default certificate verification behaviour by using openssl verify -auth_level 1. No idea why -auth_level 1 isn't the default for openssl verify.

[isbcholding@…]

Thank you!

Its to strange, but client certificate was created by RSA1024 but:

openssl x509 -text -noout -in user.crt

shows it as

Public-Key: (1023 bit)