Currently, I run Apache under Windows and use certonly and CMD scripts, to copy certs from live folder to Apache ssl.crt and ssl.key folders and to a bunch other softwares that use those certs (email, IM etc).
Now, I bring up a Fedora Linux replacement box for the web server only. It is up and running but not 100% ready to go live yet. I want to test the renewal before I am confident I can switch over.
Is my understanding correct that instead of certonly I should use apache, and that this plugin will do all of the work on my behalf, without having to employ any scripts? How is it going to work?
Also, I realize that I will have to employ some script/scripts, to propagate the renewed certs to email/IM software on other hosts. Currently, Windows scheduler takes care of running them. Should I put the new script on cron or in post-renewal hook instead?
I should probably mention that I installed letsencrypt w/o snap/docker, and it created /etc/letsencrypt and renewal-hooks undeneath it. I assume the renewal will create archive, live etc? So far I dumped copies of my existing certs into /etc/letsencrypt/live1, just to see httpd start up and serve my vhosts.
Given your config I don't think the apache plug-in will do "all of the work". I would continue to use certonly as you have been. The only thing the apache plug-in will configure is a VirtualHost for HTTPS. You already have one you can copy over.
You could use the Certbot --deploy-hook to run your propagation script. It runs only when a new cert is issued. You could also create your own script in cron. Using cron is similar to how you do it now. Your preference.
Yes, when you get the first cert those will be created.
I'm afraid you're mixing up some things with regard to the options of Certbot. certonly is a so called "subcommand" and is used without dashes (- or --). The other subcommand with regard to getting a cert issued is run, which is the default if no subcommand is present on the command line. Further more, there are a few subcommands like certificates or install or delete to manage certificates or even register to manage ACME registrations. I.e.: subcommands tell Certbot what to do.
On the other hand, --apache is an option to a subcommand and tells Certbot how to do a specific task. As the "apache" plugin is an authenticator as wel as an installer, --apache is shorthand for -i apache -a apache.
It's possible to combine certonly with --apache. Those options are not mutual exclusive.
Thank you for answering some questions but I am still not clear how to stage the migration on the new server while the existing server is still running and renewing its certs.
I don't understand the question. You said you copied over good certs to /live1/ to use to start with. That's good. Once you are confident of new server and your DNS is pointing to that IP, then setup Certbot to get new certs and update Apache (and others) to start using the new certs from /live/
Until your DNS is pointing to the new server you won't be able to use Certbot and the HTTP challenge.
Correct. But I only did it as a proof of concept, in order to be able to bring Apache up.
In live, Certbot on the new Linux box will have to renew them on its own, w/o me copying anything. The new Linux box is TO REPLACE the old Windows box, but while the new box is being created and stabilized the old box is to continue running and renewing its certs.
You are using the HTTP challenge to get your certs. Let's Encrypt Servers use the DNS to find your IP address and send the challenge to it.
Until you have your DNS pointing to your new server you won't be able to satisfy the challenge that way. You could temporarily update the DNS, setup and test certbot, test your server, and put DNS back to existing server if needed.
I don't know, and don't want to know, your entire migration plan. You may have to use the copied certs after you switch to new server and then setup certbot once it's running. If you time it carefully you will have many days remaining before cert expiry to do this.
I am not worried about letsencrypt not finding the right server because I can switch DNS back and forth. I am worried that were the Linux box to renew some certs they will be missed by live Windows.
If you have certbot installed on your Linux server, it will have created /etc/letsencrypt/archive. You should have something equivalent on the Windows server. Copy the sub-directory that is named for your domain or web-server and contains your certificate(s), key(s), and chain(s) to the Linux server. Then find or create the sub-directory in /etc/letsencrypt/live with that same domain/server name. certbot keeps a set of symbolic links in that directory pointing to your most recent certificate set in the archive sub-directory. For your migration, you may have to create these symbolic links manually. This is not hard. e.g.:
where "mydomain.com" is the actual name of your domain and "1" is the sequence number of your certificate set. The beauty of certbot is that it will automatically update those links, when you next run it on the Linux server.
It is customary for Fedora Linux to keep keys, certs and certificate-authority files in sub-directories of the /etc/pki/tls directory. If you create the following set of links, you will never have to update anything:
That should allow you to get your Fedora apache server up and running on your current certificate set. When you are ready to run certbot certonly on the Linux server, the following will happen. A new certificate set will be put in the archive/mydomain.com sub-directory; the symbolic links in the live/mydomain.com sub-directory will be updated. Apache httpd will continue to point to the latest certificate set. You will have to run systemctl reload httpd at your convenience to make Apache httpd read-in the new certificate. This setup will work fine with the --webroot option.
Your Windows server and your Linux server can send out different certs. Even for the same domain name. People sometimes do this when they have just a couple server instances behind a load balancer, for example.
But, you can only get 5 certs with the same name in one week on production system. You might want to use the staging system on your test machine (*). The staging system test certs won't be trusted by browsers. But, you'll know why so not a problem.
(*) Add --test-cert --break-my-certs to certonly command. Or, use --dry-run to use staging system without creating certs. It proves the mechanism - apart from getting certs.
Are you telling me that if on day X I test renewal on the Linux box and it renews cert #5 out of 10 then when the next day Windows live machine will run its renewal job it will successfully renew the cert #5 out of 10 again?
Or will I have to hawk over the renewal logs on both Linux test and Windows live and see what was renewed and when and to copy files back and forth?
Let's say day 1 you get a cert on Windows machine. You use that cert there.
On day 2 you get a cert on Linux machine. You use that cert there.
(that's 2 certs counted against your 5/week limit)
On day 61 you renew cert on Windows and use it there.
On day 62 you renew cert on Linux and use it there
(that's 2 certs counted against your 5/week limit)
A cert is just a set of files (leaf, intermediates, private key). There's no magic relation between a cert you get one day and one from another day regardless of how obtained or where used. They count equally against the rate limit.
There may be some confusion with the definition/use of certs.
Let's get these out in the clear:
what defines a cert is not the list of covered names
each cert has an individual number
more than one cert can exist with the exact same set of covered names
if a cert is renewed on system one, then it doesn't need to be renewed on system two
the new cert on system one can be copied to system two and also used there
if the cert is renewed on both systems, then they no longer have the exact same cert
they will then have two similar certs - but not the same one
I wrote #5 out of 10 because I have a dozen of certs, and all of them renew on different dates.
Let's skip the accounting because it is not relevant at the moment.
Are you telling me that even though the Windows machine would have renewed the cert the Linux machine will renew it too next time I allow certbot to run on it (for testing)? Or the other way around: if Linux would have renewed it, during my testing, then Windows will renew it as normal when it runs its next scheduled job 1-2-3 or however many days later, within the same expiration cycle?
When Linux test machine renews a cert that expires a few days from now, and Windows production machine's renewal jobs runs after that, will it renew it too?
I don't know how else to describe how this works. The certbot and certs on the two machines operate independently. The two machines are not aware of cert renewal activity on each other. You said you plan to switch DNS to Linux for testing and back to Windows for production.
You have to be careful that you don't try to request more than 5 certs per week. Let's Encrypt Server keeps track of your total. It doesn't matter if you have one machine making 5 certs/week or 5 machines each making 1 cert. The 6th in a week will be denied.
I only mention the rate limit because you are testing the Linux machine. Often, people accidentally issue extra certs during testing. If you don't use the staging system you can run into rate limit problems. I've described the methods to use staging earlier.
Multiple machines can request a cert with the identical domain name(s) in it. Each machine will have their own files for the leaf, intermediates, and private key (the group of files making up a cert).
With Certbot, each machine can renew that cert with the renew command. This renew does not affect the cert files existing on other machines.
I am clearly not explaining this well to you. Perhaps another volunteer will find a better way.
