Question on having a backup server on another computer?


#1

I have a simple vehicle tracking server for family & friends from home. Using certbot I got a certificate for the machine and it works out of the box (ubuntu 16.04 and apache2 etc)

As part of me trying to learn about networking I thought I would have a backup server and I am now configuring that machine. Should I run that machine using the certbot, or would the preferred method be to copy the installer cert directories and files across on to the backup machine.
I run cron jobs to regularly copy the database files and keep the the backup machine in sync and could do the same with the cert folder
i.e.
/etc/letsencrypt/live/tracker.xxxxxxxxxxx/fullchain.pem and
/etc/letsencrypt/live/tracker.xxxxxxxxxxx/privatekey.pem

Is copying the folders is the best way? Is there any other information I need to copy across such as
/etc/letsencrypt/options-ssl-apache.conf

I am not anything but a linux beginner so sorry for the basic questions but did not wish to generate unnecessary certs for the site is not needed.

Cheers

Adrian


#2

Hi,

If you copy the live folder, you would copy nothing but a bunch of links… You should try to copy the whole /etc/certbot folder so you would have all files (including renewal and account keys)

Thank you


#3

OK thank you, so it is doable that way.

Is there anything else I would need to do to ensure the update is done at 60 days if I end up on the backup machine at that point?

Cheers

Adrian


#4

I am struggling to get a cron job that would copy /etc/letsencrypt directory and links from one machine to the next, with ubuntu there is no root account, it uses sudo which would ask for a password.

So if I run certbot on the backup server to create the directory and links could I do it for the same domain as on the main server or will that corrupt/change anything on the working server?

How does one have a backup server in case of failure?

Sorry if I am explaining this badly, I am learning as I go.

Adrian


#5

There is a root account, it just doesn’t have a password. :slight_smile: If you sudo -s on the second machine, you’re now in root’s account and you can choose to, for example, add an ssh key to /root/.ssh/authorized_keys to allow ssh as root from an account on the first machine. However, this does allow that account to do anything as root on the second machine, which might not be what you want. There are ways to limit the power of the ssh key so that it can, for example, only run rsync commands that rsync into a particular directory, but these are seemingly rather complex and cumbersome.

If you don’t require that the configuration be exactly the same between the two machines, you could just copy privkey.pem and fullchain.pem themselves onto the other machine and then point your Apache configuration at those files. While the second machine would not be able to use Certbot to update these certificates, it also wouldn’t need to if it received regular updates to them automatically.

You could also choose to use Certbot’s --deploy-hook option instead of a cron job, so that the files are copied only when they’re changed. This has advantages and disadvantages (fewer unnecessary connections when nothing has changed, but a risk of missing a certificate update entirely if the second machine or its network connection are momentarily down when the first machine renews the certificate).

This is totally fine and might be a much simpler option. Multiple certificates for the same domain names coexist just fine and don’t invalidate or contradict each other at all.

Let’s Encrypt has issuance rate limits which could be a problem if you were doing this on a large number of different servers

since every issuance by any server counts against the weekly rate limit for the domain name as a whole. But with just two servers, you should be totally fine and in no risk of running into the rate limits.

So this might be a simpler option than trying to copy keys and certificates between the two machines.


#6

@schoen
Thank you very much for your answer.

The first few parts of your reply are as clear as mud, I am sure it will get easier for me as time goes on, I know that su does not work and unless I create an additional user with root permissions. sudo seems to be temporary as it last approx 5 mins without needing a password to be entered and I do not seem to achieve it as a root cron job. I hope I will get better!

But if I am not breaking any rules by running the certbot script for the backup machine, I will do that now and check it works.

Again thank you.

Adrian


#7

There are no rules to break.
But unless you are using DNS authentication the second system will NOT be able to authenticate as the first system - no more than my system can authenticate as your system.


#8

@rg305

You have to forgive my ignorance asking about DNS authentication.

I have a second level domain provided by an a provider that points the site domain name at my fixed home IP.

I ran the certbot and initially it failed, then I realised I had to have the backup routed so that my home server port forwarded to the back up machine, tried again and it worked OK So I guess that the pc send out who I am, letsencrypt then responds to the domain name which is routed to my IP the machine answers and all is OK.

I assume it is not just a case of my machine sending out a request and getting an answer, it sends the request and letsencrypt sends an independent message back to try and hit the same PC via DNS, Is that what you mean?

Thanks for your input.

Adrian


#9

LE tries to validate the name in the cert.
So it looks up that name in DNS and then connects to that IP.

If it merely went back to the IP that made the request, then any IP could get a cert for any name.


#10

Just a guess, but I expect you are the sole user on your machine, and that your backup machine is configured identically to your primary machine. In that circumstance, providing a strong password for user “root” probably entails very little security risk. “sudo bash” or “sudo -s” would let you work.

Also, “rsync” is worth studying, and although the
syntax is a little tricky, once you figure it out it is mostly bulletproof. To be effective, you really need to also use ssh authorized keys so you can have the two machines communicate automatically.

You can use “rsync” as an “ordinary user” if you want. You might consider setting up a “le” user to perform the copying chores for the certificates. You can probably avoid needing to use ssh as root if you really want to.

I bet you find other really good uses for rsync - it’s really helpful for backups and mirrors. As someone else suggested, ssh authorized keys can be very helpful, and it is possible to restrict their use so that they can be used only between your two machines.

$0.02
73 de Bill W5GFE


#11

@Buffalo

Hello Bill, yes I am the sole user on the machine all though I did allow remote ssh access so I could check on things remotely I should be the only one using it. But when I did have remote ssh access I did find a Chinese IP trying to gain access, my response was to deny access to 218.91.0.0/16 but I am sure someone else would have ago.
The two machines are similar but not same size HD’s, motherboards etc.
I will try rsync and adding users with limited access to certain directories etc and will get to play with SSH keys again when I get a bit more familiar with it all.

Thanks all for your answers.

Adrian


#12

Hey Adrian - let’s take this to email so as not to clutter up the discourse. I’m going to recommend “fail2ban” and careful configuration of “sshd”. My email is

bw@w5gfe.org