11

I have a certificate issued from Let's Encrypt.

Can I create a key and certificate for my own purpose (i.e. an OpenVPN server, or web server with internal domain name/IP address) and sign it with the Let's Encrypt certificate?

Peter Mortensen
  • 895
  • 5
  • 10
Kamil K
  • 113
  • 1
  • 5
  • 1
    Dupe https://security.stackexchange.com/questions/20513/using-a-verified-certificate-to-sign-others https://security.stackexchange.com/questions/33649/man-in-the-middle-scenario-for-tls https://security.stackexchange.com/questions/65150/is-it-possible-to-use-one-commercial-ssl-certificate-to-issue-end-user-certs https://security.stackexchange.com/questions/103685/generating-own-ssl-certificate-using-dsc-issued-by-a-ca – dave_thompson_085 Aug 01 '18 at 20:33

1 Answers1

18

Usually no, only certificates marked as being a CA can issue certificates. (or, more accurately, you can do that, but no vpn client or web browser will trust it.)

To see if your certificate is a CA, open it and look at the Basic Constraints field; a CA will look like this

CA Basic Constraints

while an End Entity will look like this:

End Entity Basic Constraints

End Entities are not allowed to issue certs, and good luck getting Let's Encrypt to give you a CA cert...

Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
  • I suspected there is some kind of limitation like this. Thank you. – Kamil K Aug 01 '18 at 13:49
  • Yeah. Cynically, how would CAs make money if you only need to buy one cert and then can issue as many as you want? Less cynically, If you could issue certs off their Root CA like that, then they are legally responsible for any fraudulent certs you make, why would they let you do that? – Mike Ounsworth Aug 01 '18 at 13:51
  • 3
    In some cases you can purchase a signed subordinate CA certificate from public CA. This process is called "certification authority root signing": https://www.sysadmins.lv/blog-en/certification-authority-root-signing.aspx – Crypt32 Aug 01 '18 at 15:01
  • 3
    @Crypt32 Interesting, thanks! That Requirements section though: "Your PKI must use Hardware Security Modules", "your company will have to pass annual external audits" is basically forcing you to follow the same rules as any other publicly-trusted CA. – Mike Ounsworth Aug 01 '18 at 15:45
  • 3
    Yes, it is. The only difference is that you don't have to bother with your CA inclusion in various trust lists (Microsoft, Mozilla, etc.), because the trust is established via public CA provider that offers you qualified subordinate CA. – Crypt32 Aug 01 '18 at 15:58
  • Re "... open it and look ...": Presuming a particular platform? – Peter Mortensen Aug 01 '18 at 16:55
  • @PeterMortensen umm, I used Firefox. Openssl can pretty-print certs,, and I have yet to meet a platform that doesn't support openssl. – Mike Ounsworth Aug 01 '18 at 16:57
  • 1
    @MikeOunsworth Issuing a CA certificate constraint to a domain would make sense as an alternative to wildcard certificates. I think it's even part of the spec, but browsers don't support it. – CodesInChaos Aug 01 '18 at 18:48
  • @MikeOunsworth: A common (and increasingly required) alternative is to let the root CA itself host your sub-CA. Then you use the provided APIs (or a web panel like DigiCert's "CertCentral") to issue all certificates; which in the end is very similar to how Let's Encrypt works. – grawity Aug 01 '18 at 18:57
  • @CodesInChaos the main concern that comes to mind is domain restriction; what's to stop a domain/CA cert for mycorp.com from issuing themselves a cert for google.com? I have to imagine that any scheme where a company can issue themselves publicly-trusted certs would need some kind of public scrutiny / auditing mechanism. – Mike Ounsworth Aug 01 '18 at 19:34
  • @grawity See my answer to Codes. Letting DigiCert host your semi-private CA for you makes sense since they are already set up for WebTrust compliance and can enforce domain restrictions at their end. – Mike Ounsworth Aug 01 '18 at 19:35
  • 3
    @MikeOunsworth Just like there is a flag in the cert which determines if a cert can act as CA, you can also have fields limiting the domain. It's part of the x.509 spec - name constraints, but browsers don't support it. – CodesInChaos Aug 01 '18 at 19:52
  • 1
    @CodesInChaos NICE! I was not aware of that extension. ++ – Mike Ounsworth Aug 01 '18 at 19:56
  • @CodesInChaos perhaps its just the benefit of hindsight, but it seems like that use-case ("give someone the ability to sign anything they want, within a limited domain") should have made it into the base design. – mbrig Aug 01 '18 at 22:15
  • @mbrig It sounds like it did make it into the basic spec, but browsers chose not to implement it because .... then managing the root cert trust list becomes more of an auditing nightmare? .... then how would CAs make money? .... some other reason that favours one CA issuing wildcard certs vs each webmaster issuing their own certs? – Mike Ounsworth Aug 01 '18 at 22:21
  • 1
    @MikeOunsworth One possible reason: adds another certificate to the hierarchy (Root CA, Intermediate CA, Constrained CA, Server Certificate), versus (Root CA, Intermediate CA, Wildcard Cert), so more overhead. Or you can issue the constrained CA directly from the root CA, (like Google's CA), but root CAs are kept offline and access is separated, so you'd need to get people together and have a signing ceremony (slow and expensive). – user71659 Aug 01 '18 at 23:57
  • It's worth noting you can also specify which CAs should be supported for a domain via CAA dns entries https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization – Tyeth Dec 11 '19 at 15:31