Migrating Servers: Want to Also Stop Using Certbot

Help
1

I have a server that has a bunch of domains that I've generated a common certificate for. The old server uses certbot, and uses a single multi-domain certificate, with all the domains listed. It has worked great over the years.

On the new server, I don't want to use certbot any more, and the reason is that certbot has been pressuring users to use snap to install it, and I don't want an extra daemon running on my system just for a single package, and I have other objections to snap.

I've been looking towards other methods of setting up the certificates, and have been leaning towards acme.sh, although I haven't decided for sure about this.

I am having trouble though, figuring out the procedure I need to follow. I ideally want to do this with zero downtime, I.e. I want to be able to fully set up the new web server, certificates and all, and then move the domains over one-by-one (this is going to be a many-day-long process because each domain has unique needs that need to be tested) to point to the new server's DNS. I have done this in the past, and it worked great, but back then I wasn't using a single SSL certificate, back then I had individual, privately-purchased SSL certificates.

I saw this documentation on switching from certbot to acme.sh and it has a step of revoking the certificates from Certbot. Is this necessary before issuing new certificates? I really don't want to do this, because it will result in downtime. I am especially nervous that the downtime could be significant, because I'd be migrating to a new, unfamiliar program and if I run into problems, it could be errors or days before I get the new certificates set up using acme.sh. I ideally would want to issue new certificates before revoking old ones, and I don't understand why there is a need to revoke the certificates at all, because my server hasn't been compromised and no one else has access to the certificates, the server is going to be wiped as soon as I have everything moved over, and the certificates are eventually going to expire anyway.

I initally thought that the way I would want to do this would be to set up the new certificates on the new server, and just not bother about migrating to a new script like acme.sh, on the old server, but I am wondering if this might not be possible because if the domains all point to the old server, there will be no way for the CA to verify that I own the domains. I don't know if there is a way around this?

I'm just so confused and I don't know the best way to go about this. I am open to suggestions about the process, as well as alternatives to acme.sh as, frankly, it is seeming harder to use than certbot. I am still open to the idea of installing certbot on the new server without snap, but I don't even know if this is possible or realistic.

I'm also nervous about using acme.sh for multiple domains. I don't see good examples of how to do this. The example given in the documentation has a single webroot. I figured out by reading websites and the built-in help file, that what I think I need to do is to use options like -d domain1.com -w /path/to/domain1.com/webroot/ -d domain2.com -w /path/to/domain2.com/webroot/ etc. But I'm not even sure if it's going to work or what is going to happen.

1 Like
2

acme.sh is often not well documented. It has also been bought by a commercial party called apilayer and defaults to the commercial CA called ZeroSSL. Two reasons why many regulars don't recommend acme.sh on this Community any longer.

I have some thoughts about some other parts of your post/questions, but that'll have to wait until tomorrow I'm afraid, it's quite late here.

4 Likes
3

Definitely NOT.
[revoking is only done when private key compromise is known (or suspected)]

Then you need to better understand how the two ACME clients function and how they really don't overwrite each other. Meaning you can easily introduce the second ACME client into the production system without any real concern. You don't need two servers. Once that client is able to obtain certs, you can either switch your web server to use the certs from the new client cert path OR remove the first client and use the second client to store certs where the first client did (extremely messy and NOT recommended).

Not via HTTP authentication; You would have to switch to DNS authentication (overkill for the task at hand and may introduce new issues or might not even be allowed by your DSP). Again: You can do what you need with just the one server.

You need not be. You can take your time and run through as many tests as you need to (using the --staging environment and never affecting the real/active certs being handled by certbot).
Again, one client doesn't replace the other.
[their requests do accumulate and count towards enforced limits so be cognizant of that aspect]

3 Likes
4

But when the primary alternative is the dependency hell that is certbot (which I'm sure is at least of part of the reason for the move to snap in the first place--on CentOS 7, for example, certbot has 47 dependencies), the zerossl default is easily overridden (and no, I'm not happy about it either, nor about apilayer's systematically buying out projects in this space), and the acme.sh documentation is still entirely adequate, acme.sh still seems worth some serious consideration. If its acme-dns support weren't so brain-damaged, I doubt I'd ever touch certbot.

The biggest conceptual difference with acme.sh is that it separates cert issuance from cert installation. It expects you'll run one command to issue the command, and a separate command to install it (copy files to the desired location(s), convert them to .p12, restart services, etc.). Both will be done when the cert is renewed, but they're initially done separately. Why that's the case, I couldn't say

What OS are you going to be running on the new server? If it's CentOS 7, there are reasonably up-to-date certbot packages in the EPEL repo. Naturally, the situation may differ with other distros.

That's frankly an idiotic suggestion, especially before obtaining the replacement cert. There's no reason to revoke the cert at all, and certainly not before you get its replacement. If the concern is that certbot will continue trying to renew the cert, you can run certbot delete after you have the new certs through acme.sh.

If you've been using certbot in interactive mode (i.e., run certbot and answer the questions), yes, acme.sh will be more difficult, because you'll need to specify all the options from the command line.

7 Likes
5

I'm running into its poor documentation, and it is slowing me down. And this purchase by this company would also deter me.

Are there any other good alternatives? I have seen some recommendations for dehydrated.

1 Like
6

That's what I thought, about revoking certificates...guess that was just a sloppy guide, which I can ignore.

I know I don't need a second server. I am switching servers for unrelated reasons, but in setting up the new server, I initially went to install certbot and I ran into the problem that it is now using snaps.

So this sparked me to want to switch ACME clients at the same time I am migrating to a new server.

I agree that this sounds preferable:

I'm starting to see though that it would be better to do the migration on the old, live server first, and then migrate to the new server later, because to do otherwise would require installing certbot on the new server which I don't want to do.

2 Likes
7

You could just copy (securely) the certificate and private key from your old server to the new server, point the new server to it for all your domains, and then migrate them over to whatever new method you're using one by one.

In terms of a client recommendation, can you give any more details on what OS/web-server/etc. your new system uses? As was already said you may be able to just keep using certbot from your OS's package manager without any trouble. If you're looking for minimal-dependencies, in addition to the shell-scripting-based ones you might want to take a look at the go-based ones? I think that go just gives a self-contained binary that you can just use, and the Bitnami stack uses lego so I think it's used by quite a few people. I haven't used any of them myself, but it may be something for you to explore.

4 Likes
8

The new server I'm setting up is on Rocky Linux (8.4), which behaves nearly-identically to AlmaLinux and Centos 8. The old server is Centos 7. And the server is running apache 2.4. I don't think these distributions have an official certbot package any more, there are some with custom repositories. Perhaps that would be a good option?

I'm going to have to research this, the only post I saw about installing certbot from a custom repository was 2 years old and it may no longer work.

2 Likes
9

CentOS 7 has certbot packages in the EPEL repo, which is pretty official. I don't know about EL8, as I don't have a suitable box handy to check right now, but I'd be kind of surprised if certbot weren't also in EPEL for EL8. But what is the question the acme.sh docs aren't answering?

5 Likes
10

If being purchased by a for-profit company is a show-stopper for you, please notice that dehydrated has also been acquired by apilayer: Selling dehydrated – lukas.im

The list of ACME clients available is quite long, as you can see from ACME Client Implementations - Let's Encrypt.. GetSSL has been mentioned quite often in the past, but back then acme.sh was more frequently adviced. Maybe we should go back to recommending GetSSL again :slight_smile: It's also under active maintanance as can be seen from the recent github commits.

5 Likes
11

These conversations all seem to be happening at once, don't they @Osiris? :grin:

We've been discussing how the list of client "options" aren't really much of options. Honestly though, I see a lack of installers as the real issue. Within a day or two, I'll be publicly releasing version 1.0.0 of my own client, which makes certificate acquisition about as easy as possible. I feel like the real issue is that ACME clients have tried to be certificate installers with this unnecessary combination having created the mess that we find ourselves in now. There is a clear, definitive point where a private key and certificate have been stored. From that point, the task is solely about webserver/device configuration to install the certificate.

Honestly, I've had some big plans, like creating clean, "official" guides for enabling/configuring TLS/SSL on webservers/devices that could be the basis to develop independent scripts/solutions for certificate installation. These would make the choice of ACME client largely irrelevant since it would clearly delineate the two roles. This could even be made into a standardized/virtualized "API" of sorts.

If only I could get some damn funding to do all this. Financing, always the issue... :confused:

3 Likes
12

Linking related topics together:

https://community.letsencrypt.org/t/provide-support-for-commercial-acme-clients-such-as-acme-sh/156764?u=griffin

https://community.letsencrypt.org/t/discussion-should-clients-like-acme-sh-even-be-listed-on-the-lets-encrypt-website/156136?u=griffin

2 Likes
13

I can now confirm that it is. And with EL8, it only has 13 dependencies, rather than the 47 under EL7. I guess that's an improvement.

4 Likes
14

acme.sh deliberately breaks the process into two steps--obtaining the cert, and installing the cert. But now that that project has been bought by apilayer, they're apparently persona non grata here.

4 Likes
15

Yes! I would certainly call that an improvement.

I just installed certbot via this method, and it was completely painless. It seems I will be sticking with it for now, but I'm still thinking about alternatives for the long-run.

Now I'm just irritated at the EFF and the certbot team for discouraging people for using what (IMHO) is a superior method of installation. They could have even made a low-effort, passing mention like "Alternatively, install it from EPEL" but instead, their dedicated pages for RHEL and other similar distributions all just mention snap and nothing else. It is bizarre to me that they have separate, distro-specific instruction pages but then they don't mention anything distro-specific on them, even when there are distro-specific options like this.

And it's frustrating when I have to learn about this option from off-site pages. Them just mentioning the repository could have saved me a lot of time and headache.

3 Likes
16

To try to look at it from their perspective, they don't control the EPEL repo, they don't know if the packages are being properly built, nor do they know if they'll be kept reasonably up-to-date. They can say, though, that if you install using snap, you'll get (and keep) an up-to-date copy that will be packaged properly (and if it isn't, it's at least under their control to fix it). So it makes some sense that they'd recommend the method that's under their control.

4 Likes
17

There is this (relatively difficult to find) on-site page:

https://certbot.eff.org/docs/install.html#alternate-installation-methods

It appears to have shrank greatly since last I browsed it.

3 Likes
18

That's possibly due to legacy reasons. Before snap, every distro did have its own specific instructions. Further more, it even does make sense now: if people saw the list without their specific distro listed due to the fact snap is recommended (Gentoo for example can't run snap by default, so it still lists the original, proper method of installing :wink: ), chances are the user will think "Hey, my distro is unsupported!" and won't click on "snapd" as they won't recognise it as the method they need.

In any case, let's focus this thread on migrating servers and complain about snap in the other thread.

4 Likes
19

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