Reverse Nginx: issue with new Root YR

Help
1

Hi,

I have a ssl website hosted by Apache, and in front a nginx reverse proxy.
both are on Ubuntu 24.04, certbot version 2.9.0
Certificate has been renewed on the Apache server, with the Root YR issue:
from the proxy server:
openssl s_client -connect mail.t-c.biz:443 -showcerts </dev/null 2>/dev/null | grep -E "( s| i):"
0 s:CN = mail.t-c.biz
i:C = US, O = Let's Encrypt, CN = YR1
1 s:C = US, O = Let's Encrypt, CN = YR1
i:C = US, O = ISRG, CN = Root YR
2 s:C = US, O = ISRG, CN = Root YR
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

Since this renew, nginx is unable to proxy the requests:
upstream SSL certificate verify error: (20:unable to get local issuer certificate) while SSL handshaking to upstream,

Here is my nginx config:
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
proxy_ssl_session_reuse on;

If I change proxy_ssl_verify to off, it works.
I tried to restart nginx: still does not work

On the proxy server, the Apache certificate seems to be validated:
wget --ca-certificate=/etc/ssl/certs/ca-certificates.crt https://mail.t-c.biz
200 OK

I do not understand the issue, can you help me ?
Thanks.

2

Welcome @jftempo and thanks for great problem description. It certainly looks like nginx is not building a valid path from Apache. Now to determine why and explain options going forward.

First, would you show the outputs of these

nginx -v
nginx -V 2>&1 | grep -i openssl
openssl version

Note the lower case v and upper case V in the first two commands

3

Hi @MikeMcQ ,

nginx -v
nginx version: nginx/1.24.0 (Ubuntu)

nginx -V 2>&1 | grep -i openssl
built with OpenSSL 3.0.13 30 Jan 2024

openssl version
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
``
4

I was hoping to see an old, custom, build of nginx :slight_smile: I see that is not the case.

nginx is only using the first intermediate when building the trust chain. Most clients will build a trust chain from any of the intermediates. As long as one of them work it is trusted. That is why your wget works because it uses the second intermediate linking to ISRG Root X1 which exists in your ca-certificates

I will setup a proxy configuration like yours to try to reproduce what you see.

Before I start that ... I see from the public internet this cert using openssl to your domain. Is that expected? Because it doesn't have the same domain name in the SAN list and is the older R13/X1 series.

openssl s_client -connect mail.t-c.biz:443

Certificate chain
 0 s:CN=ober.tempo-consulting.fr
   i:C=US, O=Let's Encrypt, CN=R13
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 16 05:53:19 2026 GMT; NotAfter: Aug 14 05:53:18 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=R13
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
5

OK issue fixed, I had to add this nginx config:

    proxy_ssl_verify_depth 2;

Because the default value is 1.

Thanks

6

Oh, great find. Thanks

7

Note that if you were using an ECDSA cert there are 3 intermediates.