I am developing an html application where an user has to first login using his digital certificate. After login he has to perform encryption and decryption of data using his digital certificate.
Now in case when the certificate is available in the form of .pfx file then we can just install it and the certificate appears in the container and we can use it during login and during encryption and decryption.
This works fine in case if we have .pfx for our digital certificate.
But now i want to enhance it for etoken's(security token). I dont know much about etoken's. The problem is that how can i use the digital certificate stored in it while login?
Also how should i use the private key stored in it while decryption?
Can anyone please tell me about any tutorials (if any) which will explain the usage of etoken and the CryptoAPI's.
As I mentioned in the answer to your previous question, Windows CSPs map the certificate from hardware to Windows certificate storage, so this is transparent to you. If you can access the certificate via Windows certificate storage API, then you don't need to care where the certificate is actually located.
Note that you can't transfer a private key to the server, i.e. you would have to use a client-side module (either ActiveX or Java applet) that will perform operations locally. This is not specific to certificates on hardware, but also to certificates which have non-exportable private keys.
Related
Need to authenticate a server using certificate, I have used OpenSSL to generate certificate and it was able to authenticate with certificate by enabling client certificate authentication in IIS.
Now when I export the certificate from the device and tried to install it in the other device it was able to authenticate the server, is there any possible way to link or generate a certificate that will only work for the specific machine?
Yes - keep the private key private.
Moving a certificate by itself to another client won't let you authenticate as the owner of that certificate. You would have to move both the certificate and its corresponding private key.
There are generally two ways you can stop the private key being copied:
Use administrative controls to ensure nobody in your organisation copies the keys. This is usually in the form of an agreement between the certificate issuer and the entity named in the certificate, to the effect that "you shall not copy the private key!!". As you can imagine, depending on the scenario, this might not be that enforceable.
If the certificate is certifying a device, generate and store the private key in a hardware device that is a permanent fixture in that client device. A Trusted Platform Module is an example of a device fitted in most modern end-user devices for this purpose.
If the certificate is certifying a person, generate and store the private key in a hardware device that is issued to that person. A smart-card is an example of such a device. You would probably also need administrative controls here to ensure that the user doesn't share their card with others and that they keep any PINs or other authentication data private.
Note that attempting to certify something like the DNS name of the client device as as unique identifier doesn't work, as DNS, MAC addresses etc. can be spoofed.
We are generating document PDF's as part of our server application workflow. We need to be able to sign these documents to prove they are from us and have not been tampered with. We currently do this using a self-signed cert and using syncfusion's PDF module (excellent sw btw!). The problem is (of course) that the self-signed cert is not in the CA trust chain so although the document is secured, it doesnt automatically validate that its from us.
I have been researching where to purchase AATL certified certificates from and have found several vendors (Identrust being one of the more affordable options). However, they all share the same delivery method which is they ship it to you on a secure USB or similar token. What I dont understand then is how to use this token with our hosted VM. Does anyone have any experience in using these types of token ie. are we simply able to export the private key from the token onto the server?
Thanks
You cannot use the tokens in this scenario.
The certificate issuer should provide you with a web-based API that you integrate in your signing process. Usually you send the document hash and get back the signature, but the actual flow and ins/outs depends on the certificate provider.
Then the PDF library you use should let you embed in the PDF file the externally computed signature.
I have my own webpage www.kasperikoski.fi that is, the way I see it, trusted, and I would like to have the ability to digitally sign PDF-documents by using some kind of sertificate that is put into my webpage so that people really know that it is me signing all these documents.
At first I thought that maybe I could share "public key" at the bottom of my webpage, but then I heard something about OpenSSL. Could that be used in my needs?
How would you carry out this one so that I could use the PDF's integrated "sign digitally"-option?
Assuming that I read your question right, you want to let your web site visitors a way to download some documents, which are created or maintained by your web site, and you want those documents to be digitally signed.
If the document is pre-created, it's possible to sign it during creation (either with the tool that generates them, or create a separate piece of code for signing). If the documents are generated on-the-fly, then your web site should include signing capabilities.
To perform signing you need a certificate with a private key. But not every certificate would work. The certificate you need should be suitable for data signing, rather than just for SSL/TLS. You can try to obtain the certificate for your site from some CA and then use it for signing the documents. Whether the users' software would accept such certificates depends on how Key Usage and Extended Key Usage properties (extensions) of the certificate are put by the CA. Another option would be to create a self-signed certificate.
In case of a self-signed certificate you would want to place the certificate itself (without a private key) to your web site for the users to download and install. This is needed for validation of the signature in your signed documents. No need to say, that you don't put the private key to download, neither you provide it to your users by any other means. It's kept only on the server (and preferably secured to make stealing it harder for the possible attacker).
The technologies / components / tools to use in these scenarios depend on which of the above options you need.
My use case is very simple : I have a GUI application, and inside this application I host a service however clients of this services must be able to authenticate with UserName safely (The only thing I want is to encrypt messages to be sure that nobody can sniff to retrieve password of clients, I don't care about more security).
So, I want to ship a certificate with my GUI application and that my host (which is inside the GUI application... I know it's a little dirty) use the certificate to encrypt messages.
So my question is : Does my requirements oblige me to install the certificate inside the store on the host machine ?
Am I obliged to generate a new certificate with makecert for every host ?
What is the easiest way to deploy my application ?
(I control the client application so the validation of the certificate is not a problem)
First of all you should not use makecert to generate production certificates.
You could store the certificate in code and not in the machine but keep in mind that the security of the whole encryption is as good as the security of the certificate's private key. If the machine where the application will be run is secure you could use the certificate "incode" but if you cannot guarantee the security of the host machie you should install the certificate in Windows Store. Make sure the user running the application has permissions to read the certificate's private key.
If using WSE or WCF make sure you test the default message or transport encryption methods provided to see if they are good enough for your use.
Here is some references for installing certificate with private key (.pfx file) programmaticly.
We want to add automatic software updates to our application, but our company isn't yet ready to buy a code-signing certificate from a trusted root CA, so we'll be using a self-signed certificate to sign code updates (.exe and .dll) for now.
Question: how to verify a binary signed with a self-signed certificate, without having to install the certificate, using Microsoft's Cryptography API? The .cer file to check against will be bundled with the application. Or is it simpler to use a generic Crypto library?
You can skip the whole X509 thing, after all you don't really need it if you're going to be using your own certificates...
For what you want to do, first you have to generate your RSA private/public key pair. Then you store the public key in your application.
When you have an update, you sign it on your site, by getting the MD5 or SHA-1 or whatever hash you want to use; then you encrypt that hash with the private key. The installed applications fetch the update and the signature (the encrypted hash); when the application gets the binary file, it computes its hash, then decrypts the other one using the public key and compares them. If they're identical then it's a valid update, otherwise you reject it and warn the user or something.
With X509 certificates that are self-signed the mechanism is going to be exactly that, but the public key is going to have a bunch of additional data like the identity of the issuer which will be the same identity of the certificate.
I seem to recall hearing of a way to enable self-signed certs some years ago, back in the Win2k days, but it was very hacky, not at all suitable for public deployment and has probably been "fixed". If you do think about using some other crypto library, or developing your own, take care: it's very hard to distinguish good crypto from bad crypto.