20

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

Improve this question
2
  • 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, 2013 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, 2013 at 0:03

2 Answers 2

Reset to default
8

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.

Improve this answer
7
  • 6
    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, 2013 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, 2013 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, 2013 at 23:32
  • 3
    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, 2013 at 23:44
  • 6
    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, 2013 at 0:06
9

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.

Improve this answer
1
  • 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, 2018 at 0:35

You must log in to answer this question.

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