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.
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.
I was recommended coSign for c# to sign and verify documents. I can't find anything helpful on the subject of using .cer and .pfx files to sign pdf files. I was assuming it would be as easy as loading a .cer file as a X509Certificate2, and then coSign could just import it.
Samples for coSign seem limited. I was able to get coSign to verify if a document had a signature already on it, but I have no idea if it can verify if that is the same one based on the digital certificate.
I've also used another library to sign documents with those type of certificate files. It is not able to verify digital signatures though.
With CoSign you can import externally-issued certificates and keys to your CoSign account. However, it is important to note that typically every CoSign account (whether CoSign on-premise or CoSign Cloud) by default already includes a key and a certificate that can be used for signing.
If you do want to use a different signature key and certificate issued on a PFX file, for example, you can follow the procedure below:
From a command-line run the utility C:\Program Files\ARX\ARX CryptoKit\utils\pkcs12util.exe
You will need to specify the PFX filename and PFX file password
Your CoSign account should now include the key and certificate from the PFX file and you can use CoSign SAPI for signing with it.
When you create a CoSign Trial or Cloud account the certificate is created on the CoSign Appliance for you. You cannot import your own certificate to the appliance, nor do you need to.
The API calls should be made to the CoSign appliance in order to function, at no time can signatures be made if the CoSign appliance is not being used (otherwise it wouldn't be so secure). You will notice that even with your CoSign user certificate that you cannot export a PFX or P12 file, because you can never export the private key from the appliance.
Regards,
Dave Strang
The Digital Signature Company
Phone: (866) 327-9754
Email: daves#arx.com
Website: www.arx.com
I'm using ITextSharp in order to read certificate informations from digitally signed pdf document.
The ITextSharp.Text.Pdf.PdfPKCS7 class exposes three properties:
Certificates (as list)
SignCertificate (as single object)
SignCertificateChain (as list)
How can I combine these three properties in order to achieve all info about a single certificate?
I'd be able to show all certificate path (all nested certificates).
Certificates gives you the list in no particular order, including certificates that weren't used for the main signature.
SignCertificate gives you the certificate of the actual signer.
SignCertificateChain gives you the list where the first Certificate is the SignCertificate, the next is the certificate of the instance that issued the SignCertificate, the next is the certificate of the instance that issued the previous certificate, and so on. This can return less certificates than Certificates, because only the certificates used for the main signature will be returned.
So you don't need to 'combine' the properties to show the certificate path, you just need SignCertificateChain. Note that your question isn't entirely clear:
'all info about a single certificate'
kind of contradicts with
'show all certificate path (all nested certificates)'
If you want to visualize the chain that resulted into the signing certificate, you need to look at more than a single certificate (unless the certificate was self-signed in which case there's only one element in the chain).
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'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).