3

Let's say that I have signed my public key with a trusted CA and the CA provided my with a signed certificate, and I want any client applications to verify against this certificate. The general process is that the client verifies against the CA's public key, and not my own, so I do not even need to transmit the public key, but what is the best practice to implement this in a C# client application?

My current chosen approach is that on the server application, I am storing the certificate (which contains my private key) in my local store, which I use to sign data. Then, on the client application, I am loading the Root store of the Current User and I pass the certificate name of the CA which signed my certificate, and if this CA is found in the store, I retrieve its public key and I verify against that. If my public key has been signed by the CA, then verification should succeed, otherwise it will fail. Is this the correct way of implementing it? If not, please provide better solutions.

The following are my questions regarding my chosen approach:

  1. Can the Certificate Name of the CA change? If so, I would have to change it in code. If this can change, what else should I use to search for the certificate? Maybe the SerialNumber?.

  2. Can someone create the same Certificate Name. I am assuming that you can. For instance, a hacker might create a certificate name which is the same as an established CA, but it is obviously up the user to add it to the trusted store on his machine. If he does not, then the hacker does not have any power whatsoever. Also, I do not think that two certificates can have the same Serial Number.

  3. If my private key is hijacked and I revoke the certificate, verification should start failing on the client's applications. It will start verifying successfully once I start signing the messages with the newly issued certificate by the CA. Is this correct?

Finally, I do not currently possess a signed certificate so I cannot test this out. That is why I am asking these questions, so that if this approach is correct, I can proceed to buy a certificate since I know the way forward. Also, hopefully, this question might help other people with the same problem.

Thanks in advance.

  • Can someone confirm whether this is the correct approach? and what is the correct approach if this one is not? – seedg Oct 21 '15 at 7:56
1

Let's say that I have signed my public key with a trusted CA and the CA provided my with a signed certificate, and I want any client applications to verify against this certificate. The general process is that the client verifies against the CA's public key, and not my own, so I do not even need to transmit the public key, but what is the best practice to implement this in a C# client application?

You DO need your public key (contained in the certificate) on clients to validate the signature you have done with your private key. You use the CA certificate to validate your certificate signature (a certificate is a public key + some info about the owner (subject) of the certificate).

You may send your certificate on every request or have it cached on the client, that is language independendt.

My current chosen approach is that on the server application, I am storing the certificate (which contains my private key) in my local store, which I use to sign data. Then, on the client application, I am loading the Root store of the Current User and I pass the certificate name of the CA which signed my certificate, and if this CA is found in the store, I retrieve its public key and I verify against that. If my public key has been signed by the CA, then verification should succeed, otherwise it will fail. Is this the correct way of implementing it? If not, please provide better solutions.

It is not the correct way. You should have your certificate on the client. Verify the certificate using the CAs certificate and then use your certificate (that contains a public key) to verify the signature.

The following are my questions regarding my chosen approach:

All of those wont happen if you correctly validate your certificate against the CA certificate. I would recommend not to reinvent the wheel here, and use some standard Certification Path from a good library, since it is complex to get it all right. I´l explain above how each thing is solved in a Certificate Path validation:

Can the Certificate Name of the CA change? If so, I would have to change it in code. If this can change, what else should I use to search for the certificate? Maybe the SerialNumber?.

Your certificate has fields that identify correctly and exactly the issuer of it, using many fileds from the certificate that should not colide. If they colide, still, the signature of your certificate needs to match.

Can someone create the same Certificate Name. I am assuming that you can. For instance, a hacker might create a certificate name which is the same as an established CA, but it is obviously up the user to add it to the trusted store on his machine. If he does not, then the hacker does not have any power whatsoever. Also, I do not think that two certificates can have the same Serial Number.

That will be soved by the signature of the CA on your certificate, that you will verify before using it.

If my private key is hijacked and I revoke the certificate, verification should start failing on the client's applications. It will start verifying successfully once I start signing the messages with the newly issued certificate by the CA. Is this correct?

That will be solved by revocation checking, that you should enable on the certification path verification. When theprivate key is hijacked, you need to ask the CA to revoke it, and it will be added on a CRL (certificate revocation list) that is checked on the the certification path verification.

Finally, I do not currently possess a signed certificate so I cannot test this out. That is why I am asking these questions, so that if this approach is correct, I can proceed to buy a certificate since I know the way forward. Also, hopefully, this question might help other people with the same problem.

You might create your own CA and do tests, using Microsofts CA, openssl or other tools. There are a lot of tutrials on that availble.

  • hi, i've got 2 questions about this - 1. usually in browsers, the certificate contains domain name to verify itself on. but here it's not the case - so, after the CA verification, should we use any data to validate the certificate? (i dont know, company name or something?) 2. about revocation - how is it defined? the public certificate is not installed in the client machine. how the revocation is published? – ArielB Apr 13 '16 at 14:55
  • @ArielB 1) Yes, if you need to check the identity, you may have any other data in the DN that can be used to check that. 2) The common way to do revocation is to publish LCRs and have a URI for the LCR on the certificate. – CristianTM Apr 15 '16 at 20:04

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.