13

Is it possible to get windows to trust a certificate, without getting it to trust the root CA as a trusted root CA?

say I have the following certificate chain,

Dept-Root-CA
Dept-Intermediate-1
Server-Certificate

I want to trust the Server-Certificate, but do not want to trust Dept-Root-CA because then it could sign any certificate and my servers would trust it. Just because I am willing to trust the certificate on Server-Certificate for a specific operation, doesn't mean I'm willing to trust that Dept-Root-CA has been properly secured.

thanks

  • What exactly are you wanting to trust it for? HTTPS? Or some other thing? There are ways of indicating that you want to accept a single certificate without accepting anything else from the root CA, but it depends on what you're doing. (You will still get errors if you try to validate the cert though) – Mark Henderson Mar 21 '13 at 23:42
  • Essentially yes. If it was custom code then it wouldn't be an issue - but this is using ADFS 2 and the only thing I can do in regards to how it treats certificates is change how the server trusts that certificate. There are other cases as well but this is just the current example. – bkr Mar 22 '13 at 0:03
5

No. As long as the certificate says "Issued by: xxx" then you must also trust xxx, all the way up the chain. If it is a self-signed certificate, you could put it in the Trusted Root CAs store, and since it is issued to and issued by the same entity, it should be trusted then.

But no it's not generally do-able or advisible to completely circumvent the entire purpose of certificate-based security.

  • 5
    I was afraid of that. I would not call it circumventing though. Just because I want a secure channel to talk to a machine in a different organizational group doesn't mean that I want to trust their CA. – bkr Mar 21 '13 at 22:57
  • Right... but the CA signed that cert, and without that CA cert the other end can just keep changing their certificate. – SpacemanSpiff Mar 21 '13 at 23:10
  • 6
    I'm not sure I understand what you're saying. I want to explicitly trust their certificate. If it was changed, I would want to have to explicitly trust it again. I basically want the model of certificate trust like there is in Firefox. In Firefox, if the cert is not valid under existing trusted CAs, you can choose to trust it anyway - if it changes, you will have to choose to trust the new certificate because it hasn't been explicitly trusted. – bkr Mar 21 '13 at 23:32
  • 2
    just keep changing their certificate If the remote end changed their cert, then it wouldn't match the one you saved. If you ignore all the CA business, aren't you just treating it like a SSH host keys. – Zoredache Mar 21 '13 at 23:44
  • 5
    realistically they'll only change it once every 2 years. the MS product I'm using requires the connection be secured via https. so it has to be trusted. because it's signed with their CA I would have to trust their CA - I don't want to do that because that would allow them to spoof any cert to my server, as opposed to allowing them limited interaction with a specific host name. – bkr Mar 22 '13 at 0:06
5

Well.... You could capture that trust information in another way.

It is, unfortunately, a bit complicated.

Create your own CA, then create your own cross-signing issuer for Dept-Intermediate-1 (or Dept-Root-CA) by signing their cert with your CA, possibly adding domain restrictions. If the "real" Dep-Intermediate-1 is deactivated (preferably) or unknown, windows will use your trust chain instead.

See my other answer here: Restrict a root certificate to a domain

This is how certificates are supposed to work, using digital signatures to represent an assertion of key ownership. Since you want to assert the cert and key belongs to the server, you sign it yourself, under your authority, and then tell the system to trust you.

There's still a lot of utility in a certificate without a CA hierarchy, above what SSH keys provide; part of that is the restrictions on them. Key usage, validity dates, revocation information, domain restrictions, etc.. The other part is the identifying information; server which owns the key, identity of the issuer, CA policies enforced, key storage information, etc.

  • This is interesting. I'll have to find some time to try work through this process and see if I can make it work. – bkr Jan 10 '18 at 0:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.