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.
Related
I want to encrypt a XML file by using a X.509 certificate and also decrypt it, too. As far as I know I need to use the public key (inside the certificate) to encrypt the XML and the private key to decrypt the XML. Thus only the guy with private key is able to read the decrypted data.
Microsoft provides some code for encryption/decryption here:
Encryption: https://msdn.microsoft.com/en-us/library/ms229744(v=vs.110).aspx
Decryption: https://msdn.microsoft.com/en-us/library/ms229943(v=vs.110).aspx
As you can see from the first example a X.509 certificate will be loaded to encrypt the file. But the second example does not(!) load a certificate to decrypt the example. It seems that the encrypted file holds all the necessary data to be decrypted? Does this mean that the file can be decrypted by anybody? I think I have a lag of understanding here - why is it not necessary to use a certificate to decrypt the data?
Regards,
Michael
On decryption, the certificate is loaded from the computers certificate store. From your second link:
The code example in this procedure decrypts an XML element using an X.509 certificate from the local certificate store of the current user account.
In that example, the public key used to encrypt the XML is stored in the encrypted data and is used to look up the proper certificate from the store.
So the answer to your question -- "why is not necessary to use a certificate to decrypt the data" -- is: it is necessary. The certificate was loaded automatically.
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 developing a library which generates XML data and signates the generated XML. I've installed a pkcs12 certificate (generated with OpenSSL from pem file) into the windows certificate store.
I'm loading the certificate from C# code with
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
X509Certificate2 cert = null;
foreach (var item in store.Certificates)
{
if (item.SubjectName.Name.Contains("CN=IDENTIFIER"))
{
cert = item;
break;
}
}
store.Close();
In my case the CN identifier is: my prename + surname. The cert comes from a third party. So I think I have no influence on the identifiers.
And here comes the question:
Is there any way to identify exactly this certificate from C#. In future it could be possible, that multiple certificates have the same X509 parameters (CN etc etc).
Thank you in advance.
Yes, it's possible that CN contains the same identifier (eg. when the certificate is issued for business entity).
Certificates are usually distinguished by one of following combinations:
1) Issuer name (not CN, but RDN, complete name record with multiple fields) + certificate serial number (it's unique within one CA)
2) Issuer name + certificate hash
If you don't know the issuer name before searching for the certificate, you can present the list of found certificates to the user and once he select one of certificates, store certificate hash for future reference.
On smaller systems (end-user's computer) the number of certificates in MY store is usually small and the chance of hash collision is minimal. On large systems the chance is higher and that's why Issuer name is used as well.
Expanding on Eugene's answer...
The Certificates property of X509Store is an X509CertificateCollection.
You'll probably be interested in its Find method and the X509FindType. It offers a number of ways to search for a certificate. Strictly speaking, both the subject DN and the subject alternative names should matter to identify the entity associated with a certificate. However, few tools do this from a presentation point of view (this could get quite cluttered in a table for example).
As GregS and Eugene pointed out, the certificate thumbprint (also known as fingerprint/hash in other tools) will identify a specific certificate uniquely, irrespectively of its issuer. It can be used with X509FindType.
Thumbprints are used in multiple places in the Windows/.Net/SSL world. In particular, it's the way to pick a given certificate to install on an HTTPS port.
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).