Question

Is there a way for a java web app to get information on the security certificates installed on one's machine via a http request and selectively grant access if a particular certifiicate is installed on the machine.

Basically the requirement is, the web application should entertain request only from a company laptop else must deny access with appropriate error text.

(These could be win laptops with certain certifcates installed on their machine or they can be from a certain set of static ips.)

Was it helpful?

Solution

Yes, this is possible using HTTPS client certificates. The exact setup and configuration depends on your application server and specific requirements, but a common scenario woul be that you create a company internal CA (certification authority) to issue the client certificates which may be restricted to specific client IP addresses and configure your application server's HTTPS connector to require a client certificate and to trust certificates issued by your own CA.

After the proper configuration has been done, the client certificate(s) is/are made available to the web application through a servlet request attribute:

X509Certificate[] certificates = (X509Certificate[])
    request.getAttribute("javax.servlet.request.X509Certificate");

OTHER TIPS

As jambjo said - you can absolutely get client certificates through HTTPS with client authentication as he described. I'd recommend that over static IPs, a certificate is harder to spoof and allows more flexibilty if you need to reconfigure the network differently in the future.

A couple other thoughts:

  • Almost any application server will let you set a trusted certificate store - the list of CA certificates your application will accept for HTTPS client auth. Limit this to the CA that is providing client certificates - either an internal company CA or a certificate provider.
  • The choice of internal CA or CA provider is a corporate one. An internal CA will take manpower to set up and maintain, a CA provider will cost you money per certificate. There reaches a tradeoff point where it's cheaper to make the certificates yourself, but until you hit that point, the CA provider may be cheaper.
  • If you have an internal CA and your rule is that "any company machine (with a certificate) can access this application", then your work is done at the Trusted CA list in the applicaiton server, since you know the company CA will not be used for anyone but people in the company.
  • If you have a CA provider, you may need to limit your access control further and use the code jambjo provided to get the certificate and look at information within it. Typically, there is a organization (O) and organizational unit (OU) component within the subject DN (distinguished name) that will tell you what organization produced this certificate. You should be able to check that to be sure you have a company computer.
  • It's viable to do the O and OU checking if you know that your CA provider will never give out your company's O and OU names to anyone but a member of your company. If that is not the case, you may need to check against a back end data store (like an LDAP directory) to be sure the user or user's machine is known to you.
  • It's also possible to link the IP address of the machine to the certificate - often SubjectAltName (Subject Alternative Name) is used for this when the certificate is being constructed. I would not recommend it, because you will need a need a new certificate if you ever change the IP address of the machine. It seems unnecessarily complex for your purposes.
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top