User Certificate vs Computer Certificate – Key Differences

certificate-authorityssl-certificate

Normally when deploying an SSL VPN solution with a cert check, I would deploy an internal MS CA and configure a GPO to give out computer certificates. The username/password with MFA proves the user is who they say they are and the computer certificate validates the computer belongs to the company's domain. Recently had an issue with a vpn client which could not read the local computer store without having local admin and according to company policy, users don't have local admin. The suggested solution was to issue a User certificate instead. Now by default, the template for User certs allows them to be exported, so we made a custom template that does not allow for export.

Every guide you read for distributing internal certs for this kind of setup uses computer certs, but the question is why? Is it really any more or less secure then a user certificate? You can't get a User cert from a non-domain computer, which is the same for Computer certs. Really it seems like it's accomplishing the same goal, with the only big different is that the Computer cert lives in the Local Computer store while the User cert lives in the User's cert store. You need local admin to read the local computer store, but that's not really increasing the security that much since neither Computer or User cert private keys can be exported. If you installed some of the additional Web plugins on the CA you could make it possible to allow non-domain computers to request certs, but those are not enabled.

In the end, you have to be on a domain computer to get a User cert issued to you, so it basically proves it's a company asset. Really woudln't user certs be easier to deal with since they don't have the headache of needing local admin to even read them? I can't think of a difference in terms of security really, but if that's the case then why does every guide suggest Computer certs? Trying to vet this out to see if there is some angle I'm missing, thought it would be helpful to ask a larger community since I've discussed this with many collegues and no one could think of a gotcha or security concern.

Best Answer

Every guide you read for distributing internal certs for this kind of setup uses computer certs, but the question is why? Is it really any more or less secure then a user certificate?

It isn't (necessarily) about security; they're using computer certificates because that's the most appropriate solution for their use case. You've already discovered some reasons why using user certificates are less convenient: you had to create a custom template, make sure that the AD didn't allow users to join non-company machines to the domain, and make sure that the certificate authority didn't have the plug-in that allows non-domain machines to request user certificates.

Since there are good non-security reasons to use computer certificates, the fact that most everybody does provides little or no evidence either way as to whether using user certificates is secure. However, you have an constraint which they didn't: for some reason, your VPN client software can't use computer certificates. I'll assume you've already researched that thoroughly. The ideal solution would be to change clients, but that would be expensive. You therefore need to make a judgement call as to how much risk using user certificates introduces.

The best (and only thoroughly safe) way to make that judgement would be to consult an expert, which is definitely not me. I've been putting off posting an answer in the hopes that someone with the appropriate experience would do so, but no such luck. So, for what little it's worth, here's how I'd look at it. However, if you have the option of spending a hopefully modest amount of money on an expert consultant, I recommend that you do so.

I only see two ways a user might try to bypass the restrictions on which computers they can use. They could try to export their user certificate from a domain machine to a non-domain machine. Or they could try to trick the certificate authority into issuing a user certificate to a non-domain machine.

I did a quick bit of research, and it suggests that although the user certificates are stored in files the user has access to, they are encrypted by the CNG Key Isolation service. Unless the user has admin access, this should prevent the keys from being exported. (If the user does have admin access, they could presumably just as easily export a computer key as a user key.)

I'm less sanguine about the second option. To the best of my knowledge, there is no documented promise that the certificate authority will make any effort to validate the computer's identity when a user key is being generated. The fact that there is a documented procedure for doing this, and you have ensured that the relevant component isn't installed, isn't good evidence that this is the only possible way.

My research suggests that certificate requests are made via DCOM, and that although the default DCOM settings do not work for a non-domain client attempting to connect to a domain server, only the client needs to be reconfigured in order to successfully make a connection. Obviously, I haven't actually tried it, but in principle I think this would work.

On the other hand, the client would still need to be able to connect to the CA in order to make the request, and if the client is outside your network then that should be blocked by your firewall. And given the context, I would assume that you already have measures in place to discourage staff from attaching personal computers to the work network. So from that perspective, while you're perhaps not as safe as you could be, you probably are as safe as you need to be, depending of course on your risk profile. (I'm going to assume you're not running a nuclear weapons site here.)

At the end of the day your best protection isn't going to be technological anyway. Provided your staff are aware of the policy and warned that VPN use is being logged and monitored, very few of them are likely to try to bypass the rules even if they are skilled enough to find a way to do so.