Roots Discourse

Https://www Unsecure and Not Redirecting

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:

  1. Fresh droplet

  2. Modified line 32 of lib/trellis/plugins/filter/filters.py as described here.

  3. Run the steps as described by @fullyint 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.

  1. a fresh droplet (so there’s no LE stuff on it)
    OR
  2. SSH in to the remote and
  • delete the CSRs in /var/lib/letsencrypt/csrs and
  • 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.

@fullyint It worked! :grinning:

I would like to buy you guys beer.

@Simeon Give it another go dude…

2 Likes

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!

Are you using DO?

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.

1 Like

This has been officially solved and merged into Trellis: https://github.com/roots/trellis/pull/622

Big thanks to @fullyint for spearheading this work :clap:

3 Likes

After updating Trellis, updating my wordpress_sites files, I’m getting this error when trying to provision new certificates:

TASK [letsencrypt : Generate CSRs]
'site_hosts' is undefined
fatal: [EXAMPLE IP]: FAILED! => {"failed": true}

My site hosts are setup like so:

site_hosts:
  - canonical: example.com.au
    redirects:
      - www.example.com.au

I also now have the following in my error log…

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:

1 Like

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!

:smiley:

3 Likes

@fullyint @swalkinshaw

I didn’t know where to put this, but I think these fixes have broken the changes required in Vagrantfile according to the docs to setup multisite.

In the docs: aliases.each do |host|
Should now be: hostnames.each do |host|

Couldn’t run vagrant up without changing this.

Good catch. You can do a PR yourself if you want: https://github.com/roots/docs

…think I did it. First PR ever

3 Likes