My bad - I was looking in the catalina log, not the localhost log...
Now I see the config being parsed:
01-Mar-2020 21:12:49.147 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.startInternal Read
configuration from: /WEB-INF/rewrite.config
01-Mar-2020 21:12:49.155
No matter where I place the rewrite.config, cannot get the
RewriteValve to find it.
I tried:
* /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml and
/usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
* /usr/local/tomcat/conf/context.xml and
/usr/local/tomcat/conf/localhost/rewrite.config
The
I hit a snag with the query string. In some cases it contains the
webapp base URI in a query parameter, such as:
/admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
So I'm trying to rewrite those as well, from
https%3A//localhost%3A5443/ to
:05 schrieb Mark Thomas:
On 29/02/2020 10:40, Michael Osipov wrote:
Tomcat does not support renegotiation of TLS contexts based
on URLs like HTTPd.
Yes it does.
If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You
Thanks! I actually needed proxyPort="443" to make the URL
https://localhost, but your suggestion did the trick.
On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas wrote:
>
>
>
> On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > Yes the clients connect only directly to nginx.
> >
> > So the proxy
t; Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>>>
>>>>
>>>>
>>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>>> on URLs like HTTPd.
>&
:40, Michael Osipov wrote:
Tomcat does not support renegotiation of TLS contexts based
on URLs like HTTPd.
Yes it does.
If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained control
gt; On 29/02/2020 10:40, Michael Osipov wrote:
>>>
>>>
>>>
>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>> on URLs like HTTPd.
>>>>>
>>>>> Yes it does.
>>>>>
>>>
t;>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>> on URLs like HTTPd.
>>>>
>>>> Yes it does.
>>>>
>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>> trigger a renegotiatio
CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained control you have in httpd but you
can replicate the typical use cases.
Really? If I say require client cert auth on the connector, it will be
enforced
CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained control you have in httpd but you
can replicate the typical use cases.
Really? If I say require client cert auth on the connector, it will be
enforced
On 29/02/2020 11:07, Michael Osipov wrote:
> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>> On 29/02/2020 10:40, Michael Osipov wrote:
>>> Tomcat does not support renegotiation of TLS contexts based
>>> on URLs like HTTPd.
>>
>> Yes it does.
>>
>
Am 2020-02-29 um 12:05 schrieb Mark Thomas:
On 29/02/2020 10:40, Michael Osipov wrote:
Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
Hi,
Instead of configuring the container for client cert Auth change the
webapp:
1) define a realm in local context.xml
2) add resp security constraint only
On 29/02/2020 10:40, Michael Osipov wrote:
> Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
>> Hi,
>>
>> Instead of configuring the container for client cert Auth change the
>> webapp:
>> 1) define a realm in local context.xml
>> 2) add resp secu
t certs). This would not be a problem if the webapp would
not be user-facing, but since it is the certificate prompt can be
confusing to many users and increase our bounce rate.
I'm looking for some workaround that would not require changing the
whole design. For example asking for the client cert only when a
On 28/02/2020 22:26, Martynas Jusevičius wrote:
> Yes the clients connect only directly to nginx.
>
> So the proxy config within 2 pairs of containers is like this:
>
> # website service; clientAuth=false
> nginx:80 -> tomcat:8080
> nginx:443 -> tomcat:8443
>
> # API service; clientAuth=true
rts). This would not be a problem if the webapp would
>not be user-facing, but since it is the certificate prompt can be
>confusing to many users and increase our bounce rate.
>
>I'm looking for some workaround that would not require changing the
>whole design. For example asking for the
Yes the clients connect only directly to nginx.
So the proxy config within 2 pairs of containers is like this:
# website service; clientAuth=false
nginx:80 -> tomcat:8080
nginx:443 -> tomcat:8443
# API service; clientAuth=true
nginx-api:90 -> tomcat-api:8080
nginx-api:5443 -> tomcat-api:8443
On 28/02/2020 21:00, Martynas Jusevičius wrote:
> Setting up a second container with a different port was easy enough.
>
> However I got stuck on the URL mapping/rewriting. Using nginx as a
> proxy, I don't think it's possible to rewrite headers with the
> upstream module:
>
> > >>> only administrators are using the API.
> > >>>
> > >>> The Connector is configured using clientAuth="want".
> > >>> This works fine with API calls which are run from shell scripts.
> > >>> In the browser however
t;> are any client certs). This would not be a problem if the webapp would
> >>> not be user-facing, but since it is the certificate prompt can be
> >>> confusing to many users and increase our bounce rate.
> >>>
> >>> I'm looking for some workaround th
shell scripts.
>>> In the browser however it prompts a certificate selection (if there
>>> are any client certs). This would not be a problem if the webapp would
>>> not be user-facing, but since it is the certificate prompt can be
>>> confusing to many
roblem if the webapp would
> > not be user-facing, but since it is the certificate prompt can be
> > confusing to many users and increase our bounce rate.
> >
> > I'm looking for some workaround that would not require changing the
> > whole design. For example asking
a problem if the webapp would
> not be user-facing, but since it is the certificate prompt can be
> confusing to many users and increase our bounce rate.
>
> I'm looking for some workaround that would not require changing the
> whole design. For example asking for the client cer
ng to many users and increase our bounce rate.
I'm looking for some workaround that would not require changing the
whole design. For example asking for the client cert only when a
certain flag is set, such as a query param or request header.
Or somehow not asking for it but still accepting it :) B
Thanks Mark, will do!
-Original Message-
From: Mark Thomas
Sent: Thursday, October 31, 2019 3:04 PM
To: Tomcat Users List ; George Stanchev
Subject: Re: Client Cert TLS issue
On 16/10/2019 18:55, George Stanchev wrote:
> And this is not where it hangs. I stepped through the c
On 16/10/2019 18:55, George Stanchev wrote:
> And this is not where it hangs. I stepped through the code through the
> handshaker but still haven't been able to figure out the hang point as I am
> not familiar with the details of that portion of TC code . I've attached two
> cacerts that you
To: users@tomcat.apache.org
Subject: Re: Client Cert TLS issue
Just a note to say I haven't forgotten this. I hope to look at this this week
unless someone beats me to it.
Mark
On 16/10/2019 17:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
&g
Just a note to say I haven't forgotten this. I hope to look at this this
week unless someone beats me to it.
Mark
On 16/10/2019 17:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
>> I would need some help with tracking an issue with TC 8.5.47 (windows x64,
Hi Chris,
This didn't make a difference and no difference in CPU utilization was
observed. The lockup happens before server request the client cert so you can
drop my big fat cacerts in a TC instance create a client-cert connector, in our
case we set the " javax.net.ssl.trust
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
George,
On 10/16/19 12:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
>> I would need some help with tracking an issue with TC 8.5.47
>> (windows x64, java: azul 1.8.0_222) configured with [1] and
>>
On 15/10/2019 22:15, George Stanchev wrote:
> Hi,
>
> I would need some help with tracking an issue with TC 8.5.47 (windows x64,
> java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple
> client tries to connect to the server, the server hangs on SSL handshake
> until
On 15/10/2019 22:15, George Stanchev wrote:
> Hi,
>
> I would need some help with tracking an issue with TC 8.5.47 (windows x64,
> java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple
> client tries to connect to the server, the server hangs on SSL handshake
> until
Hi,
I would need some help with tracking an issue with TC 8.5.47 (windows x64,
java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple
client tries to connect to the server, the server hangs on SSL handshake until
either the client times out on read or the server times out
se SSLVerifyClient=none, the browser complains
> >
> > This site can’t provide a secure connection login-test.foo.com sent an
> > invalid response.
> > ERR_SSL_PROTOCOL_ERROR
>
> What did you expect?
>
> You told the Connector - explicitly - not to ask for CLIENT-CE
> This site can’t provide a secure connection login-test.foo.com sent an
> invalid response.
> ERR_SSL_PROTOCOL_ERROR
What did you expect?
You told the Connector - explicitly - not to ask for CLIENT-CERT
authentication.
You told the application to require CLIENT-CERT authentication.
It
net.shibboleth.idp.authn.impl.X509AuthServlet
3
X509AuthHandler
/Authn/X509
X509AuthHandler
/Authn/X509
CONFIDENTIAL
X509
CLIENT-CERT
2. server.xml
session tickets, the client has to provide the cert and the full
chain in the handshake. With OpenSSL session tickets the server caches
the client cert but not the full chain.
The above is only as accurate at the last time I dug into this. There
are lots of variables, JRE version, JSSE vs OpenSSL, OpenSS
Thanks for the very quick response! Out of curiosity is this ensured by some
sort of caching in the Tomcat server after the TLS handshake? Or is it
expected that the client would send the certificate with each post handshake
request. I ask as I'm seeing intermittent requests that do not have
On 12/07/2019 08:22, Martynas Jusevičius wrote:
> In my experience with 8.x -- on all requests.
The above is correct for JSSE based TLS connections. It also applies to
most OpenSSL based connections.
There is one edge case that can cause problems. If:
- OpenSSL based TLS connections are used;
-
In my experience with 8.x -- on all requests.
On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
wrote:
>
> I was hoping to get some clarification on when to expect client x509 certs in
> http requests where the Tomcat server (v9.x) has been configured to “want” or
> “need” client auth.
>
I was hoping to get some clarification on when to expect client x509 certs in
http requests where the Tomcat server (v9.x) has been configured to “want” or
“need” client auth.
https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
says:
“If there is an SSL
ng. The "Smartcard" button authenticates the user using client
cert SSL. The actual certificate validation happens way downstream of the login
page controller so all it needs to do is to extract it from the request and
pass it on to the backend. The login page can be served either ove
value (which is the default) will not require
>>> a certificate chain unless the client requests a resource protected by
>>> a security constraint that uses CLIENT-CERT authentication. See the SSL
>>> HowTo for an example. That SSL HowTo also contains tips on using
>>&g
one
>> isn't presented. A false value (which is the default) will not require
>> a certificate chain unless the client requests a resource protected by
>> a security constraint that uses CLIENT-CERT authentication. See the SSL
>> HowTo for an example. That SSL HowTo also contains tips o
he client requests a resource protected by
>a security constraint that uses CLIENT-CERT authentication. See the SSL
>HowTo for an example. That SSL HowTo also contains tips on using
>per-user or per-session certificate-based clientAuth."
>
>So, if I am using a clientAuth="fa
ant if you want the SSL
stack to request a client Certificate, but not fail if one isn't presented. A
false value (which is the default) will not require a certificate chain unless
the client requests a resource protected by a security constraint that uses
CLIENT-CERT authentication. See the SSL HowTo
, this approach results in
renegotiation for every request.
This is when I came across, “CLIENT-CERT” alternate, which can be configured
only for certain URL (e.g. “/authenticate” in my case). However, I am not able
to get it configured as expected. I issued a client certificate and imported in
browser
None of us had. Now both of us have, and still the same result ¯\_(ツ)_/¯
The DNS response is all the same, because for development we are using
internal lan ip access (or localhost), not domain-based. And self-signed
certificates.
I thought maybe it was some Java security configuration, but
Thanks for the reply :-)
I've checked for all that!
I even ended up copying my tomcat folder and my eclipse tomcat
configuration folder from my computer to his,
So they are literally the same configuration.
I know the connector configuration is being read because if, for example, I
remove the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gael,
On 1/19/16 6:37 AM, Gael Abadin wrote:
> Thanks for the reply :-)
>
> I've checked for all that!
>
> I even ended up copying my tomcat folder and my eclipse tomcat
> configuration folder from my computer to his,
>
> So they are literally
Gael,
On 1/11/16 11:46 AM, Gael Abadin wrote:
> The server certificate is self signed. Appart from the typical warning we
> see no errors when we check it.
>
> His system (windows) clock is synchronized using microsoft's NTP server,
> same as mine.
>
> This is really weird because I have
A colleague was having trouble setting up client cert auth on this web app
we are developing. He tried the latest tomcat 6 and 7 win32 installs using
java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
from eclipse, but even though the SSL connector had clientAuth="
t; David Balažic
> Software Engineer
> www.comtrade.com
>
> > -Original Message-
> > From: Gael Abadin [mailto:gael.aba...@imatia.com]
> > Sent: 11. January 2016 10:16
> > To: Tomcat Users List
> > Subject: SSL client cert selection dialog n
t Users List
> Subject: SSL client cert selection dialog not showing up on cloned
> deployment of tomcat 7 for windows x64
> Importance: Low
>
> A colleague was having trouble setting up client cert auth on this web app
> we are developing. He tried the latest tomcat 6 and 7 win32
there suggesting a configuration where I can force SSL
without asking for a client certificate: Once I set the CONFIDENTIAL
transport guarantee and the CLIENT-CERT auth method I will be asked for a
client cert when I land on a SSL page, no matter what.
I think I am getting something wrong. Please
Mark,
What are the possible issues with renegotiation? We're on NIO connectors, is
there anything known?
George
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, October 05, 2015 8:32 AM
To: Tomcat Users List
Subject: Re: Demand CLIENT-CERT only on certain
t; -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, October 05, 2015 8:32 AM
> To: Tomcat Users List
> Subject: Re: Demand CLIENT-CERT only on certain pages but demand SSL in all
> pages
>
> On 05/10/2015 12:05, Gael Abadin wrote:
&
not
possible?
Here is my web.xml security constraint and login config (I've also tried
ommitin ):
Protected Context
/public/login/*
CONFIDENTIAL
CLIENT-CERT
And here is my server.xml config (I've also tried clientAuth="false" and
client
nectors support renegotiation
(don't use APR).
Mark
>
> Here is my web.xml security constraint and login config (I've also tried
> ommitin ):
>
>
>
> Protected Context
> /public/login/*
>
>
> CONFIDENTIAL
>
>
>
, as provided
by Apache httpd and proxied in with AJP. The username is provided by Apache
httpd in REMOTE_USER.
In theory, changing the auth-method to CLIENT-CERT should do the trick,
but I just get forbidden.
What doesn’t seem to fit is the realm definition - specifying userCredCol
is marked
. Here's
what pops up in my quick google search:
http://stackoverflow.com/questions/5086457/setting-up-client-cert-authentication-with-roles-on-tomcat-6-0
Here's another interesting article that tackles the old version of Tomcat,
but the ideas are very similar. Here's a link:
http
://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat
I’ve already found all of these, and have trawled through them to no avail. It
appears all the information is stale.
I am currently stuck on two specific areas:
- None of the debug logging seems to work
.
In theory, changing the auth-method to CLIENT-CERT should do the trick, but I
just get forbidden.
What doesn’t seem to fit is the realm definition - specifying userCredCol is
marked as mandatory, but this is obviously not present with a client
certificate. What do you specify in this field?
Does
-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat
I’ve already found all of these, and have trawled through them to no
avail. It appears all the information is stale.
Yes, indeed - most of the info on these pages is very stale. Once we
resolve it, we should add a nice article about
On 28 April 2014 04:05:35 GMT+01:00, Gary Briggs chu...@icculus.org wrote:
In short: What's the best way to configure ciphers, matching in tomcat
and openssl, to get widest browser compatability without sacrificing
security?
Check configuration with https://www.ssllabs.com/ssltest/
Mark
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gary,
On 4/27/14, 11:05 PM, Gary Briggs wrote:
In short: What's the best way to configure ciphers, matching in
tomcat and openssl, to get widest browser compatability without
sacrificing security?
In long: I'm running tomcat with
In short: What's the best way to configure ciphers, matching in tomcat
and openssl, to get widest browser compatability without sacrificing security?
In long: I'm running tomcat with client-certificate authentication behind
a proxy made by F5 [LTM, Local Traffic Manager, is the specific product].
Hi all,
I am upgrading from Tomcat 6.0.18 to 7.0.21 (32-bit Win zip).
Previously, when requesting a client certificate I would use:
X509Certificate[] certs =
(X509Certificate[])req.getAttribute(javax.net.ssl.peer_certificates);
However, after upgrading to 7.0.21 this no longer works. Instead
On 14/10/2011 18:47, Bryant Panyarachun wrote:
Hi all,
I am upgrading from Tomcat 6.0.18 to 7.0.21 (32-bit Win zip).
Previously, when requesting a client certificate I would use:
X509Certificate[] certs =
(X509Certificate[])req.getAttribute(javax.net.ssl.peer_certificates);
However,
From: Mark Thomas [mailto:ma...@apache.org]
Subject: Re: Cannot retrieve client cert when requesting
javax.net.ssl.peer_certificates
I don't see that parameter anywhere in the servlet specification.
It was in the 2.1 spec for ServletRequest, but seems to have disappeared
somewhere along
Right, I have only been able to find a reference to it in the 2.1 servlet
specification as well.
On Fri, Oct 14, 2011 at 12:27 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: Mark Thomas [mailto:ma...@apache.org]
Subject: Re: Cannot retrieve client cert when requesting
In web.xml of a war file I’m forcing ssl to be used for a particular servlet.
Tomcat has been configured for client authentication.
!-- Force SSL for entire site --
security-constraint
web-resource-collection
web-resource-nameRUSA
), but it does not seem to be sending the personal certificate.
thanks
Kannan
--- On Fri, 4/2/11, Christopher Schultz ch...@christopherschultz.net wrote:
From: Christopher Schultz ch...@christopherschultz.net
Subject: Re: CLIENT-CERT configuration doesn't work for servlet.
To: Tomcat Users List
-constraint*
* ***
* **/**security-constraint*
* *
* login-config*
* **!-- auth-methodBASIC/auth-method --***
* auth-methodCLIENT-CERT**/**auth-method*
* realm-namewebservice** /**realm-name
*
* **/**user-data-constraint*
* ***
* **/**security-constraint*
* *
* login-config*
* **!-- auth-methodBASIC/auth-method --***
* auth-methodCLIENT-CERT**/**auth-method*
* realm-name
--***
* auth-methodCLIENT-CERT**/**auth-method*
* realm-namewebservice** /**realm-name*
* **/**login-config*
* *
* security-role*
* role-namewebservice**/**role-name*
* **/**security-role
SSLCipherSuite=AES128-SHA:DES-CBC3-SHA
SSLCACertificateFile=C:\usr-files\client-cert-ca.crt /
On 13 November 2010 00:38, Mark Thomas ma...@apache.org wrote:
On 12/11/2010 16:27, Goo Sam Kong wrote:
Hi
I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.
APR/native connector
\client-cert-ca.crt
SSLCertificateFile=C:\usr\tomcat\tomcat.crt
SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key
SSLCipherSuite=AES128-SHA:DES-CBC3-SHA SSLEnabled=true
SSLEngine=on
SSLVerifyClient=optional maxThreads=150 port=8443
protocol=HTTP/1.1 scheme
On 12/11/2010 16:27, Goo Sam Kong wrote:
Hi
I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.
APR/native connector version? SSL re-negotiation wasn't supported until
recently and the CVE-2009-3555 fixes further complicate things.
Connector SSLCACertificateFile=C:\usr-files\client
Thanks again Mark,
I think it will be difficult to move to Tomcat 6 soon. If I change mod_proxy
to mod_jk, does mod_jk passes the client cert to Tomcat 5.5?
Thank you,
Andre
Mark Thomas wrote:
On 22/04/2010 20:00, acastanheira2001 wrote:
Thanks Mark,
I use mod_proxy (ProxyPass
-Original Message-
From: acastanheira2001
Sent: Monday, April 26, 2010 8:35
Subject: Re: Client cert authentication
Thanks again Mark,
I think it will be difficult to move to Tomcat 6 soon. If I
change mod_proxy to mod_jk, does mod_jk passes the client
cert to Tomcat 5.5
Thanks Mark,
I use mod_proxy (ProxyPass and ProxyReverse) to connect Apache (2.2.3) to
Tomcat(5.5)/Jboss (4.2). Can mod_proxy pass client cert to Tomcat?
I use the following code to get the client cert, but certs object is null:
public void verificaCertCliente(HttpServletRequest req) throws
On 22/04/2010 20:00, acastanheira2001 wrote:
Thanks Mark,
I use mod_proxy (ProxyPass and ProxyReverse) to connect Apache (2.2.3) to
Tomcat(5.5)/Jboss (4.2). Can mod_proxy pass client cert to Tomcat?
With 5.5.x, not with out some custom code. With 6.0.x, yes.
You'd need to port
Hi,
I have an apache server in front of Tomcat/Jboss, the former receives the
client cert and does revocation list and trust validation.
I need to pass the client cert to Tomcat only to check the SubjectAltNames.
As far as trust accreditation is done by apache, does Tomcat need to have
On 19/04/2010 13:05, acastanheira2001 wrote:
Hi,
I have an apache server in front of Tomcat/Jboss, the former receives the
client cert and does revocation list and trust validation.
I need to pass the client cert to Tomcat only to check the SubjectAltNames.
As far as trust
: Tue, 23 Feb 2010 15:07:03 -0800
Subject: Re: Trouble with CLIENT-CERT authentication method
From: kevmacmi...@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
-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
On 24/02/2010 15:03, Christopher Schultz wrote:
So, settingauth-method to CLIENT-CERT triggers an SSL renegotiation.
What if theConnector is set to clientAuth=want or
clientAuth=true? Will the initial SSL negotiation carry the client
certificate and therefore avoid CVE-2009-355?
Yes
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
-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
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
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
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
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
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
-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
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
, 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
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,
1 - 100 of 137 matches
Mail list logo
