1

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.

  • I haven't used this technology in several years, so take this with a big grain of salt, but I suspect that it might in fact be possible for a sufficiently skilled user to get the CA to issue a user cert for a non-domain computer. – Harry Johnston Jun 11 '18 at 1:53
  • I tried numerous ways to trick the CA into giving out a cert to a non-domain machine but couldn't get it to work. There are some web components you can add which will do this, but we didn't add those for this project, so it should be impossible. That was actually what I was looking for, to see if there was a way that I was not aware and did not involve overly complicated hacks which would result in user on a non-domain machine getting a cert issued. – Baron Harkonnen Jun 12 '18 at 18:07
  • How safe this is depends on whether the CA is actively verifying that the machine the user is connecting from is a domain member, or if it doesn't work for some other reason, e.g., I know some administrative tasks require the server to connect back to the client machine, which won't usually work if it isn't a domain member. On the other hand, working around that wouldn't be easy, so if your goal is just "make it difficult" and not "make it impossible" you're probably OK - assuming you have taken steps to prevent users from adding their personal machines to the domain? – Harry Johnston Jun 12 '18 at 21:16
  • That's correct, the GPO has been modified to prevent normal users from adding machines to the domain. There should be no way for a non-domain user to obtain a certificate, you should only be able to get a user cert from a machine that is part of the domain. Once it's issued, you can't export it to a non-domain machine and use it. So as far as I can tell, if you have a user cert, it would have be on a domain machine. Even though I would normally use a machine cert, it seems like the user cert will accomplish the same thing of verifying the user is on a corporate machine. – Baron Harkonnen Jun 14 '18 at 13:48
0

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.

  • This is the best answer, the user certificate does open the door in ways that a machine cert might not, however overall the security seems reasonable. We marked the private key as not exportable, but technically the key is still there and with enough time or effort, a bad actor might be able to extract it. However, I believe the same could said for the machine cert. I don't disagree that there might be some way to manipulate DCOM or some kind of man in the middle attack that might result in tricking the CA, but the reality is those are not common hacks.Thanks for your help in sounding it out. – Baron Harkonnen Jun 18 '18 at 14:31
0

These certificates are different because they serve different purposes. This is about Granularity. Basically the two types of certs you mentioned identify securely two basic types of things on your network. Computers and users. You can revoke a user certificate separately than their workstation, or otherwise control access and trust separately. User certs have the distinguished name of the user, computer certs have the FQDN of the computer.

Another thing i can think of is 802.11x, port based security. This prevents normal communication through the attached switch until you authenticate. Certificates are one way of authenticating using 802.11x protocol. If the user's certificate is not imported onto some random machine they have never logged onto before it could be a problem, hence you issue device certificates.

  • I don't disagree that the certificates are different in nature, but functionally it seems like they can serve the same purpose. Even if you export the cert and put it on another machine, it won't work because the private key is not exportable for either the user or computer cert. I tested that by copying the root cert and the user cert onto a non domain machine and the vpn would not accept the certificate. In the context of proving whether the user is on a domain computer, it seems like functionally the user and comptuer certs serve the same purpose. – Baron Harkonnen Jun 8 '18 at 13:06
  • They are different because they identify different things. One is the machine. The other is the user. You will need a different certificate for each user but only one certificate for a machine. Also, the usage of a machine certificate versus user certificate is different. A user certificate can have expanded abilities such as email encryption, code signing, etc. Typically a machine certificate is used for identity, authentication and authorization only. – John Hanley Jun 11 '18 at 2:36
  • Yes I understand they have different uses, but in the case I have described, they would serve the same purpose, which is to essential prove the user is on a corporate computer. The question is can they serve the same purpose without any caveats? I believe the answer is yes, no one has pointed out a situation in which someone could obtain a user certificate without being on a corporate resource. – Baron Harkonnen Jun 12 '18 at 13:12
  • No, they can't serve the same purpose without any caveats. Only a machine certificate can uniquely identify a machine on the domain. Only a user certificate can uniquely identify a user on your domain. One has the DN of the user, the other has the FQDN of the workstation. They are separate concepts, or separate layers of the same thing. – manbearpig Jun 13 '18 at 0:06
  • Ok then how would you get a user certificate issued to a non-domain computer? – Baron Harkonnen Jun 14 '18 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.