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 [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add rule with
pattern ^(.*)(localhost\%3A5443)(.*)$ and substitution $1localhost$3
01-Mar-2020 21:12:49.155 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add condition
localhost%3A5443 test %{QUERY_STRING} to rule with pattern
^(.*)(localhost\%3A5443)(.*)$ and substitution $1localhost$3
On Mon, Mar 2, 2020 at 11:51 AM Martynas Jusevičius
wrote:
>
> 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 only log output I get is:
>
> 01-Mar-2020 18:45:50.647 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [INITIALIZING]
> 01-Mar-2020 18:45:50.650 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [INITIALIZED]
> 01-Mar-2020 18:45:50.651 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [STARTING_PREP]
> 01-Mar-2020 18:45:50.652 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTING]
> 01-Mar-2020 18:45:50.654 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTED]
>
>
>
> On Sun, Mar 1, 2020 at 2:15 PM Martynas Jusevičius
> wrote:
> >
> > 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//localhost/ (remove the port
> > number).
> >
> > RewriteValve seems to do what I need:
> > https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
> >
> > I have mounted the following under
> > /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
> >
> >
> >
> >
> >
> >
> > and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
> >
> > RewriteCond %{QUERY_STRING} localhost%3A5443
> > RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
> >
> > However I'm not seeing any output re. RewriteValve in the Tomcat log.
> > The rewrite is not happening and it doesn't look like the config is
> > even read.
> >
> > On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
> > wrote:
> > >
> > > 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 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
> > > >
> > > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > > > instance. That should do the trick.
> > > >
> > > > Mark
> > > >
> > > >
> > > > >
> > > > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > > > where the clients access them, therefore the host name the webapp sees
> > > > > is localhost (as in my rewrite example).
> > > > >
> > > > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > > > thinking it's being accessed on localhost:80/443 instead of
> > > > > localhost:90/5443.
> > > > >
> > > > > Absolute URIs matter in this case because they are used for direct
> > > > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > > > >
> > > > >
> > > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote:
> > > > >>
> > > > >> 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
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 only log output I get is:
01-Mar-2020 18:45:50.647 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[INITIALIZING]
01-Mar-2020 18:45:50.650 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[INITIALIZED]
01-Mar-2020 18:45:50.651 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[STARTING_PREP]
01-Mar-2020 18:45:50.652 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTING]
01-Mar-2020 18:45:50.654 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTED]
On Sun, Mar 1, 2020 at 2:15 PM Martynas Jusevičius
wrote:
>
> 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//localhost/ (remove the port
> number).
>
> RewriteValve seems to do what I need:
> https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
>
> I have mounted the following under
> /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
>
>
>
>
>
>
> and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
>
> RewriteCond %{QUERY_STRING} localhost%3A5443
> RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
>
> However I'm not seeing any output re. RewriteValve in the Tomcat log.
> The rewrite is not happening and it doesn't look like the config is
> even read.
>
> On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
> wrote:
> >
> > 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 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
> > >
> > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > > instance. That should do the trick.
> > >
> > > Mark
> > >
> > >
> > > >
> > > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > > where the clients access them, therefore the host name the webapp sees
> > > > is localhost (as in my rewrite example).
> > > >
> > > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > > thinking it's being accessed on localhost:80/443 instead of
> > > > localhost:90/5443.
> > > >
> > > > Absolute URIs matter in this case because they are used for direct
> > > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > > >
> > > >
> > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote:
> > > >>
> > > >> 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/docs/http/ngx_http_upstream_module.html
> > > >>>
> > > >>> As I understand it just forwards raw traffic, so the URL rewriting
> > > >>> would have to be done on the Tomcat's side. Basically I want to
> > > >>> rewrite:
> > > >>>
> > > >>> https://localhost:5443/ => https://localhost/
> > > >>>
> > > >>> which requires rewriting the Host request header, I think.
> > > >>>
> > > >>> I was looking at the RewriteValve, but it says:
> > > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > > >>> automatically support absolute URLs (the specific redirect flag must
> > > >>> be used to be able to specify an absolute URLs, see below) or direct
> > > >>> file serving."
> > > >>>
> > > >>> Is there a way to rewrite the hostname/port in configuration?
> > > >>> Something placed in context.xml would be ideal.
> > > >>
> > > >>
> > > >> What port is
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//localhost/ (remove the port
number).
RewriteValve seems to do what I need:
https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
I have mounted the following under
/usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
RewriteCond %{QUERY_STRING} localhost%3A5443
RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
However I'm not seeing any output re. RewriteValve in the Tomcat log.
The rewrite is not happening and it doesn't look like the config is
even read.
On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
wrote:
>
> 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 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
> >
> > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > instance. That should do the trick.
> >
> > Mark
> >
> >
> > >
> > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > where the clients access them, therefore the host name the webapp sees
> > > is localhost (as in my rewrite example).
> > >
> > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > thinking it's being accessed on localhost:80/443 instead of
> > > localhost:90/5443.
> > >
> > > Absolute URIs matter in this case because they are used for direct
> > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > >
> > >
> > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote:
> > >>
> > >> 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/docs/http/ngx_http_upstream_module.html
> > >>>
> > >>> As I understand it just forwards raw traffic, so the URL rewriting
> > >>> would have to be done on the Tomcat's side. Basically I want to
> > >>> rewrite:
> > >>>
> > >>> https://localhost:5443/ => https://localhost/
> > >>>
> > >>> which requires rewriting the Host request header, I think.
> > >>>
> > >>> I was looking at the RewriteValve, but it says:
> > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > >>> automatically support absolute URLs (the specific redirect flag must
> > >>> be used to be able to specify an absolute URLs, see below) or direct
> > >>> file serving."
> > >>>
> > >>> Is there a way to rewrite the hostname/port in configuration?
> > >>> Something placed in context.xml would be ideal.
> > >>
> > >>
> > >> What port is nginx listening on?
> > >>
> > >> What port is Tomcat listening on?
> > >>
> > >> I assume the client connects directly to nginx.
> > >>
> > >> Mark
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > >> For additional commands, e-mail: users-h...@tomcat.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 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 even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark, this makes me wonder whether Tomcat properly implements RFC 7540, section 9.2.1 and RFC 8740, section 3. From my understanding the configuration you have described MUST fail here. Those aspects of those specs are implemented correctly. Authentication will fail for both HTTP/2 and TLS 1.3 if a web application level security constraint tries to trigger renegotiation. For HTTP/2 and/or TLS 1/3 you can only configure client certificate authentication on the Connector. Hi, Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3 For HTTP/2, yes because of the multiplexing. HTTP/2 explicitly prohibits renegotiation. For TLS 1.3 there is post handshake authentication but the JSSE implementation doesn't support that. However... If NIO/NIO2 is used with OpenSSL or if the APR/Native Connector is used then post-handshake authentication is supported for TLS 1.3 and CLIENT-CERT auth triggered by security constraints works as expected. But I hope this only applies to HTTP/1.1, does it? Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this > instance. That should do the trick. > > Mark > > > > > > nginx and nginx-api ports are exposed to the Docker host and that is > > where the clients access them, therefore the host name the webapp sees > > is localhost (as in my rewrite example). > > > > What I'm trying to do is to fool the webapp on tomcat-api into > > thinking it's being accessed on localhost:80/443 instead of > > localhost:90/5443. > > > > Absolute URIs matter in this case because they are used for direct > > lookups in an RDF triplestore and RDF uses absolute URIs. > > > > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote: > >> > >> 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/docs/http/ngx_http_upstream_module.html > >>> > >>> As I understand it just forwards raw traffic, so the URL rewriting > >>> would have to be done on the Tomcat's side. Basically I want to > >>> rewrite: > >>> > >>> https://localhost:5443/ => https://localhost/ > >>> > >>> which requires rewriting the Host request header, I think. > >>> > >>> I was looking at the RewriteValve, but it says: > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not > >>> automatically support absolute URLs (the specific redirect flag must > >>> be used to be able to specify an absolute URLs, see below) or direct > >>> file serving." > >>> > >>> Is there a way to rewrite the hostname/port in configuration? > >>> Something placed in context.xml would be ideal. > >> > >> > >> What port is nginx listening on? > >> > >> What port is Tomcat listening on? > >> > >> I assume the client connects directly to nginx. > >> > >> Mark > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 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 even on those contexts which do not require >> authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can >> require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. >>> >>> Mark, >>> >>> this makes me wonder whether Tomcat properly implements RFC 7540, >>> section 9.2.1 and RFC 8740, section 3. From my understanding the >>> configuration you have described MUST fail here. >> >> Those aspects of those specs are implemented correctly. Authentication >> will fail for both HTTP/2 and TLS 1.3 if a web application level >> security constraint tries to trigger renegotiation. >> >> For HTTP/2 and/or TLS 1/3 you can only configure client certificate >> authentication on the Connector. > > Hi, > > Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on > http2 or something in tls1.3, or asked the oth way around, will it fail only > for http2 && tls1.3 or for http2 || tls1.3 For HTTP/2, yes because of the multiplexing. HTTP/2 explicitly prohibits renegotiation. For TLS 1.3 there is post handshake authentication but the JSSE implementation doesn't support that. However... If NIO/NIO2 is used with OpenSSL or if the APR/Native Connector is used then post-handshake authentication is supported for TLS 1.3 and CLIENT-CERT auth triggered by security constraints works as expected. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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: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 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 even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark, this makes me wonder whether Tomcat properly implements RFC 7540, section 9.2.1 and RFC 8740, section 3. From my understanding the configuration you have described MUST fail here. Those aspects of those specs are implemented correctly. Authentication will fail for both HTTP/2 and TLS 1.3 if a web application level security constraint tries to trigger renegotiation. For HTTP/2 and/or TLS 1/3 you can only configure client certificate authentication on the Connector. Hi, Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3 I recently made some research on the toptic for work. As far as I understand there is no renogotiation in TLS 1.3 anymore. It has been replaced with PHA (post-handshake authentication). Because of, as you properly noticed, parallel streams you'd suffer from race conditions if one stream for a URL would request PHA and another won't. Here is a very helpful read: https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0001.html So doing VerifyClient require is unusable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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: >>> >>> >>> >> 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 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 even on those contexts which do not require >authentication?! >>> >>> If you required auth on the connector it always applies. >>> >>> However, if you don't require it at the connector level you can >require >>> it for a subset of URLs with security constraints and Tomcat will >>> trigger any required renegotiations. >> >> Mark, >> >> this makes me wonder whether Tomcat properly implements RFC 7540, >> section 9.2.1 and RFC 8740, section 3. From my understanding the >> configuration you have described MUST fail here. > >Those aspects of those specs are implemented correctly. Authentication >will fail for both HTTP/2 and TLS 1.3 if a web application level >security constraint tries to trigger renegotiation. > >For HTTP/2 and/or TLS 1/3 you can only configure client certificate >authentication on the Connector. Hi, Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3 > >Mark > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 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 even on those contexts which do not require authentication?! >> >> If you required auth on the connector it always applies. >> >> However, if you don't require it at the connector level you can require >> it for a subset of URLs with security constraints and Tomcat will >> trigger any required renegotiations. > > Mark, > > this makes me wonder whether Tomcat properly implements RFC 7540, > section 9.2.1 and RFC 8740, section 3. From my understanding the > configuration you have described MUST fail here. Those aspects of those specs are implemented correctly. Authentication will fail for both HTTP/2 and TLS 1.3 if a web application level security constraint tries to trigger renegotiation. For HTTP/2 and/or TLS 1/3 you can only configure client certificate authentication on the Connector. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark, this makes me wonder whether Tomcat properly implements RFC 7540, section 9.2.1 and RFC 8740, section 3. From my understanding the configuration you have described MUST fail here. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. I wasn't aware of that. Thank you for the enlightment! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 for rest api calls This will not help. In this case that appears to be correct although it isn't generally correct. You cannot configure cert-based auth from the context.xml. True. You do that in web.xml. 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 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 even on those contexts which do not require authentication?! M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 will not help. In this case that appears to be correct although it isn't generally correct. > You cannot configure cert-based auth from the > context.xml. True. You do that in web.xml. > 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 you have in httpd but you can replicate the typical use cases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 serve 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. 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 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 :) But I guess that's not how TLS works... Any ideas? Thanks. Martynas atomgraph.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 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 will not help. You cannot configure cert-based auth from the context.xml. Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 > nginx-api:90 -> tomcat-api:8080 > nginx-api:5443 -> tomcat-api:8443 Try using proxyPort="5443" on the HTTPS connector in Tomcat for this instance. That should do the trick. Mark > > nginx and nginx-api ports are exposed to the Docker host and that is > where the clients access them, therefore the host name the webapp sees > is localhost (as in my rewrite example). > > What I'm trying to do is to fool the webapp on tomcat-api into > thinking it's being accessed on localhost:80/443 instead of > localhost:90/5443. > > Absolute URIs matter in this case because they are used for direct > lookups in an RDF triplestore and RDF uses absolute URIs. > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote: >> >> 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/docs/http/ngx_http_upstream_module.html >>> >>> As I understand it just forwards raw traffic, so the URL rewriting >>> would have to be done on the Tomcat's side. Basically I want to >>> rewrite: >>> >>> https://localhost:5443/ => https://localhost/ >>> >>> which requires rewriting the Host request header, I think. >>> >>> I was looking at the RewriteValve, but it says: >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not >>> automatically support absolute URLs (the specific redirect flag must >>> be used to be able to specify an absolute URLs, see below) or direct >>> file serving." >>> >>> Is there a way to rewrite the hostname/port in configuration? >>> Something placed in context.xml would be ideal. >> >> >> What port is nginx listening on? >> >> What port is Tomcat listening on? >> >> I assume the client connects directly to nginx. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 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 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 :) But I guess >that's not how TLS works... > >Any ideas? Thanks. > > >Martynas >atomgraph.com > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org 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 -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 nginx and nginx-api ports are exposed to the Docker host and that is where the clients access them, therefore the host name the webapp sees is localhost (as in my rewrite example). What I'm trying to do is to fool the webapp on tomcat-api into thinking it's being accessed on localhost:80/443 instead of localhost:90/5443. Absolute URIs matter in this case because they are used for direct lookups in an RDF triplestore and RDF uses absolute URIs. On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote: > > 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/docs/http/ngx_http_upstream_module.html > > > > As I understand it just forwards raw traffic, so the URL rewriting > > would have to be done on the Tomcat's side. Basically I want to > > rewrite: > > > > https://localhost:5443/ => https://localhost/ > > > > which requires rewriting the Host request header, I think. > > > > I was looking at the RewriteValve, but it says: > > "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not > > automatically support absolute URLs (the specific redirect flag must > > be used to be able to specify an absolute URLs, see below) or direct > > file serving." > > > > Is there a way to rewrite the hostname/port in configuration? > > Something placed in context.xml would be ideal. > > > What port is nginx listening on? > > What port is Tomcat listening on? > > I assume the client connects directly to nginx. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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/docs/http/ngx_http_upstream_module.html > > As I understand it just forwards raw traffic, so the URL rewriting > would have to be done on the Tomcat's side. Basically I want to > rewrite: > > https://localhost:5443/ => https://localhost/ > > which requires rewriting the Host request header, I think. > > I was looking at the RewriteValve, but it says: > "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not > automatically support absolute URLs (the specific redirect flag must > be used to be able to specify an absolute URLs, see below) or direct > file serving." > > Is there a way to rewrite the hostname/port in configuration? > Something placed in context.xml would be ideal. What port is nginx listening on? What port is Tomcat listening on? I assume the client connects directly to nginx. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 just forwards raw traffic, so the URL rewriting would have to be done on the Tomcat's side. Basically I want to rewrite: https://localhost:5443/ => https://localhost/ which requires rewriting the Host request header, I think. I was looking at the RewriteValve, but it says: "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not automatically support absolute URLs (the specific redirect flag must be used to be able to specify an absolute URLs, see below) or direct file serving." Is there a way to rewrite the hostname/port in configuration? Something placed in context.xml would be ideal. On Thu, Feb 27, 2020 at 11:52 AM Martynas Jusevičius wrote: > > 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, 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 webapp see the > > > canonical URLs. That should be doable with nginx which we are using > > > anyway. > > > > > > So essentially 2 webapps on different ports, one configured without > > > the clientAuth for the end-users, and one with clientAuth for the API > > > access, correct? > > > > It depends on what you can / want to change. > > > > The approach you describe should work. > > > > If you can change the clients, a second Connector for the same > > Service/Engine/Host/Context is all that should be required. > > > > Depending on the URLs used, you might be able to deploy two versions of > > the web application to different Contexts, remap the internal servlets > > and still have clients see the same URLs. In that case you could move > > the client auth requirement to the web application. > > > > There are quite a few options. It really comes down to want you can > > control, and what is easiest for you to change. > > > > Mark > > > > > > > > > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas wrote: > > >> > > >> 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 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 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 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 :) But I guess > > >>> that's not how TLS works... > > >>> > > >>> Any ideas? Thanks. > > >> > > >> Can you configure a separate connector on a different port for the shell > > >> scripts to use? > > >> > > >> Mark > > >> > > >> - > > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > >> > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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, 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 webapp see the > > canonical URLs. That should be doable with nginx which we are using > > anyway. > > > > So essentially 2 webapps on different ports, one configured without > > the clientAuth for the end-users, and one with clientAuth for the API > > access, correct? > > It depends on what you can / want to change. > > The approach you describe should work. > > If you can change the clients, a second Connector for the same > Service/Engine/Host/Context is all that should be required. > > Depending on the URLs used, you might be able to deploy two versions of > the web application to different Contexts, remap the internal servlets > and still have clients see the same URLs. In that case you could move > the client auth requirement to the web application. > > There are quite a few options. It really comes down to want you can > control, and what is easiest for you to change. > > Mark > > > > > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas wrote: > >> > >> 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 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 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 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 :) But I guess > >>> that's not how TLS works... > >>> > >>> Any ideas? Thanks. > >> > >> Can you configure a separate connector on a different port for the shell > >> scripts to use? > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 webapp see the > canonical URLs. That should be doable with nginx which we are using > anyway. > > So essentially 2 webapps on different ports, one configured without > the clientAuth for the end-users, and one with clientAuth for the API > access, correct? It depends on what you can / want to change. The approach you describe should work. If you can change the clients, a second Connector for the same Service/Engine/Host/Context is all that should be required. Depending on the URLs used, you might be able to deploy two versions of the web application to different Contexts, remap the internal servlets and still have clients see the same URLs. In that case you could move the client auth requirement to the web application. There are quite a few options. It really comes down to want you can control, and what is easiest for you to change. Mark > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas wrote: >> >> 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 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 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 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 :) But I guess >>> that's not how TLS works... >>> >>> Any ideas? Thanks. >> >> Can you configure a separate connector on a different port for the shell >> scripts to use? >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 nginx which we are using anyway. So essentially 2 webapps on different ports, one configured without the clientAuth for the end-users, and one with clientAuth for the API access, correct? On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas wrote: > > 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 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 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 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 :) But I guess > > that's not how TLS works... > > > > Any ideas? Thanks. > > Can you configure a separate connector on a different port for the shell > scripts to use? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 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 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 :) But I guess > that's not how TLS works... > > Any ideas? Thanks. Can you configure a separate connector on a different port for the shell scripts to use? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 can plug in as truststore to try out the issue. George, The mailing list strips most attachments. Please open a BZ issue for this. One, that means it won't get forgotten and two you will be able to attach those cacert files so we can easily reproduce the issue you are seeing. Thanks, Mark
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 can plug in as truststore to try out the issue. George, The mailing list strips most attachments. Please open a BZ issue for this. One, that means it won't get forgotten and two you will be able to attach those cacert files so we can easily reproduce the issue you are seeing. Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Client Cert TLS issue
Thanks Mark,
I was going to try to build tcnative with debug this weekend to try to help out
but life begged to disagree...i will try to step in that code next week as
well...
Appreciate it!
George
-Original Message-
From: Mark Thomas
Sent: Sunday, October 20, 2019 2:38 PM
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,
>>
>> 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 (if I set
>> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I
>> have enabled the client side SSL trace and everything goes well until ECDH
>> key exchange (for brevity I have enabled only one TLS suite
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
>> requested. The cacerts we use is whatever comes with Azul's Java distro
>> which has ~150 entries + the custom cert for testing. The issue comes from
>> how the connector deals with trusted certs because if I reduce the cacerts
>> to contain only the test certificate, the request is being served without an
>> issue. Also if I remove the tcnative-1.dll from TC there is no issue either.
>>
>> Perhaps I am missing something. Any help is appreciated.
>
>
> This sounds like it is repeatable and that you have a system you can test
> with. On that basis here are a few things to try:
>
> 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake
> is hanging.
>
> 2. Try a binary search to try and determine if the issue is the number of
> certificates in the trust store or is caused by a specific certificate.
>
> It sounds like there might be an issue converting one or more of the trusted
> certs in the trust store to a format OpenSSL can work with.
>
>
>
> So the thread dumps didn't prove to be very useful - at least I couldn't see
> anything. I attached one of them (dump3.txt). But the trial and error in the
> binary searched proved it is not any certificate but a magic number of
> certificates in cacerts - 125 hang and 124 work. I don't know if it is a
> memory issue or buffer size issue - I tried removing and adding random certs
> around the 124/125 boundary and which one is out and in doesn't make a
> difference. I realize that a cert is rather large blob so it still could be
> memory issue with the size of the cert doesn't matter that much. In
> 8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
> tms, sr) we pass the DER-encoded certs to OpenSSL:
>
> // Pass along the DER encoded certificates of the accepted
> client
> // certificate issuers, so that their subjects can be
> presented
> // by the server during the handshake to allow the client
> choosing
> // an acceptable certificate
> for (X509Certificate caCert :
> x509TrustManager.getAcceptedIssuers()) {
> SSLContext.addClientCACertificateRaw(ctx,
> caCert.getEncoded());
> if (log.isDebugEnabled())
> log.debug(sm.getString("openssl.addedClientCaCert",
> caCert.toString()));
> }
>
> 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 can plug in as truststore to try out the issue.
>
> George
>
>
>
>>
>> George
>>
>> [1]
>>
>> > port="8443" SSLEnabled="true" maxHttpHeaderSize="8192"
>> maxThreads="150" acceptCount="100" enableLookups="false"
>> disableUploadTimeout="true"
>> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS"
>> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> keystoreType="JKS"
>> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit"
>> keyAlias="jboss" URIEncod
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,
>> 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 (if I set
>> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I
>> have enabled the client side SSL trace and everything goes well until ECDH
>> key exchange (for brevity I have enabled only one TLS suite
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
>> requested. The cacerts we use is whatever comes with Azul's Java distro
>> which has ~150 entries + the custom cert for testing. The issue comes from
>> how the connector deals with trusted certs because if I reduce the cacerts
>> to contain only the test certificate, the request is being served without an
>> issue. Also if I remove the tcnative-1.dll from TC there is no issue either.
>>
>> Perhaps I am missing something. Any help is appreciated.
>
>
> This sounds like it is repeatable and that you have a system you can test
> with. On that basis here are a few things to try:
>
> 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake
> is hanging.
>
> 2. Try a binary search to try and determine if the issue is the number of
> certificates in the trust store or is caused by a specific certificate.
>
> It sounds like there might be an issue converting one or more of the trusted
> certs in the trust store to a format OpenSSL can work with.
>
>
>
> So the thread dumps didn't prove to be very useful - at least I couldn't see
> anything. I attached one of them (dump3.txt). But the trial and error in the
> binary searched proved it is not any certificate but a magic number of
> certificates in cacerts - 125 hang and 124 work. I don't know if it is a
> memory issue or buffer size issue - I tried removing and adding random certs
> around the 124/125 boundary and which one is out and in doesn't make a
> difference. I realize that a cert is rather large blob so it still could be
> memory issue with the size of the cert doesn't matter that much. In
> 8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
> tms, sr) we pass the DER-encoded certs to OpenSSL:
>
> // Pass along the DER encoded certificates of the accepted
> client
> // certificate issuers, so that their subjects can be
> presented
> // by the server during the handshake to allow the client
> choosing
> // an acceptable certificate
> for (X509Certificate caCert :
> x509TrustManager.getAcceptedIssuers()) {
> SSLContext.addClientCACertificateRaw(ctx,
> caCert.getEncoded());
> if (log.isDebugEnabled())
> log.debug(sm.getString("openssl.addedClientCaCert",
> caCert.toString()));
> }
>
> 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 can plug in as truststore to try out the issue.
>
> George
>
>
>
>>
>> George
>>
>> [1]
>>
>> > port="8443" SSLEnabled="true" maxHttpHeaderSize="8192"
>> maxThreads="150" acceptCount="100" enableLookups="false"
>> disableUploadTimeout="true"
>> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS"
>> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> keystoreType="JKS"
>> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit"
>> keyAlias="jboss" URIEncoding="UTF-8" useServerCipherSuitesOrder="true"
>> ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>> TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
>> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
>>
RE: Client Cert TLS issue
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.trustStore" 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: 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.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 (if I set the >> HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I >> have enabled the client side SSL trace and everything goes well until >> ECDH key exchange (for brevity I have enabled only one TLS suite >> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs >> if requested. The cacerts we use is whatever comes with Azul's Java >> distro which has ~150 entries + the custom cert for testing. The >> issue comes from how the connector deals with trusted certs because >> if I reduce the cacerts to contain only the test certificate, the >> request is being served without an issue. >> Also if I remove the tcnative-1.dll from TC there is no issue either. >> >> Perhaps I am missing something. Any help is appreciated. > > This sounds like it is repeatable and that you have a > system you can test with. On that basis here are a few things to > try: > > 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS > handshake is hanging. > > 2. Try a binary search to try and determine if the issue is the number > of certificates in the trust store or is caused by a specific > certificate. > > It sounds like there might be an issue converting one or more of the > trusted certs in the trust store to a format OpenSSL can work with. > > > > So the thread dumps didn't prove to be very useful - at least I > couldn't see anything. Me, either. Can you try again using: pollerThreadCount="1" and acceptorThreadCount="1" on your to see if that changes anything? Do you notice a spike in CPU when the connection hangs? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2nbIYACgkQHPApP6U8 pFguXQ//cFd9lOb665cZRC68AB/0p869DBPRN9Cie8EALUgHicYSdEiRCWAUofuJ MZx8/Sds3mrB965nmfcNLWRQBBkDqVRrN39yqOMumAZeohZq9phUbGT8chsdHD8C tI8T96bEvKIlOtHoWK9qIYoEKZQ0nKotc0Rz49xZXTNmHmIred4nmR5fCQG4R5qD xoqXOo5wui3aN7y9VBk+sWBQh0HGpOXvGAHaQ2NbSKE6VTitiiEM92n6Dkz60wnG QbK2KrflW5E36NdVwNvFkqR/H3WVCrABBJ6puGHAL3nmlhg/n+MTpyqd7nkg1WSU j1U+hqxN4EHPlTcBUtaeb6DriwaQUIHNMH3h0J8H/UyfvoIRVPA570LF5Cycj7oK zlVgVmsZIZjIzt+qP6xzKkvhXzPLpemIOheDOZO4opgPdHIXGPAI9XVzwrARxMfv KeqyA16XrU6pM7GKvkDEnSDiMye/pPGbq/U3mnYdlRs4Lwn9PvmnzBasSXbrsg6i qeU1v6lSWPx18/9Qq1Qyfjxfgu3SkBpvHypwdv3MNMBk6Y2Gp/pg917FyqfNvoxX l0TaIYYf5xL6bHsxj1uopUoCnl4KxaTAaQ3qYg4+hFO3nzDNTB1k+Xu+pbuePr3U CyaIdmM3sqN7fNIwbfQ1slXrckavl+z/ZZmTZn2zIfa1yeMmP4s= =vkfG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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.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 (if I set the >> HttpsURLConnection#setConnectTimeout(0) and >> ...#setReadTimeout(0)). I have enabled the client side SSL trace >> and everything goes well until ECDH key exchange (for brevity I >> have enabled only one TLS suite >> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug >> logs if requested. The cacerts we use is whatever comes with >> Azul's Java distro which has ~150 entries + the custom cert for >> testing. The issue comes from how the connector deals with >> trusted certs because if I reduce the cacerts to contain only the >> test certificate, the request is being served without an issue. >> Also if I remove the tcnative-1.dll from TC there is no issue >> either. >> >> Perhaps I am missing something. Any help is appreciated. > > This sounds like it is repeatable and that you have a > system you can test with. On that basis here are a few things to > try: > > 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS > handshake is hanging. > > 2. Try a binary search to try and determine if the issue is the > number of certificates in the trust store or is caused by a > specific certificate. > > It sounds like there might be an issue converting one or more of > the trusted certs in the trust store to a format OpenSSL can work > with. > > > > So the thread dumps didn't prove to be very useful - at least I > couldn't see anything. Me, either. Can you try again using: pollerThreadCount="1" and acceptorThreadCount="1" on your to see if that changes anything? Do you notice a spike in CPU when the connection hangs? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2nbIYACgkQHPApP6U8 pFguXQ//cFd9lOb665cZRC68AB/0p869DBPRN9Cie8EALUgHicYSdEiRCWAUofuJ MZx8/Sds3mrB965nmfcNLWRQBBkDqVRrN39yqOMumAZeohZq9phUbGT8chsdHD8C tI8T96bEvKIlOtHoWK9qIYoEKZQ0nKotc0Rz49xZXTNmHmIred4nmR5fCQG4R5qD xoqXOo5wui3aN7y9VBk+sWBQh0HGpOXvGAHaQ2NbSKE6VTitiiEM92n6Dkz60wnG QbK2KrflW5E36NdVwNvFkqR/H3WVCrABBJ6puGHAL3nmlhg/n+MTpyqd7nkg1WSU j1U+hqxN4EHPlTcBUtaeb6DriwaQUIHNMH3h0J8H/UyfvoIRVPA570LF5Cycj7oK zlVgVmsZIZjIzt+qP6xzKkvhXzPLpemIOheDOZO4opgPdHIXGPAI9XVzwrARxMfv KeqyA16XrU6pM7GKvkDEnSDiMye/pPGbq/U3mnYdlRs4Lwn9PvmnzBasSXbrsg6i qeU1v6lSWPx18/9Qq1Qyfjxfgu3SkBpvHypwdv3MNMBk6Y2Gp/pg917FyqfNvoxX l0TaIYYf5xL6bHsxj1uopUoCnl4KxaTAaQ3qYg4+hFO3nzDNTB1k+Xu+pbuePr3U CyaIdmM3sqN7fNIwbfQ1slXrckavl+z/ZZmTZn2zIfa1yeMmP4s= =vkfG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 either the client times out on read or the server times out (if I set
> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I
> have enabled the client side SSL trace and everything goes well until ECDH
> key exchange (for brevity I have enabled only one TLS suite
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
> requested. The cacerts we use is whatever comes with Azul's Java distro which
> has ~150 entries + the custom cert for testing. The issue comes from how the
> connector deals with trusted certs because if I reduce the cacerts to contain
> only the test certificate, the request is being served without an issue. Also
> if I remove the tcnative-1.dll from TC there is no issue either.
>
> Perhaps I am missing something. Any help is appreciated.
This sounds like it is repeatable and that you have a system you can test with.
On that basis here are a few things to try:
1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake is
hanging.
2. Try a binary search to try and determine if the issue is the number of
certificates in the trust store or is caused by a specific certificate.
It sounds like there might be an issue converting one or more of the trusted
certs in the trust store to a format OpenSSL can work with.
So the thread dumps didn't prove to be very useful - at least I couldn't see
anything. I attached one of them (dump3.txt). But the trial and error in the
binary searched proved it is not any certificate but a magic number of
certificates in cacerts - 125 hang and 124 work. I don't know if it is a memory
issue or buffer size issue - I tried removing and adding random certs around
the 124/125 boundary and which one is out and in doesn't make a difference. I
realize that a cert is rather large blob so it still could be memory issue with
the size of the cert doesn't matter that much. In
8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
tms, sr) we pass the DER-encoded certs to OpenSSL:
// Pass along the DER encoded certificates of the accepted
client
// certificate issuers, so that their subjects can be presented
// by the server during the handshake to allow the client
choosing
// an acceptable certificate
for (X509Certificate caCert :
x509TrustManager.getAcceptedIssuers()) {
SSLContext.addClientCACertificateRaw(ctx,
caCert.getEncoded());
if (log.isDebugEnabled())
log.debug(sm.getString("openssl.addedClientCaCert",
caCert.toString()));
}
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 can plug in as truststore to try out the issue.
George
>
> George
>
> [1]
>
> port="8443" SSLEnabled="true" maxHttpHeaderSize="8192"
> maxThreads="150" acceptCount="100" enableLookups="false"
> disableUploadTimeout="true"
> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS"
> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> keystoreType="JKS"
> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit"
> keyAlias="jboss" URIEncoding="UTF-8" useServerCipherSuitesOrder="true"
> ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
> TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA256,
> TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA,
> TLS_RSA_WITH_AES_256_CBC_SHA,
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 either the client times out on read or the server times out (if I set
> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I
> have enabled the client side SSL trace and everything goes well until ECDH
> key exchange (for brevity I have enabled only one TLS suite
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
> requested. The cacerts we use is whatever comes with Azul's Java distro which
> has ~150 entries + the custom cert for testing. The issue comes from how the
> connector deals with trusted certs because if I reduce the cacerts to contain
> only the test certificate, the request is being served without an issue. Also
> if I remove the tcnative-1.dll from TC there is no issue either.
>
> Perhaps I am missing something. Any help is appreciated.
This sounds like it is repeatable and that you have a system you can
test with. On that basis here are a few things to try:
1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS
handshake is hanging.
2. Try a binary search to try and determine if the issue is the number
of certificates in the trust store or is caused by a specific certificate.
It sounds like there might be an issue converting one or more of the
trusted certs in the trust store to a format OpenSSL can work with.
Mark
>
> George
>
> [1]
>
> port="8443" SSLEnabled="true" maxHttpHeaderSize="8192"
> maxThreads="150" acceptCount="100" enableLookups="false"
> disableUploadTimeout="true"
> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS"
> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> keystoreType="JKS"
> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit"
> keyAlias="jboss" URIEncoding="UTF-8" useServerCipherSuitesOrder="true"
> ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
> TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA256,
> TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA,
> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_SHA_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_SHA_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM, TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_CCM_8, TLS_ECDHE_ECDSA_WITH_AES_256_CCM,
> TLS_ECDHE_ECDSA_WITH_AES_256_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384" />
>
>
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 Mark Thomas wrote: > 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 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 looks like SSLVerifyClient=optional is the correct setting for you > use case. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
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 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 looks like SSLVerifyClient=optional is the correct setting for you use case. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client-cert, ciphers, and proxies
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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-certificate authentication behind a proxy made by F5 [LTM, Local Traffic Manager, is the specific product]. The LTM is basically a reverse proxy. You hand it your server's certificate and private keys, then tell it to do that SSL proxy thing. It conducts a MITM attack; listening, modifying, and watching your traffic for sketchy behaviour [Wait... why is that IRC instead of HTTP?]. Skeevy as it sounds as I've described it, I've actually so far been very happy with it. For example, rather than routing with SNAT, the proxy injects an X-Forwarded-For header into the HTTP stream; my server cannot even address/route to anything outside, but I can still configure tomcat to log the originating address, and it's still TLS end-to-end. The proxy comes with a default set of ciphers configured which resembles openssl cipher string: !SSLv2:!EXPORT:!DH:RSA+RC4:RSA+AES:RSA+DES:RSA+3DES:@SPEED I believe this string corresponds to a tomcat cipher configuration: TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_EXPORT_WITH_RC4_40_MD5, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_DES_CBC_SHA, TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA Something doesn't seem right about the above: you have an EXPORT cipher in your Tomcat list, but the OpenSSL configuration shouldn't be using that (due to !EXPORT). This works fine with IE9,10 and Chrome. But recent firefox versions don't like it, I get the error correspondong to no cypher overlap [which I presume is missing overlap between firefox and tomcat, because when the overlap is missing between tomcat and the F5, the F5 just drops the connection] I'm using the most recent Tomcat7 release right now, with the latest JDK7 release. Does anyone have any suggestions as to what set of options will go best for me, both in the openssl-based proxy, and in tomcat? Remember that the client is only contacting the F5 to negotiate the cipher. The cipher used between LTM and Tomcat is not relevant. You ought to be able to set the cipher on the Tomcat end to be one specific thing that you particularly like (and of course that is supported by LTM) and it will always use that, regardless of what the client is using. I'm surprised that LTM has a configuration that does not allow it to accept connections from recent versions of Firefox. That would seem to be a serious problem. I know that Firefox 28 can do SSL_RSA_WITH_RC4_128_SHA (as reported by ff; should be TLS_RSA_WITH_RC4_128_SHA in Java-speak and RC4-SHA in OpenSSL-speak) because I can see it connected to such a side using that cipher right now in a window I've got up. I agree with Mark: you should use Qualys's tools and perhaps something like sslscan (freely-downloadable; also available from some some Linux package-managers) to help figure out what ciphers are actually available given a particular configuration. Do you have the ability to modify the LTM's cipher configuration? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTXlp8AAoJEBzwKT+lPKRYQE8QAKjL/Bj7c/7W+kfOzrDUOb6U +clKS9hq7uJAjABTjKRW3dNh0W41W4XAkvZ4iYZaSxFcxPp8djQ7kaNaeF3qbzI6 m9kedJGJMTlA0Mq2bv82Mbq95+kJyqgmWBzecJMIoVMRMgkb1a1exAeBW4fSKGa9 Qq/ZG4dudS0CAC/cvsj0ObaoX8aWO1VC7QVGUXZlEbel2ebV7n+p9sdOZHijTlUl dfc0E4TIGNpBxi1EXrpJs8rcTpHw47y3tyPPzEQmPcO5/jqPCfp+6tkHVpTBQm1u a/T9w7ERRw5Pp5V4WNHheb6rob8CYUOrhMCuwMbdoYD7cil/HwX+WWN9OmulubGz H02NaJf/0w3OCa6c8TJA23Qkedz32AL0+BUYmDCDymzYgsAT9BhVPY+q2T7lc60T z0/VTjJTPJeC4835R5HniaQnXoXnT2bnuJxCfxgl/VFXbSV+sNq5npTOKW0HvakU n9EFiVic0RChJj2Y7L88hsa2BS2olQO6C5+Feriqg3t1yqDgFW+I7aZFU9LKf2U4 JEr4NHB9Yftns8ECZqeoGCDxjbU06TWx4vMMTLxpKtSrXiAB3HQ5WYaKWTz4FGDb FpTS4ek1MTxLa+VJU9NSM1Wt8qzIXEiv0rYU23c8ygAtc44nVGmwI6GwZxJADAFG s6tYp6S2zNh1sQXpaD52 =3je8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CLIENT-CERT configuration doesn't work for servlet.
You have http://host/ClientCertSignServlet configured to redirect to https://host/ClientCertSignServlet due to the transport-guarantee. Did you expect some other response than 302? When I enable client authentication on tomcat, I'm not able to open the https url, it says page cannot be displayed. I can't find what status code it is, as it is all encrypted on the network, but I could see that some step of the handshake had been attempted, and I see a list of CA (Certifying Authority) names amongs the encrypted junk of text. These CA names are those configured as Intermediate Certifying Authorities on the browser cert store. I'm not sure why these are required to be sent on the network, I thought the browser should send the certificate from the Personal Certificate store as this is the keystore of the browser (whose issuing 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 ch...@christopherschultz.net wrote: From: Christopher Schultz ch...@christopherschultz.net Subject: Re: CLIENT-CERT configuration doesn't work for servlet. To: Tomcat Users List users@tomcat.apache.org Date: Friday, 4 February, 2011, 1:54 AM -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. !-- Force SSL for entire site -- security-constraint web-resource-collection web-resource-nameRUSA Authentication/web-resource-name url-pattern/ClientCertSignServlet/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method realm-nameClient Cert Users-only Area/realm-name /login-config 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 browser cert store and use it for client authentication. How to get it working? You have http://host/ClientCertSignServlet configured to redirect to https://host/ClientCertSignServlet due to the transport-guarantee. Did you expect some other response than 302? SSL client certificates can't be negotiated over HTTP... you need HTTPS. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1LDukACgkQ9CaO5/Lv0PBaXwCfdbp5epSvyjuwRRRd4fgZh2Kr YdUAoKOcGe15s0Q+2UccCQpoNCz55Z3Q =mGdv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 (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 Tomcat 5: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/SSLValve.java?view=annotate Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Client-cert-authentication-tp28287654p28364194.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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_jk passes the client cert to Tomcat 5.5? mod_proxy_ajp works perfectly. It will set request.isSecure() and fills in all the certs in the chain not trusted by apache httpd. Thank you, Andre Mark Thomas wrote: 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 Tomcat 5: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/cata lina/valves/SSLValve.java?view=annotate Mark -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
ServletException
{
String[] mensagem = null;
X509Certificate[] certs = (X509Certificate[])
req.getAttribute(javax.servlet.request.X509Certificate);
if (certs != null) {
for (int i = 0; i certs.length; i++) {
mensagem[i] = (Client Certificate [ + i + ] = +
certs[i].toString());
log.info(mensagem[i]);
}
} else {
if (https.equals(req.getScheme())) {
log.info(This was an HTTPS request, + but no client certificate is
available);
} else {
log.info(This was not an HTTPS request, + so no client certificate
is available);
}
}
}
Thanks in advance for your attention.
markt-2 wrote:
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 accreditation is done by apache, does Tomcat need to have
a
keystore and https set?
No.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
View this message in context:
http://old.nabble.com/Client-cert-authentication-tp28287654p28333274.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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 Tomcat 5: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/SSLValve.java?view=annotate Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 accreditation is done by apache, does Tomcat need to have a keystore and https set? No. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 cert transparently you have to use the HTTPS protocol - there is no other wide-recognized protocol to get at the cert. Consider: You have to make sure that the cert you get is actually one that the user is allowed to present you (one that he didn't snatch off the neighbour's disk). This is done by checking whether the client also owns the private key associated to the public key in the cert, so some encryption traffic will have to take place. Best, -- David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Cert
Hi, You mean http://pheox.com/products/jcapi/ 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 right as long as you do not need to make sure that the client machine that is uploading the cert to the server is actually also one on which there currently is a user that knows the password to the keystore. After all, one someone snarfs the certificate, he can impersonate that browser. Which may or may not be what you want. Or do you have some additional security cooking in there? (Just curious, no need to answer) Best, -- David --On Tuesday, February 21, 2006 4:31 PM -0300 Luis Henrique [EMAIL PROTECTED] wrote: 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 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 cert transparently you have to use the HTTPS protocol - there is no other wide-recognized protocol to get at the cert. Consider: You have to make sure that the cert you get is actually one that the user is allowed to present you (one that he didn't snatch off the neighbour's disk). This is done by checking whether the client also owns the private key associated to the public key in the cert, so some encryption traffic will have to take place. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 anyway to request a client cert without https? Thanks for your help Luis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 anyway to request a client cert without https? Thanks for your help Luis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 cert transparently you have to use the HTTPS protocol - there is no other wide-recognized protocol to get at the cert. Consider: You have to make sure that the cert you get is actually one that the user is allowed to present you (one that he didn't snatch off the neighbour's disk). This is done by checking whether the client also owns the private key associated to the public key in the cert, so some encryption traffic will have to take place. Best, -- David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
