5

After countless hours of reading I have come to the find that mutual authentication via client certificates seemed to be a viable and appropriate solution for the following scenario.

I have a ASP.NET MVC Website, call it example.com, with an area that needs to be secured so only our partners can access it. Requiring our partners to register each of their employees is out of the question so I thought issuing a client certificate to our each of partners would be a more reasonable solution.

So my questions are this.

  1. Are client certificates the appropriate method of authenticating our partners or should we use a different authentication scheme?
  2. How can I issue/manage client certificates to our partners? Do I need to use a managed PKI like DigiCert or Verisign?
  3. If client certificates are the appropriate method how do I verify the client certificate being supplied by a partner is one our company issued and that it is still valid?

As of right now when we partner with a company an entry will be made into our database with the name of the partner, their location, ect... and they will be given a unique id.

My idea was to store the certificate serial # & thumbprint in a table with the company's unique id, is this enough info to validate a certificate? Does this seem like a reasonable solution?

  • 1
    I have no experience with ASP.net, but the usual method would be to create an own root certificate and have your webserver trust it. You can then sign the certificates you give to your clients with that root key. – Philipp Apr 11 '15 at 21:49
  • "Requiring our partners to register each of their employees is out of the question so I thought issuing a client certificate to our each of partners would be a more reasonable solution." - So you replace registering each employee with shipping a certificate to each employee (probably after registration)? Or do you want all employees of the same partner to share the same certificate, which would then be no different then sharing the same login? – Steffen Ullrich Apr 11 '15 at 22:19
  • Preferably one certificate per partner, installed on each machine. – matt. Apr 11 '15 at 22:25
  • 1
    A shared certificate has the same security as a shared login. – Steffen Ullrich Apr 11 '15 at 22:26
  • 1
    But the administrative overhead to change the account in case an employee leaves is higher with the certificate based solution, because you have to roll out somehow the new certificates to all machines instead of just telling everybody the new password of the shared account. – Steffen Ullrich Apr 11 '15 at 22:34
4

Yes, and no.

Using client certificates doesn't solve the problem, it moves the problem. Whereas before your problem is the creation, distribution, and protection of a password or other secret. And now your problem is the creation, distribution, and protection of a client certificate.

A client certificate is a lot like a password. But it has the special property that it can be validated by signatures. So if you're going to use client certs, the best way to go is to give the company a signing cert and have the company use that cert to sign certificates for all of its users. There's a certain amount of IT overhead to this idea, so it might not fly with your company.

An interesting alternative might be to use an SSO protocol, which basically means training your service to trust their login system. This can be done with off-the-shelf software, and support may already be included in the auth solution their company is using. For example most only services support OAuth 2, while Active Directory has baked-in SAML support.

  • I am not set on using certificates, I thought it would be easier..how naive of me. Distributing signing certificates and letting them manage the creating and deletion of employee certs sounds interesting but so does the SAML support of AD. I believe most of our partners are all using Windows with AD, how would I authenticate with a token I didn't create though? I would much rather trust their login system and have an SSO experience. – matt. Apr 12 '15 at 16:28

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.