38

My customer uses a self signed certificate for an application to work. To be able to work, I have to install the root certificate they used to sign the certificate.

Is it possible to configure a root certificate so it only validates towards one domain ?

MichaelD
  • 515
  • 5
  • 7
  • It might just be me, but I'm unclear what you are actually asking. What end state are you trying to accomplish? If you import their root certificate into the domain controllers trust, then just the systems under that domain would be able to validate against it... – Gravy Feb 23 '15 at 14:50
  • It sounds like you are confusing self-signed certificates with using a root CA that is not publicly trusted.An application configured to use a self-signed certificate is very bad, as the application would need to be configured to ignore certificate validation errors. Using a root CA that is not publicly trusted is actually quite common. – Greg Askew Feb 23 '15 at 15:41
  • do you have an internal CA server? – Crypt32 Feb 23 '15 at 15:43
  • 2
    A CA can restrict itself to certain domains with [name constraints](https://tools.ietf.org/html/rfc5280#section-4.2.1.10), but applying constraints retroactively to someone else's CA is a different matter. – Matt Nordhoff Feb 23 '15 at 16:18
  • 3
    there is no difference. You can apply name constraints to a 3rd party CA as well. You just sign 3rd party root CA certificate by using your private CA and publish generated cross-certificate. In this case, foreign chain will end up to your private chain through restricted cross-certificate. – Crypt32 Feb 23 '15 at 16:45

2 Answers2

29

As a rule of thumb:

No, implied in trusting the customer's CA certificate is the trust in every certificate signed by that CA.

I don't know of any applications/libraries that have an easy option that allows you as the end-user to select that you'll trust your customers or any other CA certificate only for certain (sub-) domains i.e. only for *.example.com and *.example.org and nothing else.

Mozilla has a similar concern about currently trusted government sponsored CA's as an open attention point and for instance Chrome has extra checks built in for accessing Google sites, which was how the rogue *.google.com certificate and the compromise of the Diginotar CA became public.

But even if you don't trust the CA, you can still import/trust a specific server certificate signed by that CA, which will prevent SSL warnings for the hostnames in that certificate. That should make your application work without errors or complaints.

Exceptions:

A very underused option of the X.509v3 PKI standard is the Name Constraints extension, which allows a CA certificate to contain white- and blacklists of domain name patterns it is authorized to issue certificates for.

You might be lucky and your customer has restrained themselves when they set up their PKI infrastructure and included that Name constraint in their CA certificate. Then you can import their CA certificate directly and know that it can only validate a limited range of domain names.

Community
  • 1
HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • you are incorrect. It is doable with internal CA server. – Crypt32 Feb 23 '15 at 15:43
  • 2
    @CryptoGuy: An internal CA can also issue certificates for external domains. Once you trust your internal CA there is no restriction such that only certificates for your own (Active Directory or DNS) domain `example.com` or `*.ad.example.com` are valid. Your internal CA can also issue certificates for `*.example.bank` allowing a nice man-in-the-middle attack and snooping your online banking credentials. – HBruijn Feb 23 '15 at 16:02
  • 1
    Well "everything" isn't perfectly accurate. There are things like certificate revocation lists. But that doesn't change the bottom line. – Ben Voigt Feb 23 '15 at 16:08
  • 1
    sorry, you are incorrect again. You can restrict 3rd party CA to trust certificates (from that CA) issued to a name list you wish. Regarding your own internal CA, I assume the trust undoubt. If you don't trust your own CA, then something is wrong with your IT. I want to say that by having a private CA, OP can establish a partial trust to a 3rd party CA (by limiting names they trust). – Crypt32 Feb 23 '15 at 16:10
  • @CryptoGuy: I think we have a bit of a misunderstanding based on the word domain, which I primarily associate with DNS and not a Microsoft Active Directory domain. Active Directory Certificate Services also brings a whole bunch of controls, policies and somewhat proprietary extensions not present in the plain X.509 PKI used primarily on the internet for TLS and SSL. – HBruijn Feb 23 '15 at 18:22
  • ADCS is fully compatible with Internet PKI, so I don't understand your complains about proprietary extensions. I have deployed many ADCS servers with various configurations and never experienced issues with "proprietary" extensions. – Crypt32 Feb 23 '15 at 18:39
  • 3
    To your edited post: even if 3rd party CA do not have Name Constraints extension, it is possible to apply them by using your own internal CA server via cross-certification. In this case, cert chain will be as follows: leaf SSL cert -> cross-certificate -> your CA certificate -> your internal root certificate. The trick is that you sign 3rd party CA by using your internal CA. And cross-certificate will have all required constraints. – Crypt32 Feb 23 '15 at 18:43
  • 2
    CryptoGuy says this is possible, but finding implementation details is challenging. How about an answer describing how this can be accomplished? And maybe a discussion of which platforms support nameConstraints. – jorfus Oct 19 '16 at 17:42
  • @CryptoGuy, Constraining an internal CA is exactly the right thing to do. I don't know why you'd argue otherwise. – jorfus Oct 19 '16 at 17:56
  • Unfortunately, Microsoft dropped their great whitepaper about cross-certification which was written by Brian Komar, so I can't provide the link. – Crypt32 Oct 19 '16 at 17:59
  • To be honest, I am on the application side, and I prefer HBruijn solution rather than having to tell all my users to install a CA or use openssl for that regard... as Crypt32 suggests. It makes no sense to me. However, it is true that in the OP question that might not be an option, and in that case davenpcj is the only way. – user1156544 Jun 30 '17 at 12:39
22

@CryptoGuy had a pretty good answer here, but I wanted to expand on it.

To paraphrase:

You can restrict 3rd party CA to trust certificates (from that CA) issued to a name list you wish. Even if 3rd party CA do not have Name Constraints extension, it is possible to apply them by using your own internal CA server via cross-certification. The trick is that you sign 3rd party CA by using your internal CA.

leaf SSL cert -> cross-certificate -> your CA certificate -> your internal root certificate.

And here's how you make that work (using OpenSSL command line CA)

Create a simple CA

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

You may skip creating an intermediate CA

Create an intermediate CA request, with Name Constraints.

openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg

With this in the ossl_domain_com.cfg file:

[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca

[ req_distinguished_name ]
CN=somedomain.com trust CA

[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com

Then, sign that Intermediate domain CA with your CA.

openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg

If you skipped creating the intermediate, use your root CA to sign

Now re-sign the original domain's CA under your authority, using their certificate. You can add the CA extensions here.

openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt

You may need to use openssl x509 -x509toreq to create a request, which you would sign exactly the same way as the intermediate above.

Now, add your root CA, intermediate CA, and the domain-cross-ca to your browser's trust database.

Community
  • 1
davenpcj
  • 611
  • 5
  • 7
  • 4
    MacOS does not support nameConstraints. Just FIY for anyone working on a name constrained internal CA. http://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x https://archive.is/6Clgb – jorfus Oct 19 '16 at 17:58
  • 1
    Q: what is the status of this solution? What systems does it work in nowadays (2018)? // I have wanted this every time I am forced to install yet another company self signed cert; and every time I think about the Hong Kong Post Office or Symantec. // I think that I might not care not everone implements the narrowing so described, so long as they do not accidentally implement a widening. – Krazy Glew Feb 23 '18 at 02:08
  • @KrazyGlew I have a batch file I use for this, and I still use it regularly. Occasionally I have to reissue the intermediate certs as they expire or rotate, so it's a little more manual, but it hasn't been a problem. I do occasionally run across authority-managed sites which my browser fails to trust due to use of a different intermediate Authority, or an extra domain name they've added, which mine doesn't trust. – davenpcj Jun 12 '18 at 15:45
  • 2
    I've just successfully used it, thanks. It works great without the intermediate certificate, is there any advantage to using one? Also, the `basicConstraints` line in the configuration file seems to cause the constraints extension to be included in the certificate twice, which causes Firefox to reject the certificate with a cryptic error message. I think it can safely be removed. – wrtlprnft Feb 11 '19 at 21:52
  • 1
    I get an error at last step: `error with certificate to be certified - should be self signed`. What does it mean and how to solve this? https://pastebin.ubuntu.com/p/QHhpQh2N6J/ – mymedia Sep 10 '19 at 14:30
  • @mymedia Apparently a limitation of OpenSSL. It uses `X509_V_FLAG_CHECK_SS_SIGNATURE` on the cert-to-be-signed, and outputs that error if not. You have to cross-sign the top-level issuer of the domain, or convert the cert to self-signed or req. – davenpcj Apr 29 '21 at 21:38
  • @jorfus as per a newer answer at that link, *older* macOS's don't support it, but newer do. – Nick T Aug 22 '22 at 14:44