opnsense Nginx, website on synology webstation

[RamSense]

no errors there to the site url:

CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <domainname>
verify return:1
---
Certificate chain
0 s:CN = <domainname>
   i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
subject=CN = <domainname>

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3055 bytes and written 403 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 40ECCDD0F5259C9C5A4DA19303D796865BEE345A6CD04B7BD958F12CD76C8B9C
    Session-ID-ctx:
    Resumption PSK: C9D1C9FC9CEEB39B86191369CD7CEA30F9AC48FE57DD788A3834CE25F04842201914FD5E5772E16C9929BC086451EA55
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - b8 36 42 74 c7 75 cc f1-8b 17 ae 92 be 6c 34 86   .6Bt.u.......l4.
    0010 - b2 15 ff f1 1d 64 0f 0d-b0 77 f2 2e 42 c4 07 16   .....d...w..B...

    Start Time: 1611255660
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 80921EF250DE4870CA312FF6382871B6F979853F03A425FB8ADA222D01D56038
    Session-ID-ctx:
    Resumption PSK: 4C20487328E90DFC5CFF1D4B6A14A649F86ABEBEFE886F58027E60022FDA33C2225AAAE570BAB6B78D098866C47C33CF
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 5c 5f d4 84 d6 65 e8 16-34 07 16 62 e5 b9 5c d9   \_...e..4..b..\.
    0010 - 75 28 b8 10 8d 76 df 39-fb 28 25 f2 f1 f6 33 39   u(...v.9.(%...39

    Start Time: 1611255660
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0

[Fright]

thanks.
hmm..so if on Synology you used "Name-based virtual hosts" (or as it is called in Synology) this may be SNI issue.
so when nginx connects to upstream it sends wrong SNI and synology starts with self-signed cert.
in this case you can try:
1) change default cert (if synology allows that) to LE and test again
2) fix SNI directives on nginx plugin. but in this case you will need to edit location.conf template by hand (my request is still not reviewed on github). if you are ready to try, I will write what and where to change and you can try to verify upstream again

[RamSense]

Your the best!

I changed the default synology cert from self signed to lets encrypt of a website domain for synology as default cert
I changed in nginx - upstream - TLS: Servername override -> added that domain used as synology default cert

and website loads again!
Strange... but it works

So now it is to wait for the fix for nginx 1.20 to being able to add the < TLS: Trusted Certificate> domains. ?

* one thing I think of now is: with the default domain for synology not being the internal cert and using the lets encrypt domain for a website, I will get an error on e.g. iPhone while going to the synology domain cert not matching I think.
How to fix that? or is this a temporary work around and will I have to set the default cert synology back to self singed cert after the nginx update?

[Fright]

glad it worked

Strange... but it works

why its strange? finally a configuration is created that meets the requirements and it works  ;)

So now it is to wait for the fix for nginx 1.20 to being able to add the < TLS: Trusted Certificate> domains. ?

yes. but I am starting to think that fixing of SNI directives in locations templates also becomes critical for some configurations (upstream verification with SNI virtual hosting)

I will get an error on e.g. iPhone while going to the synology domain cert not matching I think

maybe the LE certificate does not contain synology domain name?

will I have to set the default cert synology back to self singed cert after the nginx update?

yes, hopefully

[RamSense]

thnx again for your help and fast replies!
Glad it works now and will wait for the nginx update to configure it further how it should be with < TLS: Trusted Certificate>

and getting synology default back to self signed.
you are correct with the LE nog containing the synology domain while I use only the local ip to connect to synology itself or from outside with mobile using vpn to local ip synology, so no domain is being used therefor.

[RamSense]

Is it to soon to change back to the self signed cert for Synology?
Im running on opnsense 21.1.5
with the latest Nginx in it.
I am now able to add my domain cert to TLS: Trusted Certificate
And I removed TLS: Servername override

Sites keep working, so there has been made improvements. But when I change my default cert on the synology to the self signed cert, the site gives the error page from nginx/opnsense. So I think I was to early trying for that, or I am missing something in my settings for nginx in doing so (?)

[Fright]

hi
21.1.5 includes fixes for sni. so it should work imho

But when I change my default cert on the synology to the self signed cert, the site gives the error page

any clue in Services: Nginx: Logs-HTTP Error logs at this moment?

And I removed TLS: Servername override

TLS SNI Forwarding should be enabled in Location
TLS: Servername override should be enabled in Upstream and set to name in cert (nginx will compare names in cert with name in this field)

[RamSense]

Thanks for your help.
I tried again with synology to the self singed cert and
I have TLS SNI Forwarding enabled now in Location, but still getting:
Server Error

Sorry, but something went wrong on our side.

There is nothing you can do except waiting until we fix the issue.

and in Nginx Logs-http error:
*1 upstream SSL certificate verify error: (2:unable to get issuer certificate) while SSL handshaking to upstream, client:

switching off TLS SNI Forwarding and Synology back to the previous default cert, kept the system not running anymore, while it did work previously.
I restored a opnsense backup config and system is still not working. Don't know why. Only 2 things I did was enabling TLS SNI forwarding on this time, and off while I got the above error....

rebooted the Synology, and still not working... Strange.
So I went back to the backup settings that was working yesterday, but not working now anymore.....

[RamSense]

in addition:
I have now removed  TLS: Trusted Certificate in upstream 
And website is running again. Strange while I had it yesterday working with TLS Trusted certificates listed in upstream.

What can this be?

[RamSense]

Testing further:

Now I have TLS SNI Forwarding enabled in Location
TLS: Servername override enabled and filled with domain

and as long as I keep TLS: Trusted Certificate empty my site works. As soon as I enable the certs I get the error again.....

[Fright]

hi.sorry, I can react slowly soon

and as long as I keep TLS: Trusted Certificate empty my site works. As soon as I enable the certs I get the error again....

so what's in the Services: Nginx: Logs: HTTP Error logs  at this moment? the name must be mismatched or the root certificate cannot be found

[RamSense]

I just tested it:
without TLS: Trusted Certificate I get: no HTTP error

with TLS: Trusted Certificate I get this on 2 of the 3 domains:
*1 upstream SSL certificate verify error: (2:unable to get issuer certificate) while SSL handshaking to upstream, client:

But with TLS: Trusted Certificate filled the default Lets encrypt synology NAS domain cert still does work, the other 2 domains do not.(?). That default cert change from self signed to one of the 3 domains lets encrypt cert was your earlier solution replacing the self singed cert on synology. That one does work. So has this to do with the virtual hosts also?

[Fright]

Hi

:unable to get issuer certificate

so there is not enough depth or the CA's certificate is not in the trusted list

quick tested on test VM with 21.1.5 without any customs\tweaks:
-change gui cert to self-signed with 'configctl webgui restart renew'
-copy gui cert to trusted CA's
-add upstream to 127.0.0.1 with  TLS: Verify Certificate enabled and gui cert as trusted CA
-add server with location pointed to 127.0.0.1 upstream
works well accessing gui via nginx
if i set wrong trusted CA (say R3 LE) nginx throws "upstream SSL certificate verify error: (18:self signed certificate) while SSL handshaking to upstream"

can you check what certificates synology returns when accessing each site?

[RamSense]

Hi Fright,

I tried to set with TLS: Trusted Certificate  and with TLS: Verify Depth from 1 (what it already was), 2, 3 all to 8 but no difference.

can you check what certificates synology returns when accessing each site?

When I go to all of the 3 domains, the 3 domain/sites show all the right specific SSL cert (lets encrypt) for that specific domain on the site.
Or do I have to check this some other way?

[Fright]

he 3 domain/sites show all the right specific SSL cert (lets encrypt) for that specific domain on the site.

more like sites do not pass the intermediate CA certificate (R3)
can you share the result of
'openssl s_client -connect OneOfYourInternalSiteOnSynology:443'
connecting to one of the virtual hosts?