Yeah, well, I haven't worked out how to tell nginx to look at the SNI for a HTTPS request and bomb out completely if it doesn't match any SSL-enabled vhost. Unless you've got pervasive IPv6 -- then I can set everything up so manually mangling URLs to use HTTPS doesn't cause problems (there's no links to HTTPS resources on sslcoop.org)...
Turns out the real scarce resource is IPv4 addresses -- but we already knew that. ipv6coop.org, anyone? (grin)
Catch-all + HTTP --> HTTPS
server {
# Set server name & make it the default for this IP address
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
return 301 https://EXAMPLE.TLD$request_uri;
}
Or, rewrite HTTPS to HTTP for that vhost only server {
listen 443;
server_name EXAMPLE.TLD;
return 301 http://EXAMPLE.TLD$request_uri;
}
Mozilla's server-side TLS wiki at https://wiki.mozilla.org/Security/Server_Side_TLS is the best documentation I've found yet, and includes great examples of complete configs for various servers. Hope that helps.By the time the server can return the redirect you propose, the user agent must have already accepted the non-matching certificate.
Testing a couple third-party sites, our local bus company simply times out when you manually input https://www.libertybus.je. Doing this on the main BBC site https://www.bbc.co.uk/ quickly returns you to the http version. Those are different setups but the cert errors do not happen, which is the goal here.
meowtaxi is sooo right! Seriously, I was going to post the same thing. Sure, I expected an SSL error when I manually switched to the https version of your url, but the specific SSL error I ended up getting reflects really, really poorly on an organization that aims to become a CA.
I did check your FAQ first for some mention of the site's current SSL woes...