The acme.sh will change default CA to ZeroSSL on August-1st 2021

Client dev
1

As for now, if no server is provided, or you have not --set-default-ca yet, acme.sh uses letsencrypt as the default CA.

Starting from August-1st 2021, acme.sh will release v3.0, in which the default CA will use ZeroSSL instead.

This change will only affect the newly created(issued) certs after August-1st (with v3.0), any pre-existing certs will still be renewed automatically aginst the current CA.

Q&A:

  1. As an existing user, what do I need to do?

    Generally, nothing needs to do. (If auto-upgrade is enabled, acme.sh can upgrade itself).
    No matter acme.sh is upgraded to v3.0 or not, your existing certs will be renewed as before, against the same CA it's currently using.

  2. Will I still be able to use letsencrypt then?

    Yes, of cause. you are still free to use any supported CA with providing --server parameter.

    acme.sh  --issue  -d example.com --dns dns_cf    --server  letsencrypt

  3. What if I don't like this change? I want to stick to letsencrypt?

    Yes, sure. You can --set-default-ca now or any time you like. Then acme.sh will always use the default ca you set:

    acme.sh --set-default-ca  --server  letsencrypt

    If you set the default CA, acme.sh will respect your choice first. It will always use this default ca in the future, no matter in v2.*, v3.* or any future v4.*.

    acme.sh always respects your choice first, and will never make any changes to your files without your permissions.

  4. My current cert is using letsencrypt, Will it be changed when renewed then?

    No, and never. Don't worry. when your cert is renewed, it will use the current CA, not the default CA.

  5. As a new user after August-1st 2021(v3.0), what will it look like to me?

    You can install acme.sh as normal, nothing is changed.

    You can also issue certs as normal See how to issue a cert:

    acme.sh --issue  -d example.com  --dns dns_cf

    The cert will be issued with the defualt CA ZeroSSL

    You can also try with letsencrypt:

    acme.sh --issue  -d example.com --dns dns_cf  --server letsencrypt

See more: Change default CA to ZeroSSL · acmesh-official/acme.sh Wiki · GitHub

12 Likes
2

Thanks Neil, for those of us with a lot of existing acme.sh deployments, making the change in this way is very much appreciated :slight_smile: .

9 Likes
3

Hello @Neilpang,

I appreciate the notification of this change so far in advance. May I ask the reason for this change?

Cheers,
sahsanu

6 Likes
4

Just guessing here, but probably money? Cold hard cash!

Guess I won't be recommending acme.sh any longer and we should add a big fat warning at the list of ACME clients in the documentation.

4 Likes
5

Hi @Osiris,

Maybe that is the reason, I see acme.sh is a ZeroSSL's trusted partner so maybe there is some kind of sponsorship behind this change but I'll wait until @Neilpang answer.

Maybe ISRG should have some kind of sponsorship program for other acme clients that add value to Let's Encrypt ecosystem.

acme.sh is and will be after the change an excellent acme client so in my case, if nothing wrong happens, I'll keep recommending it. I see no need to modify the acme clients list while acme.sh supports Let's Encrypt and the doc is clear about how to use it.

Cheers,
sahsanu

5 Likes
6

As far as I know (but correct me if I'm wrong please), all clients on the clients list will use Let's Encrypt by default. If acme.sh is the odd man out, I think that warrants a warning. Just something like: "Note: this client does not use the Let's Encrypt ACME server by default. Please see the documentation on how to change the ACME server used to correctly configure it for use with Let's Encrypt."

3 Likes
7

As I have announced, acme.sh was sponsored and acquired by apilayer a year ago: https://twitter.com/neilpangxa/status/1222792801835872256

ZeroSSL is an ACME compatible free CA by apilayer.

Acme.sh will change default CA, but it's still open and free. Users are still free to choose to use any ACME compatible CAs.

ZeroSSL is almost the same as Letsencrypt: support unlimited 90days certs, including wildcard certs. Full ACME compatible.

Moreover, as letsencrypt is going to change the crossing-signed root, ZeroSSL's setigo root will have a better compatibility than letsencrypt's.

There is also a 6 months period for the users to make choices.

And, the users can select back to use letsencrypt anytime.

So, I think this change won't hurt the users.

As the name implies, acme.sh will always stick to RFC8555 ACME protocol.
It will always keep open and free.

Thanks.
-Neil

8 Likes
8

Appreciate the explanation, I didn't know acme.sh was acquired by apilayer.

5 Likes
9

I didn't review the list but I suppose all or most of them defaults to Let's Encrypt. Anyway, the list is for clients supporting ACMEv2, in this case they must support Let's Encrypt of course but I don't see anywhere that clients must have Let's Encrypt as their default CA.

4 Likes
10

This would break anyone who doesn't get the notification and is using CAA to restrict issuance.

4 Likes
11

Aaaaalmost the same, except wildcard certificates aren't free, certificates with more than a single hostname in the SAN aren't free, more than 3 certificates aren't free.

In short: ZeroSSL isn't really a proper free alternative for Let's Encrypt for many people. :wink:

But only for users getting a new certificate.

5 Likes
12

As far as I know, ZeroSSL certificates issued using ACME api don't have a limit, are free of charge, can have multiple domains and wildcards.

ACME Documentation - ZeroSSL

6 Likes
13

Well, that's very confusing..? They might want to add that to their pricing page I linked above..

4 Likes
14

I agree, when you check the pricing page you see you can have only 3 90-Days certificates but unlimited 90-Days ACME certificates and you think, what the f*** are the ACME Certificates? :wink:

So, checking their site I found that ACME Certificates are the ones issued using ACME clients, that's all :slight_smile:

4 Likes
15

Ah, I looked over the unlimited ACME certificates-part..

Luckily the ACME server of ZeroSSL works perfectly :grimacing:

All authorizations were not finalized by the CA.

:confused:

Second attempt with just 1 hostname in stead of 5 in the SAN:

Remote end closed connection without response

Third attempt:

Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
acme.errors.TimeoutError

 
I can't even test their claims of unlimited ACME certs :frowning:

4 Likes
16

The limit on the pricing page is all for website purchases.

For the ACME api, there is no limit.

There is even no rate limit(yet?).

Wildcard certs, ECC certs are all supported free.

4 Likes
18

Well, with their malfunctioning ACME server I can understand they offer all those things for free, as it doesn't actually work..

I can't even get acme.sh to work with the ZeroSSL ACME server.. The Wiki says I can just run acme.sh --register with the EAB keys and "Done".. However, the next output when trying to get a cert issued is Create new order error. Le_OrderFinalize not found. {"type":"urn:ietf:params:acme:error:malformed","status":400,"detail":"A Key ID MUST be specified"} suggesting the EAB keys aren't used?

The ZeroSSL ACME documentation suggest to use the API key in stead of the EAB keys for "partner ACME clients", which acme.sh is, but I can't find anything about that on the acme.sh Wiki.. Ah well, strengthing my idea about the lack of proper documentation for acme.sh again unfortunately.. Although the REST API is not the same as the ACME server, so all those "free certificates without limitations" wouldn't be applicable if using the API key..

If it's even impossible to get the ZeroSSL ACME server working with a "partner ACME client", well, I can imagine they offer everything for free using their ACME server.. :smiley: Smart way of making more moneyz!

4 Likes
19

I tried again with the step:

acme.sh --install .....

acme.sh --register-account -m  my@example.com  --server zerossl

acme.sh --issue -d  example.com  --dns dns_cf ......

It works expected.

If you still have problems please report bug here:

Thanks.

4 Likes
20

I don't want to use -m and I don't want to use --install. It's a standalone Bash script, the latter shouldn't be required for the script to work.

4 Likes
21

I've been using acme.sh since the ACMEv1 days (2017 probably?) and I'm still sticking to it. From my perspective acme.sh was never a did-not-read-did-not-care type of script. You had to understand the script and it's quirks (certbot is no different by the way):

For example, acme.sh does by default not rotate keys (at least it didn't do this in the past and I don't think it does now). This was a rather strange design decision, because this kinda breaks the purpose of why we have 90-days certificates at all: To limit the effects of (undetected) key compromise [there are other reasons for short-lived certificates too]. There's a long back and forth discussion on acme.sh's issue tracker on this topic.

Anyway, if you want it "the standard way" you always needed to configure your certs with the --always-force-new-domain-key option to get a sensible key rotation. This new change is pretty similar: If you want to keep the old behavior you can still do it, you just need to configure it. Obviously configuration is always hard for non-informed users, but acme.sh has never been a does-not-need-configuring type of script.

For users who want to stick with Let's Encrypt and acme.sh, you can easily set the default CA to Let's Encrypt via the --set-default-ca command line argument. You only need this once, thus not requiring a --server letsencrypt each time you get a new cert. Compatibility with old certs is ensured anyway, but that's not the point here.

The change makes sense considering that acme.sh is owned by apilayer and ZeroSSL is an apilayer product - it's kinda first party for them, at least from their ACME support (they basically offer two different products: Certificates via the webinterface and Certificates via ACME, both products have different pricing and different features).

As long as acme.sh still supports Let's Encrypt I believe they can and should still be "advertised" here. Users should obviously be aware on the choice of their CA, so a prominant banner that tells them what CA they will be using is only fair (But also tell them that they have the ability to choose!).

I personally use acme.sh for both Let's Encrypt and ZeroSSL certificates: First of all, this is incredibly easy with acme.sh, you can use both CA's side by side with this client. Second, the reason why I'm using two different CA's in the first place is client compatibility: The ZeroSSL chain (they're basically a reseller for Sectigo) is much more compatible than Let's Encrypts ISRG Root X1, so I'm using their certificates for services that need legacy compatibility and everything else gets their certificates from Let's Encrypt.

Choice in the CA ecosystem has always been a good thing and is also kinda the reason on why Let's Encrypt worked on making ACME an IETF standard. "What is the default" doesn't really matter that much to me, as this is easily changeable for people unhappy with the default choice. The only argument against is that there will be uninformed people not knowing what they're doing, which is why good documentation is so important.

10 Likes