but when I use it on the 3 different istances of nginx I start to have a problem I can't solve:
I can correctly visit the first website I connect to in the browser but then I cannot reach the other two (or they redirect me to the first visited); if i clear all the browser data I can again correctly connect to one of the three website but then again I cannot reach the others.
I don't think is strictly browser related, maybe it's some problem with nginx configuration (caching maybe?) because it's causing problem even outside client browsing, in the communication between subdomains
In order to obtain an LE wildcard cert you will need to use DNS authentication.
That is likely your biggest hurdle.
Once that works, you can either share that single wildcard cert or replicate the process to each server and have three separate similar wildcard certs.
[both will work - so either way is OK]
Q #1: Do you already have a wildcard cert?
It seems like you have one.
Q #2: Is there any other redirection used (that hasn't been shown)?
[or perhaps the HTML code itself has some sort of base reference assigned to the single domain]
the only thing I forgot to mention is that the 3 separate webserver are behind a proxy server that redirect connection requests by SNI, then the webservers terminate the TLS
No, there're no such sort of restriction at html level.
Mind the problem occur only when I setup the single wildcard certificate (that has *.example.com example.com as SANs) on the three separate nginx configs. If I setup three different, not wildcard, certificate (example.com on webserver1, a.example.com on webserver2 and b.example.com on webserver3) all html connection are restricted to the correct webserver and don't interferes with each other
Wildcarding is a new territory for me and although i didn't expect such strange beheaviour from a certificate, the problem might be something related to the webserver configuration, ssl caching maybe? but I can't wrap my head around how the *.example.com instead of a.example.com could cause that with the webserver config I showed you in the OP
some more info:
during the troubleshooting I narrowed down the problem a bit more, I noticed that once I visit the website that use the wildcard I cannot visit the other two anymore, even if those 2 do not use the wildcard certificate.
For example if I setup a.example.com to use the wildcard certificate (that again, contains both *.example.com and example.com as domains) but the other two webserver use the old normal certificate (so -d example.com certificate for example.com webserver and -d b.example.com certificate for b.example.com) and the first website that I visit through the browser (every browser behave the same) is a.example.com I cannot access the other two website; It's like that once the handshake happen with the a.example.com wildcard certificate the browser start to catch every call to b.example.com and to example.com and redirect them to a.example.com which gives me an error page.
If I delete the browser cache and cookies, and try again starting by visiting the other two sites first, they behave correctly, I can jump from one to another without problem. But as soon as I visit the one with the wildcard certificate I cannot visit them anymore
Then your system doing SNI logic is NOT doing it as you would expect.
Meaning that it may be doing it in reverse order and matching the SNI from the SAN.
Writing those previous long messagges helped me because in the meantime I had other browser's pages open on another tabs and when I got back to them I tried to refresh the page that had an error on and it went to the correct website! So I thought that there was something on the webserver or proxy that has a cache timeout of more or less 10 minutes.
On the webserver I already did some test on the ssl cache but that was not the case so I got back to analyze the entire connection path and found the problem to be a misconfigured parameter in the proxy server, the proxy_timeout directive.
I didn't had that parameter specified on my configuration so it defaulted to a value of 10 minutes; set it up to 3 seconds et voilà! problem solved
thank you for your support @rg305 , I hope that this can help someone in the future
after some testing, I can't do that, it feels like clunky workaround because even if it solve that problem, new ones arises: when those webservers need some time (>3s) to process and serve the content, the connection is terminated early and fails to do so. Anyway here's the proxy stream block configs:
did some progress and inspecting the tcp packets with tcpdump i found that the SNI present in the hello packets of connections to ALL three webserver is always example.com, even for a.example.com and b.example.com so the proxy cannot distinguish where to route what
now it starts to makes sense but from here, how can I move forward?
EDIT: I was wrong, after some more digging to get the correct tcp data, I found that the command
Although the logic/flow shown seems correct, it is all within one stream {}.
[with a server {} within it]
Can you show how is that stream is called / being used (anywhere else)?
I don't know if I got what you are asking, the stream block exist only on the proxy server instance and the tls connections are then terminated on the 3 backend servers as I showed you