tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Newbie question re certificates
Date Tue, 02 Dec 2014 21:42:17 GMT
Hash: SHA256


On 12/2/14 8:09 AM, Andrew Gronosky wrote:
> On 2014-12-02 04:55, John Dunn wrote:
>> I have been asked the following question during an audit, which
>> I personally don't understand.
>> "When using Mutually authenticated TLS  is authorisation based on
>> the certificate name(and not just on the root CA)?"

Just to be clear: none of this matters if you aren't using "client
certificates" to identify clients. If you are using plain-old TLS for
encryption and site-identity, then the answer to this question is "we
don't use mutual TLS authentication/authorization".

>> Can anyone clarify what exactly this means and whether Tomcat
>> supports this?
>> Cheers
> I believe the question is asking whether, during the
> authentication process, Tomcat inspects the certificate and reads
> the CN of the client cert, then matches it against the set of known
> users (defined in whatever Realm you are using).


Technically, the TLS handshake is over before Tomcat gets to inspect
the cert's CN and the Realm does anything with it.

In the case of the TLS handshake, it's part authentication
(determining who you are) and part authorization (determining if you
are allowed to do something). For the TLS handshake, the configuration
of your truststore and those certificates that are within that
truststore are what matter.

If you trust the certificate that signed all of your client
certificates, then you will authorize all client certificates to
complete TLS handshakes and thus access your web application. If you
trust individual certificates (more fine-grained control, but a pain
in the neck to administer) then you are using your TLS certificate
trust for authorization at the individual (person) certificate level
and not "a root CA" (note that the signing certificate doesn't have to
be a CA in the usual sense... you can create a local CA that can sign

> I found out just yesterday that the answer is yes, at least for
> Tomcat 7.
> There are really two things going on with the client certs in
> mutual authentication. First, the server requests the client cert
> in order to complete the TLS handshake and establish a connection.
> Next, *after* the TLS connection is open, if the resource being
> accessed has an auth-constraint in web.xml, Tomcat checks the CN,
> matches it to a user name, maps that name to a role, and checks
> that the role is allowed to access the resource.


> As I discovered yesterday, if you have a client cert that is signed
> by a CA that Tomcat trusts, but whose name (synonymously, CN) does
> not map to a recognized user, then you will connect to Tomcat but
> get an HTTP 401 error as your response.  If the user name is
> recognized but lacks the required role, you get HTTP 403.

You already corrected this to be 401, which is correct.

So, Tomcat can block (or admit) users either by only trusting the
individual client certificates or by trusting all certificated signed
by a CA and then a second authorization step will occur after the TLS
handshake, where you can configure authorization based upon your

- -chris
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message