I am importing X509 from PKCS #12 file (using PFXImportCertStore Cryptographic API) in Computer's Personal Store.
Problem:
Any process running under "Local Service" account or any non-admin account can not access privates key (restricted to Admin user by Windows).
How to give access to private keys of a certificate to non-admin users and local service?
Note:
Since multiple process use certificates, I preferred using Computers store instead user's store.
This is a tricky one with some pitfalls. I had the same problem and was close to despair, when I finally found the remark which saved me in this post
I succeeded to do this for a local service running under the Network Service account.
First, there is the option to grant other users access to the private key of a certificate in the MS certificate store. Already this I'd classify as druid knowledge: this option is available in the context menu (right click the certificate), but only if the certificate resides in the localMachine\Personal store. There, in the entry All tasks, you will find the sub entry Manage Private Keys. This is not available in other stores, not even in the CurrentUser\Personal store.
This entry opens a dialog which allows you to add access rights to the certificate for other users. Here, the next hurdle waits for you: the default setting is to search for users in the domain, not on the local machine. The desired user may not be found, unless you change the search filter.
To this result I came very fast by googling, but it did not help. I could get the service to run, but only if I changed the service user to the logon account, which is not what I wanted (this leads, btw, to a workaround: create a local user account for services and import the certificate from within that user account. You can then place the certificate in almost any store and it will work fine)
This is where the post cited above comes in, the last hurdle for me: the procedure described above seems to work only if you import the certificate into the certificate store from within the MMC snapin. Select the store localMachine\Personal and use the context menu to import the certificate in question. (I chose to make the private key exportable, this may or may not be relevant here). If you import the certificate by double clicking on it in the file system, it will be imported into some store in the Current User location. I used to do this and then move it into the localMachine\Personal folder and changed the access right -- this did never work for me. Only after importing it from within localMachine\Personal in the MMC certificate snap-in it worked immediately...
(Also note that you have to place the certificate into a store which can be found by the service user. Your current user stores usually does not allow this, so localMachine is the better choice, anyway)
I don't know whether you can move the certificate around afterwards, but that's easy to check in the system..
When I import a public/private pair into windows certificate store, Windows does not require any password of any kind to encrypt the keys.
From that I conclude that if it is a user's store, it uses the user's password (or probably the user's hashed password) to encrypt the private key, and, if it is the local machine store, it is probably some kind of hardware-based key to encrypt the private key.
Did I get it right???
And if I did, what is the point of non-exportable keys if I can decrypt the keys???
And last question - If I got it right up to here, what are the alternatives?
As "SLanks" link explains, the private keys are encrypted with the user's password or the machines's password (depends on the location of the keys in the store).
Therefore, anyone who can log to the machine can obtain to this user's keys and anyone who has access to the machine can obtain keys stored for the local machine.
I have a certificate that has to be imported into Certificates/Trusted Root Certification Authorities and has a corresponding private key.
To actually access the key from code you need to set private key permissions to grant full access to particular IIS application pool. I totally understand that but the problem is that this can only be set on personal certificates and not trusted root ones.
I've tried adding the same certificate to Personal store and the following code doesn't break:
X509Store store = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly);
foreach (X509Certificate2 cert in store.Certificates)
{
if (cert.HasPrivateKey)
{
// access private key here
}
}
store.Close();
Setting permissions on certificate in personal store works if I change StoreName.Root to StoreName.My. I'm able to access it there. But I'm not able to access it in root. It just says:
Keyset does not exist
Any suggestions?
Additional information
If I set my application pools identity to Local System (which has total permissions over my machine) I can successfully access private key. So the main question is how do I set permissions on my application pool identity to have access to private keys for certificates in the Trusted Root store.
Why trusted root store and not personal?
I have a pre-built assembly that accesses this certificate in this particular store, so simply placing the certificate in Personal store won't do the trick for me. That's why setting trust permissions on private keys of trusted root certificates is imperative.
I haven't tried this with the Trusted Root Certification Authorities but what I have found is the simplest thing to do with other Certificate Stores is to drag and drop the certificate into the Personal Store and then set permissions and then drag and drop back to the original certificate store. In your case the Trusted Root Certification Authorities.
Steps using Certificates MMC:
Import certificate to the store you want it and mark keys as exportable. (You might be able to bypass this and import directly to the Personal Store, but I haven't tried.)
Drag and drop the imported cert to the Personal Store.
Right click the certificate in the Personal Store and in the context menu, click "All Tasks", then in the submenu click on "Manage Private Keys". Set the appropriate permissions according to your app pool as referenced in step 1.
After permissions have been set, drag and drop the certificate back to the original store (in your case the Trusted Root Certification Authorities).
Solution
It is possible to set trust permissions on certificates other than those in Personal certificate store, but you can't set permissions via MMC. At least not directly on the store that is. Accepted answer shows a simplified approach with moving certificates around to achieve the same result.
You have to do it this way...
Getting the tool
Get WF_WCF_Samples file from Microsoft. This is a self extracting archive, but you won't need to extract everything. So...
Open the file with any archiver tool and only extract FindPrivateKey solution/project
Open in Visual Studio and compile it.
Finding your private key
Open MMC and add Certificates snap-in. Make sure you select Computer and Local Machine when adding it.
Select the store that has your certificate with private key.
Open private key and copy its Thumbprint
Open command prompt and navigate to the folder where you compiled your FindPrivateKey tool
Enter this command
FindPrivateKey YourStoreName LocalMachine -t "ThumbprintWithSpaces" -a
ie.
FindPrivateKey Root LocalMachine -t "83 45 22 ..." -a
Copy file along with path (it will liekly span over two lines so copy to Notepad and concatenate)
Grant certificate trust
open command prompt and enter:
icacls "FullPathOfYourPrivateKey" /grant:r "UserFQDN":f
ie.
icacls "c:\ProgramData..." /grant:r "IIS AppPool\ASP.NET v4.0":f
Done.
This will grant certificate private key full trust to your user (in my case above it's application pool identity) so you can use the key to sign data or do whatever you need to do with it.
In case you don't want full permissions, you can easily change the last part after colon. It can have many different settings, so I urge you to check icacls command help.
If you are using Windows Server 2003, you'll notice that you don't get the Manage Private Keys task under your certificate.
If you install Microsoft WSE 2.0 on to your machine, you can use a tool called X509 Certificate Tool. Just search for your cert, its more than likely in (or should be) in Local Machine / Personal Store.
NOTE: if you have your cert in Current User / Personal Store (which often is the default), it will only be accessible to the user that is currently logged in, which means if you want your webserver to access it, it can't without changing permissions to your AppPool.
You should be able to change the permissions to the private key very easily, by default, your AppPool on your webserver will be using NETWORK SERVICE to run your web application. So just add NETWORK SERVICE to the security and by default it will set the Read and Read / Execute permissions which is sufficient for your BouncyCastle, etc, to read the private key so you can sign your document.
Hope this helps.
What is the series of steps needed to securely verify a ssl certificate? My (very limited) understanding is that when you visit an https site, the server sends a certificate to the client (the browser) and the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity.
How exactly is this done?
What about the process makes it immune to man-in-the-middle attacks?
What prevents some random person from setting up their own verification service to use in man-in-the-middle attacks, so everything "looks" secure?
Here is a very simplified explanation:
Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.
Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority.
The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.
Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.
Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.
You said that
the browser gets the certificate's issuer information from that
certificate, then uses that to contact the issuerer, and somehow
compares certificates for validity.
The client doesn't have to check with the issuer because two things :
all browsers have a pre-installed list of all major CAs public keys
the certificate is signed, and that signature itself is enough proof that the certificate is valid because the client can make sure, on his own, and without contacting the issuer's server, that that certificate is authentic. That's the beauty of asymmetric encryption.
Notice that 2. can't be done without 1.
This is better explained in this big diagram I made some time ago
(skip to "what's a signature ?" at the bottom)
It's worth noting that in addition to purchasing a certificate (as mentioned above), you can also create your own for free; this is referred to as a "self-signed certificate". The difference between a self-signed certificate and one that's purchased is simple: the purchased one has been signed by a Certificate Authority that your browser already knows about. In other words, your browser can easily validate the authenticity of a purchased certificate.
Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.
If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).
I KNOW THE BELOW IS LONG, BUT IT IS DETAILED, YET SIMPLIFIED ENOUGH. READ CAREFULLY AND I GUARANTEE YOU'LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED.
First of all, anyone can create 2 keys. One to encrypt data, and another to decrypt data. The former can be a private key, and the latter a public key, AND VICERZA.
Second of all, in simplest terms, a Certificate Authority (CA) offers the service of creating a certificate for you. How? They use certain values (the CA's issuer name, your server's public key, company name, domain, etc.) and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data. The result of this encrypted data is a SIGNATURE.
So now the CA gives you back a certificate. The certificate is basically a file containing the values previously mentioned (CA's issuer name, company name, domain, your server's public key, etc.), INCLUDING the signature (i.e. an encrypted version of the latter values).
Now, with all that being said, here is a REALLY IMPORTANT part to remember: your device/OS (Windows, Android, etc.) pretty much keeps a list of all major/trusted CA's and their PUBLIC KEYS (if you're thinking that these public keys are used to decrypt the signatures inside the certificates, YOU ARE CORRECT!).
Ok, if you read the above, this sequential example will be a breeze now:
Example-Company asks Example-CA to create for them a certificate.
Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate.
Tomorrow, internet-user-Bob uses Chrome/Firefox/etc. to browse to https://example-company.com. Most, if not all, browsers nowadays will expect a certificate back from the server.
The browser gets the certificate from example-company.com. The certificate says it's been issued by Example-CA. It just so happens to be that Bob's OS already has Example-CA in its list of trusted CA's, so the browser gets Example-CA's public key. Remember: this is all happening in Bob's computer/mobile/etc., not over the wire.
So now the browser decrypts the signature in the certificate. FINALLY, the browser compares the decrypted values with the contents of the certificate itself. IF THE CONTENTS MATCH, THAT MEANS THE SIGNATURE IS VALID!
Why? Think about it, only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them.
How about man in the middle attacks?
This is one of the main reasons (if not the main reason) why the above standard was created.
Let's say hacker-Jane intercepts internet-user-Bob's request, and replies with her own certificate. However, hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA. Lastly, hacker-Jane remembers that she has to include a signature on the certificate. But what key does Jane use to sign (i.e. create an encrypted value of the certificate main contents) the certificate?????
So even if hacker-Jane signed the certificate with her own key, you see what's gonna happen next. The browser is gonna say: "ok, this certificate is issued by Example-CA, let's decrypt the signature with Example-CA's public key". After decryption, the browser notices that the certificate contents don't match at all. Hence, the browser gives a very clear warning to the user, and it says it doesn't trust the connection.
The client has a pre-seeded store of SSL certificate authorities' public keys. There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called "root" certificates in order for the server to be trusted.
You can examine and/or alter the list of trusted authorities. Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not.
The pre-seeded list can vary depending on which client you use. The big SSL certificate vendors insure that their root certs are in all the major browsers ($$$).
Monkey-in-the-middle attacks are "impossible" unless the attacker has the private key of a trusted root certificate. Since the corresponding certificates are widely deployed, the exposure of such a private key would have serious implications for the security of eCommerce generally. Because of that, those private keys are very, very closely guarded.
if you're more technically minded, this site is probably what you want: http://www.zytrax.com/tech/survival/ssl.html
warning: the rabbit hole goes deep :).