I created two machines. Server A and Server B. I shared Server A's IP address to Server B hence they share same A/AAAA record.
Case 1 : If server A and Server B are up, the request comes to Server A, with nginx load balancing half of the requests are served by Server A and rest are served by Server B.
Case 2: If server A goes down, all the requests comes directly to server B(as they both shares same IP address). To serve the requests on server B, we need same let's encrypt certificates on server B. I installed certificates on Server A and copied certificate files from Server A to Server B and everything works fine.(Not sure if copying is the best way to handle the issue)
We have setup a cron to renew certificates automatically in Server A and new certificates are copied to Server B.
Suppose, if server A goes down, we have to make sure auto renewal happens in Server B. When i try to run certbot renew command in server B, it says let's encrypt expecting symlinks. This issue is happening because i only copied certificate files to server B. To rectify the issue, i copied complete let's encrypt folder to server B.
I would like to know if it's a best way to copy certificates from Server A to Server B or do you suggest any other solution?
Please find the server details below.
Cloud instance used : Linode
To install certbot certificate : certbot --nginx
To renew certificate : certbot renew
Cron command for auto renewal : 43 6 * * * certbot renew
Domain name : staging.cdn.talentsprint.com
Hi @Chandana3008, and welcome to the LE community forum
In order to resolve your problem as requested, you need to copy the entire ACME client directory.
For certbot, the default location is: "/etc/letsencrypt"
[make sure to copy any symlinks as symlinks]
That said, I'm not sure how you get this to work/renew consistently.
Unless, the load-balancer is set to always prefer server A whenever it is available.
That said, I'm not so sure this is the best solution to this problem.
But it is a solution you are confortable with and I hope that this completes your mission.
The load balancer isn't set to prefer Server A always. The request comes from server A. It distributes 50-50 load to Server A and server B.
We have to make sure that the renewal happens from both the servers A and B. If we set this up, how to make sure that both the servers generate same set of certificates?
One way, perhaps the easiest, is to switch to using a DNS Challenge. Certbot has a plugin for Linode DNS (see docs here).
The DNS Challenge works by placing a TXT record in your DNS so the server that Certbot ran on is not queried to confirm the domain name.
If you only have two servers having each requesting their own cert is fine. If you have many more that will be a problem due to Let's Encrypt rate limits.
To continue using the HTTP Challenge you need to make sure that every server can return the challenge token created by Certbot. There are several options to make this work that require some one-time re-configuration of your servers. If you still want to proceed let us know and we can give further ideas for that.
Even if they happen at the exact same moment in time, they will each be doing so independently.
Meaning: The replies expected from A are not the same as the ones expected from B.
There is no way to run certbot twice as if it had only been run once.
Anyone, from anywhere, could use DNS to validate a certificate for a domain.
[from server A, from server B, from your PC, from anywhere that has the API credentials]
Yes. But, they do not use the same cert. They would each have their own and could even renew on different schedules. Completely separate.
If your A and B servers are in the same local network as the nginx doing the load balancing (LB) then why do A and B even need certs? Can't you just use HTTP to proxy to them?
You get one cert for the LB to handle the initial incoming HTTPS request from the user-agent (like a browser). Based on the nginx docs I linked earlier the idea is this ...
http {
upstream myapp1 {
server serverA.example.com;
server serverB.example.com;
}
server {
listen 443 ssl;
server_name staging.cdn.talentsprint.com;
ssl_certificate "/etc/letsencrypt/.../fullchain.pem";
ssl_certificate_key "/etc/letsencrypt/.../privkey.pem";
# And any other log or app related settings
# Note http:// used for proxy
location / {
proxy_pass http://myapp1;
}
}
}
And, yes, there is also a way to do the proxy with HTTPS and have certs in Server A and B but that is more complicated. HTTPS connections are also slower to setup so you would need to care about performance.
