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.
…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.
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!)
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?
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;
}
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.
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.
You may know this already but in case you don’t, they have a handy rebuild feature that allows you to blank the droplet and start with a fresh copy of the OS while keeping the same ip (I always take a snapshot first).
One thing to watch however is that they don’t insert the SSH key(s) from your DO account so you will need to make sure you can access the email address associated with the account to get the root password of the rebuilt droplet.
I used WP migrate DB pro to pull the DB and then rebuilt the droplet and was up and running again in ten minutes.
I’m using Vultr (https://www.vultr.com) who seem like a DO-clone except unlike DO they actually have a Server based in Australia.
They’ve got a similar feature which I was hesitant to use but didn’t consider taking a full snapshot first. I’m already using WP Migrate DB Pro to sync development / staging / production but there’s a fair few ‘moving parts’ on this particular project – like WooCommerce – so I really want to make sure if I’m doing the nuclear option that I can get it back up successfully.
Thanks for the tip and following this through though.
2016/08/01 04:30:01 [warn] 763#763: conflicting server name "example.com.au" on 0.0.0.0:443, ignored
2016/08/01 04:34:56 [warn] 30624#30624: conflicting server name "example.com.au" on 0.0.0.0:443, ignored
2016/08/01 04:34:57 [warn] 763#763: conflicting server name "example.com.au" on 0.0.0.0:443, ignored
2016/08/01 04:48:27 [emerg] 1480#1480: BIO_new_file("/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
2016/08/01 04:48:36 [emerg] 727#727: BIO_new_file("/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
2016/08/01 05:05:44 [emerg] 723#723: BIO_new_file("/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
2016/08/01 05:22:51 [emerg] 712#712: BIO_new_file("/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
2016/08/01 05:27:05 [emerg] 722#722: BIO_new_file("/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/ssl/letsencrypt/example.com.au-bundled.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
…and if set ssl enabled: false I get this error on provisioning:
AnsibleUndefinedVariable: 'site_hosts_canonical' is undefined
@Simeon you mentioned updating your wordpress_sites files but could you confirm that you updated all files as in roots/trellis#622? I suspect your files are missing the site_hosts definition in group_vars/all/helpers.yml, potentially among other things.
Once you have the full set of updates, I suggest you run the entire server.yml playbook (without specifying any --tags). If that runs into trouble, you could then run just ansible-playbook server.yml -e env=production --tags wordpress
to work out the Nginx confs, and then run ansible-playbook server.yml -e env=production --tags letsencrypt
I’m currently testing an update to implement this. In the meantime, if you’re working on a site/project with some existing letsencrypt CSRs/certs, you may need to do one of these:
Ah you’re so right. I just bulk overwrote everything in Trellis but brought the old group_vars directory along, which means I didn’t have the new and updated files in the all directory. Trying now.
Edit: It works! Had to SSH into the remote and remove the old CSRs as described, then another provision and deploy.
www now redirects to non-www with fully green SSL on my international domain!