Hi,
I currently have lets encrypt working with https://mysite on VPS 1 on NGINX debian jessie wordpress
I have two working lets encrypt with https://mysite2 &3 on VPS2 respectively.
I am also using cloudflare.
My attempt was to transfer my domain from one vps to another.
Please can you advise on best practice for this to be achieved, as I tried all scenarios with scp the /certs to the other host. As i had to get connectivity back to my site I couldnt revert back to http version-by deleting cloudflare-allowing only port 80 , changing wp-options in mysql, etc.
Is there a simpler way that I can just scp the cert files to get it working and create my server block, thus re-input DNS IP on new VPS?
Just scping the cert & private key will do just fine for the validity of that certificate (if your nginx is properly configured to represent that of course), but you’ll run into trouble when renewing.
Which client are you using? If you’re using certbot, I would advice to recreate the files/symlinks/folders in /etc/letsencrypt/ for your mysite1 on your second VPS, including the files in /archive/mysite1/, the symlinks in /live/mysite1/ and the configuration file in /renewal/mysite1.conf.
You said you already “tried all scenarios”… But I’m guessing it’s not working, otherwise you wouldn’t be posting here… What exactly isn’t working?
Hi thanks for taking the time to reply to my issue. Ok so what I attempted was an scp of all my https://mysite files from : archive, csr, keys, live, renewal into my new VPS which already has files belonging to existing https://mysite1 &2 . I simply transferred my wp-content and database via sql, creating the NGINX server block to configure:
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name www.Mysite.comMysite.com;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-R$
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
ssl_certificate /etc/letsencrypt/live/Mysite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/Mysite.com/privkey.pem;
port_in_redirect off;
I noticed whilst adding the files into /etc/letsencrypt/csr folder it has the same naming convention for the existing domain “0000_csr-certbot.pem”; Mysite2 as I was ultimately getting my site redirected to that domain. Do you suspect that this is the cause or is it a red herring and is there something otherwise I can entertain. Because-I had also attempted to revert back to http and trying for a new cert, which does not work because my site is always being redirected to the https version so It gets disconnected.
The CSRs are, as far as I know, not really used any longer after the issuing of a certificate, so you don’t have to copy those.
Furtermore, I’m not sure I understand the logic behind “(…) because my site is always being redirected to the https version so It gets disconnected.” How does a redirect lead to a disconnect?
If you could give the actual hostname of the site, it’s much easier to debug…
Ok I have ommited on this occasion the csr file. I have re-done everything previously mentioned with scp my certs. And I have also deleted my site from cloudflare for safe measure, and updated my DNS accordingly
This is my serverblock conf file
server {
listen 80;
listen [::]:80;
server_name www.brimmen.combrimmen.com;
return 301 https://www.brimmen.com$request_uri;
}
this is the error I am getting with
sudo tail -f /usr/local/nginx/logs/error.log
2016/12/02 23:27:11 [error] 2657#2657: *163 no “ssl_certificate” is defined in server listening on SSL port while SSL handshaking, client:
The error no "ssl_certificate" is defined in server listening on SSL port... is because you have a server block listening on 443 and trying to use ssl but you have not defined the needed ssl directives...
If you want to perform a redirect from https://brimmen.com to https://www.brimen.com you need to specify the right ssl_certificate, ssl_certificate_key, etc for your domain brimmen.con inside above server block.
On a (mostly) unrelated note, make sure that renewal is actually working on the new VPS. certbot is quite finicky when it comes to the files in /etc/letsencrypt and tends to fail in unexpected ways if any files are missing, have wrong permissions, or are no longer symlinks but actual files. This may include files in ./archive or ./csr.
I typically recommend to just copy the entirety of /etc/letsencrypt using rsync -a, which preserves symlinks, permissions, etc.
I have chowned each file with the uploaded SCP files from the other server. I have re-tried the process to no avail with NGINX official https://www.nginx.com/blog/free-certificates-lets-encrypt-and-nginx/. I now have brimmen.com brimmen.com-0001 in my /live directory and also attempted to include this in each server block:
server {
listen 80;
listen [::]:80;
server_name www.brimmen.combrimmen.com;
ssl_certificate /etc/letsencrypt/live/brimmen.com-0001/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/brimmen.com-0001/privkey.pem;
return 301 https://www.brimmen.com$request_uri;
}
At this stage I have brought down multiple sites with the introduction of this new site, and I would like to uninstall and re-do all domains, as it seems a conflict of certs in my opinion.
sudo tail -f /usr/local/nginx/logs/error.log
2016/12/03 00:14:51 [error] 3142#3142: *127 no “ssl_certificate” is defined in server listening on SSL port while SSL handshaking, client: 108.162.245.199, server: 0.0.0.0:443
OK chaps-thanks for your endeavours. I have restored each server snapshot and re-inserted original DNS. …My next approach will be to uninstall and and install again. I have confidence in the multiple domain option on one server as I already have it. Just this new domain is causing a pain. How can I uninstall, as to do a full install on the new server. Do you have a link for this please as im using NGINX.