The issue was TLS: Verify Depth and TLS SNI Forwarding.
I run nginx on the server as well. And for that I need to have SNI enabled and TLS: Verify Depth set to 2.
Here is the explanation from some AI:
I run nginx on the server as well. And for that I need to have SNI enabled and TLS: Verify Depth set to 2.
Here is the explanation from some AI:
QuoteTLS: Verify Depth
Controls how many certificates deep a TLS certificate chain may be when validating a peer's certificate.
A certificate chain normally looks like:
text
Server certificate
↓
Intermediate CA certificate
↓
Root CA certificate
The verify depth is the maximum number of issuer certificates the verifier will follow.
For example:
Depth 0: Accept only a directly trusted certificate; no intermediate chain.
Depth 1: Allow one issuer level.
Depth 2 or higher: Allow longer chains containing intermediate CAs.
A higher value does not make certificates more trusted. It only permits deeper certificate chains to be checked. The certificate must still be valid, trusted, within its validity period, and match the expected hostname where applicable.
If the depth is too low, valid certificates using one or more intermediate CAs may fail with a "certificate chain too long" or verification-depth error. If it is unnecessarily high, the practical security impact is usually small, but it allows more deeply nested chains than needed.
TLS SNI Forwarding
SNI—Server Name Indication—is a hostname sent by the client at the beginning of the TLS handshake. It tells the server which hostname the client wants, allowing one IP address to host multiple HTTPS sites with different certificates.
For example, a client connecting to:
text
https://example.com
may send:
text
SNI: example.com
With TLS SNI forwarding enabled, a proxy or TLS gateway passes that hostname to the next TLS server when it creates or relays the upstream connection. The upstream server can then select the correct certificate and virtual host.
This is important when:
One server hosts multiple HTTPS domains.
A reverse proxy connects to an HTTPS backend.
The proxy is handling or relaying TLS without terminating the whole connection.
The upstream certificate depends on the requested hostname.
If SNI forwarding is disabled or incorrect, the upstream server may return:
A certificate for the wrong domain.
The default virtual host.
A TLS hostname-mismatch error.
An unexpected application or website.
The two settings control different things:
Setting Controls
TLS Verify Depth How deeply the peer's certificate chain may be validated
TLS SNI Forwarding Whether the requested hostname is sent to the upstream TLS server
In a typical HTTPS proxy configuration, use a verify depth sufficient for the certificate chain—often 2 or 3—and enable SNI forwarding when the upstream server hosts multiple TLS domains or requires the hostname to select the correct certificate.
"