This is very likely an instance of the as-yet-unresolved issue of international domains not redirecting, as reported in response to roots/trellis#570.
Bah. I hope not. It’s already a bit of a pain to have to edit config files just to get the .com.au to work. The site is straight-up broken if the www loads with security errors and won’t redirect 
I searched again and found the discourse thread I vaguely remembered addressing the issue. Turns out you were on that thread, so you’ve already implemented a temporary solution before. An alternative temporary solution might be to set up a specific redirect using an nginx include.
Yeah your workaround in that thread got the site actually launching, but there remains this issue with www subdomain.
As for the nginx include, I’m not really following that documentation. And the www redirect works on my development server (though it’s non-https). It just won’t redirect the https://www in production.
I’m not certain this will work, but you could try the temporary solution (I think you’ve applied that already) then run these steps to hopefully iron out potential problems in your nginx conf.
If that doesn’t resolve the issue, could you update us on what the latest errors are exactly?
I apologize for mentioning the nginx includes option because looking at it a little more, I see that it will not currently accommodate your redirect on the domain level. The problem is that the includes happen within the server block but in your case would need to create a separate server block. If you’re curious, however, here is an example of using nginx includes.
Not sure if this is problem, but reminds me of an issue I had with SSL redirects because the certs and ssl config file were not put in the redirect block in the conf file. This PR fixed it https://github.com/roots/trellis/pull/537. But check your conf file and make sure the redirect block has the needed ssl certs.
1 Like
I’m not really following everything that’s being said in that PR, but my site has the corrected versions of those conf files in my version of Trellis.
Also I tried setting ssl enabled :false, deploying, then changing and deploying again. No fix.
Sorry yea not super clear in PR. My point was making sure that in your sites-enabled/website.org file making sure that the block that the redirects SSL www to non-www has ssl info in it so like:
server {
listen 443 ssl spdy;
server_name www.example.org;
return 301 $scheme://example.org$request_uri;
include ssl.conf;
include ssl-stapling.conf;
ssl_certificate /etc/nginx/ssl/example.pem;
ssl_trusted_certificate /etc/nginx/ssl/example.pem;
ssl_certificate_key /etc/nginx/ssl/example.key;
}
This is an older version of Trellis so yours might look different but it needs to have those certificates or else it will give the Connection is not private warning and not redirect.
I’ve never used letsencrypt, but I guess it’d have to be wildcard for it to redirect from that www? IDK
Hmm, I’ve taken a look at my file doesn’t have anything like your…
server_name www.example.org;
return 301 $scheme://example.org$request_uri;
I added it into wordpress-site.conf.js, deployed, and got a ‘too many redirects’ error.
My development version doesn’t have https enabled and it redirects www to root fine. But the production server just won’t do it. Will keep experimenting with this conf file I guess.
I just ran into this issue myself.
The www subdomain is not secured and is not redirecting to root.
Anyone managed to get it working?
…and for the record, it’s an international domain so likely that the issue reported in response to roots/trellis#570 is indeed the culprit as pointed out by @fullyint.
Update:
I’m still having this issue. I was hoping removing all Let’s Encrypt data like in this thread and re-provisioning would fix it, but it didn’t.
I created a new instance if the Staging server, provisioned, deployed and even migrated the DB from Production to Staging, and it does not have the same problem. Though, the Staging server has a .xyz domain, and the Production has .com.au – so it could still be related to international domains.
(But then that said, I’ve deployed another .com.au website using Trellis/Let’s Encrypt and it does not have this issue … confusing!)
Thanks for the reply.
I’m going to try with a fresh droplet.
One thing I’m not sure about: if I snapshot the existing droplet and then refresh it back to a clean install of Ubuntu 12.04 and then re-provision with a fresh let’s encrypt certificate, could I go back and use the old snapshot and the old certificate again if necessary?
Just wondering…
Okay, I’ve tried the following:
-
Fresh droplet
-
Modified line 32 of
lib/trellis/plugins/filter/filters.pyas described here.
This time ansible completed without an error, but the www subdomain is still insecure and not redirecting.
Looking at the nginx config in sites-available, I can see the following server block:
server {
listen 443 ssl http2;
include h5bp/directive-only/ssl.conf;
include h5bp/directive-only/ssl-stapling.conf;
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
ssl_buffer_size 1400; # 1400 bytes to fit in one MTU
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
ssl_certificate /etc/nginx/ssl/letsencrypt/volunteeringmatters.org.uk-bundled.cert;
ssl_certificate_key /etc/nginx/ssl/letsencrypt/volunteeringmatters.org.uk.key;
server_name www.volunteeringmatters.org.uk;
return 301 $scheme://volunteeringmatters.org.uk$request_uri;
}
any help gratefully received.
Looking at it with fresh eyes this morning, I’ve noticed that Firefox gives this error:
SSL_ERROR_BAD_CERT_DOMAIN
So it seems that the problem is that the Let’s Encrypt certificate does not include the www subdomain.
I think I’ll bite the bullet and try installing a different certificate manually.
@treb0r Could you share your mod here, for review?
I think you’ll have success after making that mod, and then doing the following.
- a fresh droplet (so there’s no LE stuff on it)
OR - SSH in to the remote and
- delete the CSRs in
/var/lib/letsencrypt/csrsand - delete the certs in
/etc/nginx/ssl/letsencrypt
Then run server.yml again.
Maybe you already tried these steps after making the mod.
That was my estimation of your cert (no www):
$ openssl s_client -connect www.volunteeringmatters.org.uk:443 -servername www.volunteeringmatters.org.uk | openssl x509 -noout -text
X509v3 Subject Alternative Name:
DNS:volunteeringmatters.org.uk
I’m working on a PR to recreate the CSRs and certs if site_hosts or www_redirect are modified. I’ll hopefully at least post it for review in the next day or two.
As for the steps to make the www_redirect work for international domains, it will require some extensive careful work, which accounts for the delay.
1 Like
Thanks for the reply.
if len(host.split('.')) > 2 and ( ('.').join(host.split('.')[-2:]) != 'org.uk' ):
Okay, I’ll give it a go. I think I’ve got two more attempts before I run into the rate limit for the domain. I must have run the first provision before I modified that file before.
Sorry if I sound impatient, you know how it is when a client site is broken.
I’m eternally grateful for the fantastic work that you guys do with roots and I understand that these kind of issues are par for the course when it comes to iterative software development.
That’s cool there’s a fix for this now … but it only appears to work on a fresh droplet. I tried removing the Certs as described above – but my site is already live – and that wasn’t enough to fix this issue.
Guess I’ll need to pull a local copy of the site and start it over to fix it.
Good to know for next time though!