You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kevin Mills <ke...@gmail.com> on 2010/02/18 00:48:51 UTC
Trouble with CLIENT-CERT authentication method
Greetings fellow Tomcat-ers:
I'm trying enable client certificate authentication on a per-webapp
basis using Tomcat 6.0.24. According to the various sources of
documentation I've found, this should be possible by enabling the SSL
Connector (which I've done), getting client certificate authentication
working for the Connector (this works for me), then setting
clientAuth="false" on the Connector and placing the following in the
webapp's web.xml:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
I've tried various combinations of security constraints, roles,
realms, etc. but can never get the CLIENT-CERT authentication to work
for my webapp. As I mentioned above, all is fine if I set
clientAuth="true" but I don't want to impose client certificate
authentication across the whole site.
Searching the archives, I ran across bug 46950
(https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) which looks
to describe my very problem. However, the bug is marked "fixed" as of
6.0.21 (I'm using 6.0.24) and I am not seeing the correct behavior.
Furthermore, the issue was reported against the APR Connector and I'm
using the default flavor (which, according to the one of the answering
developers, works for him).
Can anyone tell me what's going on here?
Thank you!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2010 16:30, Kevin Mills wrote:
> On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
>> CVE-2009-3555?
>
> Now that this is working, I'd like to ask what other options exist for
> using client certificate authentication on a per-webapp basis.
> Requiring my customers to enable a feature
> (allowUnsafeLegacyRenegotiation) that exposes them to a potential
> man-in-the-middle attack doesn't seem like a good idea! (Heck, it even
> says "Unsafe" in the property name!)
>
> I saw mention of overriding the SSL implementation with
> sslImplementation="classname"... does that still work in 6.x? Is that
> a good option? And what about an Authentication Valve, is that the
> right direction?
No. The TLS protocol is broken. You need to avoid renegotiation or wait
for the updated protocol and Sun to implement the fix in JSSE or an
OpenSSL release with the fix.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
> CVE-2009-3555?
Now that this is working, I'd like to ask what other options exist for
using client certificate authentication on a per-webapp basis.
Requiring my customers to enable a feature
(allowUnsafeLegacyRenegotiation) that exposes them to a potential
man-in-the-middle attack doesn't seem like a good idea! (Heck, it even
says "Unsafe" in the property name!)
I saw mention of overriding the SSL implementation with
sslImplementation="classname"... does that still work in 6.x? Is that
a good option? And what about an Authentication Valve, is that the
right direction?
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
> The rules on how security constraints combine are in the Servlet spec.
> It can take a bit of time to get your head around it.
>
> To require a cert for your servlet too, one option would be:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Everything</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>X509</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> </login-config>
>
> which requires it for everything.
That seems to do the trick! Thanks very much - I really appreciate
your immediate responses!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2010 00:42, Kevin Mills wrote:
> On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
>> <snip/>
>>
>>> :-) "Doesn't work", meaning I don't get prompted for my certificate.
>>> I see my servlet's output without any sort of authentication.
>>
>> What URL are you requesting? Only index.jsp will prompt for a cert. Your
>> servlet will just require SSL to be used.
>
> Ooooohhh... my mistake! Yes, index.jsp does prompt me for a
> certificate! So how would I make the servlet also require one? I was
> under the (mistaken?) impression that the "/*" url-pattern would cover
> the servlet.
The rules on how security constraints combine are in the Servlet spec.
It can take a bit of time to get your head around it.
To require a cert for your servlet too, one option would be:
<security-constraint>
<web-resource-collection>
<web-resource-name>Everything</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>X509</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
which requires it for everything.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
> <snip/>
>
>> :-) "Doesn't work", meaning I don't get prompted for my certificate.
>> I see my servlet's output without any sort of authentication.
>
> What URL are you requesting? Only index.jsp will prompt for a cert. Your
> servlet will just require SSL to be used.
Ooooohhh... my mistake! Yes, index.jsp does prompt me for a
certificate! So how would I make the servlet also require one? I was
under the (mistaken?) impression that the "/*" url-pattern would cover
the servlet.
Thanks very much!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2010 00:24, Kevin Mills wrote:
<snip/>
> <servlet-mapping>
> <servlet-name>MyServlet</servlet-name>
> <url-pattern>/myServlet</url-pattern>
> </servlet-mapping>
<snip/>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>MyApp</web-resource-name>
> <url-pattern>/index.jsp</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>X509</role-name>
> </auth-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Everything</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> </login-config>
<snip/>
> :-) "Doesn't work", meaning I don't get prompted for my certificate.
> I see my servlet's output without any sort of authentication.
What URL are you requesting? Only index.jsp will prompt for a cert. Your
servlet will just require SSL to be used.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/18/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
>
> Stupid question: don't you want clientAuth="true"?
>
In this particular case, no. I don't want to force client certificate
authentication for all SSL connections coming to port 8443. Instead,
I am looking to do client certificate authentication on a per-webapp
basis. As Mark pointed out, however, this opens up a potential
man-in-the-middle attack so I'm still investigating other ways to
accomplish this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Mark Thomas <ma...@apache.org>.
On 24/02/2010 15:03, Christopher Schultz wrote:
> So, setting<auth-method> to CLIENT-CERT triggers an SSL renegotiation.
> What if the<Connector> is set to clientAuth="want" or
> clientAuth="true"? Will the initial SSL negotiation carry the client
> certificate and therefore avoid CVE-2009-355?
Yes. But test carefully as there is a wide variety in client behaviour.
I've heard reports of some mobile clients renegotiating every few
requests. A real case of YMMV.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin,
On 2/23/2010 6:07 PM, Kevin Mills wrote:
> On 2/19/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
>> So, with clientAuth="false", how do you get a client certificate to use
>> for authentication? Or, does the presence of the CLIENT-CERT in web.xml
>> trigger an SSL-renegotiation where the client cert /is/ requested from
>> the client.
>
> The presence of CLIENT-CERT:
>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> </login-config>
>
> in web.xml triggers the renegotiation and the client cert is requested
> from the client. As Mark pointed out, this exposes the TLS bug
> CVE-2009-355 so be warned!
So, setting <auth-method> to CLIENT-CERT triggers an SSL renegotiation.
What if the <Connector> is set to clientAuth="want" or
clientAuth="true"? Will the initial SSL negotiation carry the client
certificate and therefore avoid CVE-2009-355?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuFP6gACgkQ9CaO5/Lv0PAs6gCZAXQ5c1cbjbw8U48p527U08h9
wukAmwZ40uKqBalI+W21EvMrloxLM3Hx
=bTUA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Trouble with CLIENT-CERT authentication method
Posted by Martin Gainty <mg...@hotmail.com>.
could you clarify if this failure is from client to server or server to client?
and who/what is generating the cert?
thanks,
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Tue, 23 Feb 2010 15:07:03 -0800
> Subject: Re: Trouble with CLIENT-CERT authentication method
> From: kevmacmills@gmail.com
> To: users@tomcat.apache.org
>
> On 2/19/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
> > So, with clientAuth="false", how do you get a client certificate to use
> > for authentication? Or, does the presence of the CLIENT-CERT in web.xml
> > trigger an SSL-renegotiation where the client cert /is/ requested from
> > the client.
>
> The presence of CLIENT-CERT:
>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> </login-config>
>
> in web.xml triggers the renegotiation and the client cert is requested
> from the client. As Mark pointed out, this exposes the TLS bug
> CVE-2009-355 so be warned!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/19/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
> So, with clientAuth="false", how do you get a client certificate to use
> for authentication? Or, does the presence of the CLIENT-CERT in web.xml
> trigger an SSL-renegotiation where the client cert /is/ requested from
> the client.
The presence of CLIENT-CERT:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
in web.xml triggers the renegotiation and the client cert is requested
from the client. As Mark pointed out, this exposes the TLS bug
CVE-2009-355 so be warned!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin,
On 2/19/2010 2:18 PM, Kevin Mills wrote:
> On 2/19/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
>> On 2/19/2010 1:48 AM, Jason Brittain wrote:
>>> Nope. clientAuth="false" means that the webapp's web.xml specifies which
>>> resources require the client certificate.
>>
>> Gotcha: I thought that "false" would cause the connector to ignore all
>> client cert info, while "want" would collect it but not process it,
>> while "true" would perform the checks for you.
>>
>> Instead, "false" and "want" are essentially the same (right?) and "true"
>> does the checks for you. If you have "want" or "false", plus a
>> <web-resource-collection> that demands CLIENT-AUTH, then it will be used
>> for identification purposes, but not actually checked against a valid
>> certificate chain.
>>
>> Do I have that right?
>
> The behavior I see is this: "false" does not request the client
> certificate at all. "want" requests it, but allows the connection to
> go through if no client certificate is presented. "true" requires a
> client certificate and kills the connection if no client certificate
> (or an unacceptable one) is presented.
So, with clientAuth="false", how do you get a client certificate to use
for authentication? Or, does the presence of the CLIENT-CERT in web.xml
trigger an SSL-renegotiation where the client cert /is/ requested from
the client.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt+6XQACgkQ9CaO5/Lv0PCSLQCfZkZ+Seia0JZmq+CcgXobgv2I
Ly8AniUQwHgGu9YHZH8Prr8qMwBVF+D3
=QNkD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/19/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
> On 2/19/2010 1:48 AM, Jason Brittain wrote:
>> Nope. clientAuth="false" means that the webapp's web.xml specifies which
>> resources require the client certificate.
>
> Gotcha: I thought that "false" would cause the connector to ignore all
> client cert info, while "want" would collect it but not process it,
> while "true" would perform the checks for you.
>
> Instead, "false" and "want" are essentially the same (right?) and "true"
> does the checks for you. If you have "want" or "false", plus a
> <web-resource-collection> that demands CLIENT-AUTH, then it will be used
> for identification purposes, but not actually checked against a valid
> certificate chain.
>
> Do I have that right?
The behavior I see is this: "false" does not request the client
certificate at all. "want" requests it, but allows the connection to
go through if no client certificate is presented. "true" requires a
client certificate and kills the connection if no client certificate
(or an unacceptable one) is presented.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason,
On 2/19/2010 1:48 AM, Jason Brittain wrote:
> Nope. clientAuth="false" means that the webapp's web.xml specifies which
> resources require the client certificate.
Gotcha: I thought that "false" would cause the connector to ignore all
client cert info, while "want" would collect it but not process it,
while "true" would perform the checks for you.
Instead, "false" and "want" are essentially the same (right?) and "true"
does the checks for you. If you have "want" or "false", plus a
<web-resource-collection> that demands CLIENT-AUTH, then it will be used
for identification purposes, but not actually checked against a valid
certificate chain.
Do I have that right?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt+wY0ACgkQ9CaO5/Lv0PDbcwCeMk2ae1G85O64nNhCU/orDBxK
Qg4An3sHZYQ68DAB5KEWTsW65zugvSBK
=cbwC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Jason Brittain <ja...@gmail.com>.
Christopher:
Nope. clientAuth="false" means that the webapp's web.xml specifies which
resources require the client certificate. See the Connector doc page's
description of the accepted values for the clientAuth attribute:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
"clientAuth" is a rather confusing name for this attribute since a value of
"false" makes it appear as though client certs won't be used, which isn't
really how it works. Less confusing names might be "clientAuthChallenge" or
"clientAuthRequired" with values such as "always", "want", and "protected".
--
Jason Brittain
On Thu, Feb 18, 2010 at 1:29 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin,
>
> On 2/17/2010 7:24 PM, Kevin Mills wrote:
> > Sure thing - here is my Connector element:
> >
> > <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
> > maxThreads="50" scheme="https" secure="true"
> > keystoreFile=".../tomcat.keystore" keystorePass="..."
> > clientAuth="false" sslProtocol="TLS"
>
> Stupid question: don't you want clientAuth="true"?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkt9sR0ACgkQ9CaO5/Lv0PDsVgCgkR1Md/xdnO14MU3ZWMXQz13l
> gCAAniGMybkQIU3VghXUj4G0l0OfrE2w
> =m/Iy
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Jason Brittain
Re: Trouble with CLIENT-CERT authentication method
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin,
On 2/17/2010 7:24 PM, Kevin Mills wrote:
> Sure thing - here is my Connector element:
>
> <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
> maxThreads="50" scheme="https" secure="true"
> keystoreFile=".../tomcat.keystore" keystorePass="..."
> clientAuth="false" sslProtocol="TLS"
Stupid question: don't you want clientAuth="true"?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt9sR0ACgkQ9CaO5/Lv0PDsVgCgkR1Md/xdnO14MU3ZWMXQz13l
gCAAniGMybkQIU3VghXUj4G0l0OfrE2w
=m/Iy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
> Then you probably haven't got your config quite right. There are plenty
> of things to go wrong with this but this definitely works - I was using
> it just the other day.
>
> We'll need to see:
> - connector element from server.xml
> - web.xml
> - tomcat-users.xml (assuming that is what you are using)
> for starters.
Sure thing - here is my Connector element:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="50" scheme="https" secure="true"
keystoreFile=".../tomcat.keystore" keystorePass="..."
clientAuth="false" sslProtocol="TLS"
allowUnsafeLegacyRenegotiation="true" />
My web.xml (based on what I saw in your reply to bug 46950):
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<distributable/>
<servlet>
<description>Test servlet</description>
<display-name>My Servlet</display-name>
<servlet-name>MyServlet</servlet-name>
<servlet-class>MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/myServlet</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>MyApp</web-resource-name>
<url-pattern>/index.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>X509</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Everything</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
</web-app>
And my tomcat-users.xml:
<tomcat-users>
<role rolename="manager"/>
<user username="tomcat" password="..." roles="manager"/>
<role rolename="X509"/>
<user username="EMAILADDRESS=...,CN=...,OU=...,OU=...,OU=...,O=...,L=...,ST=...,C=..."
password="null" roles="X509" />
</tomcat-users>
>
> Also a better description of the problem than "doesn't work" would help.
>
:-) "Doesn't work", meaning I don't get prompted for my certificate.
I see my servlet's output without any sort of authentication.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2010 00:04, Kevin Mills wrote:
> On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
>> On 17/02/2010 23:48, Kevin Mills wrote:
>>> Can anyone tell me what's going on here?
>>
>> CVE-2009-3555?
>>
>> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
>> search for
>> allowUnsafeLegacyRenegotiation
>
> Thanks for your reply - I did see that option and forgot to mention
> that I tried it to no avail.
Then you probably haven't got your config quite right. There are plenty
of things to go wrong with this but this definitely works - I was using
it just the other day.
We'll need to see:
- connector element from server.xml
- web.xml
- tomcat-users.xml (assuming that is what you are using)
for starters.
Also a better description of the problem than "doesn't work" would help.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Kevin Mills <ke...@gmail.com>.
On 2/17/10, Mark Thomas <ma...@apache.org> wrote:
> On 17/02/2010 23:48, Kevin Mills wrote:
>> Can anyone tell me what's going on here?
>
> CVE-2009-3555?
>
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
> search for
> allowUnsafeLegacyRenegotiation
Thanks for your reply - I did see that option and forgot to mention
that I tried it to no avail.
Seeing as this renegotiation is a Bad Thing, what is the recommended
way to do this? Another thread I followed talked about setting the
Connector to allow any certificates and writing an Authentication
Valve... is that the right direction?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Trouble with CLIENT-CERT authentication method
Posted by Mark Thomas <ma...@apache.org>.
On 17/02/2010 23:48, Kevin Mills wrote:
> Can anyone tell me what's going on here?
CVE-2009-3555?
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
search for
allowUnsafeLegacyRenegotiation
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org