views:

1067

answers:

3

Hello everyone,

I am doing self-signing certificate in my test environment. Here is more details about what I am doing.

http://www.hanselman.com/blog/SigningPowerShellScripts.aspx

My brief steps are (the purpose is to establish trust connection between computer C and computer A based on certificate),

  1. Making computer A a root CA by using makecert.exe;
  2. Self sign a certificate B which is issued by computer A as root CA;
  3. Install certificate B on computer A as certificate used to do communication;
  4. Install/trust root CA (compter A) into computer C;
  5. Then computer C will trust computer A's communication using certificate B.

My confusion is, computer C trusts computer A without installing certificate B? I think both root CA's certificate and the other party's certificate are needed to be installed. Any comments or ideas?

thanks in advance, George

+1  A: 

Computer C must trust the root CA (on Computer A). Then, any certificates presented from another computer (say, Computer D) issued by the same root CA will be automatically trusted.

For instance, in Windows, you (by default) already have and trust the root CA certificate for Verisign. When you navigate to an HTTPS site that uses a Verisign certificate, you will automatically trust it - since you trust Verisign, and Verisign issued the cert to the HTTPS site.

IOW - you only need to trust the CA and install it's cert.

Mark Brackett
Thanks Mark, install root CA's certificate is fine, no need to install the certificate of publisher or person, which is issued by the root CA?
George2
Correct. By installing the root CA's certificate on a machine, you are instructing that machine to trust *anything issued by that CA*.
Mark Brackett
+1  A: 

You have step 2 incorrect, semantically at least. If you are generating a certificate signed by a CA then it is not self signed at all, it's signed by the CA.

So on machine C you only need to put your generated CA certificate in the trusted CA store. By doing this you are saying you trust anything it has signed, in your case certificate B.

However you say you're using this for communication - be aware that if you use something like WCF which will check for revocation you will need to turn this off as your generated CA won't support this.

blowdart
Thanks blowdart, "You have step 2 incorrect, semantically at least. If you are generating a certificate signed by a CA then it is not self signed at all, it's signed by the CA." -- it is my bad, I mean signed by the self-established CA. :-)
George2
Thanks blowdart, in your solution, I want to confirm whether you mean I just need to install certificate of B into machine C's trusted publisher? If yes, I disagree since certificate B is issued by root CA computer A, which is not trusted by computer B by default.
George2
(continued) so, I think I have to install the whole chain of trust -- install root CA's certificate (in my sample, machine A's root CA certificate) into machine B's trusted root certificate authorities. Any comments?
George2
No, you don't. Installing your own CA, certificate A will be enough to build the chain trust.
blowdart
You mean install root CA's certificate is fine? No need to install the publisher's certificate itself?
George2
The root CA should be fine to trust the signing chain. Now after that Powershell may need to have the signing certificate trusted as well, but that's outside of my experience.
blowdart
+1  A: 

Computer A doesn't actually become a "root CA". You need to create a root certificate, and then install it on the target computer.

It's not quite as simple as installing the root certificate on the target computer as different applications may use different certificate stores. For example, you need to install root certificates into both Firefox and Explorer.

You can then create "child" certificates - signed by the root certificate - and the target system will accept the child certificate as valid, because it has been signed by the trusted root certificate.

A certificate is just a way of validating someone's public key. The certificate contains both your public key in plain text, and your public key encrypted by the private key of the signer. To validate the public key published in the certificate, you decrypt the encrypted version of the public key - using the public key of the signer - and check that it's the same as the plain text version of the public key.

In a self-signed certificate, you encrypt your public key with your private key. So a self signed certificate is also a root certificate because there is no higher signing authority in the chain.

Intermediate certificates can also be used to sign other certificates. In this way certificates can be used to build a "chain of trust" back to some (at least theoretically) trusted root certificate.

Bruce Schneier has a reasonable description of this in his book "Applied Cryptography". And Peter Gutman has a more colourful description of certificates at this linky:

http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

billmcc
Thanks billmcc, I am interested in the certificate store issue you mentioned. As far as I know Windows manages certificate by top 2 categories -- currentuser or localmachine, and under the 2 categories, there are sub named stores. Is that correct? If yes, any tools to see all local named stores?
George2
"and then install it on the target computer." -- target computer you mean in my sample, computer A or computer C?
George2
In your example, the target computer is computer C.
billmcc
In terms of certificate stores, I was thinking specifically that FireFox doesn't use the Windows certificate store, and other apps - especially cross platform - may do the same thing.
billmcc
certmgr.exe comes with Visual Studio. This lets you access the certificates in the Windows store.
billmcc