The redirect from www.example.com -> example.com does not work properly

[ScuttleSE]

The server-segment in the config where the redirect from www.example.com to example.com is done does not contain any SSL-settings, leading nginx to totally freak out if you have multiple domains on the server.

You need to add the same settings and same certs under both HTTPS server-sections in the conf

[nickjj]

It should work. It's what I'm running in production right now.

I have 3 domains on 1 server, all with their own vhost config, each redirecting from www to non-www.

The nginx rule redirects to the https variant of example.com.

[ScuttleSE]

Are they all using the same cert-file? In that case it would work fine, but if you have separate certs for the different domains it won't

[nickjj]

Yes they are all using the same certificate, but each site also has its own vhost config, which in turn has its own SSL configuration, so I'm not seeing why that would cause issues for you.

[ScuttleSE]

Since the SSL handshake is done before any headers are loaded, Nginx will use the default SSL-cert on the site if nothing else is defined in the server-section. If that cert, like in your case, happen to have the current hostname everything is fine and dandy, but if the default ssl-cert is for foo.com and I load www.bar.com, things won't work.

[nickjj]

Shouldn't bar.com's vhost config have its own config which has bar's certificate? That redirect would also only be valid for bar.com, not foo.com (it wouldn't even match for foo.com due to the server_name not being the same).

[ScuttleSE]

Indeed it has, but if you look at the config-file, all of the SSL cert-config is enclosed in its on server-section for bar.com. www.bar.com doesn't know anything about that config, it will revert to whatever the default SSL certificate happen to be.

[ScuttleSE]

The easiest (only?) solution is to duplicate all the SSL-settings you have for bar.com in the server-section for www.bar.com

[nickjj]

Ok I see.

I forgot, the redirect is listening on port 443 (I thought it was on port 80), and the port 80 redirect to 443 is already happening prior to that in the Let's Encrypt challenge.

So you're saying the redirect's SSL config defaults to what you have set as the default_server, rather than what's in the same vhost (the server block under it).

[ScuttleSE]

Exactly. Or, in my case where I don't have a default_server, it seems to default to whichever cert it loads first when restarting...

In your case it doesn't make any difference since all the vhosts uses the same cert :)

[nickjj]

Since it's "just" a redirect, I wonder if we can get by with just duplicating the 3 SSL certificate values, rather than everything. It should be safe to inherit the rest of the values.

[ScuttleSE]

Probably, yeah, I'm gonna do some more testing once I can generate certs at letsencrypt again, accidently hit the rate limiter while testing here earlier :)

[nickjj]

For correctness and less "wtf is happening" it might be best to duplicate them all.

But please let me know if it works (if you duplicate them all) once your rate limit expires. That would be all of the ssl_ values along with the resolver values.

[ScuttleSE]

Yup, yup, I have already massacred your template-file to get the ssl working and to be able accommodate my "upstream only" servers :)

[nickjj]

In the end, having support for your modifications seems reasonable. It's not what I do personally, but I imagine a lot of other people would be interested.

And there's been times where I wanted to test something without potentially blowing up my SSL certificates on all domains, so maybe I'd start using that too.

If you get everything everything, can you email me your working configs to [email protected]? Then I'll implement, test and merge it into this role -- unless you're feeling generous and would like to do that via a PR.

[ScuttleSE]

A PR is definately doable, I'll get one up as soon as I get stuff running here

[nickjj]

Awesome thanks.