Transfer SSL to a new server Debian9/ownCloud10 > Ubuntu16.04/nextCloud12


#1

The full domain name of your site:
cloud.hixfamily.us
cloud.hixfamilyreunion.com
www.hixfamily.us
www.hixfamilyreunion.com

the command line you ran:
Lots, but Most recent was
$ sudo letsencrypt renew --dry-run

the output of that command

Processing /etc/letsencrypt/renewal/cloud.hixfamily.us.conf
2018-01-09 20:03:13,415:WARNING:letsencrypt.cli:Renewal configuration file /etc/letsencrypt/renewal/cloud.hixfamily.us.conf is broken. Skipping.
** DRY RUN: simulating ‘letsencrypt renew’ close to cert expiry
** (The test certificates below have not been saved.)

No renewals were attempted.

Additionally, the following renewal configuration files were invalid:
/etc/letsencrypt/renewal/cloud.hixfamily.us.conf (parsefail)
** DRY RUN: simulating ‘letsencrypt renew’ close to cert expiry
** (The test certificates above have not been saved.)
0 renew failure(s), 1 parse failure(s)

name and version of your operating system and your web server
Ubuntu 16.04 LTS / Web Server is Apache2

what type of hosting provider you are using:
I am hosting from VMs on an ESXi Appliance


So, I swear that I have made every attempt to not waste anyone time by googling the heck out of this. I have very rarely ever had to resort to forums for assistance because 999 times out of 1K someone else (or many different someones) have had a similar enough issue to send me in the right direction.

I am VERY low in my skill level with Linux mainly due to my poor programming background. Though I am a tech in Windows networks by trade so I am good at getting the concepts down, but I will need some help with the syntax of most commands.

So enough with the intro…

I had just finished setting up an ownCloud 10 server, and integrated it with my Windows Server 2012 R2 DC. I needed to make some ‘logical’ changes to the location of one of my OUs, not realizing (more ‘forgetting’) that the user account that owncloud was using to connect to my directory was being moved. So this broke … well EVERYTHING having to do with user accounts. I researched for days and came up with nothing other than to do essentially a ‘paint job’ over the cracks instead of fixing anything. So I turned to the forums, created this Post:
https://central.owncloud.org/t/i-think-i-broke-my-owncloud-10-0-3-stable-on-debian-9/11020

Plenty of lookers, but no takers :frowning:

So, I researched further and came across nextCloud. Felt that starting fresh with a better version of what I had was the best way to go at this point. So after installing the server using this Guide:
https://bayton.org/docs/nextcloud/installing-nextcloud-on-ubuntu-16-04-lts-with-redis-apcu-ssl-apache/
and of course:
https://docs.nextcloud.com/server/12/admin_manual/installation/source_installation.html
I finally got the point of encrypting the web server… and here we are a week and half later.
I cannot for the life of me figure this stuff out. So using this below:
Moving and merging certs from Server A to B
and
Migrating to a new server - need to move letsencrypt

I booted both servers up using two different IPs on my network, since the router is pointing to x.x.x.15 for web hosting, I left the old server with that IP (also not sure what else it would break if I change the IP while it was running, and other than the username and duplicate user issues… it still works fine) and the new server is set with x.x.x.25.

Using the scp command, copied the entire letsencrypt to my new server admin user’s home drive. Then:

$sudo cp -r letsencrypt/ /etc/
then ran the command --dry-run

But before I did this, I did attempt to revoke the license (and help me out here… never hosted my own websites so this is all new to me too… this is LITERALLY my first time transferring a SSL) using the guide located at:
https://letsencrypt.org/docs/revoking/
and it seem to have worked. but I think i have a cron job that renews it … which I guess I could be disabled, but I would have to google how to do that… lol.

Anyways… Please help me transfer my certificates from the old web server to my new one, let me know what I need to do and I will do it. :slight_smile:

Thanks again for reading that mess up there too btw :smiley:


#2

Hi @Charles944,

The underlying reason for your error is probably the cp command, because Certbot uses symbolic links to store some required information within /etc/letsencrypt; if you copy or back up /etc/letsencrypt or its subdirectories using a method that doesn’t preserve symbolic link structure, they will probably break.

Two other things that may be worth pointing out:

There is usually no reason to copy certificates from one computer to another. Instead, you can create totally new and independent certificates on the new machine. Multiple certificates for the same name(s) are allowed to coexist and be valid simultaneously.

Similarly, there is usually no reason to revoke a certificate. A certificate does not have to be revoked in order to issue a new certificate for the same names. The same certificate (or different certificates) may be used on more than one server simultaneously. Revocation is intended for the case where you have lost control of the private key (in the sense that an unauthorized person might have had access to it), or where you know that you no longer control a domain name mentioned in a certificate. It’s not needed for the case where you’re no longer using a certificate or where you’re switching servers. Also, revocation does not affect Let’s Encrypt rate limits—you can’t issue more new certificates or issue them any sooner if you revoke previous certificates.


#3

First and foremost… THANK YOU FOR THE REPLY!!! I actually felt the sinking horror that no one was going to reply at all to this post and WHAM!!! less than a minute later! YOUR AWESOME!!!

I also appreciate the time you took to define the symbolic links :slight_smile: I was not aware that any were in use … could have done an ls command … sigh

anyways, again thanks :smiley:

… so there it is. There was no need to copy the entire directory.

But when I attempted to run the command to create the certs for the new server it failed. I will have to change it back to the original IP and run it again so I can get you the exact error message, but if I recall it was something regarding the domain name being invalid (not a fully routable domain). Not knowing much about certs I was concerned that it was due to the fact that they had already been issued to the other server. Since that is not the case, I should get the server in production mode (shut down the old server and change the IP of the new one) but I need to know… should I delete the cloud.hixfamily.us folder in let’s encrypt before attempting to create a new cert? Or just leave it like it is? I am a avid banner-man for ‘no change’ :slight_smile:


#4

Wanted to update:

So the issue was that I did not understand the error message when I was setting this thing up. The error was plain, it was due to outage with TLS-SNI… I thought I was doing something wrong. I wasn’t

after scratching the server, rebuilding from scratch and then running the following command:
sudo certbot --authenticator standalone --installer apache -d cloud.hixfamily.us -d cloud.hixfamilyreunion.com -d www.hixfamily.us -d www.hixfamilyreunion.com --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"
instead of:

sudo certbot --apache -d cloud.hixfamily.us -d cloud.hixfamilyreunion.com -d www.hixfamily.us -d www.hixfamilyreunion.com

Also I opened the ports in my firewall and took the time to create each virutal Host file in Apache sites-available folder [\etc\apache2\sites-available]

So that it looked like this:

-rw-r--r-- 1 root root 1332 Jan 10 10:10 000-default.conf
-rw-r--r-- 1 root root  352 Jan 10 13:13 001-cloud.hixfamily.us-redir.conf
-rw-r--r-- 1 root root 1503 Jan 10 13:04 001-cloud.hixfamily.us-ssl.conf
-rw-r--r-- 1 root root  219 Jan 10 11:57 002-cloud.hixfamilyreunion.com-redir.conf
-rw-r--r-- 1 root root 1510 Jan 10 13:02 002-cloud.hixfamilyreunion.com-ssl.conf
-rw-r--r-- 1 root root  237 Jan 10 11:58 003-www.hixfamily.us-redir.conf
-rw-r--r-- 1 root root 1415 Jan 10 10:55 003-www.hixfamily.us-ssl.conf
-rw-r--r-- 1 root root  253 Jan 10 11:58 004-www.hixfamilyreunion.com-redir.conf
-rw-r--r-- 1 root root 1440 Jan 10 10:46 004-www.hixfamilyreunion.com-ssl.conf
-rw-r--r-- 1 root root 6338 Apr  5  2016 default-ssl.conf
-rw-r--r-- 1 root root  340 Jan 10 13:11 nextcloud.conf

the *-redir.conf were for the intent to automatically redirecting http to https.
After running the above command I realized that that was not needed. So anyone repeating these steps you don’t need the Redirection. Certbot will create those during setup. Had I known I would have not created them… because now my sties available looks like this:

-rw-r–r-- 1 root root 1332 Jan 10 10:10 000-default.conf
-rw-r–r-- 1 root root 352 Jan 10 13:13 001-cloud.hixfamily.us-redir.conf
-rw-r–r-- 1 root root 1503 Jan 10 13:04 001-cloud.hixfamily.us-ssl.conf
-rw-r–r-- 1 root root 1700 Jan 10 13:26 001-cloud.hixfamily.us-ssl-le-ssl.conf
-rw-r–r-- 1 root root 219 Jan 10 11:57 002-cloud.hixfamilyreunion.com-redir.conf
-rw-r–r-- 1 root root 729 Jan 10 13:28 002-cloud.hixfamilyreunion.com-redir-le-ssl.conf
-rw-r–r-- 1 root root 1510 Jan 10 13:02 002-cloud.hixfamilyreunion.com-ssl.conf
-rw-r–r-- 1 root root 237 Jan 10 11:58 003-www.hixfamily.us-redir.conf
-rw-r–r-- 1 root root 1415 Jan 10 10:55 003-www.hixfamily.us-ssl.conf
-rw-r–r-- 1 root root 1745 Jan 10 13:29 003-www.hixfamily.us-ssl-le-ssl.conf
-rw-r–r-- 1 root root 253 Jan 10 11:58 004-www.hixfamilyreunion.com-redir.conf
-rw-r–r-- 1 root root 1440 Jan 10 10:46 004-www.hixfamilyreunion.com-ssl.conf
-rw-r–r-- 1 root root 1770 Jan 10 13:30 004-www.hixfamilyreunion.com-ssl-le-ssl.conf
-rw-r–r-- 1 root root 6338 Apr 5 2016 default-ssl.conf

all of the -le-ssl.conf were created by the command.

Thanks again @schoen for the help, glad it got me thinking out of my error box and taking a step back to see it logically. I was definitely taking the hard road.

I will mark this as solved


#5

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