opnsense Nginx, website on synology webstation

[Fright]

and one more thing: the next error you are likely to get (after cert chain will be correct) will be:
'upstream SSL certificate does not match 'upstreamblahblahblah'.
since plugin uses upstream uids in proxy_pass directives, you need specify the server name from the upstream certificate in the "TLS: Servername override" field. so nginx can verify name from upstream certificate against this field and not against upstream UID

[RamSense]

when you access your synology directly, what cert you see in your browser? -> internal cert made at the synology. It is only used to locally access the synology, not for the websites. Those have an lets encrypt cert.

can the field " "TLS: Servername override" contain more than 1 domain name?

[Fright]

not for the websites. Those have an lets encrypt cert

got it, thanks
so LE CA's from this cert should be presented in System->trust

can the field " "TLS: Servername override" contain more than 1 domain name?

no. and there is no need. the field does not have to match all subject names at once )

[RamSense]

i have added in system - trust - certificate the self signed synology cert. -> still the error when going to the websites
Since internal cert I do not have an system-trust-authority for the synology. (?)

TLS Servername Override -> so only 1 domain should be mentioned. Maybe silly question, but when I have multiple websites, it does not matter which domain I add here? only one is enough? I have one upstream server.

and really thank you for your help and explanation

[Fright]

i have added in system - trust - certificate the self signed synology cert.

no-no. no need to add this cert to OPN if you not using it for websites on synology.
need to add CAs certs from LetsEncrypt chain on synology cert to OPN->System->Trust, restart ngnix and look in HTTP Error Logs for changes in behavior

, it does not matter which domain I add here?

yes (in your case since you don't use SNI). better to use name from the cert's CN

[RamSense]

no-no. no need to add this cert to OPN if you not using it for websites on synology.
need to add CAs certs from LetsEncrypt chain on synology cert to OPN->System->Trust, restart ngnix and look in HTTP Error Logs for changes in behavior

Ok, but I already had my lets encrypt cert used on synology added on OPNsense-system-trust. That was why it worked before Nginx 1.20. Or must I delete those, add them again an see if it works?

[Fright]

Ok, but I already had my lets encrypt cert used on synology added on OPNsense-system-trus

again: not cert itself. certs of CA's that issued this cert should be in OPNsense-system-trust-Authorities.
and although it may sound strange, try to play with the value of "TLS: Verify Depth" field (make it 2 o bigger).
(although the error message should be different in this case, I have seen messages that it caused an "unable to get local issuer certificate" error.  for me it works well with depth 2 for certs with 2 intermediate CAs in chain. I have seen messages that it requires depth=4 for this)

[RamSense]

I have added the content of cert.pem and privkey.pem in the system-trust-certificates
and the content of chain.pem in the system-trust-authorities.
Those where already added to opnsense. Or I must have missed something and it somehow did work on the previous nginx?

I tried just setting verify depth to 2 and 4 but no difference.
Don't know what I am missing

[Fright]

I have added the content of cert.pem and privkey.pem in the system-trust-certificates

no need to import private key for this

Or most have missed something and it somehow did work on the previous nginx?

in previous versions, verification was not allowed (the line was missing in the template). so the error just could not occur

I tried just setting verify depth to 2 and 4 but no difference.

hm. the same error in the log?

[Fright]

and can you share result of

Code: [Select]

# openssl s_client -connect 198.168.1.133:443
? (you can omit the content between BEGIN CERT--END CERT to save space. and sanitize private info)

[RamSense]

the error is the same, only the first digit can be different per line.
it is *8 and *1, *5, thereafter it is the same
*11 upstream SSL certificate verify error: (20:unable to get local issuer certificate) while SSL handshaking to upstream, client: <my device ip>, server: <my website url>, request: "GET /HTTP/2.0", upstream:

[RamSense]

and can you share result of
Code: [Select]

This is the result:
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = 192.168.1.133, emailAddress = info@xxxx
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = 192.168.1.133, emailAddress = info@xxxx
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = 192.168.1.133, emailAddress = info@xxxx
   i:C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = xxxxx, emailAddress = info@xxxx
---
Server certificate
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
subject=C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = 192.168.1.133, emailAddress = info@xxxx

issuer=C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = xxxx, emailAddress = info@xxxx

---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2372 bytes and written 419 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 533E94733C1CA4F3F9C852F5B57970F34DCF969F2B4EDE0CC1D03FE27964627A
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1611250116
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---
closed

[Fright]

verify error:num=21:unable to verify the first certificate

so as you can see there is cert issue on upstream

Certificate chain
 0 s:C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = 192.168.1.133, emailAddress = info@xxxx
   i:C = NL, ST = xx, L = xxxxx, O = xxxxx, OU = xxxxx, CN = xxxxx, emailAddress = info@xxxx

upstream server sends only leaf cert (should send chain with issued intermediate (or root) CAs cert) and there is a strong feeling that this is a self-signed certificate. Not letsencrypt

or the synology web-intraface bind to 443 also?

can you repeat this command but with internal site name?
openssl s_client -connect OneOfYourInternalSiteOnSynology:443

[RamSense]

yeah the error is there.
The only thing I do not understand is that it was working before the update and now with 1.20 it does not.

And now the error seems to be something like verifying the self signed cert in stead of the lets encrypt... and all after the update, or is that a coincidence (I have not changed anything in the config on opnsense or synology)

[Fright]

can you repeat this command but with internal site name?
openssl s_client -connect OneOfYourInternalSiteOnSynology:443

The only thing I do not understand is that it was working before the update and now with 1.20 it does no

as I said, 1.20 enabled upstream verification. before that it did not work and therefore these errors could not exist at all