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 FINE
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 https%3A//local
: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 conf
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 co
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
enf
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
enf
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 security const
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 client cert o
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
). 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
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
ng
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:
> https://nginx.org/en/d
e both purposes, however
> > >>> 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.
> > >&g
ere
> >>> 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 fo
e run from 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
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
t 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 cli
nfusing 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 accepti
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 ca
: 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.trus
-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
>> tcnative-1.
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 eith
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 eithe
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
t 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, O
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.
> https://j
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 certifica
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 over http o
ire a valid certificate
>>> chain from the client before accepting a connection. Set to want 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 certi
lse 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
>> per-use
esource 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="false" and relying on &qu
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
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 but
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 looki
-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 the
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 .
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 already
e 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 not showing up on cloned
> > deploym
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
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="
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
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 pages but demand SSL in all
> pages
>
> On 05/10/2015 12:05, Gael Aba
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 ce
which connectors 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
&g
t 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&q
> 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
mcat,
> 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 stu
t; Try doing some online searching for the type of errors you got. 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 t
gt; I need to switch basic authentication to client certificates, 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.
&
.
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
-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 client-c
On 28 April 2014 04:05:35 GMT+01:00, 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?
Check configuration with https://www.ssllabs.com/ssltest/
Mark
--
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]
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 retriev
> 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 disap
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");
>
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
suing CA I have added to the truststore on
tomcat), but it does not seem to be sending the personal certificate.
thanks
Kannan
--- On Fri, 4/2/11, Christopher Schultz wrote:
From: Christopher Schultz
Subject: Re: CLIENT-CERT configuration doesn't work for servlet.
To: "Tomcat Users L
/ClientCertSignServlet
>
>
> CONFIDENTIAL
>
>
>
>
> CLIENT-CERT
> Client Cert Users-only Area
>
>
> When I try to access the servlet (using http url) , it immediately
> returns 302 permanently moved. It is supposed to ask the user to ch
CONFIDENTIAL
CLIENT-CERT
Client Cert Users-only Area
When I try to access the servlet (using http url) , it immediately returns 302
permanently moved. It is supposed to ask the user to choose a certificate from
the list of available certificates in the
**<**http-method**>**POST*
> >
> > * *
> >
> > * ***
> >
> > * **<**auth-constraint**>***
> >
> > ***<**role-name**>**webservice*
> >
> > * *****
&
*
>
> * ***
>
> * **<**user-data-constraint**>***
>
> * **<**transport-guarantee**>**CONFIDENTIAL** transport-guarantee**>***
>
> * *
>
> * ***
>
> * *
>
> * *
>
> * **<**login-config**>***
&g
**<**role-name**>**webservice*
* *
* ***
* **<**user-data-constraint**>***
* **<**transport-guarantee**>**CONFIDENTIAL*
* *
* ***
* *
* *
* **<**login-config**>***
*
Hi Mark,
Thank you for the settings. I am not sure what is the APR/native connector
version, I am using the default APR/native connector in 6.0.29 (I do not
set/change APR on my Windows machine).
I am not sure why the client certificate authentication failed when my
client certificate was signed
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.
> SSLCertificateFile="C:\usr\tomcat\to
Hi
I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.
I changed server.xml as below.
> -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_j
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,
>
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'
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 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.
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 a
On 24/02/2010 15:03, Christopher Schultz wrote:
So, setting to CLIENT-CERT triggers an SSL renegotiation.
What if the is set to clientAuth="want" or
clientAuth="true"? Will the initial SSL negotiation carry the client
certificate and therefore avoid CVE-2009-355?
Yes. B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin,
On 2/23/2010 6:07 PM, Kevin Mills wrote:
> On 2/19/10, Christopher Schultz wrote:
>> So, with clientAuth="false", how do you get a client certificate to use
>> for authentication? Or, does the presence of the CLIENT-C
bilité
pour le contenu fourni.
> Date: 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 wrote:
> > So, with clientAuth="false", h
On 2/19/10, Christopher Schultz 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.
>>> 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
On 2/19/10, Christopher Schultz 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 c
On 2/18/10, Christopher Schultz 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 pe
-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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin,
On 2/17/2010 7:24 PM, Kevin Mills wrote:
> Sure thing - here is my Connector element:
>
> maxThreads="50" scheme="https" secure="true"
>keystoreFile=".../tomcat.keystore" keystorePass="..."
>
On 18/02/2010 16:30, Kevin Mills wrote:
> On 2/17/10, Mark Thomas 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
> (allowUnsafeLegacy
On 2/17/10, Mark Thomas 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-i
Everything
> /*
>
>
> X509
>
>
> CONFIDENTIAL
>
>
>
> CLIENT-CERT
>
>
> which requires it for everything.
That seems to do the trick
1 - 100 of 144 matches
Mail list logo
