I'm trying to figure out if there is any way to have a .NET client use a client certificate without involving the Windows keystore in any way.
I have a code snippet like this:
test1.Service s = new test1.Service();
X509Certificate c = X509Certificate.CreateFromCertFile(#"C:\test.pem");
s.ClientCertificates.Add(c);
int result = s.TestMethod();
However, this only works if I also have the certificate referenced in "test.pem" installed in my certificate store. I assume this is because the key is necessary for the negotiation. If I don't have the cert/key in the store, the cert is not sent with the request.
What I want to do is be able to provide both the certificate and private key from a file or files and not involve the Windows certificate store in any way.
Is there any way to do this?
I'm going to post an answer to my own post, but will leave it open to see if others can solve it different.
Basically, I'm punting. If you have a PKCS12 file (with both key and cert in it) you can use the X509Certificate2 class to load that file and use it, and it won't interrogate the keystore.
I could not find a way to do this with flat PEM key and cert files (like what you'd need with Python, for example).
Related
I am trying to connect to Bloomberg FIX (EMSX) through SSL using QuickFIX/n.
I have got 3 .pem files from Bloomberg using which I have to configure the SSL connectivity. I have gone through all the available reference material on the internet but in vain.
Can anybody help in doing this configuration??
Thanks in advance.
Have a look at using Stunnel and check out this question...
QuickFIX/n expects .pfx extension files. See http://quickfixn.org/tutorial/configuration.html#ssl
This extension is normally used for PKCS #12 encoded files which contain the certificate and the private key, protected by a password.
You may need to convert your .pem files so that you have one .pfx file which contains your private key and the certificate and another file which contains your CA Certificate. The SSLCertificate and SSLCACertificate configuration parameters of the QuickFIX/n session should then be set to the path of these two files. SSLCertificatePassword should contain the password.
QuickFIX/n is strict and requires the FIX Acceptor (Bloomberg EMSX in this case) to have the x509v3 extended key attribute "TLS Web Server Authentication" (1.3.6.1.5.5.7.3.1) to be explicitly present in the server certificate that is presented during the SSL handshake.
If not present, you will get an error message in the QuickFIX/n session event log:
Remote certificate is not intended for server authentication: It is
missing enhanced key usage 1.3.6.1.5.5.7.3.1
Some FIX Acceptors still don't define this in their server certificate, so even if you go to the effort of converting your PEM files to PFX, it still won't work.
You can use Stunnel which doesn't seem to mind what purpose was intended for the server certificate that is presented. As an added bonus Stunnel understands PEM files so no need to convert. However, you should be aware that if your end goal is end-to-end encryption, the hop between your QuickFIX/n application and Stunnel will be in clear text.
We have a requirement where we need to be able to encrypt/decrypt the query string as below:
http://oursite.com/login?uname=encryptedUName&fname=encryptedFname&lname=encryptedLname.
The way it works is that our company supplies the CSV of records to third party vendors. The third party vendors then generated the above url and sends to the customer by email marketing.
So, I'm thinking of
encrypting the records in CSV file
Third party vendors just parses the encrypted text and generates the email.
When user click on link the user comes to our site.
We then decrypt and prepopulate the form fields.
The file content may look like below:
*login?uname=encryptedUName&fname=encryptedFname&lname=encryptedLname.
login?uname=encryptedUName&fname=encryptedFname&lname=encryptedLname.*
Questions:
Should I use X509 certificate to encrypt and decrypt?
Or, should I use RSA?
How do I determine whether X509 or RSA?
Thanks.
A digital certificate works on top of a public & private key pair (asymmetric encryption). What a certificate adds is trust.You can sign a certificate using Certificate Authorities and create a trust chain.
In your case it doesn't seem as though you would need a certificate because you manage the encryption/decryption by yourself and your vendors know you and don't need a third party to verify you are who you say you are.
But, you may use a self-signed certificate as a key container if it's simpler for your vendors.
While working on this question, I identified that the problem is slightly different than initially stated, so I am changing title and description
I'm trying to authenticate myself against WebService using my client certificate. I am using WebRequest for that purpose. I need to use self-signed certificate, without registering it in Windows X509 trusted root store.
The way I know if client certificate is presented or not is by examining request object on the server
I tried to use code from this question as a guidance. It doesn't work on .NET. Here is my code:
var certificate = new X509Certificate2(Properties.Resources.MyCert);
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(host);
req.ClientCertificates.Add(certificate);
WebResponse resp = req.GetResponse();
var stream = resp.GetResponseStream();
What I observe is that even though req.ClientCertificates does contain certificate with a valid private key, that certificate is never presented to server. I get no indication from WebClient that certificate is not used during handshake.
If I put certificate into "trusted root", the code will work (even when certificate is not in "personal").
My questions are:
Since certificate is usable when it's placed in "trusted root", I assume it is likely due to policy or something of that kind. Is it possible to coerce .NET to ignore policy settings and use supplied client certificate during TLS negotiation?
If abovementioned coercion is not possible, is there a call which will tell me ahead of time, that certificate I am about to use is not usable, and will be ignored? Alternatively, if such call is not available, could I make WebClient fail indicating a certificate error, instead of silently skipping over?
NOTE: I am aware that configuring certificates as described by Microsoft will work. This is NOT what I am looking for. I don't want to register potentially insecure certificate in trusted root, because this is potentially security hazard. I want to use cert on client without registering in store, or at least to get an exception indicating that certificate cannot be used. I realize that there can be multiple reasons why certificate cannot be used for a session, but there must be an exception, or at least some sort of indication on the client side that it cannot use specified cert. Instead, client simply doesn't present one.
When you instantiate your X509Certificate2, is the PrivateKey property set? If it is null, you are missing the private key, meaning the SSL/TLS client will be unable to authenticate you.
Make sure you are loading the certificate from a PFX file (or similar) instead of a CER. These contain the private key, too. They are usually password protected for that purpose. See How to retrieve certificates from a pfx file with c#? for more info.
I'd like to use XMLDSIG for verifying that a .config file has not been tampered with. I also want to be able to verify the signature chain so that I can trust the signature.
I've got three certificates in the chain:
Root CA -> Intermediate Signing CA -> Signing Key
I check that the file is signed with a key that is issued by the intermediate CA.
I'd like to do this without installing any certificates in the user's Windows certificate store. These are self-signed certificates, so not every user is going to want me installing them in their Root store. I don't have a problem with installing them in my root store.
I have the original .CER files -- they're included in the Signature block, and I can include them with the verification code. I can build a certificate chain from this by using X509ChainPolicy.ExtraStore.
If the certificates are not installed in the root store, and I verify the chain, then X509Chain.Build returns false, and the chain has a X509ChainStatusFlags.UntrustedRoot in it.
Can I add trusted certificates just for the duration of this operation?
Assuming you have physical copies of the public keys of ALL signing certs in the trust chain, then this is possible by using the OpenSSL command line tool.
http://www.madboa.com/geek/openssl/#verify-standard
It's a bit of a steep learning curve at first, but a very powerful utility.
If you don't have the signing certs, then you cannot verify anything. That would be the same as trying to verify a human signature without having seen the original. You have nothing to compare to, so how could you verify the authenticity?
Update
There's something here perhaps that could help you:
http://social.msdn.microsoft.com/Forums/eu/clr/thread/1966a6e8-b6f4-44d1-9102-ec3a26426789
I have a .p12 file for my ASP.NET application to connect to a web service via HTTPS.
I am trying to import the .p12 file into the Local Machine/My store. The .p12 file contains more than one certificate. One contains the private key and the other is the CA certificate to complete the chain.
Currently I am using the `System.Security.Cryptography.X509Certificates.X509Certificate2 object's Import method to import this file into the store. Today I noticed that the CA certificate is not getting imported, only the main certificate containing the private key is getting imported using this method. After further review of MSDN I have found the following rule regarding the Import method:
Note that a PFX/PKCS12 certificate can contain more than one certificate. In that case, the first certificate associated with a private key is used or, if no private key is found, the first certificate is used.
Can anyone suggest to me another method for importing the .p12 file programmatically that will actually import all certificates in the file? I am using PowerShell to perform this function.
Instead of using the X509Certificate2.Import method, use the X509Certificate2Collection.Import method. It will give you all certificates from the .p12 file.
You can then add each certificate to its appropriate store.