Well, your redirects are working now. Did you change that server block as I showed?
As for the other, I think it's likely your nginx binary could be faulty. A pattern I see is that individual requests succeed (curl, wget, ...). Browsers fail but they multi-thread their requests so you will see multiple requests simultaneously. You could use the Dev Tools / Network in the browser and see if it gives hints about which request in the page is failing. Maybe something has gone wrong with how you process multi requests (I have no idea what exactly - just guessing. And I dont know nchan).
Yes I did update the redirect/challenge block as you gave me. Thanks for that.
I agree - I also suspect that my compile of nginx contains the fault. Further I suspect it is in openSSL, but the maintainer has not responded to pleas for help.
nchan is a module to pass messages from one visitor to another, and run a chat room. The code using web_rtc for the heavy lifting, (audio and video) and that requires SSL.
I can now report that the following versions of nginx all fail with the same protocol error
My compile of Oct 21,
Official version 1.20.0
Official version 1.22 with openSSL.1.1.1n
My compile of 1.22.0 with openSSL1.1.1p
My compile of nginx 1.23 with openSSL1.1.p
I really doubt that the version I was running from Oct21 until 10 days ago without any problem, is the problem.
So where can we go from here? star.thecompanycoachltd.com is really simple, so I shall strip everything unnecessary out of its configuration and test that. Update to follow.
I did some Wireshark dumps to see what's going on, but I'm not very wiser.. Your server sends a "change cipher spec" message to the client after the ClientHello and the client tries again afterwards.. But I can't find out why.
The results you get with curl are what I would expect. The html page is a log in screen,
How are the TLS 1.2 ciphers specified? Could it be that curl manages TLS 1.3, but the browsers cant yet, try to swap back to TLS 1.2 and fails to get a new cipher offered?
Cracked it!
I had a dummy site set up for https requests for sites I don't host - which has a self signed cert.
When I took this out, all started to work!
I don't understand what was going wrong - but it isn't any more!
server {
listen 443 ssl;
listen [::]:443 ssl;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
server_name _;
location / {
try_files /index.htm =404;
}
}
The idea being that is would show the visitor a "not on this server" message.
However it managed to mess up all the https sites!
It might work if I just listen on 443 and don't have any ssl going on. Must test. Tomorrow!
That's not true. Self-signed certs will cause warning or error messages in various clients (browsers, ...) but a connection to nginx can be made. You must specify the self-signed cert and its key though (just like a CA cert/key).
I guess I was not clear. In my testing and experience, if you have any "listen 443 ssl" directives paired with a self signed certificate, then yes indeed, visitors can accept the warning, and visit that site. BUT
ALL visitors using a browser who come to every other https:// site hosted on the same instance of nginx will receive a protocol error and not be able to visit the site they want. Pages can be downloaded with curl, but browsers do not work.
I feel this may be a bug in the current version of nginx.
No, I beg to differ again I have a production server with a self-signed cert and LE certs and each server works fine.
I have seen what may be (is probably) a bug in nginx though. It is not exactly what you are describing but shows a pattern that could be involved in your peculiar results
Let's say you have multiple servers with listen 443 ssl.
And, one of these ssl servers (and not the first) does not have the ssl_certificate and ssl_certificate_key lines
Then, that server will inherit the ssl certs from the prior ssl server
So, perhaps there are other ssl related settings that might inherit from server to server? And, maybe you had such a setting in your self-signed server config?
Inheriting settings from the higher http level is normal. But, inheriting from prior server seems wrong to me. I don't see this kind of inheriting with other settings so seems a bug with nginx ssl setting inheritance. I never found any docs about it.
