ISRG/Let's Encrypt have achieved what they have through automating the CA.
Could versions/branches of the automation tools be published with the intent to standardize or provide a clear path for business wanting to create name-constrained subordinate CAs with the fulfillment of the audit requirements being mostly automated and less burdensome?
This would make it more practical for small-medium businesses to maintain publicly trusted authority for everything under their domain.
2 Likes
This may be a dumb question, but what would be the advantages for a small-medium business running and auditing their own CA versus automating their DNS challenges and using Let's Encrypt (or another automated full CA) for whatever certs they need? That is, whatever efforts that would have been made toward automating running a CA could instead be efforts made toward automating issuance with a willing full CA. It just seems a lot easier to me to just use Let's Encrypt than to run my own CA, but there are probably use cases I'm not thinking of.
2 Likes
@petercooperjr When you have perhaps hundreds of servers all under the same TLD, but many have their own specific subdomains that need to be separated for security. Most small-medium and larger companies have to deploy internal CAs anyway, and being able to use the same standardized infrastructure to assign certificates on-demand without going to an external service can be helpful.
Part of it is also that Name-Constrained Subordinate CAs (NCSCA) can be issued for more than just server authentication certificates; with a NCSCA a company CA can issue publicly trusted document signing certificates for each employee in the domain with the hierarchy of their domain and company structure, and be able to publish revocation automatically with the termination of an employee.
3 Likes
Let's Encrypt used to use technically constrained subordinate CAs (not mil, not US Government, not IPv4, not IPv6), but not anymore.
All this stuff is part of the certificate profile, which I think any CA automation software should support? For example, if you operate an internal PKI + ACME server using smallstep, you can configure that as part of the certificate template. (Though I'm not sure whether the issuance itself will check the CSR against the name constraint when signing.)
I rate smallstep very highly for this kind of thing in general though. It's built to be used in these kinds of generic situations, unlike highly specialized software like that which Let's Encrypt builds for itself.
2 Likes
It's been a while since I looked at this, but I think that is irrelevant. IIRC, the end Certificate's chained certificate (fullchain) needs to include the issuing CA's Certificate, said CA Certificate containing the name-constraint itself. So a name-constrained CA could sign any number of external domains - but the certificates would be recognized as invalid by libraries/browsers, because the chain prohibits them.
Also, I think Amazon offers a pricey cloud version of this service.
2 Likes
but wouldn't itself being against it's own CPS, making it a misissue? name-cconstrained CA still have some audit requirement, mostly 8.7 form itself and parent CA.
3 Likes
One would hope, anyway! Less stressful to reject them early as policy than to hope that nobody figures out a way to misuse such certificates. Comments like this are scary, though possibly out of date.
Edit: found a discussion on smallstep about both blocking names using name constraints and also during the issuance process: Limit the allowed domains in certificate requests to be signed · smallstep/certificates · Discussion #382 · GitHub
2 Likes
Probably, if those are coming from a trusted root, and I admittedly was not thinking of a trusted context when first reading this. But those are organizational issues – as is validation. The point I intended to make could have been more clear - the CA software itself doesn't have to be extended to enforce the constraint or perform any validation to function, as the constraint is in the required intermediate and bubbles down. Those features could be handled elsewhere.
2 Likes
I probably should have specified I was referring to a trusted context, as many existing public CAs offer subordinates managed on a company's behalf, or as described in the latest spec from the CABF in sections 7.1.5, 8.1, and 8.7, managed by the client, but with a quarterly audit requirement. If the audit requirement with the issuing CA could be met with automated tools, then the cost of a company running their own subordinate CA comes way down.
4 Likes
You were clear, I read your posting too fast.
What you desire is great and I am all for it - but I don't think it is likely, at least in the next few years. The compliance and regulation of it by the sponsoring CA would be overwhelming, and LetsEncrypt already has a large backlog of "essential" features they are working through.
If you're looking to deploy something internally in the near future, a chunk of what you want could be handled by DNS challenges as @petercooperjr suggested. Using the popular acme-dns server as an example, your organization could delegate the DNS challenges to a centralized acme-dns server, or even facet them out by subdomain. Your org could even use a centralized API server to coordinate everything, so internal systems only talk to the internal API - and that machine is the only one that talks to LetsEncrypt or acme-dns.
3 Likes
Alternatively, there might be a good place within the PKI world to have a discussion about how to make name-constrained delegations less burdensome. I think the biggest policy obstacle to it is that domains can expire or be transferred and the people writing PKI rules care about making sure that certificates issued under the old meaning of a DNS name get revoked, or don't last very long, under the new meaning.
So if a CA issued a name-constrained intermediate for example.com that was valid for a year, there would be a question about how the original CA can continue to confirm that the recipient continues to control example.com over the course of that whole year. This is also a question for normal end-entity certificates (which is one reason that Let's Encrypt favors short-lived certificates!), but it might be more of a question for intermediates because they are more powerful.
For paid CAs that sell name-constrained intermediates, they might rely more on contracts and bureaucratic means to make it reasonably likely that the recipient will actually continue to control the name, or at least stop using the intermediate otherwise. I imagine that gets scarier for the industry if you try to automate it more and do it on a wider scale.
It might be a good discussion to bring up in the CA/B Forum.
5 Likes
Trying to avoid paying for such a "service"...
A 90 day validation period on Intermediates CAs (ICAs) would severely reduce their "usefulness" in my eyes.
I think the Intermediates should be at least double the end-leaf period (at an absolute minimum).
So for 90 day leafs, that would be 180 day ICA life.
With ICA renewals starting at 120 days.
OR
with equally less for both...
Like 120 day ICAs and 60 day leaf certs.
With ICA renewals starting at 90 days.
Such a scenario seems kind of risky in my eyes given there are (currently) no alternate service providers.
I really would not like putting all eggs into one really short-lived basket.
But someone has to "pave the way"...
So if anything like this can be done by LE (in any way shape or form), I would say "yes, please do it".
Any shortcomings can always get fixed later (in version 2.0) - LOL
2 Likes
for that kind of trust it can be synced to domain renewal or oscp verifier can look up whois info (registration date, so it will change when domain change hand) to confirm it's from same group.
1 Like
The CA/B Forum is dealing with issues related to certificate issuance conditions. All their work is based on the assumption that the underlying domain name system is stable in respect of the ownership of a given domain. I think the scope of their work should be extended downward to involve more from the aspect of the management of the domain name system.
2 Likes
Well, if the DNS service could be completely trusted (with DNSSEC and DANE and the like), then sites could just publish their public keys in DNS directly and then we wouldn't really need Domain-Validation CAs (or intermediate name-constrained CAs) at all since browsers could just check DNS for the needed keys. We're some ways off from that being a reliable way to go everywhere, though. (Just look at the number of Help requests here from people confused that their domain name is DNSSEC-enabled.) I'm not sure where the right balance between DNS and CA validation is, or if the easiest approach is to just shorten DV certificate lifetimes even more.
3 Likes
I was thinking, for example, that an expired domain cannot be purchased again until all certificates issued for the previous owner expire.
1 Like
What about a five-year certificate? Ouch! 
1 Like
Perhaps revoking all previously issued certs could expedite the transfer.
2 Likes
Precisely, good detail.
The main point is, that domain management cannot assume in their standards and procedures that certificate management standards do not exist.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.