Welcome! Log In Create A New Profile

Advanced

Ignore Certificate Errors

Posted by Roger Fischer 
Roger Fischer
Ignore Certificate Errors
August 30, 2018 06:20PM
Hello,

is there a way to make NGINX more forgiving on TLS certificate errors? Or would that have to be done in OpenSSL instead?

When I use openssl s_client, I get the following errors from the upstream server:

140226185430680:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
140226185430680:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
140226185430680:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2010:

This causes NGINX (reverse proxy) to return 502 Bad Gateway to the browser.

The NGINX error log shows:

2018/08/29 09:09:59 [crit] 11633#11633: *28 SSL_do_handshake() failed (SSL: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature) while SSL handshaking to upstream, client: 192.168.1.66, server: s5.example.com, request: "GET /xyz

I have added “proxy_ssl_verify off;”, but that did not make any difference.

Surprisingly, the browser (directly to the upstream server) does not complain about the TLS error.

Is there anything else I can do either in NGINX or openssl to suppress the 502 Bad Gateway?

Thanks…

Roger

PS: I don’t have control over the upstream server, so I can’t fix the root cause (faulty certificate).

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Maxim Dounin
Re: Ignore Certificate Errors
August 30, 2018 08:20PM
Hello!

On Thu, Aug 30, 2018 at 09:09:44AM -0700, Roger Fischer wrote:

> Hello,
>
> is there a way to make NGINX more forgiving on TLS certificate errors? Or would that have to be done in OpenSSL instead?
>
> When I use openssl s_client, I get the following errors from the upstream server:
>
> 140226185430680:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
> 140226185430680:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
> 140226185430680:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2010:
>
> This causes NGINX (reverse proxy) to return 502 Bad Gateway to the browser.
>
> The NGINX error log shows:
>
> 2018/08/29 09:09:59 [crit] 11633#11633: *28 SSL_do_handshake() failed (SSL: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature) while SSL handshaking to upstream, client: 192.168.1.66, server: s5.example.com, request: "GET /xyz
>
> I have added “proxy_ssl_verify off;”, but that did not make any difference.
>
> Surprisingly, the browser (directly to the upstream server) does not complain about the TLS error.
>
> Is there anything else I can do either in NGINX or openssl to suppress the 502 Bad Gateway?
>
> Thanks…
>
> Roger
>
> PS: I don’t have control over the upstream server, so I can’t fix the root cause (faulty certificate).

As per the error message, the problem seems to be not with the
cerifitcate, but with the key exchange during the SSL handshake.
For some reason signature verification after the key exchange
fails due to wrong padding.

Most likely the problem is specific to some ciphers, so forcing a
different cipher with proxy_ssl_ciphers could help, see
http://nginx.org/r/proxy_ssl_ciphers.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roger Fischer
Re: Ignore Certificate Errors
September 10, 2018 06:20PM
Hello,

I eventually found out that the problem was a missing “proxy_ssl_server_name on;”.

Without the Server Name Indication (SNI) in the TLS handshake, the server returns a certificate that causes this problem.

I am also wondering if these days the default should be on. It seems that SNI is in widespread use.

Roger


> On Aug 30, 2018, at 11:13 AM, Maxim Dounin <[email protected]> wrote:
>
> Hello!
>
> On Thu, Aug 30, 2018 at 09:09:44AM -0700, Roger Fischer wrote:
>
>> Hello,
>>
>> is there a way to make NGINX more forgiving on TLS certificate errors? Or would that have to be done in OpenSSL instead?
>>
>> When I use openssl s_client, I get the following errors from the upstream server:
>>
>> 140226185430680:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
>> 140226185430680:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
>> 140226185430680:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2010:
>>
>> This causes NGINX (reverse proxy) to return 502 Bad Gateway to the browser.
>>
>> The NGINX error log shows:
>>
>> 2018/08/29 09:09:59 [crit] 11633#11633: *28 SSL_do_handshake() failed (SSL: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature) while SSL handshaking to upstream, client: 192.168.1.66, server: s5.example.com, request: "GET /xyz
>>
>> I have added “proxy_ssl_verify off;”, but that did not make any difference.
>>
>> Surprisingly, the browser (directly to the upstream server) does not complain about the TLS error.
>>
>> Is there anything else I can do either in NGINX or openssl to suppress the 502 Bad Gateway?
>>
>> Thanks…
>>
>> Roger
>>
>> PS: I don’t have control over the upstream server, so I can’t fix the root cause (faulty certificate).
>
> As per the error message, the problem seems to be not with the
> cerifitcate, but with the key exchange during the SSL handshake.
> For some reason signature verification after the key exchange
> fails due to wrong padding.
>
> Most likely the problem is specific to some ciphers, so forcing a
> different cipher with proxy_ssl_ciphers could help, see
> http://nginx.org/r/proxy_ssl_ciphers.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Sorry, only registered users may post in this forum.

Click here to login