Another free CA as an alternative to Let's Encrypt

Use pipx-in-pipx to make it even more robust: https://pypi.org/project/pipx-in-pipx/

Link: https://dehydrated.io/

Very good point. This is a great selling point for Go. It takes so much deployment pain away.

> You could jump through all those silly hoops (most of which will be completely alien to people who are not Python devs) in order to use the "official" dependency-heavy Python client.

Why would snaps or docker be completely alien to people who aren't python devs?

> And that's before we start talking about conflicts that can occur between Python libraries....which, let's face it will happen in an "average Joe" environment where Joe is just randomly using apt to install any Python dependencies.

What kind of conflicts are you talking about? In both Debian and Ubuntu repos, all Python packages and their dependencies are nicely versioned and separated so there can't be any conflicts between Python versions. As for the handful of Python packages that are mutually exclusive (Pillow and PIL), either only one implementation is in the repos or you can install any one of them and have it work since they're drop-on replacements.

Now, if you start installing system-wide packages with sudo pip, you'll of course break things, but if you're installing things from the apt repos, there is no reason to ever do this (and pip will yell at you that you shouldn't do it).

I've stopped using Ubuntu in favour of good old Debian due to Canonical foisting snaps. I know you can remove snapd but the whole Ubuntu ecosystem is pivoting towards them.

Because it's not conjusive to a minimal attack surface - by way of example: https://www.helpnetsecurity.com/2019/02/13/cve-2019-7304/

certbot does not officially support binary packages on Linux, so you have three choices for supported releases: snap, docker, or pip (best effort). If I’m not already using docker for the site (spoiler: I’m not) then why the fuck would I install docker if I’m not willing to install snap?

The OpenBSD acme-client is OpenBSD specific and lacks a whole bunch of features, it is I suppose exactly what you'd expect the default acme-client to be in OpenBSD and so it fits its role perfectly but it doesn't make any sense as the "standard" ACME client with no support for lots of desirable ACME features.

From the gh page doc it requires too much stuff to set up. Imagine if you need certs for >10 domains I prefer lego + cronjob or caddy. Most web apps speak http now and it's just a matter of proxying to a local port, unless you are using php, uwsgi, psgi. Php-fpm is also well supported.

> I don't know any case where someone has control over the root domain but is not eligible for a wildcard cert.

Companies very very often point their root domain at a hosting company for their marketing site; let's use Netlify as an example.

This does NOT mean that I would expect Netlify to be able to issue wildcard certs for my domain.

Basic "www-izer" (redirection) services are another example where the root domain is pointed somewhere that should not be able to issue wildcard certs.

This loose allowance is going away. Current BRs allow using 3.2.2.4.18 and 3.2.2.4.19 (Agreed upon change to Website) for wildcards until December 2021. After that:

> For Certificates issued on or after 2021‐12‐01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.

Let's Encrypt are just ahead of the curve here, this was always unsafe because it means if your corporate site https://big-corp.example/ is on some bulk host that bulk host can get (even though presumably they wouldn't) wildcard certificates that will also match mail.big-corp.example and db2.big-corp.example and auth.big-corp.example and vpn.big-corp.example ...

> Having control over the HTTP response for the root domain but not being authorized to have SSL certificates over subdomains is already a veriry dubious concern

What about marketing/static hosting sites like Netlify/Vercel/etc? I can point my domain there. That does not mean they should be authorized to have wildcard certs over the whole domain.

The Ten Blessed Methods (no there currently aren't ten of them, yes I'm going to keep calling them that) do not allow you to just make up rules like "Let's have a DNS record saying it's OK not to verify anything".

Currently methods 3.2.2.4.18 and 3.2.2.4.19 allow you to get a wildcard based on the web site changes, but that's clearly unsafe and is going away from December. Let's Encrypt never allowed it because it would be hypocritical to have people saying "This is unsafe" while also allowing it.

It depends--some ACME clients have a list of DNS providers they support and take API credentials to automate DNS verification

I use

1. Free Cloudflare DNS 2. Traefik's built-in ACME client

Great and now your application server has control over your DNS which it otherwise would not need.

I already had Bind on the machine so it was logical to add the zone there and utilize nsupdate : https://gist.github.com/kronthto/893715f12cc0b1cda9fcfdbd8dc...

But what you are suggesting should work just fine aswell - there should be no need for a persistent service. Of course the service would need to run on port 53, so you actually cannot have another nameserver on that machine already, and also require CAP_NET_BIND_SERVICE .

A quick search lead me to this python project that could be an inspiration: https://github.com/pawitp/acme-dns-server

use the same provider (but a different account)?

you are unavoidably dependent on 1-3 anyway

The "DNS provider with a better API" can be your own bind9 server on the same machine as certbot, updated with RFC 2136. Completely standard, no changing APIs, no 4th party, no maintenance. I set up a server like this at work and haven't touched it for a year and a half.

Which isn't going to happen; DNSSEC and DANE were introduced in browsers several years ago, and the browser developers withdrew support. These are dead-letter standards.

i've always reencrypted when getting a new cert. not sure if thats an antipattern though. i just didn't want to be bothered by which cert encrypted what data

Encryption is performed with private key, not with certificate. If you can issue new certificate for the same private key, it should be able to decrypt old stuff.

Rotating keys might be a good security practice, though. But not necessary.

Now you just have to upgrade certbot every 1-2 years instead, it feels like.

It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server.

This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file.

After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs.

There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process.

While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…

Concerns when automating and connecting with a third-party service is that you can introduce more vulnerability. (Or even introduce a backdoor if you use a malware / insecure software to do so.)

Except when certbot fails (silently) for some unknown and different reason every three months, and you have to ssh in anyway to fix it. Out of all the software I run on my tiny hobby VPS (a few web sites, E-mail), certbot requires more babysitting by an order of magnitude. Even more than spamassassin, which gets wedged regularly. I'm not a professional sysadmin, so something is probably configured incorrectly, but certbot's error messages are so cryptic and non-actionable that I've never been able to solve it. So, I have a calendar reminder every three months to log in to the VPS and figure out what went wrong this time...

Back before the corporate browsers took over standards via whatwg and worse, unilateral moves, you could have a TLS cert for many, many years. I often set mine for 20. But because of changes browsers have made in the name of security this is no longer possible and so shifts the insecurity to another part of the process (the complex system for automation on both client and server sides).

With the DNS option the machine doing the request doesn't have to be the machine using the certificate though.

I have a separate machine doing the DNS challenge and the cert is then distributed to the machine needing it.

Technically true for the regular web challenge, but easier with DNS I think.

> If you want to use the www auth you need to allow outbound connections to any IP

Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions:

* https://github.com/dehydrated-io/dehydrated/blob/master/docs...

> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.

Are you aware of LE/ACME's "DNS alias" mode?

* https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth.

People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition):

* https://github.com/joohoi/acme-dns

There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider:

* https://github.com/AnalogJ/lexicon

And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.

> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised

This is true, but the machine doing DNS modifications doesn't need to be accessible to any outside initiated connections at all. So if someone has the capacity to compromise such a computer, what would stop them from compromising your desktop computer or your laptop instead?

But either way it would indeed be nice to have further limits on what the box could do. But I think LetsEncrypt does not need to change anything to make this possible.

https://letsencrypt.org/docs/challenge-types/

The DNS verification works by creating a DNS TXT record named "_acme-challenge" with a TXT value on the domain you are verifying.

So really what you want is for your DNS provider to implement into their API access keys that can be restricted so that the absolutely only thing the key is allowed to do is to create, change and delete the DNS TXT record named "_acme-challenge". Perhaps some DNS providers already make this possible? But the one I am using is only able to limit it to a ZONE, but not to a specific record type and not to a specific label.

In fact I wish CloudFlare would allow such specific fine-grained permissions. But even if they did they'd probably make it part of the Enterprise plan and I am still not an Enterprise customer so.

Edit: Meanwhile that I was writing this someone else posted a sibling comment about ACME DNS alias mode, which I had not heard of. https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... That's very close to good enough. Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.

Why would the leaf be different? Are CAs supposed to refuse to sign certificates that have been signed by a different CA?

They're all 3 certificates long (leaf/intermediate/root) apart from Let's Encrypt which, due to their cross-signature, are 4 certificates long for ECC.

Same here! I think it was ZeroSSL that bought Caddy now that I remember.

What did you find unclear, specifically? We encourage users to come ask for help on our forums, we'll gladly explain everything you need to know. https://caddy.community

X.509 has a feature called constraints, where you say e.g. "This is a CA but it must only issue for names under .foo.example" or "This is a CA but it can only issue for S/MIME" and to make these effective you set a bitflag that means "If you are parsing this certificate and you don't understand this part, the certificate is invalid for you".

The consequence of that second element is that clients which don't understand the constraint (and thus wouldn't know which are or are not trustworthy leafs under the constrained intermediate) mustn't trust the intermediate at all. This means if you need those clients you cannot use the constraints they don't understand, because they'll reject your entire intermediate.

Mozilla defines constrained as it pertains to the problems they care about, so for example they do not consider a CA constrained if it lacks a constraint they require.

For your use-case there are two practical options:

1. Most suitable for commercial projects e.g. you're a startup selling a new IoT device. Talk to a commercial CA and work out a deal where you get what you need. Outfits like Sectigo strike deals like this all the time. They understand that you don't want to pay high prices per certificate for this problem, but on the other hand you may be able to guarantee minimum volume and that means it makes commercial sense compared to piecemeal orders.

2. For a hobby project talk to Let's Encrypt about getting an exemption to the rate limit for your specific application, or, if it fact the devices are owned by third parties, whether this should be on the Public Suffix List and thus exempt from rate limits anyway. (the PSL also means these devices can't share HTTP cookies among each other, which might well be exactly what you wanted anyway).