Can we host our own sub-CA for our domain from the LE Chain?


#1

Our internal domain is a public suffix, example.com. We have application servers that can only use their own CSR (no access to the OS) and these add entries to the SAN that Let’s Encrypt finds invalid (hostname with no domain suffix for instance). So domain-validated, manually created certificates cant be made.

We are happy to install our own CA for our domain and issue certificates for these edge cases but it would perfect to have our internal CA become a sub-CA and so the certificate chain is publically trusted. Or am I misunderstanding something and wishing for the impossible?

we have certbots working flawlessly for IIS websites and want to use it more for other things (VPN connections, telephony etc) but are frustrated by the application vendors implementation of raising CSRs.


#2

Hi @Gibbo_GT40

this is impossible. Letsencrypt creates public trusted certificates. But this requires, that Letsencrypt can check your ownership of these domains.

But: If your internal domain has a public visible domain name: Isn’t it possible to use the complete fully qualified domain names as internal names?

And to use dns-validation?


#3

Hi,

Currently, i don’t think Let’s Encrypt have any plan to allow other operate a subCA under their root certificate. (As this have been asked in previous threads)

Pinging @josh for more information.

Thank you


#4

Let’s Encrypt’s delegation from the DST root has a path length constraint which would prevent Let’s Encrypt from designating any other sub-CAs (at least using that path). Currently, Let’s Encrypt does not offer this kind of service at all; Let’s Encrypt is only meant for issuing publicly-trusted certificates, which are subject to industry rules that require that they be FQDNs controlled by the subscriber who receives the certificate.

Creating sub-CAs would be very costly for Let’s Encrypt because of audit requirements and human intervention. The reason that Let’s Encrypt certificates are free of charge is that the entire DV issuance process can be automated, so there’s no marginal cost in human labor for issuing a new end-entity cert. But this woudn’t be true for a hypothetical sub-CA delegation, which would involve human beings reviewing policy documents and contracts—expensive activities.

Normally, in order to operate an internal CA you’d have to add trust for your internal CA to all of the devices that are going to accept its certs.


#5

If the Internet can resolve any of those FQDNs to actual Internet routable IPs, then you may get a cert for it.

Every CA on the planet follows the same rules - like: You need an FQDN that can be resolved via global DNS.

(as described) The “domain” is improper and can NOT be validated.
Manually created certificates (that follow standard practice) are made every day.


#6

Is your organisation a publicly trusted Certificate Authority? No? Then what you want is impossible. Sub-CAs should obviously also be trusted. Otherwise, the “origin CA” would loose their trust if they’d enable non-trusted sub-CAs.


#7

If there was a way to restrict sub-CAs to only issue certs for the domain they own/control…
But that is not the case.
A sub-CA would be able to issue valid certs for any and every domain out there.


#8

If the locked down application method of creating the CSR didn’t include unqualified host names in the SAN yes.


#9

Thats the bit in my knowledge i was missing and makes perfect sense and why i could find a way to do what I wanted to do.


#10

The name constraint extension exists, though clients don’t necessarily implement it.

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

The old Let’s Encrypt X1 and X2 intermediates used a name constraint to block .mil for contractual reasons. (Which is why Windows XP rejected them, IIRC.)

https://crt.sh/?id=10235198


#11

Great explanation, thinks for your time.

I shall continue with plan A of using LE for externally facing resources and internal for internal only and distribute the trust of our CA around the internal servers with GPO etc


#12

You can also proxy those systems and secure the connections.
Via full FQDNs to the proxy.
And then only the proxy would have to trust the individual SHORTNAMEs.
Could save some time - depending on how large the many-to-many area is.
Breaking it in two; A many-to-one and a one-to many.


#13

Does your internal domain (example.com) actually work externally? For example - your main public website is on www.example.com, but all your internal systems are on internal1.example.com, internal2.example.com, etc (and only accessible from the internal DNS server).

If that 's the case, just register a wildcard cert on the main domain & use that on all the internal systems.