tl;dr: is it possible to have a Let’Encrypt certificate issued with the keyCertSign bit set?
Hi,
I have generated a certificate through the acmebot on Azure with the intention of signing additional certificates for subdomains with it. After lots of fruitless experimentation I realized that I could never have succeeded since the cert does not have the keyCertSign bit set, so it cannot be used as an intermediate cert to sign other certificates.
Is it possible to request a Let’s Encrypt certifiace with that bit set so that I can use it as an intermediary? If so, how can I do that?
BTW: I did tests on ptlfoo.p.getportal.org. You can see the connection failure when visiting that domain. Here is the report of an SSL server test and under “certification paths” it tells you “Not trusted (CA key usage check failed: keyCertSign bit is not set)”
I think what you might want is a “Technically Constrained” certificate, which is is subordinate CA that is constrained to issue certificates only for a certain DNS subtree (domain name).
That probably doesn’t fit in with Let’s Encrypt/ISRG’s overall mission of helping secure things for the general public. Their efforts are better spent on the millions of ordinary certificates they issue per day.
Yes, that is what I would need. Thanks for the hint.
I guess, for Let’s Encrypt to issue these kinds of certificates would be fine, since they cannot be “misused” in any way. But with how rarely they are nedded, I see that it is not a priority feature.
Is there some reason that either getting a wildcard certificate, or just automating getting a real separate certificate for each domain from Let’s Encrypt, wouldn’t work for your purposes? Why do you need to sign new certificates yourself when Let’s Encrypt can sign ones for you?
I am building a service where people can have their own personal cloud computer (called Portal). Each Portal would be reachable under a subdomain like <short hash>.p.getportal.org. (BTW, you can read more on getportal.org)
If successful, this would result in (hopefully) many more then 50 Portals being provisioned per week. And if I understand Let’s Encrypt rate limiting correctly, it would prevent each one requesting a separate certificate. (However for a prototype I might take that route)
Also, privacy and data-ownership is important, so each certificate should be issued for exactly that one Portal. Otherwise, with a wildcard certificate, they would all have to share a single private key, which I do not want to do. It would open an attack vector where an attacker could spoof any Portal if they get their hands on one of the keys.
Additionally, if you decide you really want individual certificates despite the above post, you can apply for a rate limit adjustment here.
I’m also pretty sure even technically constrained subordinates are subject to WebTrust audit requirements which would put them out of reach for anyone except a massive corporation.
this is a reason to only support cipher suites with perfect forward secrecy, not a reason to avoid a wildcard.
from what I think I know about perfect forward secrecy, I don't see how that would help me here. Perhaps I need to read up on the topic.
do you plan to disseminate the private key?
Originally, I planned to have each Portal generate its own private key, then create a CSR that is signed by my Let's Encrypt cert. Each Portal would keep its private key secret, obviously.
or can you have a separate tls terminator/reverse proxy in front of the portals?
Not quite sure what you mean here. I plan for each Portal to have its own tls terminator routing requests to services/apps inside.
A single tls terminator in front of all Portals would not work. In general I want to work under the assumption that each user can have full access to their own Portal. That means that they must also be isolated from each other.
knowledge of the secret key doesn't allow you to read past traffic. so, once you realize the key has been compromised, you can replace it with minimal damage.
there still is impersonation risk for future traffic, but that's an issue either way.
if you want an alternative, you can have each of your clients get their certificates by themselves, automatically: add *.p.getportal.org onto the Public Suffix List, and each of your portals will have their independence ratelimits-wise.
Yes ok, I was mainly thinking about impersonation which is why I want to have locally generated keys, not shared keys.
Another good hint about the public suffix list, thanks. I wasn’t aware something like that existed. I’m not quite sure about the implications but I’ll look into it.