Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to restrict the SSL access to a Tomcat instance using certificates, and not relying on any "user" accounts.

I have a CA which is being used to sign the certificates, but if I configure Tomcat to trust the CA then it will trust anyone signed by it, whereas I would like to be much more restrictive and only allow certs for which I have approved that particular usage (namely, for the apps I have running on that server).

It seems to me that this is exactly what the Extended Key Usage part of X.509 is for, and I can create certs with that field defined to a custom value, but I can't figure out if there is any way to make Tomcat pay attention to that field and only allow certain Usages. Does anyone know how to do this? Even pointers for Apache httpd would be useful, since I could put Tomcat behind an https front end in a pinch.

share|improve this question

Apache specific stuff, since I'm much more comfortable working with it than with tomcat directly --

Cert usage isn't exposed in the list of SSL environment variables that Apache makes available by default. But it looks like you could use a custom SSLRequire like this:

SSLRequire "certUsageSSLClient" in PeerExtList("SECCertUsages")

I believe those names are right, but you might have to delve into the OIDs there if the shortnames aren't exactly what your ssl implementation expects.

share|improve this answer

This cannot be done at the SSL layer in tomcat with extendedKeyUsage. mod_ssl (from the APR) only allows you to do this with SSLRequire, but since that is not valid at server scope, it will be ignored. I don't think the non-APR implementation supports this either as I've seen no evidence for it at all.

At best, you can look at the certificate yourself in your servlet (assuming it exposes it to you; I'm not sure how to do that), and check the extension there.

However, what you are trying to do is not typical. The usual way of doing this is to create your own trust root (do not trust the browser trust root or anything) and use that to issue client certificates. They need to be a client certificate (with clientAuth, and if v3, the appropriate EKUs for that), but nothing else must be special. You are reasonable to rely on the DN to identify the user.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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