What's the difference between managing certificates for a user account and for a computer account?

Question

We have some domain-joined computers that were unable to import a third party root cert as a trusted cert provider. In trying to fix this, I noticed that when we go to use the certificate management snap-in, we get a prompt like in the screenclip below.

My question is, what's the difference between the user account and the computer account in the certificate management snap-in?

Solution

The difference is exactly what it says. With Windows, certificates get assigned to accounts. So, if you want to apply a certificate to a specific computer, that's done by assigning the certificate to the computer account. This is a slight difference that's mainly just semantic when compared to *nix systems, where a user-certificate would be stored in the user's directory some where, and a computer certificate would typically be found in a system directory somewhere.

Of course, as you noticed with your problem, the difference is that the computer account applies to the machine, and the user account applies to the user. If you need your machine to be authenticated with public key crypto (like an SSL cert for https, as the most common example), the certificate needs to be associated with the machine, not the user. If it's a user that you want to authenticate, rather than the whole machine, the certificate needs to be associated with the user.

Practically speaking, the difference you'll see in the certificate management snap-in is which "personal" certificate store you see and are able to manage - the one for the user account or the computer account... or for a service account, if you select that one. As you can see in the screenclip below, on my company workstation, my user has a certificate for code signing purposes, and my computer has a certificate for authentication when using secured protocols (RDP, HTTPS, TLS, etc.) - and they're different certificate stores, which you can see from their different paths.

As a result, my user can sign the PowerShell scripts I create, but my machine cannot. This is important, because the whole reason that I set up code signing certificates was because other coworkers were causing problems deploying broken copy-pasta scripts to our production servers, and I don't want them to get around that by simply logging on to my machine. Similarly, my user cannot claim to be machine, because my user doesn't have my machine certificate.

Don't ask me why Microsoft didn't design their certificate management snap-in so that you could view the user's and the machine's personal certificate stores at the same time in the same window, but they didn't. I would have done it differently, if they'd asked me, but instead, they paid someone else ungodly sums of money for something worse.

So because it makes a difference which "Personal" certificate store you're managing, and Microsoft paid someone other than me to design and create their certificate management snap-in, you have to select which account's certificates you want to manage when you add the snap-in.

Comments

[lbanz]

I believe if you import it with the computer account, the certificate will be added to everyone's account whereas if you use a user account it will only be added to that specific user.

[daisy]

@lbanz but after import the cert as trusted ca provider, I still see it as untrusted when I double click on the cer file

[Ryan Bolger]

You can just add a second (or more) instance of the Certificates snap-in in the same MMC console. One for Computer, one for user.

[Massimo]

The answer is good, but maybe the rant about the UI (and especially about the payment of UI designers) could have been omitted...