Home / server / Questions / 242584
Accepted
Zac Thompson
Asked: 2011-03-03 20:50:54 +0800 CST

Can I restrict SSL access to Tomcat by Extended Key Usage?

  • 772

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.

tomcat java ssl x509

2 Answers

  1. 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.

    http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html

    • 1
  2. Best 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.

    • 1