Ignore Certificate Errors

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Ignore Certificate Errors

Roger Fischer
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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Ignore Certificate Errors

Maxim Dounin
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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Ignore Certificate Errors

Roger Fischer
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 <[hidden email]> 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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx