Two years ago there was a discussion about allowing permittedSubtree certificate authority signing by letsencrypt.
Since a few years have passed is there any progress on this or is it possible to reconsider allowing this?
Hi @sqrtroot,
As far as I'm aware @jsha's response on that thread is still the status quo:
under current BRs, a name constrained subordinate has to meet all the same requirements an unconstrained subordinate does, which means secured storage and audits. It would be quite a lot of work and expense!
It is not something Let's Encrypt is able to pursue in the short to medium term.
Do you have any other good recomendations on createing certificates for internal network without leaking domain names for them. I’ve got a script that does it with dns responses but they will still show up in certificate transparancy reports and leak info that way.
If the services are strictly internal and you control the relying parties I recommend you create an internal PKI instead of using the web PKI. You might be interested in a project like cfssl.
One option would be a private enterprise PKI trusted only by your internal equipment. There are numerous software solutions for that.
Another workaround would be...
Using neat DNS tricks and clever wildcard certificates.
- Hypothetical Scenario 1
I want to have secret hostnames not published in CT logs but with a certificate trusted in the public PKI.
- It is assumed that implementer has full DNS control over domain, such as example.com
- For each secret host, choose an FQDN in the form of secret-host-name.non-secret-but-unique-name.example.com. For example,, internal-wiki.priv-group-1.example.com.
- Request certificate issuance for a certificate with the dnsName "*.priv-group-1.exampe.com"
- For security sake, define a new priv-group-X for each secret host and ensure only the single secret host name resolves in that hierarchy.
- Hypothetical Scenario 2
Above all else, I just want to keep as many of my host names as possible secret from the CT logs, etc, and I largely have a hierarchy of hostnames flatly sharing the PSL+1 level. (www.example.com, mail.example.com, internal-web.example.com) I am willing to accept the risk of managing multiple wildcard certificates which would overlap.
- It is still beneficial to have one certificate + key pair unique to each server. However, because LE limits the number of exact duplicate certificates in force at a given time, you can't just create CSR + request certificates for the exact combination of "*.example.com" and "example.com" on 10 different servers. However, there's a trick...
- For each server, choose a dnsName unique to include in the certificate that is inside a further domain hierarchy level, like "cert-tag".
- For example, let's say on server A, I'm going to choose "server-1.cert-tag.example.com". I would request a certificate for that server with the following SAN dnsNames: "*.example.com example.com server-1.cert-tag.example.com"
- Following that pattern, you can request certificates for all the servers (subject to overall rate limits) and have them all be wildcard certs for the example.com domain.
Note that the techniques I've described here require that you configure your infrastructure / domain name service such that you can use the dns-01 validation method.
In closing, I'd like to point out one further issue:
Even if LE could issue you a name constrained intermediate CA certificate and even if you didn't have to abide by audit and secure storage and management processes for said intermediate certificate, you would pragmatically have to still publish the certificates (and the hostnames within) to the CT logs. If you did not, the newer browser versions which require SCTs on certificates which are issued descendant to a publicly trusted root would reject those certificates.
Matt
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.