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:
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
From one client ACME developer to another: have you considered just letting the CA return errors, rather than trying to anticipate them? Like, you don't have to know whether something will work. Just try it; it should make the client logic much simpler. CAs will all have slightly different policies and implementations, I figure as long as you handle errors well that's the only complexity you need to worry about.
I'm finally nearing completion of the total overhaul of my former ACME client.
nbsp's are not my friend right now...
I don't want to use
-mand I don't want to use
I'm totally with you on this.
For Let's E certs, I've been using acme.sh for years. The one thing is, I'm running my own fork which I yank out all install-related things. I fail to understand why any of these ACME-clients want to touch my Nginx configs and all of them do that without asking me first. Zero trust here.
It's not required to use
--install. I was just showing the example steps.
Do whatever you want. but if you don't follow my steps, it doesn't make any help to your problems.
I was trying to use the EAB options (from the example on your Wiki), which are an alternative to the
-m option. However, using the EAB options, it failed. However, I do want to use the EAB options and not
-m. Therefore, your example was, in my specific case, not applicable.
I just tried again with the EAB wiki.
It works as expected.
If you still see errors, please report bugs at github and provide logs with
A lot has changed with the transition from Comodo to Sectigo, and it's inaccurate to say Sectigo is a bad actor based on the actions of Comodo. The CEO you're concerned about stayed behind at Comodo Security Solutions, as did the browser. Meanwhile, Sectigo has taken over the aspects of Comodo's work that benefit the ecosystem at large, like running crt.sh and the Mammoth and Sabre CT logs. They also sponsor Let's Encrypt's CT logs.
I just want to reiterate that @Neilpang is a valued member of our community doing great work, and more ACME clients with more diversity of supported backends is a good thing for our shared mission of encrypting the web.
If I use certbot, this doesn't matter at all, right?
Correct, certbot (currently?) only uses Let's Encrypt as the CA, not any other.
But you can specify the server and eab data to use it for example with ZeroSSL:
--eab-kid "$ZEROSSL_EAB_KID" --eab-hmac-key "$ZEROSSL_EAB_HMAC_KEY" --server "https://acme.zerossl.com/v2/DV90"