Re: Client cert auth on demand

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

Re: Client cert auth on demand

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

Re: Client cert auth on demand

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

Re: Client cert auth on demand

Am 2020-02-29 um 15:12 schrieb Mark Thomas: On 29/02/2020 13:05, Thomas Meyer wrote: Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : On 29/02/2020 11:23, Michael Osipov wrote: Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05

Re: Client cert auth on demand

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

Re: Client cert auth on demand

On 29/02/2020 13:05, Thomas Meyer wrote: > Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : >> On 29/02/2020 11:23, Michael Osipov wrote: >>> Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: > Am 2020-02-29 um 12:05 schrieb Mark Thomas: >> On

Re: Client cert auth on demand

Am 2020-02-29 um 14:05 schrieb Thomas Meyer: Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : On 29/02/2020 11:23, Michael Osipov wrote: Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:4

Re: Client cert auth on demand

Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : >On 29/02/2020 11:23, Michael Osipov wrote: >> Am 2020-02-29 um 12:13 schrieb Mark Thomas: >>> 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: >>> >>>

Re: Client cert auth on demand

On 29/02/2020 11:23, Michael Osipov wrote: > Am 2020-02-29 um 12:13 schrieb Mark Thomas: >> 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 context

Re: Client cert auth on demand

Am 2020-02-29 um 12:13 schrieb Mark Thomas: 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. If you specify CLIEN

Re: Client cert auth on demand

Am 2020-02-29 um 12:13 schrieb Mark Thomas: 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. If you specify CLIEN

Re: Client cert auth on demand

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. >> >> If you specify CLIENT-CERT auth for a sub-set of

Re: Client cert auth on demand

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 f

Re: Client cert auth on demand

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 for rest api calls > > This wi

Re: Client cert auth on demand

Am 2020-02-29 um 10:09 schrieb Thomas Meyer: Am 27. Februar 2020 10:58:01 MEZ schrieb "Martynas Jusevičius" : Hi list, I'm using a Docker image based on tomcat:8.0-jre8. It serves as an end-user facing webapp but also as a REST API which authenticates using client certificates. The same URLs s

Re: Client cert auth on demand

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

Re: Client cert auth on demand

Am 27. Februar 2020 10:58:01 MEZ schrieb "Martynas Jusevičius" : >Hi list, > >I'm using a Docker image based on tomcat:8.0-jre8. It serves as an >end-user facing webapp but also as a REST API which authenticates >using client certificates. The same URLs serve both purposes, however >only administr

Re: Client cert auth on demand

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

Re: Client cert auth on demand

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

Re: Client cert auth on demand

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/docs/http/ngx_http_upstream_module.html As I understand it j

Re: Client cert auth on demand

Tomcat is deep within the Docker image configured with a single connector and a single ROOT webapp, so it's easier to deploy a second container than to add a second connector or context :) Thanks for your help. On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas wrote: > > On 27/02/2020 10:28, Martyna

Re: Client cert auth on demand

On 27/02/2020 10:28, Martynas Jusevičius wrote: > Yes, that could be an option. Or, since we're on Docker, a second > instance of the webapp on a different port would be easier. > > But we would need to add some URL rewriting proxy before that > connector to strip that port number to make the weba

Re: Client cert auth on demand

Yes, that could be an option. Or, since we're on Docker, a second instance of the webapp on a different port would be easier. But we would need to add some URL rewriting proxy before that connector to strip that port number to make the webapp see the canonical URLs. That should be doable with ngin

Re: Client cert auth on demand

On 27/02/2020 09:58, Martynas Jusevičius wrote: > Hi list, > > I'm using a Docker image based on tomcat:8.0-jre8. It serves as an > end-user facing webapp but also as a REST API which authenticates > using client certificates. The same URLs serve both purposes, however > only administrators are us

RE: Client Cert TLS issue

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

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

RE: Client Cert TLS issue

: 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

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, >> >> I would need some help with tracking an issue with TC 8.5.47 (windows x64,

RE: Client Cert TLS issue

tStore" to explicitly point to cacerts and hit it with curl -k https://localhost:8443/ George -Original Message- From: Christopher Schultz Sent: Wednesday, October 16, 2019 1:16 PM To: users@tomcat.apache.org Subject: Re: Client Cert TLS issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA2

Re: Client Cert TLS issue

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

RE: Client Cert TLS issue

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

Re: Client Cert TLS issue

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

Re: Client-CERT SSLVerifyClient=none does not seem to work .. any suggestion for debugging?

Thank you for your response. Perhaps I was not clear.. what I really want to do is to have Client authentication only for the particular path (/Authn/X509). But it does not seem to kick in and I am wondering if there is any suggestion for troubleshooting. -Vivien On Thu, Aug 29, 2019 at 12:48 AM

Re: Client-CERT SSLVerifyClient=none does not seem to work .. any suggestion for debugging?

On 28/08/2019 23:09, Vivien Wu wrote: > Tomcat version: 8.5.14 > OS: debian 9 (stretch) > Issues: If using SSLVerifyClient=optional, it seems to work (log attached, > assuming config is validated); > however when trying to use SSLVerifyClient=none, the browser complains > > This site can’t provid

Re: Client-cert, ciphers, and proxies

-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

Re: Client-cert, ciphers, and proxies

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

Re: CLIENT-CERT configuration doesn't work for servlet.

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

Re: CLIENT-CERT configuration doesn't work for servlet.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kannan, On 2/3/2011 2:20 PM, Kannan J wrote: > 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. > > > > > RUSA Authentication > /ClientCertSignServlet >

RE: Client cert authentication

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

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? Thank you, Andre Mark Thomas wrote: > > On 22/04/2010 20:00, acastanheira2001 wrote: >> >> Thanks Mark, >> >> I use mod_proxy (Proxy

Re: Client cert authentication

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 this to

Re: Client cert authentication

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 Ser

Re: Client cert authentication

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 acc

Re: Client Cert

Hi, You mean Interesting link (\me writes down) But in that case, what you do is basically do is provide the user with a tool to extract his cert from a Windows keystore and then upload the cert to the server over an open connection. This is perfectly all rig

Re: Client Cert

I have founded one way to do what I want I have used the JCAPI lib (www.phoex.com) in an applet So, now the user can choose the cert to send to server. It works on Windows keystore. On 2/17/06, David Tonhofer, m-plify S.A. <[EMAIL PROTECTED]> wrote: > --On Friday, February 17, 2006 2:01 PM -0300

Re: Client Cert

--On Friday, February 17, 2006 2:01 PM -0300 Luis Henrique <[EMAIL PROTECTED]> wrote: I dont care about the session security. I just want to associate the broser user with one in my database. For this a need to get his cert. You *can* set up HTTPS then drop to NULL encryption :-P To get the

Re: Client Cert

I dont care about the session security. I just want to associate the broser user with one in my database. For this a need to get his cert. On 2/17/06, Duan, Nick <[EMAIL PROTECTED]> wrote: > What do you want to accomplish? SSL is the only (I mean one that is > established) way to ensure a secure

RE: Client Cert

What do you want to accomplish? SSL is the only (I mean one that is established) way to ensure a secure session. ND -Original Message- From: Luis Henrique [mailto:[EMAIL PROTECTED] Sent: Friday, February 17, 2006 10:11 AM To: users@tomcat.apache.org Subject: Client Cert Is there anywa