Between ZeroSSL's sponsorship of Caddy (and Caddy, with 2.3, is also obtaining certs from them by default) and this, looks like they're trying to take some of Let's Encrypt's market share. I guess competition is a healthy thing...
there will be uninformed people not knowing what they're doing, which is why good documentation is so important.
Yes, the default CA is marked in the main readme. GitHub - acmesh-official/acme.sh: A pure Unix shell script implementing ACME client protocol
And it will always be updated with the correct value.
Thanks.
And what else could they be?
Like:
Q. How could LE users NOT get a new cert from ZeroSSL?
A. When one is automatically switched from LE to any other CA, acme.sh will try to get you a new cert on renewal and fail because your CAA is not allowing it.
[did I just repeat myself?]
Just to clarify what others users and especially neilpang was trying to say about old certificates.
acme.sh has supported different CA's for quite some time. acme.sh remembers the used CA for every single certificate. Meaning that a certificate issued by Let's Encrypt will also be renewed with Let's Encrypt. This behavior will not change even with the future default-switch, because this will only affect new-from-acme.sh-perspective certificates. A renewal will not change your CA. Only if you do new amce.sh --issue command your CA will change.
I don't agree with this claim. If you have undetected key compromise with automated key rotation you're likely to just get compromised again each time the keys are rotated, so you gained nothing.
I can see maybe there are scenarios where e.g. you have offsite backup that gets compromised and if you were doing rotation the offsite might be pushed out enough that keys revealed are worthless, but it's a real edge case.
The main purpose of shorter certificate lifetimes was to achieve agility. If the goal was to avoid key compromise the rule would say you can't re-use keys, not that certificates have to be short-lived. For example SHA-1 deprecation took several years because people had 3+ year certificates with SHA-1 in them, obviously some of those people will be surprised if it stops working any time in that period.
This goal was not impacted by key re-use. I don't see re-use of any otherwise cryptographically secure private key over a period of a few years to be a problem. Again, if it was a problem the rules could outlaw it already, and they don't, because people who've thought about this harder than me don't see it as a problem.
Can you rotate if you want to? Sure. Should you by default? It depends, it may be a huge inconvenience and as we saw there is little benefit.
Competition in any space is great for the overall quality of the competitors, so it's good to have more acme options.
On the general topic of zerossl gradually eating up some of the Let's Encrypt client ecosystem (they also now own Caddy), you can see why they're doing it (instant market share), the question is how will that benefit them commercially in the long run.
... and what kind of damage will a for-profit entity do to the "market" in the long run? I personally don't see security and privacy as monopolizable commodities in the modern web. To me it's a bit like putting an auto manufacturer in charge of oxygen management.
Perhaps the word "priceless" is appropriate.
If you look at some of the history of "free" on the internet... well...
PayPal was free... until they sold out to ebay and became one of the most notorious financial companies in history that has now cratered by the hand of their owner.
Yahoo Auctions was free... until they started charging and cratered overnight.
From where do I get an unpleasant feeling when a for-profit entity tries to "absorb market share" in a free and crucial sector? History.
I really like the fact that Let's Encrypt is pushing the price tag on security and privacy towards zero. If certificates can become as free and available as oxygen, there's no longer an economic excuse for not using them. I fear that ZeroSSL is not existing in that sector to keep the floor low, but to silently monopolize to raise the floor.
To clarify, Caddy now supports multiple issuers. Let's Encrypt and ZeroSSL are the defaults -- the other will be tried if one fails. You can, of course, configure this entirely to your liking.
Since ZeroSSL's funding, Caddy has improved quickly and drastically. For example, it's the only web server that can automate certificates from multiple sources (including an internal, self-signed issuer if desired -- doesn't even have to be ACME). It's super stable and scales well in production. And pretty much all the new features and fixes in the past year have been a direct result of sponsorships.
I guess there may exist a target group that can't manage the current DIY free system and would be willing to pay for free.
And, to a certain extent, that might actually be a good thing; To be able to easily buy a fully functional freely secured system without the hassles that may come with it (going all in on the DIY path isn't for everyone).
We all know "time is money", I see this more as paying to save time and that makes sense (so long as the price is reasonable).
Yes, thanks--I knew that, and meant that, but my post wasn't very clear. And certainly sponsorship provides funding, and funding does helpful things like putting food on the table, buying hardware, etc.
I can confirm that ~ 3% of users are willing to pay for support etc. Some people just want to be able to contact support and get reliable help or expedited fixes, usually it's those who have a business (which makes money) that they need to keep running smoothly.
Congrats, @Neilpang! From the start of Let's Encrypt, we have worried that if we were the only free CA, or the only ACME CA, it would create too much centralization and a potential single point of failure for the encrypted web. I am completely thrilled that there's another free ACME CA out there, and I think your setting acme.sh to use it by default really shows the robustness of the ecosystem. I'm also particularly glad that you've been able to get sponsorship to continue working on acme.sh.
+1 totally agree!
@Neilpang thanks for your hard work and early heads up of this change.
I've been using acme.sh for my underlying Centmin Mod LEMP stack integration to automate HTTPS/SSL certs for Nginx vhost site creation for years now and tens of thousands of Centmin Mod users have automatic Nginx HTTPS because of acme.sh 
Certbot/python was just too heavy a footprint compared to pure bash script.
Example of how Centmin Mod LEMP stack uses acme.sh and Letsencrypt to automate Wordpress installation with advanced guest full HTML page caching and HTTPS by default with CF DNS API based domain validation & configuring Cloudflare Full SSL and Nginx origin configured with optional dual SSL support for RSA + ECDSA SSL Letsencrypt certificates https://blog.centminmod.com/2020/09/06/203/wordpress-cache-enabler-advanced-full-page-caching-guide/ 
I think there are a few concerns going on here, one with the general concept of sponsorship of F/OSS, and some with the particular sponsor at issue.
Sponsorship is a mixed blessing. On the one hand, it provides funding, which is helpful for any number of things. On the other hand, it gives the sponsor some degree of explicit or implicit control over what the sponsored project does, not infrequently resulting in tension between what the sponsor wants and what the community wants, and sometimes resulting in the destruction of the sponsored project altogether (See: CentOS).
How big of a concern is this? Well, that depends a lot on the sponsor(s). And unfortunately, ZeroSSL has given cause for some concern:
- They changed, overnight and without warning, from a pretty nice web-based client for Let's Encrypt (leaving aside what a bad idea that is), into issuing "their own" certs (on which, more later)
- At the same time, they moved from being a totally-free service to a mostly-paid service
- "Their own" certs aren't really theirs, they're Sectigo (i.e., Comodo) certs, and Comodo is well established as a bad actor. For any who may be unaware or have forgotten:
- They took part in the general CA FUD against Let's Encrypt, but took it several steps farther.
- They tried to register the trademark for "Let's Encrypt", in an apparent attempt to prevent Let's Encrypt from using their own name--eventually public outcry forced them to back down.
- Their own web browser, for a time, singled out certs from Let's Encrypt, marking sites using those certs as not secure. They eventually updated the code to apply the same warning to any DV cert.
- When called out about about each of these issues, let's just say that their CEO didn't do anything to dispel the idea that they were deliberately spreading FUD.
So I think concern, to a degree, is completely justified. Two pretty major players here (probably the most popular alternative client, and a pretty cool web server) have been sponsored by a company with some questionable history, who also keeps some pretty questionable company. And within a fairly short period of time, both are taking steps to favor that sponsor--over LE in the case of acme.sh, equal with LE in the case of Caddy. This isn't "OMG the sky is falling", but I don't think it requires being a paranoid conspiracy theorist to be a little concerned here.
Thanks @danb35 for keeping the light shinning on things that get done in the dark and are all to easily forgotten. We'll have to keep close eyes on them.
One of the things that really made me raise an eyebrow 
was the business need for apilayer to "buy up" overlapping things:
zerossl.comsslforfree.comacme.sh
Sure, the third differs in features from the first two, but those first two served fundamentally the same userbase, which is a telltale sign of a monopolization attempt. Why buy it when you can probably build it yourself for far cheaper unless you're trying to follow Sun Tzu's teachings?
By the way, I continue to think that there are three of them!
I also think this development really shows ACME's credibility as an interoperable standard.
(In very early mock-ups of Certbot, we had the idea that users would be prompted to choose from a list of compatible CAs when they requested a certificate... while I'm not certain that that would give users a clearly better experience, it's cool to consider that it's now theoretically possible.)
I could see a benefit to using a CA preference list and have it just go down the list until it can get a cert.
Hopefully on the first preferred CA; but should that fail, it could immediately continue by retrying with the number two CA listed (and so on until the list is exhausted - in which case, your Internet is likely down).
While we may be wandering a little from the topic Certify The Web does also support multiple CA's out of the box and automatic CA fallback has been a planned feature for a while - the main obstacle is that there is no agreed way for an ACME service to declare it's DV cert limitations (or rate limits etc) up front, so you have to code/configure each (e.g. BuyPass keeps changing how many domains you can have on a single cert and have been flip-flopping on wildcard support, so you might be able to fallback to them or you might not).
Incidentally CTW was also approached by apilayer for potential acquisition last January (I'm all for having an exit strategy) but I think we were a little out of their price range, being already free + commercial. Interesting though, I wonder which other projects were approached and which others have been sponsored etc that we don't know about.
I look forward to seeing more free + paid ACME CAs, I think even LE could charge (perhaps under a different brand) - as I previously mentioned, some orgs do just want to pay someone so they can ask for support when they need it.
buypass was option for a while, however they dont offer wildcards, when zerossl as far i noticed for my needs, seems to be exactly the same as LE.
Since i saw this i did switch my home domain certificate to zerossl, just to see if everything works properly and again for me it can be direct replacement for LE, there is also one benefit you can get full ECDSA chain right now, since E1 signing is still not active on LE side...
buypass has however one advantage above zerossl (and probably LE), CAA mailing in case someone wants to create certificate for your domain and is not authorized...
anyway for my home domain im gonna use zerossl for next 2-3 months, hopefully E1 signing for my ECDSA chain will be possible at that time, so i have choices...
I also hope all provides will add CAA warning mails as buypass is doing and yes i dont really care technically if i issue ECDSA certificate that whole chain is not signed with ECDSA, however my OCD prefers it 