34

(Posted to ServerFault instead of StackOverflow because I feel it concerns OS configuration more than programming code).

I'm currently responsible for maintaining a system which connects to a third-party webservice. This webservice requires client authentication certificates, which is fair enough, but the webservice itself is secured with a self-signed certificate created by a self-created root certification authority certificate - the same root that creates the client auth certificates.

It would be enough to merely add the current service certificate to the known-trusted list and to ignore the self-created authority certificate, unfortunately the service certificate changes regularly so the authority certificate must be trusted to ensure the application doesn't break when the service cert is renewed.

However I don't (personally) trust the CA cert based on my experience with the company running the webservice - it would not surprise me if it would be leaked to the web - and worryingly the CA cert has no key-usage restrictions placed on it (while external MITM attacks are a possibility, though remote, I'm more concerned about a leaked certificate used for code-signing, for example).

Is it possible for me to tell my computer (currently a server box, but in future ordinary desktop client boxes) to trust a CA but only for a given set of key-usages and a small set of possible subject-names (domain-names)?

The server is currently Windows Server 2012 R2, but it could be running on a Linux box - though the desktop machines are all Windows boxes.

4
  • 3
    At least on Linux, many applications have an option to specify the location of peer CA certificates, so you can limit the scope of this CA to only the application using it. @CryptoGuy 's answer would work on Linux as well, there's nothing windows-specific in it.
    – Edheldil
    May 5, 2016 at 9:24
  • 1
    @Edheldil: It's implementation-specific though – e.g. Windows has supported X.509 name constraints for much longer than e.g. NSS or GnuTLS. May 5, 2016 at 9:54
  • Your system connects to this third-party service; can the client code on your system be configured to trust that service's CA, in such a way that it is done just for that client code, not for your entire system?
    – Castaglia
    May 5, 2016 at 22:21
  • @Castaglia I can write my own certificate verification code that works independently of the host system, but there are other pieces of client software that I don't have control over which do use systemwide certificate services.
    – Dai
    May 6, 2016 at 1:40

1 Answer 1

43

Yes, it is possible. In the case of Windows, there is a feature called Cross-Certification or Qualified Subordination.

The idea is that you sign third party's issuing CA certificate in your environment. As the result remote SSL certificate is chained to your own root CA certificate. In order to protect yourself from possible rogue certificates, you implement a Name Constraints certificate extension where you specify a list of acceptable names. If third party CA issue certificate for any other name (not explicitly specified in the Name Constraints extension), it will be automatically rejected by your CryptoAPI provider.

In addition to name constraints, you can describe Enhanced Key Usages constraint by defining the Application Policies certificate extension in the cross-certificate. So, your trust provider will successfully validate only usages specified in the Application Policies extension.

More information: Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003

p.s. although, the article is written against Windows Server 2003, the article still applies to the most recent Windows Server version.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .