Migrating to new server

Those two statements disagree with each other.

I believe it to be best practice when using HTTPS redirection to exclude the .well-known/acme-challenge folder.
The .htaccess file does not exclude anything and sends all HTTP requests to the second sites’ acme-challenge folder.
That should (incorrectly) yield:
http://site1.tld/anything goes to http://site2.tld/.well-known/acme-challenge/anything
http://site1.tld/.well-known/acme-challenge/anything goes to http://site2.tld/.well-known/acme-challenge/.well-known/acme-challenge/anything

You don’t even show the other redirection in use that you mention, so I can’t completely see/understand the problem.

no, it is not the same folder. It is a deployment setup, where each release gets its own folder and it is simlinked to /current/ like:

current -> /var/www/html_prod/releases/13

in /shared/public/ there is only the main .htaccess needed by the application since that is shared by all the releases. (It is an empty file now though, to not interfere with the Certbot client.)

Therefore in current/public, there is a simlink to it like so:

.htaccess -> /var/www/html_prod/shared/public/.htaccess

If I want to access the files served right now, I need to go into /current/public/, which is where I created the folders for Certbot. And it works using the browser, so that should be right, no?

Do you have a test.txt file in the acme-challenge folder?
If so, it can only be reached via redirection (not best practice - as that requires working HTTPS to complete):
telnet five.epicollect.net 80
GET /.well-known/acme-challenge/test.txt HTTP/1.1
host: five.epicollect.net
HTTP/1.1 301 Moved Permanently
Date: Wed, 14 Jun 2017 22:55:22 GMT
Server: Apache/2.4.18 (Ubuntu)
Location: https://five.epicollect.net/.well-known/acme-challenge/test.txt
Content-Length: 356
Content-Type: text/html; charset=iso-8859-1

title>301 Moved Permanently/title>
h1>Moved Permanently/h1>
p>The document has moved a href=“https://five.epicollect.net/.well-known/acme-challenge/test.txt”>here/a>./p>
address>Apache/2.4.18 (Ubuntu) Server at five.epicollect.net Port 80/address>

Connection to host lost.

The second domain works as expected:
telnet fi–ec5dev3.dide.ic.ac.uk 80
GET /.well-known/acme-challenge/test.txt HTTP/1.1
host: fi–ec5dev3.dide.ic.ac.uk
HTTP/1.1 200 OK
Date: Wed, 14 Jun 2017 23:01:30 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Wed, 14 Jun 2017 14:02:41 GMT
ETag: "9-551ec01662f14"
Accept-Ranges: bytes
Content-Length: 9
Content-Type: text/plain

It works

test.txt is on the new server, at fi–ec5dev3.dide.ic.ac.uk

On five.epicollect.net I have the 301 redirect, which is what I was asked to do the get Certbot working.

I have a working HTTPS on five.epicollect.net

Um, I don’t quite understand your deployment setup. Are you still supplying -w /var/www/html_prod/shared/public/?

If you run echo "This also works" > /var/www/html_prod/shared/public/.well-known/acme-challenge/test2.txt, will that cause there to be a http://fi–ec5dev3.dide.ic.ac.uk/.well-known/acme-challenge/test2.txt file?

I am definitely an idiot, /shared/ is the wrong folder, thanks for spotting it.

I have just run sudo certbot certonly --webroot -w /var/www/html_prod/current/public/ -d five.epicollect.net -d fi--ec5dev3.dide.ic.ac.uk pointing /current/ and bingo:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for five.epicollect.net
http-01 challenge for fi--ec5dev3.dide.ic.ac.uk
Using the webroot path /var/www/html_prod/current/public for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/html_prod/current/public/.well-known/acme-challenge

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/five.epicollect.net/fullchain.pem. Your cert
   will expire on 2017-09-12. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

I will go ahead with the https setup and report back if I have any more issues

Thank you very much @schoen and @rg305

Oh, awesome! I’m glad that the 301 redirect method is working after all. Now we have a practical example to show other nginx users who are thinking of using this approach.

I’m glad it worked out and that you now have your certificate.

Thanks again for the prompt support.

I think this use case could be documented as well, for other users.

The dirt simple way to migrate is…

  1. rsync -a oldserver:/etc/letsencrypt/. newserver:/etc/letsencrypt/.

  2. change all site IPs (if more than one) from oldserver IP to newserver IP.

And you’re done.

Thanks, I will try that when I have another migration to do!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.