Say I had toaster.bad, no subdomains,
want to have TLS with publically trusted certs for a bunch of services but I want to decrease blast radius in case of compromise.
Therefore I want different keypairs for different services.
Are there facilities for that with LE?
You can generate multiple certificates with different keypairs, as long as you're staying within the rate limits.
Not sure what good it would do with regard to a compromise if all services are hosted on the same system though. If one is compromised in that case, all certs would be compromised.
3 Likes
They may not necessarily be on the same system or at least in another way beyond some security boundary.
My wording was for application compromise, not system compromise. Whatever that means in terms of real-world accuracy of system vulnerability exposure or not. This is purely theroretical.
So LE Certs do not get revoked when a new one with the same name gets fetched, interesting.
If I can have ratelimit/time many valid certs at the same time. And everything that is able to complete an ACME-challenge for that domain can fetch new ones:
Which ACME challenges are existing and supported?
(According to docs HTTP-01, DNS-01, TLS-ALPN-01)
So I essentially have to protect DNS and Port 80,443 on the addresses the name points to, to gatekeep issuance.
How would I be notified if new ACME-challenges get enabled whose paths I may not have locked down for users/programs?
How likely is a new challenge type a month?
Can I tell LE to disable challenge types for my zone or otherwise get a stronger authentication continuity?
Are there other free of cost CAs with DV other DV challenges that do not revoke same name issuances?
CAA Records should deal with those but not that strongly.
Is there some established way to somehow cross-sign services using ones own CA that has stricter verification, so as to have own clients trust only that but still have certs publically trusted for others?
Do I think the wrong way here and there is a really simple solution to that thought?
Usually applications cannot reach the certificate once it has been started. It's common to start an application as root so it can read the root owned private key and afterwards drop the privileges to a much lesser privileged user.
Correct.
Those you've read in the docs.
I don't know what you mean by this. It's quite common to have port 80 and 443 open. Look at all those websites out there using them. Or what do you mean by "protecting" and "gatekeeping" exactly?
I don't think you have to "lock down" anything to begin with, but my bet is to follow the API Announcements category. That way you'll get an email on the address associated with your Community account when a new thread is opened there.
You could use CAA RRs for that. See Enabling ACME CAA Account and Method Binding for more info about that.
I'm not 100 % sure, but I'm not aware of any free CA revoking duplicate certs. See ACME CA Comparison - Posh-ACME for a comparison of ACME CAs.
No, cross-signing is not an option for end users. Only for entities with lots of money willing to set up their own sub-CA for 
Personally I think you're overthinking this 
6 Likes
This unprivileged process will still have the private key in its memory though.
2 Likes
True true. That's technically exploitable.
1 Like
I mean, you can do really fancy things to try to isolate the private key from the system using it. Like, you can configure nginx to use PKCS11 to a Hardware Security Module, or possibly some system isolated in some other way. AWS offers some kind of "enclave" concept, where they manage the private key and the VM doesn't directly get to access it, though I haven't tried playing with it since it looks much more complex than my personal requirements. Wouldn't shock me if other "cloud" hosting offered something similar (at least the hosting providers that deal with larger scale customers).
For most use cases, though, it's more than enough to just keep systems up to date, monitor Certificate Transparency, and use CAA with those extra parameters to limit challenge methods & account.
5 Likes
I would insert a reverse proxy and use different subdomains.
Directing each name to separate systems.
No two systems would ever use the same cert, nor know anything about the certs in other systems.
[even the proxy would not know anything about the private keys]
1 Like
I know but yeah if it wrangles it for encryption then its still in memory like other person said. Otherwise it has some message passing thing to a separated process that does crypto handling. Which would be one kind of a security barrier I mentioned.
Whatever can listen on TCP 443,80 (only tcp?) for that IP can obtain certs to all DNS names that point to that IP.
Whatever can add TXT records to a DNS zone can issue certs for it.
I have to gatekeep access to these abilities to prevent rogue things obtaining LE certs for my hostnames.
This is all theoretic. I am bot assuming linux or any normal hosting conventions here. I
Quite high noise channel for that.
Discourse in general is very mail-noisy.
Not optimal but filters exist.
Nice. This is part of what I am looking for and closes a bunch of gaps in my mental model.
And Acme Accounts at LE are authenticated by their own keypair for the account only. At least certbots file structure under /etc/letsencrypt makes me think that.
Cool, thanks for that link.
sadface
Thats what I want.
Have a very solid mental model of what LE certs prove and what not.
For improving my admin game and maybe finding a scalable enough conceptual hole to one day to brag about.
Usually the cheap PKCS11 hardware keystores have horrible performance.
Softhsm on different host or similar concept might be good enough for a somewhat well used site.
Yeah almost all the clouds have some way that they manage TLS termination for you with automatic cert handling. I am kinda put off by a lot of theater around enclave terminology. Because in the end its a promise and their cloud hsm could be a radioactive potato. I have to trust them anyways, so they shouldn't pester me with details about their paid abstraction.
But thats my jaded internet cynic speaking.
The challenge and account binding really is most of what I missed.
1 Like
A lot of money is very relative. You can have your intermediate as a service, there are CAs that offer that. Cost isn't public but order of magnitude is 10k.
- https://www.digicert.com/dedicated-intermediate
- Dedicated Intermediate CAs | GlobalSign
- and others. But not Let's Encrypt.
Just know that the CA selling you the service keeps full control of all the issuing private keys at all times. They wouldn't be trusted very long if they gave you the power to issue certificates outside CA/B Baseline Requirements.
5 Likes
Did you ever start with Apache just to notice that it can't handle your application or TLS passthrough when you want to add more services to the mix?
I was debugging someones complex setup with user controlled subdomains that uses LE where they were stuck about reasonable cert handling config.
Thats what started this whole thought process.
10k for not owning the private keys feels weird.
What would I gain over a public CA.
The whole reason for the idea is to have 2 "assurance" levels.
Those machines where my own CA is in trusted certstore and those where it isn't.
I guess the less annoying way would be to have some kind of 2 infra name structures or querying host address based cert chain delivering.
Like internal.example.org and external.example.org or serve private CA signed certs only to owned ip range.
Edit:
lol service . net is occupied by a plesk panel
You could define your trust chains by yourself and browsers would show "Verified by: Yourself"
Not much.
You can use public certificates on both. The only requirement is that the fqdn actually be valid, in public DNS, and controlled by you. If you use dns-01 validation you can even resolve A/AAAA records to private IP addresses.
1 Like
Quote from your first link for intermediate as a service:
"Note: In some rare cases (e.g., SSL inspection/decryption), the intermediate is hosted by the customer."
I wonder.
That can happen. It requires the "customer" to follow CA/B baseline requirements, including all audits and all. It pretty much amounts to running your CA. You just went from spending 10k to 1M+.
Inspection and decryption should not happen, that's an ultraquick way to get distrusted by browsers. Unless you use a private CA.
Yeah read further and its a non intersecting offer (inspection vs browsertrust) as you say.
1 Like
Depends. The running webserver would somehow need to be serving the challenge token. So that would require access to whatever the webserver would be serving. If an attacker could manage to put random stuff into the /.well-known/acme-challenge/ directory, then yes, they could issue a certificate if nor other mitigations (such as CAA) are in place.
For the dns-01 challenge, it's often recommended to run a private instance of acme-dns. That way you separate the ACME challenge from the DNS stuff from your regular DNS zone like BIND or PowerDNS.
8 emails in 2022. I'm sure you can handle 8 mails per year without filtering, right?
Correct, each ACME account has their own separate account keypair.
3 Likes
8 mails in 2022
Then its just me that didnt read properly
custom acme-dns
If its what I think it is that sounds nice.
requirement to serve /.well-known paths
When it can listen on a port, it usually can send too. And just create a new LE account. (Still under the assumption that CAA account pinning is not active.)
Thanks for all the info!
It's a "custom" DNS server specially and only for ACME dns-01 challenges. You'd use CNAME RRs or NS RRs to "redirect" the _acme-challenge DNS label to the acme-dns instance. If the acme-dns instance isn't running, there's no way the challenge would succeed.
Note that usually (always?) that would require that you have separate IP addresses for the regular DNS service and the acme-dns service.
1 Like