Re: Client cert auth on demand

[Martynas Jusevičius]

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

[Martynas Jusevičius]

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

[Martynas Jusevičius]

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

[Michael Osipov]

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

[Martynas Jusevičius]

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

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

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

[Michael Osipov]

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

[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

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

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

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

[Michael Osipov]

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

[Michael Osipov]

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

[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

-
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

[Michael Osipov]

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

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

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

[Michael Osipov]

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

[Mark Thomas]

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

[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

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

[Martynas Jusevičius]

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

[Mark Thomas]

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

[Martynas Jusevičius]

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

[Martynas Jusevičius]

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

[Mark Thomas]

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

[Martynas Jusevičius]

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

[Mark Thomas]

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

Client cert auth on demand

[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

RE: Client Cert TLS issue

[George Stanchev]

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

[Mark Thomas]

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

[George Stanchev]

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

[Mark Thomas]

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

[George Stanchev]

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

[Christopher Schultz]

-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

[George Stanchev]

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

[Mark Thomas]

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

Client Cert TLS issue

[George Stanchev]

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.

George

[1]

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

[Vivien Wu]

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?

[Mark Thomas]

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

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

[Vivien Wu]

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


When digging into tomcat log, the only clues as follows.


28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.authenticator.AuthenticatorBase.invoke  Calling
authenticate()
28-Aug-2019 18:16:38.091 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.authenticator.AuthenticatorBase.invoke  Failed
authenticate() test

.. wondering if anyone has any suggestion as how to debug the issues.

Thank you all in advance for your help.




Configuration:
1. web.xml




X509AuthHandler

net.shibboleth.idp.authn.impl.X509AuthServlet
3


X509AuthHandler
/Authn/X509



X509AuthHandler
/Authn/X509


CONFIDENTIAL


X509



 CLIENT-CERT





2. server.xml


 




 

 



3. logging.properties

org.apache.catalina.realm.level = ALL
org.apache.catalina.realm.useParentHandlers = true
org.apache.catalina.authenticator.level = ALL
org.apache.catalina.authenticator.useParentHandlers = true
net.unicon.tomcat7.realm.level = ALL
net.unicon.tomcat7.realm.useParentHandlers = true
org.apache.coyote.http11.level = ALL
org.apache.coyote.http11.useParentHandlers = true

with  -Djavax.net.debug=ssl




4. When SSLVerifyClient=none is specified in Connector,  got the following
in the browser,

This site can’t provide a secure connection login-test.foo.com sent an
invalid response.
ERR_SSL_PROTOCOL_ERROR

and in the catalina log,

28-Aug-2019 18:16:38.089 FINE [https-openssl-apr-8443-exec-1]
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [GET
/idp/Authn/X509?conversation=e1s1 HTTP/1.1
Host: login-test.foo.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
DNT: 1
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Sec-Fetch-Site: none
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7,mt;q=0.6,zh-TW;q=0.5
Cookie: JSESSIONID=70B72EE82D09700707565E884DB1E3C5.jvm1; x509passthrough=1

]
28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.authenticator.AuthenticatorBase.invoke Security
checking request GET /idp/Authn/X509
28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking
constraint 'SecurityConstraint[X509AuthHandler]' against GET /Authn/X509
--> true
28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.realm.RealmBase.findSecurityConstraints   Checking
constraint 'SecurityConstraint[Automatic Forward to HTTPS/SSL]' against GET
/Authn/X509 --> true
28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.authenticator.AuthenticatorBase.invoke  Calling
hasUserDataPermission()
28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.realm.RealmBase.hasUserDataPermission   User data
constraint already satisfied
28-Aug-2019 18:16:38.090 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.authenticator.AuthenticatorBase.invoke  Calling
authenticate()
28-Aug-2019 18:16:38.091 FINE [https-openssl-apr-8443-exec-1]
org.apache.catalina.authenticator.AuthenticatorBase.invoke  Failed
authenticate() test
28-Aug-2019 18:16:38.094 FINE [https-openssl-apr-8443-exec-1]
org.apache.coyote.AbstractProcessorLight.process Socket:
[org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@2081420c:139711359418528],
Status in: [OPEN_READ], State out: [OPEN]
28-Aug-2019 18:16:38.094 FINE [https-openssl-apr-8443-exec-1]
org.apache.coyote.AbstractProtocol$ConnectionHandler.release Pushed
Processor [org.apache.coyote.http11.Http11Processor@4c325234]
28-Aug-2019 18:16:38.115 FINE [https-openssl-apr-8443-exec-2]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Processing
socket [139,711,359,418,528] with status [OPEN_READ]
28-Aug-2019 18:16:38.115 FINE [https-openssl-apr-8443-exec-2]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Found
processor [null] for socket [139,711,359,418,528]
28-Aug-2019 18:16:38.115 FINE [https-openssl-apr-8443-exec-2]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Popped
processor [org.apache.coyote.http11.Http11Processor@4c325234] from cache
28-Aug-2019 18:16:38.124 FINE [https-openssl-apr-8443-exec-2]
org.apache.coyote.

Re: TLS client cert clarification

[Mark Thomas]

On 12/07/2019 19:07, Wilmoth, Jon wrote:
> Thanks for the very quick response!  Out of curiosity is this ensured by some 
> sort of caching in the Tomcat server after the TLS handshake?  Or is it 
> expected that the client would send the certificate with each post handshake 
> request.  I ask as I'm seeing intermittent requests that do not have a 
> "javax.servlet.request.X509Certificate" attribute value populated.  This also 
> differs by browser (e.g. more frequently on MacOS Chrome 75.0.3770.100, not 
> on MacOS Safari 12.1.1).

It depends.

Without session tickets, the client has to provide the cert and the full
chain in the handshake. With OpenSSL session tickets the server caches
the client cert but not the full chain.

The above is only as accurate at the last time I dug into this. There
are lots of variables, JRE version, JSSE vs OpenSSL, OpenSSL version,
client etc. and some may have changed since my last test.

Mark


> On 7/12/19, 2:00 AM, "Mark Thomas"  wrote:
> 
> On 12/07/2019 08:22, Martynas Jusevičius wrote:
> > In my experience with 8.x -- on all requests.
> 
> The above is correct for JSSE based TLS connections. It also applies to
> most OpenSSL based connections.
> 
> There is one edge case that can cause problems. If:
> 
> - OpenSSL based TLS connections are used;
> - TLS session tickets are enabled; and
> - the session has been resumed via a ticket; then
> 
> the client certificate will be available but the full client certificate
> chain will not. The full chain will only be available in the initial
> connection.
> 
> Mark
> 
> > 
> > On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
> >  wrote:
> >>
> >> I was hoping to get some clarification on when to expect client x509 
> certs in http requests where the Tomcat server (v9.x) has been configured to 
> “want” or “need” client auth.  
> https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
>  says:
> >>
> >> “If there is an SSL certificate associated with the request, it must 
> be exposed by the servlet container to the servlet programmer as an array of 
> objects of type java.security.cert.X509Certificate and accessible via a 
> ServletRequest attribute of javax.servlet.request.X509Certificate.”
> >>
> >> Is this only for the request that initiated the TLS handshake?  Or 
> does this mean it will be present on all requests (i.e. requests on a 
> keep-alive connection after the initial handshake) while the TLS connection 
> is still open?
> >>
> >> Thanks,
> >> Jon
> > 
> > -
> > 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: TLS client cert clarification

[Wilmoth, Jon]

Thanks for the very quick response!  Out of curiosity is this ensured by some 
sort of caching in the Tomcat server after the TLS handshake?  Or is it 
expected that the client would send the certificate with each post handshake 
request.  I ask as I'm seeing intermittent requests that do not have a 
"javax.servlet.request.X509Certificate" attribute value populated.  This also 
differs by browser (e.g. more frequently on MacOS Chrome 75.0.3770.100, not on 
MacOS Safari 12.1.1).

On 7/12/19, 2:00 AM, "Mark Thomas"  wrote:

On 12/07/2019 08:22, Martynas Jusevičius wrote:
> In my experience with 8.x -- on all requests.

The above is correct for JSSE based TLS connections. It also applies to
most OpenSSL based connections.

There is one edge case that can cause problems. If:

- OpenSSL based TLS connections are used;
- TLS session tickets are enabled; and
- the session has been resumed via a ticket; then

the client certificate will be available but the full client certificate
chain will not. The full chain will only be available in the initial
connection.

Mark

> 
> On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
>  wrote:
>>
>> I was hoping to get some clarification on when to expect client x509 
certs in http requests where the Tomcat server (v9.x) has been configured to 
“want” or “need” client auth.  
https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
 says:
>>
>> “If there is an SSL certificate associated with the request, it must be 
exposed by the servlet container to the servlet programmer as an array of 
objects of type java.security.cert.X509Certificate and accessible via a 
ServletRequest attribute of javax.servlet.request.X509Certificate.”
>>
>> Is this only for the request that initiated the TLS handshake?  Or does 
this mean it will be present on all requests (i.e. requests on a keep-alive 
connection after the initial handshake) while the TLS connection is still open?
>>
>> Thanks,
>> Jon
> 
> -
> 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: TLS client cert clarification

[Mark Thomas]

On 12/07/2019 08:22, Martynas Jusevičius wrote:
> In my experience with 8.x -- on all requests.

The above is correct for JSSE based TLS connections. It also applies to
most OpenSSL based connections.

There is one edge case that can cause problems. If:

- OpenSSL based TLS connections are used;
- TLS session tickets are enabled; and
- the session has been resumed via a ticket; then

the client certificate will be available but the full client certificate
chain will not. The full chain will only be available in the initial
connection.

Mark

> 
> On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
>  wrote:
>>
>> I was hoping to get some clarification on when to expect client x509 certs 
>> in http requests where the Tomcat server (v9.x) has been configured to 
>> “want” or “need” client auth.  
>> https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
>>  says:
>>
>> “If there is an SSL certificate associated with the request, it must be 
>> exposed by the servlet container to the servlet programmer as an array of 
>> objects of type java.security.cert.X509Certificate and accessible via a 
>> ServletRequest attribute of javax.servlet.request.X509Certificate.”
>>
>> Is this only for the request that initiated the TLS handshake?  Or does this 
>> mean it will be present on all requests (i.e. requests on a keep-alive 
>> connection after the initial handshake) while the TLS connection is still 
>> open?
>>
>> Thanks,
>> Jon
> 
> -
> 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: TLS client cert clarification

[Martynas Jusevičius]

In my experience with 8.x -- on all requests.

On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
 wrote:
>
> I was hoping to get some clarification on when to expect client x509 certs in 
> http requests where the Tomcat server (v9.x) has been configured to “want” or 
> “need” client auth.  
> https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
>  says:
>
> “If there is an SSL certificate associated with the request, it must be 
> exposed by the servlet container to the servlet programmer as an array of 
> objects of type java.security.cert.X509Certificate and accessible via a 
> ServletRequest attribute of javax.servlet.request.X509Certificate.”
>
> Is this only for the request that initiated the TLS handshake?  Or does this 
> mean it will be present on all requests (i.e. requests on a keep-alive 
> connection after the initial handshake) while the TLS connection is still 
> open?
>
> Thanks,
> Jon

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

TLS client cert clarification

[Wilmoth, Jon]

I was hoping to get some clarification on when to expect client x509 certs in 
http requests where the Tomcat server (v9.x) has been configured to “want” or 
“need” client auth.  
https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
 says:

“If there is an SSL certificate associated with the request, it must be exposed 
by the servlet container to the servlet programmer as an array of objects of 
type java.security.cert.X509Certificate and accessible via a ServletRequest 
attribute of javax.servlet.request.X509Certificate.”

Is this only for the request that initiated the TLS handshake?  Or does this 
mean it will be present on all requests (i.e. requests on a keep-alive 
connection after the initial handshake) while the TLS connection is still open?

Thanks,
Jon

client cert authentication

[George Stanchev]

I guess I am looking for some pointers how to approach a certain scenario from 
"the right way" of implementing it. Say you have a standard login form with 
user/pass edits and "Login" and "Smartcard" buttons. The "Login" button does 
Its obvious thing. The "Smartcard" button authenticates the user using client 
cert SSL. The actual certificate validation happens way downstream of the login 
page controller so all it needs to do is to extract it from the request and 
pass it on to the backend. The login page can be served either over http or 
https. The way currently is implemented, is for the "Smartcard" for the servlet 
to detect that the "Smartcard" has been pressed and to 302 to a specially 
designated https connector that has 
"clientAuth="true"+"trustManagerClassName=... AnyCertX509TrustManager" 
attributes that handle the client cert authentication. I suspect though that 
this is a hack, and there could be a more clever way to handle this with either 
forwarding or somehow manually upgrading the connection from HTTP to 
HTTPS/clientAuth or HTTPS to HTTPS/clientAuth to challenge for a client 
certificate. I'd like to eliminate the 302 and the maintenance of a separate 
connector. Some pointers/advice would be appreciated...

Re: [EXTERNAL] Using CLIENT-CERT

[Amit Pande]

Thank you so much Chris and Mark! Sincerely appreciate the inputs.

Sent from my iPhone

> On Apr 11, 2018, at 8:16 AM, Christopher Schultz 
> <ch...@christopherschultz.net> wrote:
> 
> Mark and Amit,
> 
>> On 4/10/18 2:21 AM, Mark Thomas wrote:
>>> On 9 April 2018 23:29:43 BST, Amit Pande <amit.pa...@veritas.com> wrote:
>>> Some more debugging here and I got some stuff working here.
>>> 
>>> Only one question:
>>> 
>>> It is not really clear from the documentation of "clientAuth"
>>> 
>>> "Set to true if you want the SSL stack to require a valid certificate
>>> chain from the client before accepting a connection. Set to want if you
>>> want the SSL stack to request a client Certificate, but not fail if one
>>> isn't presented. A false value (which is the default) will not require
>>> a certificate chain unless the client requests a resource protected by
>>> a security constraint that uses CLIENT-CERT authentication. See the SSL
>>> HowTo for an example. That SSL HowTo also contains tips on using
>>> per-user or per-session certificate-based clientAuth."
>>> 
>>> So, if I am using a clientAuth="false" and relying on "CLIENT-CERT"
>>> configuration, does that mean browsers won't prompt users to supply the
>>> certificate when a protected resource is accessed?
>> 
>> In that scenario the browser will prompt the user for a certificate if 
>> everything is correctly configured.
>> 
>> However, it is possible that the browser will determine that it has no 
>> matching certificates and therefore decide not to display the certificate 
>> prompt.
> 
> Also, sometimes browsers will "remember" your choice from a prior
> interaction during the same browser session. So for example if you have
> clientAuth="want" and you press "No/Cancel/[escape]/[close window]" the
> browser may "remember" that you don't want to present a certificate.
> 
> -chris
> 
> -
> 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: [EXTERNAL] Using CLIENT-CERT

[Christopher Schultz]

Mark and Amit,

On 4/10/18 2:21 AM, Mark Thomas wrote:
> On 9 April 2018 23:29:43 BST, Amit Pande <amit.pa...@veritas.com> wrote:
>> Some more debugging here and I got some stuff working here.
>>
>> Only one question:
>>
>> It is not really clear from the documentation of "clientAuth"
>>
>> "Set to true if you want the SSL stack to require a valid certificate
>> chain from the client before accepting a connection. Set to want if you
>> want the SSL stack to request a client Certificate, but not fail if one
>> isn't presented. A false value (which is the default) will not require
>> a certificate chain unless the client requests a resource protected by
>> a security constraint that uses CLIENT-CERT authentication. See the SSL
>> HowTo for an example. That SSL HowTo also contains tips on using
>> per-user or per-session certificate-based clientAuth."
>>
>> So, if I am using a clientAuth="false" and relying on "CLIENT-CERT"
>> configuration, does that mean browsers won't prompt users to supply the
>> certificate when a protected resource is accessed?
> 
> In that scenario the browser will prompt the user for a certificate if 
> everything is correctly configured.
> 
> However, it is possible that the browser will determine that it has no 
> matching certificates and therefore decide not to display the certificate 
> prompt.

Also, sometimes browsers will "remember" your choice from a prior
interaction during the same browser session. So for example if you have
clientAuth="want" and you press "No/Cancel/[escape]/[close window]" the
browser may "remember" that you don't want to present a certificate.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [EXTERNAL] Using CLIENT-CERT

[Mark Thomas]

On 9 April 2018 23:29:43 BST, Amit Pande <amit.pa...@veritas.com> wrote:
>Some more debugging here and I got some stuff working here.
>
>Only one question:
>
>It is not really clear from the documentation of "clientAuth"
>
>"Set to true if you want the SSL stack to require a valid certificate
>chain from the client before accepting a connection. Set to want if you
>want the SSL stack to request a client Certificate, but not fail if one
>isn't presented. A false value (which is the default) will not require
>a certificate chain unless the client requests a resource protected by
>a security constraint that uses CLIENT-CERT authentication. See the SSL
>HowTo for an example. That SSL HowTo also contains tips on using
>per-user or per-session certificate-based clientAuth."
>
>So, if I am using a clientAuth="false" and relying on "CLIENT-CERT"
>configuration, does that mean browsers won't prompt users to supply the
>certificate when a protected resource is accessed?

In that scenario the browser will prompt the user for a certificate if 
everything is correctly configured.

However, it is possible that the browser will determine that it has no matching 
certificates and therefore decide not to display the certificate prompt.

Mark

>
>Is it because in case of "CLIENT-CERT", the client is always expected
>to supply a certificate?  If yes, is there any recommended practice to
>configure browser for this? Or application needs to take care of
>supplying one when accessing such a protected resource?
>
>Appreciate your inputs.
>
>
>
>On 4/8/18, 6:44 PM, "Amit Pande" <amit.pa...@veritas.com> wrote:
>
>I am trying to setup Tomcat (8.5.28) and the web-app correctly in order
>to get the mutual authentication (using client certificates) done but
>only for some recourses and not all.
>
>For instance, I have a “authenticate” API for which I want to enable
>the client certificate authentication.  So, I want only a
>“/authenticate” URL to ask for a client certificate from the browser.
>
>I want to first validate if this client certificate is issued by a
>trusted CA. If yes, accept the request and invoke the “/authenticate”
>business logic which further validates the certificate/user against our
>own user database.
>
>Looking at Tomcat documentation “clientAuth=want” in server.xml seemed
>a potential option but the issue with that is when this results in
>asking for user certificate for all the URLs being invoked from the
>Browser (unless we tell Browser to remember the decision). Also, this
>approach results in renegotiation for every request.
>
>This is when I came across, “CLIENT-CERT” alternate, which can be
>configured only for certain URL (e.g. “/authenticate” in my case).
>However, I am not able to get it configured as expected. I issued a
>client certificate and imported in browser but still unable to get the
>browser pop-up which asks for the certificate to be sent. Debugging SSL
>level did not yield much.
>
>https://stackoverflow.com/questions/41438536/protecting-webresource-in-tomcat-8-5-with-client-cert
>
>This is the link that closely matches the requirement and I saw Chris’
>input there. However,
>
>
>“Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>allRolesMode="authOnly"
>resourceName="UserDatabase" />
>“
>In server.xml
>
>And
>
>
>
>
>  
>
>My Secure Area
>
>/authenticate
>
>  
>
>  
>
>CONFIDENTIAL
>
>  
>
>  
>
>  *
>
>  
>
>
>
>In my web app’s web.xml.
>
>When I access the URL from browser, I expected to see a dialog asking
>for client-certificate and then a successful invocation of the
>“/authenticate”. However, from browser, I don’t get a pop-up and I get
>a HTTP 401 with below message.
>
>
>Message Cannot authenticate with the provided credentials
>
>Description The request has not been applied because it lacks valid
>authentication credentials for the target resource.
>
>
>Appreciate your help on this.
>
>Thanks,
>Amit
>
>
>
>-
>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: [EXTERNAL] Using CLIENT-CERT

[Amit Pande]

Some more debugging here and I got some stuff working here.

Only one question:

It is not really clear from the documentation of "clientAuth"

"Set to true if you want the SSL stack to require a valid certificate chain 
from the client before accepting a connection. Set to want if you want the SSL 
stack to request a client Certificate, but not fail if one isn't presented. A 
false value (which is the default) will not require a certificate chain unless 
the client requests a resource protected by a security constraint that uses 
CLIENT-CERT authentication. See the SSL HowTo for an example. That SSL HowTo 
also contains tips on using per-user or per-session certificate-based 
clientAuth."

So, if I am using a clientAuth="false" and relying on "CLIENT-CERT" 
configuration, does that mean browsers won't prompt users to supply the 
certificate when a protected resource is accessed?

Is it because in case of "CLIENT-CERT", the client is always expected to supply 
a certificate?  If yes, is there any recommended practice to configure browser 
for this? Or application needs to take care of supplying one when accessing 
such a protected resource?

Appreciate your inputs.



On 4/8/18, 6:44 PM, "Amit Pande" <amit.pa...@veritas.com> wrote:

I am trying to setup Tomcat (8.5.28) and the web-app correctly in order to 
get the mutual authentication (using client certificates) done but only for 
some recourses and not all.

For instance, I have a “authenticate” API for which I want to enable the 
client certificate authentication.  So, I want only a “/authenticate” URL to 
ask for a client certificate from the browser.

I want to first validate if this client certificate is issued by a trusted 
CA. If yes, accept the request and invoke the “/authenticate” business logic 
which further validates the certificate/user against our own user database.

Looking at Tomcat documentation “clientAuth=want” in server.xml seemed a 
potential option but the issue with that is when this results in asking for 
user certificate for all the URLs being invoked from the Browser (unless we 
tell Browser to remember the decision). Also, this approach results in 
renegotiation for every request.

This is when I came across, “CLIENT-CERT” alternate, which can be 
configured only for certain URL (e.g. “/authenticate” in my case). However, I 
am not able to get it configured as expected. I issued a client certificate and 
imported in browser but still unable to get the browser pop-up which asks for 
the certificate to be sent. Debugging SSL level did not yield much.


https://stackoverflow.com/questions/41438536/protecting-webresource-in-tomcat-8-5-with-client-cert

This is the link that closely matches the requirement and I saw Chris’ 
input there. However,


“Realm className="org.apache.catalina.realm.UserDatabaseRealm"
allRolesMode="authOnly"
resourceName="UserDatabase" />
“
In server.xml

And




  

My Secure Area

/authenticate

  

  

CONFIDENTIAL

  

  

  *

  



In my web app’s web.xml.

When I access the URL from browser, I expected to see a dialog asking for 
client-certificate and then a successful invocation of the “/authenticate”. 
However, from browser, I don’t get a pop-up and I get a HTTP 401 with below 
message.


Message Cannot authenticate with the provided credentials

Description The request has not been applied because it lacks valid 
authentication credentials for the target resource.


Appreciate your help on this.

Thanks,
Amit



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Using CLIENT-CERT

[Amit Pande]

I am trying to setup Tomcat (8.5.28) and the web-app correctly in order to get 
the mutual authentication (using client certificates) done but only for some 
recourses and not all.

For instance, I have a “authenticate” API for which I want to enable the client 
certificate authentication.  So, I want only a “/authenticate” URL to ask for a 
client certificate from the browser.

I want to first validate if this client certificate is issued by a trusted CA. 
If yes, accept the request and invoke the “/authenticate” business logic which 
further validates the certificate/user against our own user database.

Looking at Tomcat documentation “clientAuth=want” in server.xml seemed a 
potential option but the issue with that is when this results in asking for 
user certificate for all the URLs being invoked from the Browser (unless we 
tell Browser to remember the decision). Also, this approach results in 
renegotiation for every request.

This is when I came across, “CLIENT-CERT” alternate, which can be configured 
only for certain URL (e.g. “/authenticate” in my case). However, I am not able 
to get it configured as expected. I issued a client certificate and imported in 
browser but still unable to get the browser pop-up which asks for the 
certificate to be sent. Debugging SSL level did not yield much.

https://stackoverflow.com/questions/41438536/protecting-webresource-in-tomcat-8-5-with-client-cert

This is the link that closely matches the requirement and I saw Chris’ input 
there. However,


“Realm className="org.apache.catalina.realm.UserDatabaseRealm"
allRolesMode="authOnly"
resourceName="UserDatabase" />
“
In server.xml

And




  

My Secure Area

/authenticate

  

  

CONFIDENTIAL

  

  

  *

  



In my web app’s web.xml.

When I access the URL from browser, I expected to see a dialog asking for 
client-certificate and then a successful invocation of the “/authenticate”. 
However, from browser, I don’t get a pop-up and I get a HTTP 401 with below 
message.


Message Cannot authenticate with the provided credentials

Description The request has not been applied because it lacks valid 
authentication credentials for the target resource.


Appreciate your help on this.

Thanks,
Amit

Re: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Gael Abadin]

None of us had. Now both of us have, and still the same result ¯\_(ツ)_/¯

The DNS response is all the same, because for development we are using
internal lan ip access (or localhost), not domain-based. And self-signed
certificates.

I thought maybe it was some Java security configuration, but looking at it
on the Windows Control Panel widget we also have the same

Anyway, thanks for the tips! :-)




2016-01-19 16:49 GMT+01:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Gael,
>
> On 1/19/16 6:37 AM, Gael Abadin wrote:
> > Thanks for the reply :-)
> >
> > I've checked for all that!
> >
> > I even ended up copying my tomcat folder and my eclipse tomcat
> > configuration folder from my computer to his,
> >
> > So they are literally the same configuration.
> >
> > I know the connector configuration is being read because if, for
> > example, I remove the .keystore file I get an error. Or if I change
> > the port the SSL connector starts listening on that port on
> > deployment.
> >
> > Also, I made sure we are launching using the same JRE.
> >
> > I tried clientAuth="true" instead of "want". And accesing from my
> > browser on my computer. Still no client certificate request. Log
> > files don't show any errors.
> >
> > We even tried to reboot the system ^^'.
> >
> > Eclipse versions differ, but I don't see how that could result in
> > tomcat not requesting SSL client certs...
> >
> > Anyway, since we couldn't find the cause I recommended him to use a
> > fresh tomcat 7 install, download the last eclipse-JEE and java SDK,
> > using a new workbench, and starting a new project redownloading the
> > source files from the repo. It's a little overkill, but that should
> > do it...
>
> Is it possible that one of you has added-on for instance the
> "unlimited encryption" setting in the JRE and the other has not?
>
> I'm grasping at straws here because it seems like you've looked at all
> the usual things that could have gone wrong.
>
> Bad DNS response? (!!?)
>
> - -chris
>
> > 2016-01-19 1:59 GMT+01:00 Christopher Schultz
> >  :
> >
> >> Gael,
> >>
> >> On 1/11/16 11:46 AM, Gael Abadin wrote:
> >>> The server certificate is self signed. Appart from the typical
> >>> warning we see no errors when we check it.
> >>>
> >>> His system (windows) clock is synchronized using microsoft's
> >>> NTP server, same as mine.
> >>>
> >>> This is really weird because I have already delopoyed the same
> >>> app and config in two other systems, appart from mine, without
> >>> any issues, and
> >> his
> >>> and mine are basically the same...
> >>
> >> Run "diff" on the two conf/server.xml files from the two
> >> servers? Different conf/context.xml file? How about a
> >> conf/[engine]/[host]/[app].xml file making a difference in one or
> >> the other environment?
> >>
> >> -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlaeWvEACgkQ9CaO5/Lv0PD+ZwCdEckChNr97VUhice9tPr5BnE9
> lp4AoILZ9L0uycFJx+hf4Tt7CMpDTPX7
> =2t5+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.



.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

Re: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Gael Abadin]

Thanks for the reply :-)

I've checked for all that!

I even ended up copying my tomcat folder and my eclipse tomcat
configuration folder from my computer to his,

So they are literally the same configuration.

I know the connector configuration is being read because if, for example, I
remove the .keystore file I get an error. Or if I change the port the SSL
connector starts listening on that port on deployment.

Also, I made sure we are launching using the same JRE.

I tried clientAuth="true" instead of "want". And accesing from my browser
on my computer. Still no client certificate request. Log files don't show
any errors.

We even tried to reboot the system ^^'.

Eclipse versions differ, but I don't see how that could result in tomcat
not requesting SSL client certs...

Anyway, since we couldn't find the cause I recommended him to use a fresh
tomcat 7 install, download the last eclipse-JEE and java SDK, using a new
workbench, and starting a new project redownloading the source files from
the repo. It's a little overkill, but that should do it...

2016-01-19 1:59 GMT+01:00 Christopher Schultz 
:

> Gael,
>
> On 1/11/16 11:46 AM, Gael Abadin wrote:
> > The server certificate is self signed. Appart from the typical warning we
> > see no errors when we check it.
> >
> > His system (windows) clock is synchronized using microsoft's NTP server,
> > same as mine.
> >
> > This is really weird because I have already delopoyed the same app and
> > config in two other systems, appart from mine, without any issues, and
> his
> > and mine are basically the same...
>
> Run "diff" on the two conf/server.xml files from the two servers?
> Different conf/context.xml file? How about a
> conf/[engine]/[host]/[app].xml file making a difference in one or the
> other environment?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.



.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

Re: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gael,

On 1/19/16 6:37 AM, Gael Abadin wrote:
> Thanks for the reply :-)
> 
> I've checked for all that!
> 
> I even ended up copying my tomcat folder and my eclipse tomcat 
> configuration folder from my computer to his,
> 
> So they are literally the same configuration.
> 
> I know the connector configuration is being read because if, for
> example, I remove the .keystore file I get an error. Or if I change
> the port the SSL connector starts listening on that port on
> deployment.
> 
> Also, I made sure we are launching using the same JRE.
> 
> I tried clientAuth="true" instead of "want". And accesing from my
> browser on my computer. Still no client certificate request. Log
> files don't show any errors.
> 
> We even tried to reboot the system ^^'.
> 
> Eclipse versions differ, but I don't see how that could result in
> tomcat not requesting SSL client certs...
> 
> Anyway, since we couldn't find the cause I recommended him to use a
> fresh tomcat 7 install, download the last eclipse-JEE and java SDK,
> using a new workbench, and starting a new project redownloading the
> source files from the repo. It's a little overkill, but that should
> do it...

Is it possible that one of you has added-on for instance the
"unlimited encryption" setting in the JRE and the other has not?

I'm grasping at straws here because it seems like you've looked at all
the usual things that could have gone wrong.

Bad DNS response? (!!?)

- -chris

> 2016-01-19 1:59 GMT+01:00 Christopher Schultz
>  :
> 
>> Gael,
>> 
>> On 1/11/16 11:46 AM, Gael Abadin wrote:
>>> The server certificate is self signed. Appart from the typical
>>> warning we see no errors when we check it.
>>> 
>>> His system (windows) clock is synchronized using microsoft's
>>> NTP server, same as mine.
>>> 
>>> This is really weird because I have already delopoyed the same
>>> app and config in two other systems, appart from mine, without
>>> any issues, and
>> his
>>> and mine are basically the same...
>> 
>> Run "diff" on the two conf/server.xml files from the two
>> servers? Different conf/context.xml file? How about a 
>> conf/[engine]/[host]/[app].xml file making a difference in one or
>> the other environment?
>> 
>> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlaeWvEACgkQ9CaO5/Lv0PD+ZwCdEckChNr97VUhice9tPr5BnE9
lp4AoILZ9L0uycFJx+hf4Tt7CMpDTPX7
=2t5+
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Christopher Schultz]

Gael,

On 1/11/16 11:46 AM, Gael Abadin wrote:
> The server certificate is self signed. Appart from the typical warning we
> see no errors when we check it.
> 
> His system (windows) clock is synchronized using microsoft's NTP server,
> same as mine.
> 
> This is really weird because I have already delopoyed the same app and
> config in two other systems, appart from mine, without any issues, and his
> and mine are basically the same...

Run "diff" on the two conf/server.xml files from the two servers?
Different conf/context.xml file? How about a
conf/[engine]/[host]/[app].xml file making a difference in one or the
other environment?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Gael Abadin]

A colleague was having trouble setting up client cert auth on this web app
we are developing. He tried the latest tomcat 6 and 7 win32 installs using
java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
from eclipse, but even though the SSL connector had clientAuth="want" there
was no client cert request when establishing the SSL connection.

I had a similar problem before because of an expired self-signed server
certificate so I sent him my .keystore file with the new cert that I am
using and he replaced his with mine. Still a no go.

Then I sent him my own tomcat and eclipse tomcat x64 deployment config and
we switched his runtime to the same as mine (latest Java 8 x64). Same
problem.

At this point I don't know what else to try. His setup is exactly the same
as mine, but I can't get the client auth to work on his.

Any ideas?



-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.
<http://www.linkedin.com/company/imatia-innovation>
<http://www.youtube.com/imatiainnovation>

.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

Re: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Gael Abadin]

The server certificate is self signed. Appart from the typical warning we
see no errors when we check it.

His system (windows) clock is synchronized using microsoft's NTP server,
same as mine.

This is really weird because I have already delopoyed the same app and
config in two other systems, appart from mine, without any issues, and his
and mine are basically the same...

2016-01-11 16:51 GMT+01:00 David Balažic <david.bala...@comtrade.com>:

> Wrong system clock?
>
> What does the client say? (about the server certificate. Is it valid?
> Expired?)
>
> Regards,
> David Balažic
> Software Engineer
> www.comtrade.com
>
> > -Original Message-
> > From: Gael Abadin [mailto:gael.aba...@imatia.com]
> > Sent: 11. January 2016 10:16
> > To: Tomcat Users List
> > Subject: SSL client cert selection dialog not showing up on cloned
> > deployment of tomcat 7 for windows x64
> > Importance: Low
> >
> > A colleague was having trouble setting up client cert auth on this web
> app
> > we are developing. He tried the latest tomcat 6 and 7 win32 installs
> using
> > java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
> > from eclipse, but even though the SSL connector had clientAuth="want"
> > there
> > was no client cert request when establishing the SSL connection.
> >
> > I had a similar problem before because of an expired self-signed server
> > certificate so I sent him my .keystore file with the new cert that I am
> > using and he replaced his with mine. Still a no go.
> >
> > Then I sent him my own tomcat and eclipse tomcat x64 deployment config
> > and
> > we switched his runtime to the same as mine (latest Java 8 x64). Same
> > problem.
> >
> > At this point I don't know what else to try. His setup is exactly the
> same
> > as mine, but I can't get the client auth to work on his.
> >
> > Any ideas?
> >
> >
> >
> > --
> >
> >
> >
> > .
> >
> > Alberto Gael Abadin Martinez
> > Junior Developer
> >
> > [image: IMATIA]
> >
> > www.imatia.com
> >
> > *Tel: *+34 986 342 774 ext 4531
> >
> > *Email: *gael.aba...@imatia.com
> > Edificio CITEXVI
> > Fonte das Abelleiras, s/n - Local 27
> > 36310 Vigo (Pontevedra)
> > España
> >
> > .
> > <http://www.linkedin.com/company/imatia-innovation>
> > <http://www.youtube.com/imatiainnovation>
> >
> > .
> >
> > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> > contener información confidencial, siendo para uso exclusivo del
> > destinatario. Queda prohibida su divulgación copia o distribución a
> > terceros sin la autorización expresa del remitente. Si usted ha recibido
> > este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
> > su borrado. Gracias por su colaboración.
> > This message, and in the case of any file annexed to it, can have
> > confidential information, and it is exclusively for the use of the
> > addressee of the message. It is strictly forbidden to spread a copy or
> > distribute to third parties, without the express order of the sender. If
> > you have received this message mistakenly, we request you to notify to
> the
> > sender, and please be sure to erase it. Thank you for your collaboration.
> >
> > .
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.
<http://www.linkedin.com/company/imatia-innovation>
<http://www.youtube.com/imatiainnovation>

.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

RE: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[David Balažic]

Wrong system clock?

What does the client say? (about the server certificate. Is it valid? Expired?)

Regards,
David Balažic
Software Engineer
www.comtrade.com

> -Original Message-
> From: Gael Abadin [mailto:gael.aba...@imatia.com]
> Sent: 11. January 2016 10:16
> To: Tomcat Users List
> Subject: SSL client cert selection dialog not showing up on cloned
> deployment of tomcat 7 for windows x64
> Importance: Low
> 
> A colleague was having trouble setting up client cert auth on this web app
> we are developing. He tried the latest tomcat 6 and 7 win32 installs using
> java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
> from eclipse, but even though the SSL connector had clientAuth="want"
> there
> was no client cert request when establishing the SSL connection.
> 
> I had a similar problem before because of an expired self-signed server
> certificate so I sent him my .keystore file with the new cert that I am
> using and he replaced his with mine. Still a no go.
> 
> Then I sent him my own tomcat and eclipse tomcat x64 deployment config
> and
> we switched his runtime to the same as mine (latest Java 8 x64). Same
> problem.
> 
> At this point I don't know what else to try. His setup is exactly the same
> as mine, but I can't get the client auth to work on his.
> 
> Any ideas?
> 
> 
> 
> --
> 
> 
> 
> .
> 
> Alberto Gael Abadin Martinez
> Junior Developer
> 
> [image: IMATIA]
> 
> www.imatia.com
> 
> *Tel: *+34 986 342 774 ext 4531
> 
> *Email: *gael.aba...@imatia.com
> Edificio CITEXVI
> Fonte das Abelleiras, s/n - Local 27
> 36310 Vigo (Pontevedra)
> España
> 
> .
> <http://www.linkedin.com/company/imatia-innovation>
> <http://www.youtube.com/imatiainnovation>
> 
> .
> 
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> contener información confidencial, siendo para uso exclusivo del
> destinatario. Queda prohibida su divulgación copia o distribución a
> terceros sin la autorización expresa del remitente. Si usted ha recibido
> este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
> su borrado. Gracias por su colaboración.
> This message, and in the case of any file annexed to it, can have
> confidential information, and it is exclusively for the use of the
> addressee of the message. It is strictly forbidden to spread a copy or
> distribute to third parties, without the express order of the sender. If
> you have received this message mistakenly, we request you to notify to the
> sender, and please be sure to erase it. Thank you for your collaboration.
> 
> .

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Gael Abadin]

@Mark Thomas:

I have been going through the documentation on

https://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html

trying to come up with a set of security constraints that allow me to force
SSL without asking for a client certificate except on a single login page,
but there is nothing there suggesting a configuration where I can force SSL
without asking for a client certificate: Once I set the CONFIDENTIAL
transport guarantee and the CLIENT-CERT auth method I will be asked for a
client cert when I land on a SSL page, no matter what.

I think I am getting something wrong. Please, can you be more specific on
the solution you suggest?



2015-10-06 16:52 GMT+02:00 Mark Thomas <ma...@apache.org>:

> On 06/10/2015 15:46, George Stanchev wrote:
> > Mark,
> >
> > What are the possible issues with renegotiation? We're on NIO
> connectors, is there anything known?
>
> NIO should be fine. We've seen odd issues on OSX we haven't been able to
> track down.
>
> Mark
>
> >
> > George
> >
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Monday, October 05, 2015 8:32 AM
> > To: Tomcat Users List
> > Subject: Re: Demand CLIENT-CERT only on certain pages but demand SSL in
> all pages
> >
> > On 05/10/2015 12:05, Gael Abadin wrote:
> >> Hello, fellow users.
> >>
> >> I've been trying to configure tomcat to request client certificate
> >> authentication on a single page, while serving every other SSL page
> >> without requesting a client certificate (before or after
> >> authentication). Depending on the configuration I use, one of 2 things
> >> happen: either I get a request for a client certificate on ANY HTTPS
> >> page I visit first, or I do not get a request at all, never, even when
> >> I launch the browser and go straight to the protected page
> (/my-app-name/public/login/login.xhtml).
> >>
> >> Am I doing something wrong or is this kind of configuration just not
> >> possible?
> >
> > That should be possible but you'll need two security constraints. One to
> require TLS everywhere and one for the pages where you require
> authentication.
> >
> > You may also hit issues with which connectors support renegotiation
> (don't use APR).
> >
> > Mark
> >
> >>
> >> Here is my web.xml security constraint and login config (I've also
> >> tried ommitin ):
> >>
> >>   
> >> 
> >>   Protected Context
> >>   /public/login/*
> >> 
> >> 
> >>   CONFIDENTIAL
> >> 
> >>   
> >>   
> >> CLIENT-CERT
> >>   
> >>
> >>
> >> And here is my server.xml config (I've also tried clientAuth="false"
> >> and
> >> clientAuth="true"):
> >>
> >>   >> shutdown="SHUTDOWN">
> >>>> className="org.apache.catalina.startup.VersionLoggerListener"/>
> >>
> >>   
> >>>> className="org.apache.catalina.core.AprLifecycleListener"/>
> >>   
> >>   
> >>   
> >>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
> >>>>
> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
> >>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
> >> />
> >>
> >>   
> >>  >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> >> name="UserDatabase" pathname="conf/tomcat-users.xml"
> >> type="org.apache.catalina.UserDatabase"/>
> >>   
> >>
> >>   
> >>
> >>  >> redirectPort="443"/>
> >>
> >>  >> port="443" protocol="org.apache.coyote.http11.Http11Protocol"
> >> scheme="https" secure="true" sslProtocol="TLS"/>
> >>
> >> 
> >>
> >> 
> >>   
> >>  >> resourceName="UserDatabase"/>
> >>   
> >>>> unpackWARs="true">
> >>  >> directory="logs" pattern="%h %l %u %t %r %s %b"
> >> prefix="localhost_access_log." suffix=".txt"/>
> >>  >> reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web&

RE: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[George Stanchev]

Mark,

What are the possible issues with renegotiation? We're on NIO connectors, is 
there anything known?

George

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, October 05, 2015 8:32 AM
To: Tomcat Users List
Subject: Re: Demand CLIENT-CERT only on certain pages but demand SSL in all 
pages

On 05/10/2015 12:05, Gael Abadin wrote:
> Hello, fellow users.
> 
> I've been trying to configure tomcat to request client certificate 
> authentication on a single page, while serving every other SSL page 
> without requesting a client certificate (before or after 
> authentication). Depending on the configuration I use, one of 2 things 
> happen: either I get a request for a client certificate on ANY HTTPS 
> page I visit first, or I do not get a request at all, never, even when 
> I launch the browser and go straight to the protected page 
> (/my-app-name/public/login/login.xhtml).
> 
> Am I doing something wrong or is this kind of configuration just not 
> possible?

That should be possible but you'll need two security constraints. One to 
require TLS everywhere and one for the pages where you require authentication.

You may also hit issues with which connectors support renegotiation (don't use 
APR).

Mark

> 
> Here is my web.xml security constraint and login config (I've also 
> tried ommitin ):
> 
>   
> 
>   Protected Context
>   /public/login/*
>     
> 
>   CONFIDENTIAL
> 
>   
>   
> CLIENT-CERT
>   
> 
> 
> And here is my server.xml config (I've also tried clientAuth="false" 
> and
> clientAuth="true"):
> 
>   shutdown="SHUTDOWN">
>className="org.apache.catalina.startup.VersionLoggerListener"/>
> 
>   
>className="org.apache.catalina.core.AprLifecycleListener"/>
>   
>   
>   
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
> />
> 
>   
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> name="UserDatabase" pathname="conf/tomcat-users.xml"
> type="org.apache.catalina.UserDatabase"/>
>   
> 
>   
> 
>  redirectPort="443"/>
> 
>  port="443" protocol="org.apache.coyote.http11.Http11Protocol"
> scheme="https" secure="true" sslProtocol="TLS"/>
> 
> 
> 
> 
>   
>  resourceName="UserDatabase"/>
>   
>unpackWARs="true">
>  directory="logs" pattern="%h %l %u %t %r %s %b"
> prefix="localhost_access_log." suffix=".txt"/>
>  reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web"/>
>   
> 
>   
> 
> 
> It is my first Tomcat SSL client cert set up so I must be missing 
> something. Hope you may help me see it :-)
> 
> Cheers,
> 


-
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: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Mark Thomas]

On 06/10/2015 15:46, George Stanchev wrote:
> Mark,
> 
> What are the possible issues with renegotiation? We're on NIO connectors, is 
> there anything known?

NIO should be fine. We've seen odd issues on OSX we haven't been able to
track down.

Mark

> 
> George
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Monday, October 05, 2015 8:32 AM
> To: Tomcat Users List
> Subject: Re: Demand CLIENT-CERT only on certain pages but demand SSL in all 
> pages
> 
> On 05/10/2015 12:05, Gael Abadin wrote:
>> Hello, fellow users.
>>
>> I've been trying to configure tomcat to request client certificate 
>> authentication on a single page, while serving every other SSL page 
>> without requesting a client certificate (before or after 
>> authentication). Depending on the configuration I use, one of 2 things 
>> happen: either I get a request for a client certificate on ANY HTTPS 
>> page I visit first, or I do not get a request at all, never, even when 
>> I launch the browser and go straight to the protected page 
>> (/my-app-name/public/login/login.xhtml).
>>
>> Am I doing something wrong or is this kind of configuration just not 
>> possible?
> 
> That should be possible but you'll need two security constraints. One to 
> require TLS everywhere and one for the pages where you require authentication.
> 
> You may also hit issues with which connectors support renegotiation (don't 
> use APR).
> 
> Mark
> 
>>
>> Here is my web.xml security constraint and login config (I've also 
>> tried ommitin ):
>>
>>   
>> 
>>   Protected Context
>>   /public/login/*
>> 
>> 
>>   CONFIDENTIAL
>> 
>>   
>>   
>> CLIENT-CERT
>>   
>>
>>
>> And here is my server.xml config (I've also tried clientAuth="false" 
>> and
>> clientAuth="true"):
>>
>>  > shutdown="SHUTDOWN">
>>   > className="org.apache.catalina.startup.VersionLoggerListener"/>
>>
>>   
>>   > className="org.apache.catalina.core.AprLifecycleListener"/>
>>   
>>   
>>   
>>   > className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
>>   > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
>>   > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>> />
>>
>>   
>> > factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>> name="UserDatabase" pathname="conf/tomcat-users.xml"
>> type="org.apache.catalina.UserDatabase"/>
>>   
>>
>>   
>>
>> > redirectPort="443"/>
>>
>> > port="443" protocol="org.apache.coyote.http11.Http11Protocol"
>> scheme="https" secure="true" sslProtocol="TLS"/>
>>
>> 
>>
>> 
>>   
>> > resourceName="UserDatabase"/>
>>   
>>   > unpackWARs="true">
>> > directory="logs" pattern="%h %l %u %t %r %s %b"
>> prefix="localhost_access_log." suffix=".txt"/>
>> > reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web"/>
>>   
>> 
>>   
>> 
>>
>> It is my first Tomcat SSL client cert set up so I must be missing 
>> something. Hope you may help me see it :-)
>>
>> Cheers,
>>
> 
> 
> -
> 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

Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Gael Abadin]

Hello, fellow users.

I've been trying to configure tomcat to request client certificate
authentication on a single page, while serving every other SSL page without
requesting a client certificate (before or after authentication). Depending
on the configuration I use, one of 2 things happen: either I get a request
for a client certificate on ANY HTTPS page I visit first, or I do not get a
request at all, never, even when I launch the browser and go straight to
the protected page (/my-app-name/public/login/login.xhtml).

Am I doing something wrong or is this kind of configuration just not
possible?

Here is my web.xml security constraint and login config (I've also tried
ommitin ):

  

  Protected Context
  /public/login/*


  CONFIDENTIAL

  
  
CLIENT-CERT
  


And here is my server.xml config (I've also tried clientAuth="false" and
clientAuth="true"):



  

  
  
  
  
  
  
  
  

  

  

  








  

  
  


  

  


It is my first Tomcat SSL client cert set up so I must be missing
something. Hope you may help me see it :-)

Cheers,

-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.
<http://www.linkedin.com/company/imatia-innovation>
<http://www.youtube.com/imatiainnovation>

.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

Re: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Mark Thomas]

On 05/10/2015 12:05, Gael Abadin wrote:
> Hello, fellow users.
> 
> I've been trying to configure tomcat to request client certificate
> authentication on a single page, while serving every other SSL page without
> requesting a client certificate (before or after authentication). Depending
> on the configuration I use, one of 2 things happen: either I get a request
> for a client certificate on ANY HTTPS page I visit first, or I do not get a
> request at all, never, even when I launch the browser and go straight to
> the protected page (/my-app-name/public/login/login.xhtml).
> 
> Am I doing something wrong or is this kind of configuration just not
> possible?

That should be possible but you'll need two security constraints. One to
require TLS everywhere and one for the pages where you require
authentication.

You may also hit issues with which connectors support renegotiation
(don't use APR).

Mark

> 
> Here is my web.xml security constraint and login config (I've also tried
> ommitin ):
> 
>   
> 
>   Protected Context
>   /public/login/*
> 
> 
>   CONFIDENTIAL
> 
>   
>   
> CLIENT-CERT
>   
> 
> 
> And here is my server.xml config (I've also tried clientAuth="false" and
> clientAuth="true"):
> 
> 
> 
>   
> 
>   
>className="org.apache.catalina.core.AprLifecycleListener"/>
>   
>   
>   
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
> 
>   
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> name="UserDatabase" pathname="conf/tomcat-users.xml"
> type="org.apache.catalina.UserDatabase"/>
>   
> 
>   
> 
>  redirectPort="443"/>
> 
>  port="443" protocol="org.apache.coyote.http11.Http11Protocol"
> scheme="https" secure="true" sslProtocol="TLS"/>
> 
> 
> 
> 
>   
>  resourceName="UserDatabase"/>
>   
>unpackWARs="true">
>  directory="logs" pattern="%h %l %u %t %r %s %b"
> prefix="localhost_access_log." suffix=".txt"/>
>  reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web"/>
>   
> 
>   
> 
> 
> It is my first Tomcat SSL client cert set up so I must be missing
> something. Hope you may help me see it :-)
> 
> Cheers,
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Switching basic auth to client-cert with realms - how?

[Neven Cvetkovic]

Graham,

On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett minf...@sharp.fm wrote:

 Hi all,

 I have a basic authentication setup that works great as below.

 login-config
 auth-methodBASIC/auth-method
 realm-namePatricia/realm-name
 /login-config

 !-- Security roles referenced by this web application --
 security-role
 role-nameadministrator/role-name
 /security-role
 security-role
 role-nameunderwriter/role-name
 /security-role
 security-role
 role-nameaccountant/role-name
 /security-role
 security-role
 role-namebroker/role-name
 /security-role
 security-role
 role-namefeeds/role-name
 /security-role

 It is backed up with a realm like this:

   Realm className=“org.apache.catalina.realm.DataSourceRealm
  [snip]
  userTable=person userNameCol=mail
  userCredCol=user_password
  userRoleTable=company_person roleNameCol=serial /

 I need to switch basic authentication to client certificates, as provided
 by Apache httpd and proxied in with AJP. The username is provided by Apache
 httpd in REMOTE_USER.

 In theory, changing the auth-method to CLIENT-CERT should do the trick,
 but I just get forbidden.

 What doesn’t seem to fit is the realm definition - specifying userCredCol
 is marked as mandatory, but this is obviously not present with a client
 certificate. What do you specify in this field?

 Does anyone have a working example of authentication using client
 certificates and authorization using a realm backed with a DataSource?


Here's a nice article, detailing how to add CLIENT-CERT:
http://java.dzone.com/articles/enabling-client-cert-based

It is based on MemoryRealm, not DataSourceRealm, but the idea is similar.

Here's a summary:

1. You need to define user/pass/roles:

role rolename=secureconn/
user username=CN=client1, OU=Application Development, O=GoSmarter,
L=Bangalore, ST=KA, C=IN password=null  roles=secureconn/

2. You define in web.xml the login type:
login-config
auth-methodCLIENT-CERT/auth-method
realm-nameDemo App/realm-name
/login-config

You would get a 403 if an invalid certificate is sent based on the security
constraints you set earlier.

Ultimately, you need to turn on extra logging on that realm so you would
know why the 403s were generated.

Try doing some online searching for the type of errors you got. Here's what
pops up in my quick google search:
http://stackoverflow.com/questions/5086457/setting-up-client-cert-authentication-with-roles-on-tomcat-6-0

This person had an issue how CNs were handled, and as a result extra
inserted spaces between commas, e.g.
(1) no spaces: CN=testuser,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
(2) with spaces: CN=testuser, O=Internet Widgits Pty Ltd, ST=Some-State,
C=AU

The issue was how X509Principal.getName() call returned:
X500Principal.RFC2253
X500Principal.RFC1779

Let us know what you find by turning on extra logging.

Cheers!
Neven

Re: Switching basic auth to client-cert with realms - how?

[Neven Cvetkovic]

Graham,

On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett minf...@sharp.fm wrote:

 What doesn’t seem to fit is the realm definition - specifying userCredCol
 is marked as mandatory, but this is obviously not present with a client
 certificate. What do you specify in this field?


You define the password column, which could have NULL values now, since we
don't use passwords anymore.



 Does anyone have a working example of authentication using client
 certificates and authorization using a realm backed with a DataSource?



 Try doing some online searching for the type of errors you got. Here's
 what pops up in my quick google search:

 http://stackoverflow.com/questions/5086457/setting-up-client-cert-authentication-with-roles-on-tomcat-6-0


Here's another interesting article that tackles the old version of Tomcat,
but the ideas are very similar. Here's a link:
http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

Summary:

User Names
The user name column should contain the certificate subject's distinguished
name, as a character string. Unfortunately, the method Tomcat uses to
obtain this string produces an implementation-dependent result, so it's
possible if you were to switch to a new security provider or even just
upgrade your Java runtime, you might need to map your user names to a new
form. You'll have to test your deployment to find out what format is used.

Specifically, getName() is called on the Principal returned by
X509Certificate.getSubjectDN() to obtain a String, which is used as the
user name. If you read the documentation, you'll find that this is no
longer the best approach.

Authentication
The simplest set up would be to load your trust anchors into Tomcat's trust
store, which is configured in the server.xml file. With this setup, any
client certificate chain that is root in one of your trusted CAs will be
considered authenticated, and rightly so—authentication means that an
identity is known, and is distinct from authorization, which determines
what that identity is allowed to do.

Authorization
Since anyone with a signed certificate will be authenticated, you need to
set up roles in order to protect private resources in your application.
This is done by setting up security constraints, associated with roles, in
your web.xml file. Then, in your database, populate the roles table to
grant trusted users with extra roles.

The relationship between the user table and the roles table works exactly
as it would with FORM-based authorization, and should be utilized to grant
appropriate permissions to users that you trust.

A Note on Passwords
The JDBCRealm will create a new Principal, which does carry a password, but
unless your application downcasts this Principal to the Tomcat-specific
implementation (GenericPrincipal), this property won't be visible to you,
and it doesn't really matter what you put in that column. I recommend NULL.

In other words, when using JDBCRealm with client-auth, the password field
is ignored. This GenericPrincipal has a method to access an underlying
principal, but unfortunately, the Principal from the certificate is not
passed along; the JDBCRealm will set it to null; the only useful method in
this scenario might be getName() (returning the subject DN is some possibly
non-standard form).

Table Structure and Content
Use exactly the same table structure you would for a FORM-based JDBCRealm
(or DatasourceRealm). The only difference will be in the content. The user
name will be a text representation of the subject distinguished name, and
the password will be NULL or some dummy value.

I don't know how much of it is still relevant in Tomcat7/Tomcat8.

By the way, what platform, what JVM and what version of Tomcat do you run?

Hope that helps!

Cheers!
Neven

Re: Switching basic auth to client-cert with realms - how?

[Graham Leggett]

On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com wrote:

 What doesn’t seem to fit is the realm definition - specifying userCredCol
 is marked as mandatory, but this is obviously not present with a client
 certificate. What do you specify in this field?
 
 
 You define the password column, which could have NULL values now, since we
 don't use passwords anymore.

I don’t follow, do you mean I shouldn’t define the password column?

 Here's another interesting article that tackles the old version of Tomcat,
 but the ideas are very similar. Here's a link:
 http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

I’ve already found all of these, and have trawled through them to no avail. It 
appears all the information is stale.

I am currently stuck on two specific areas:

- None of the debug logging seems to work any more in any kind of predictable 
fashion, as detailed in my other message.
- Turning on SQL statement logging in postgres shows that at no point is any 
SQL statement executed against the database.

If I had some kind of meaningful error that accompanied the 403 it would be a 
huge help.

Is anyone able to confirm where I might place a breakpoint to step through the 
tomcat code?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Switching basic auth to client-cert with realms - how?

[Graham Leggett]

Hi all,

I have a basic authentication setup that works great as below.

login-config
auth-methodBASIC/auth-method
realm-namePatricia/realm-name
/login-config

!-- Security roles referenced by this web application --
security-role
role-nameadministrator/role-name
/security-role
security-role
role-nameunderwriter/role-name
/security-role
security-role
role-nameaccountant/role-name
/security-role
security-role
role-namebroker/role-name
/security-role
security-role
role-namefeeds/role-name
/security-role

It is backed up with a realm like this:

  Realm className=“org.apache.catalina.realm.DataSourceRealm
 [snip]
 userTable=person userNameCol=mail
 userCredCol=user_password
 userRoleTable=company_person roleNameCol=serial /

I need to switch basic authentication to client certificates, as provided by 
Apache httpd and proxied in with AJP. The username is provided by Apache httpd 
in REMOTE_USER.

In theory, changing the auth-method to CLIENT-CERT should do the trick, but I 
just get forbidden.

What doesn’t seem to fit is the realm definition - specifying userCredCol is 
marked as mandatory, but this is obviously not present with a client 
certificate. What do you specify in this field?

Does anyone have a working example of authentication using client certificates 
and authorization using a realm backed with a DataSource?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Switching basic auth to client-cert with realms - how?

[Neven Cvetkovic]

Graham,

On Fri, Mar 13, 2015 at 4:49 PM, Graham Leggett minf...@sharp.fm wrote:

 On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com
 wrote:

  What doesn’t seem to fit is the realm definition - specifying
 userCredCol
  is marked as mandatory, but this is obviously not present with a client
  certificate. What do you specify in this field?
 
 
  You define the password column, which could have NULL values now, since
 we
  don't use passwords anymore.

 I don’t follow, do you mean I shouldn’t define the password column?


According to my understanding - password field will be irrelevant. Since we
use certificates to authenticate, not username/password combo. Thus, keep
the field as is.


  Here's another interesting article that tackles the old version of
 Tomcat,
  but the ideas are very similar. Here's a link:
 
 http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

 I’ve already found all of these, and have trawled through them to no
 avail. It appears all the information is stale.

 Yes, indeed - most of the info on these pages is very stale. Once we
resolve it, we should add a nice article about this, and add to Tomcat Wiki
:)))


 I am currently stuck on two specific areas:

 - None of the debug logging seems to work any more in any kind of
 predictable fashion, as detailed in my other message.


From your other log files (your last email in the other thread) - it seems
your pages are not secured at all, e.g.
FINE:  Not subject to any constraint

Do you have security-constraint defined in your web.xml?


 - Turning on SQL statement logging in postgres shows that at no point is
 any SQL statement executed against the database.


Well, we are not hitting the database yet, as secured page was not hit yet
- just unsecured / - judging from your provided log files.

That's why I would first make sure the logging does work properly with the
other login method (BASIC/FORM), just to make sure you can see stuff being
logged.

Then you can switch to new CLIENT-CERT, and troubleshoot the problem.


 If I had some kind of meaningful error that accompanied the 403 it would
 be a huge help.

 Is anyone able to confirm where I might place a breakpoint to step through
 the tomcat code?


I would try constructors on RealmBase, AuthenticatorBase base classes or
their derived subclasses, e.g. BasicAuthenticator, SSLAuthenticator,
DataSourceRealm.

Try also - the authenticate() method on the DataSourceRealm ... that's
probably going to be called at some point :))

Hope that helps!

Cheers!
Neven

Re: Client-cert, ciphers, and proxies

[Mark Thomas]

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

[Christopher Schultz]

-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

Client-cert, ciphers, and proxies

[Gary Briggs]

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

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?

Thanks!
Gary

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Cannot retrieve client cert when requesting javax.net.ssl.peer_certificates

[Bryant Panyarachun]

Hi all,

I am upgrading from Tomcat 6.0.18 to 7.0.21 (32-bit Win zip).

Previously, when requesting a client certificate I would use:

X509Certificate[] certs =
(X509Certificate[])req.getAttribute(javax.net.ssl.peer_certificates);

However, after upgrading to 7.0.21 this no longer works. Instead it returns
null.

However, I can retrieve the client certificate when I use:

X509Certificate[] certs =
(X509Certificate[])req.getAttribute(javax.servlet.request.X509Certificate);

I'm curious as to why the javax.net.ssl.peer_certificates parameter no
longer works in this case. Is it an issue cause by a Tomcat regression
change?

Re: Cannot retrieve client cert when requesting javax.net.ssl.peer_certificates

[Mark Thomas]

On 14/10/2011 18:47, Bryant Panyarachun wrote:
 Hi all,
 
 I am upgrading from Tomcat 6.0.18 to 7.0.21 (32-bit Win zip).
 
 Previously, when requesting a client certificate I would use:
 
 X509Certificate[] certs =
 (X509Certificate[])req.getAttribute(javax.net.ssl.peer_certificates);
 
 However, after upgrading to 7.0.21 this no longer works. Instead it returns
 null.
 
 However, I can retrieve the client certificate when I use:
 
 X509Certificate[] certs =
 (X509Certificate[])req.getAttribute(javax.servlet.request.X509Certificate);
 
 I'm curious as to why the javax.net.ssl.peer_certificates parameter no
 longer works in this case. Is it an issue cause by a Tomcat regression
 change?

I don't see that parameter anywhere in the servlet specification.
Neither do I see it in the Tomcat code base.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Cannot retrieve client cert when requesting javax.net.ssl.peer_certificates

[Caldarale, Charles R]

 From: Mark Thomas [mailto:ma...@apache.org] 
 Subject: Re: Cannot retrieve client cert when requesting 
 javax.net.ssl.peer_certificates

 I don't see that parameter anywhere in the servlet specification.

It was in the 2.1 spec for ServletRequest, but seems to have disappeared 
somewhere along the way.

http://download.oracle.com/docs/cd/E17802_01/products/products/servlet/2.1/api/javax.servlet.ServletRequest.html#getAttribute%28javax.servlet.String%29

It's still mentioned in some docs for other app servers.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cannot retrieve client cert when requesting javax.net.ssl.peer_certificates

[Bryant Panyarachun]

Right, I have only been able to find a reference to it in the 2.1 servlet
specification as well.

On Fri, Oct 14, 2011 at 12:27 PM, Caldarale, Charles R 
chuck.caldar...@unisys.com wrote:

  From: Mark Thomas [mailto:ma...@apache.org]
  Subject: Re: Cannot retrieve client cert when requesting
 javax.net.ssl.peer_certificates

  I don't see that parameter anywhere in the servlet specification.

 It was in the 2.1 spec for ServletRequest, but seems to have disappeared
 somewhere along the way.


 http://download.oracle.com/docs/cd/E17802_01/products/products/servlet/2.1/api/javax.servlet.ServletRequest.html#getAttribute%28javax.servlet.String%29

 It's still mentioned in some docs for other app servers.

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Bryant Panyarachun
bpanyarac...@gmail.com
(661)644-5174

CLIENT-CERT configuration doesn't work for servlet.

[Kannan J]

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?
 
Thanks
Kannan 

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

[Kannan J]

 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

Error Tomcat CLIENT-CERT autentication.

[amcereijo cereijo]

Hi,


I´m trying to configure the tomcat for mutual authentication  with server
and client using certificate.

I have a tomcat 5.5.26 and a java web application (web service) under JVM
1.5

I did the next:



I generated two certificates with keytool, one for client and other for
server.

I created a cacerts importing  for the server, the client certificate and
for the client, importing the server certificate.



In my web application (web service), I configure the web.xml like this

***security-constraint*

* web-resource-collection*

*web-resource-namewebservice**/**
web-resource-name*

*url-pattern/webservice**/**url-pattern*

*http-methodPOST**/**http-method*

* **/**web-resource-collection*

* ***

* auth-constraint*

*role-namewebservice**/**role-name*

* **/**auth-constraint*

* ***

* user-data-constraint*

*   transport-guaranteeCONFIDENTIAL**/**
transport-guarantee*

* **/**user-data-constraint*

* ***

*   **/**security-constraint*

* *

*   login-config*

* **!-- auth-methodBASIC/auth-method --***

* auth-methodCLIENT-CERT**/**auth-method*

* realm-namewebservice** /**realm-name*

*   **/**login-config*

* *

*   security-role*

* role-namewebservice**/**role-name*

*   **/**security-role*



I configure the server.xml adding

*Connector port=8443 maxHttpHeaderSize=8192*

*   protocol=HTTP/1.1*

*   SSLEnabled=true*

*   maxThreads=150
minSpareThreads=25 maxSpareThreads=75*

*   enableLookups=false
disableUploadTimeout=true*

*   acceptCount=100
scheme=https secure=true*

*   clientAuth=true
sslProtocol=TLS *

*   keystoreFile=C:\Archivos de
programa\Apache Software Foundation\Tomcat 5.5\conf\tomcatserver.keystore*

*   keystorePass=tomcat*

*
keyAlias=tomcatcertlocalhost*

*   keypass=tomcat*

*   truststoreFile=C:\Archivos
de programa\Apache Software Foundation\Tomcat
5.5\conf\tomcatservercacerts.keystore*

*   truststorePass=tomcat*

*/*



I add in tomcat-users.xml the following

*role rolename=webservice/*

*user username=CN=client, OU=client, O=client, L=Madrid, ST=Madrid, C=ES
password=null roles=webservice/*



When I execute my client for call the webservice, I put the properties

*System.setProperty(**javax.net.ssl.trustStore**,**C:/Program
Files/Apache Software Foundation/Tomcat 5.5/conf/truststore.keystore**);***

* System.setProperty(**javax.net.ssl.trustStorePassword**,**
tomcat**);***

*   ***

*   System.setProperty(**javax.net.ssl.keyStore**,
**C:/OpenSSL-Win32/bin/ssl/client/client1.p12**);***

*   System.setProperty(**
javax.net.ssl.keyStorePassword**,**tomcat**);***

*   System.setProperty(**
javax.net.ssl.keyStoreType**,**PKCS12**);*



In server logs I get the error:


*17-ene-2011 13:20:34 org.apache.coyote.http11.Http11Processor action*

*ADVERTENCIA: Exception getting SSL attributes*

*javax.net.ssl.SSLHandshakeException: null cert chain*

*   at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
Source)*

*   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)*

*   at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)*

*   at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)*

*   at
com.sun.net.ssl.internal.ssl.ServerHandshaker.clientCertificate(Unknown
Source)*

*   at
com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown Source)
*

*   at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown
Source)*

*   at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown
Source)*

*   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown
Source)*

*   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown
Source)*

*   at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)*

*   at java.io.InputStream.read(Unknown Source)*

*   at
org.apache.tomcat.util.net.jsse.JSSE14Support.synchronousHandshake(JSSE14Support.java:88)
*

*   at
org.apache.tomcat.util.net.jsse.JSSE14Support.handShake

Re: Error Tomcat CLIENT-CERT autentication.

[Goo Sam Kong]

Hi Angel,

I encountered the same problem as you with Tomcat 5.5.27, so I upgraded to
latest Tomcat to get rid of the certification error.

https://issues.apache.org/bugzilla/show_bug.cgi?id=37869 is bug report on
certification error.

Thank you.


On 17 January 2011 22:14, amcereijo cereijo amcere...@gmail.com wrote:

 Hi,


 I´m trying to configure the tomcat for mutual authentication  with server
 and client using certificate.

 I have a tomcat 5.5.26 and a java web application (web service) under JVM
 1.5

 I did the next:



 I generated two certificates with keytool, one for client and other for
 server.

 I created a cacerts importing  for the server, the client certificate and
 for the client, importing the server certificate.



 In my web application (web service), I configure the web.xml like this

 ***security-constraint*

 * web-resource-collection*

 *web-resource-namewebservice**/**
 web-resource-name*

 *
  url-pattern/webservice**/**url-pattern*

 *http-methodPOST**/**http-method*

 * **/**web-resource-collection*

 * ***

 * auth-constraint*

 *role-namewebservice**/**role-name*

 * **/**auth-constraint*

 * ***

 * user-data-constraint*

 *   transport-guaranteeCONFIDENTIAL**/**
 transport-guarantee*

 * **/**user-data-constraint*

 * ***

 *   **/**security-constraint*

 * *

 *   login-config*

 * **!-- auth-methodBASIC/auth-method --***

 * auth-methodCLIENT-CERT**/**auth-method*

 * realm-namewebservice** /**realm-name*

 *   **/**login-config*

 * *

 *   security-role*

 * role-namewebservice**/**role-name*

 *   **/**security-role*



 I configure the server.xml adding

 *Connector port=8443 maxHttpHeaderSize=8192*

 *   protocol=HTTP/1.1*

 *   SSLEnabled=true*

 *   maxThreads=150
 minSpareThreads=25 maxSpareThreads=75*

 *   enableLookups=false
 disableUploadTimeout=true*

 *   acceptCount=100
 scheme=https secure=true*

 *   clientAuth=true
 sslProtocol=TLS *

 *   keystoreFile=C:\Archivos
 de
 programa\Apache Software Foundation\Tomcat 5.5\conf\tomcatserver.keystore*

 *   keystorePass=tomcat*

 *
 keyAlias=tomcatcertlocalhost*

 *   keypass=tomcat*

 *   truststoreFile=C:\Archivos
 de programa\Apache Software Foundation\Tomcat
 5.5\conf\tomcatservercacerts.keystore*

 *   truststorePass=tomcat*

 */*



 I add in tomcat-users.xml the following

 *role rolename=webservice/*

 *user username=CN=client, OU=client, O=client, L=Madrid, ST=Madrid, C=ES
 password=null roles=webservice/*



 When I execute my client for call the webservice, I put the properties

 *System.setProperty(**javax.net.ssl.trustStore**,**C:/Program
 Files/Apache Software Foundation/Tomcat
 5.5/conf/truststore.keystore**);***

 * System.setProperty(**javax.net.ssl.trustStorePassword**,**
 tomcat**);***

 *   ***

 *
 System.setProperty(**javax.net.ssl.keyStore**,
 **C:/OpenSSL-Win32/bin/ssl/client/client1.p12**);***

 *   System.setProperty(**
 javax.net.ssl.keyStorePassword**,**tomcat**);***

 *   System.setProperty(**
 javax.net.ssl.keyStoreType**,**PKCS12**);*



 In server logs I get the error:


 *17-ene-2011 13:20:34 org.apache.coyote.http11.Http11Processor action*

 *ADVERTENCIA: Exception getting SSL attributes*

 *javax.net.ssl.SSLHandshakeException: null cert chain*

 *   at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
 Source)*

 *   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown
 Source)*

 *   at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)*

 *   at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)*

 *   at
 com.sun.net.ssl.internal.ssl.ServerHandshaker.clientCertificate(Unknown
 Source)*

 *   at
 com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown
 Source)
 *

 *   at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown
 Source)*

 *   at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown
 Source)*

 *   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown
 Source

Re: Error Tomcat CLIENT-CERT autentication.

[amcereijo cereijo]

Hi,
Finally I did it works.
I changed a piece of code for validating local certificates that i found
looking for in internet:

*private static void localHostNameVerifi() throws Exception{*
* HostnameVerifier hv = new HostnameVerifier()*
*{*
*public boolean verify(String urlHostName, SSLSession session)*
*{*
*System.out.println(Warning: URL Host:  + urlHostName +  vs.
*
*+ session.getPeerHost());*
*return true;*
*}*
*};*
* trustAllHttpsCertificates();*
* HttpsURLConnection.setDefaultHostnameVerifier(hv);*
* }*
* *
* *
*public static class miTM implements javax.net.ssl.TrustManager,*
*javax.net.ssl.X509TrustManager*
*{*
*public java.security.cert.X509Certificate[] getAcceptedIssuers()*
*{*
*return null;*
*}*
* *
*public boolean isServerTrusted(*
*java.security.cert.X509Certificate[] certs)*
*{*
*return true;*
*}*
* *
*public boolean isClientTrusted(*
*java.security.cert.X509Certificate[] certs)*
*{*
*return true;*
*}*
* *
*public void checkServerTrusted(*
*java.security.cert.X509Certificate[] certs, String
authType)*
*throws java.security.cert.CertificateException*
*{*
*return;*
*}*
* *
*public void checkClientTrusted(*
*java.security.cert.X509Certificate[] certs, String
authType)*
*throws java.security.cert.CertificateException*
*{*
*return;*
*}*
*}*
* private static void trustAllHttpsCertificates() throws Exception*
*{*
* *
*//  Create a trust manager that does not validate certificate
chains:*
* *
*javax.net.ssl.TrustManager[] trustAllCerts =*
* *
*new javax.net.ssl.TrustManager[1];*
* *
*javax.net.ssl.TrustManager tm = new miTM();*
* *
*trustAllCerts[0] = tm;*
* *
*javax.net.ssl.SSLContext sc =*
* *
*javax.net.ssl.SSLContext.getInstance(SSL);*
* *
*sc.init(null, trustAllCerts, null);*
* *
*javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(*
* *
*sc.getSocketFactory());*
* *
*}*


For this code (get on SCJWS guide by Ivan A Kirzsan):

   * static{*
*  HttpsURLConnection.setDefaultHostnameVerifier(new
HostnameVerifier() {*
* public boolean verify(String hostname, SSLSession session) {*
* if(hostname.equals(localhost)){*
* return true;*
* }*
* return false;*
* }*
*
*
* });*
*   }*


Now, almost in local, it´s working perfect.

Thanks, regards. Ángel.

2011/1/18 Goo Sam Kong skgo...@gmail.com

 Hi Angel,

 I encountered the same problem as you with Tomcat 5.5.27, so I upgraded to
 latest Tomcat to get rid of the certification error.

 https://issues.apache.org/bugzilla/show_bug.cgi?id=37869 is bug report on
 certification error.

 Thank you.


 On 17 January 2011 22:14, amcereijo cereijo amcere...@gmail.com wrote:

  Hi,
 
 
  I´m trying to configure the tomcat for mutual authentication  with server
  and client using certificate.
 
  I have a tomcat 5.5.26 and a java web application (web service) under JVM
  1.5
 
  I did the next:
 
 
 
  I generated two certificates with keytool, one for client and other for
  server.
 
  I created a cacerts importing  for the server, the client certificate and
  for the client, importing the server certificate.
 
 
 
  In my web application (web service), I configure the web.xml like this
 
  ***security-constraint*
 
  * web-resource-collection*
 
  *web-resource-namewebservice**/**
  web-resource-name*
 
  *
   url-pattern/webservice**/**url-pattern*
 
  *http-methodPOST**/**http-method*
 
  * **/**web-resource-collection*
 
  * ***
 
  * auth-constraint*
 
  *role-namewebservice**/**role-name*
 
  * **/**auth-constraint*
 
  * ***
 
  * user-data-constraint*
 
  *   transport-guaranteeCONFIDENTIAL**/**
  transport-guarantee*
 
  * **/**user-data-constraint*
 
  * ***
 
  *   **/**security-constraint*
 
  * *
 
  *   login-config*
 
  * **!-- auth-methodBASIC/auth-method --***
 
  * auth-methodCLIENT-CERT**/**auth-method*
 
  * realm-namewebservice** /**realm-name*
 
  *   **/**login-config*
 
  * *
 
  *   security-role*
 
  * role-namewebservice**/**role-name*
 
  *   **/**security-role*
 
 
 
  I configure the server.xml adding
 
  *Connector port=8443 maxHttpHeaderSize=8192*
 
  *   protocol=HTTP/1.1

Re: Client not able with perform client-cert authentication with Tomcat 6.0.29 on APR

[Goo Sam Kong]

Hi Mark,

Thank you for the settings. I am not sure what is the APR/native connector
version, I am using the default APR/native connector in 6.0.29 (I do not
set/change APR on my Windows machine).

I am not sure why the client certificate authentication failed when my
client certificate was signed with SHA256 but client certificate
authentication worked perfectly when client certificate was signed with
SHA1.

From http://old.nabble.com/SHA256-digest-windows-0.9.8k--td26123008.html, it
mentioned developer required to include a call to
OpenSSL_add_all_algorithms()
instead calling SSL_library_init() which only adds the more commonly uses
SSL
algorithms. I am not sure where should I include this.

Can you advice how to solve my problem?

My APR connector settings:
Connector port=8443
   protocol=org.apache.coyote.http11.Http11AprProtocol
   SSLEnabled=true
   maxThreads=150
   scheme=https
   secure=true
   SSLCertificateFile=C:\usr\tomcat\tomcat.crt
   SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key
   SSLVerifyClient=optional
   SSLVerifyDepth=1
   SSLCipherSuite=AES128-SHA:DES-CBC3-SHA
   SSLCACertificateFile=C:\usr-files\client-cert-ca.crt /

On 13 November 2010 00:38, Mark Thomas ma...@apache.org wrote:

 On 12/11/2010 16:27, Goo Sam Kong wrote:
  Hi
 
  I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.

 APR/native connector version? SSL re-negotiation wasn't supported until
 recently and the CVE-2009-3555 fixes further complicate things.

  Connector SSLCACertificateFile=C:\usr-files\client-cert-ca.crt
 SSLCertificateFile=C:\usr\tomcat\tomcat.crt
 SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key
 SSLCipherSuite=AES128-SHA:DES-CBC3-SHA
 SSLEnabled=true
 SSLEngine=on
 SSLVerifyClient=optional
 maxThreads=150
 port=8443
 protocol=HTTP/1.1
 scheme=https
 secure=true
 sslProtocol=TLS /

 Is SSLEngine a valid attribute here? I don't see it in the Connector docs.
 SSLVerifyClient=optional can (should?) be removed.
 Is that SSLCipherSuite compatible with your client? Try removing that
 setting until everything else is working.

 The following settings are known to work:

 Connector
  port=8443
  protocol=org.apache.coyote.http11.Http11AprProtocol
  SSLEnabled=true
  maxThreads=150
  scheme=https
  secure=true
  SSLCertificateFile=${catalina.base}/conf/tomcathost-cert.pem
  SSLCertificateKeyFile=${catalina.base}/conf/tomcathost-key.pem
  SSLCACertificateFile=${catalina.base}/conf/cacert.pem /

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Client not able with perform client-cert authentication with Tomcat 6.0.29 on APR

[Goo Sam Kong]

Hi

I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.

I changed server.xml as below.

?xml version=1.0 encoding=UTF-8?
Server port=8005 shutdown=SHUTDOWN

!--APR library loader. Documentation at /docs/apr.html --
Listener SSLEngine=on
className=org.apache.catalina.core.AprLifecycleListener /
Listener className=org.apache.catalina.core.JasperListener /
!-- Prevent memory leaks due to use of particular java/javax APIs--
Listener
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
/
Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /

GlobalNamingResources
Resource auth=Container description=User database that can be
updated and saved
factory=org.apache.catalina.users.MemoryUserDatabaseFactory
name=UserDatabase
pathname=conf/tomcat-users.xml
type=org.apache.catalina.UserDatabase /
/GlobalNamingResources

Service name=Catalina

Connector connectionTimeout=2 port=8080 protocol=HTTP/1.1
redirectPort=8443 /
Connector SSLCACertificateFile=C:\usr-files\client-cert-ca.crt
SSLCertificateFile=C:\usr\tomcat\tomcat.crt
SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key
SSLCipherSuite=AES128-SHA:DES-CBC3-SHA SSLEnabled=true
SSLEngine=on
SSLVerifyClient=optional maxThreads=150 port=8443
protocol=HTTP/1.1 scheme=https secure=true
sslProtocol=TLS /

Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /


Engine defaultHost=localhost name=Catalina
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase /

Host appBase=webapps autoDeploy=true name=localhost
unpackWARs=true xmlNamespaceAware=false
xmlValidation=false

Context docBase=cert path=/cert reloadable=true
source=org.eclipse.jst.j2ee.server:cert /
Context docBase=crl path=/crl reloadable=true
source=org.eclipse.jst.j2ee.server:crl /
Context docBase=tdci-2.5.0 path=/tdci-2.5.0
reloadable=true
source=org.eclipse.jst.j2ee.server:tdci-2.5.0 /
/Host
/Engine
/Service
/Server

*My **Java **XML-RPC client thrown exception below:*
Exception in thread main java.net.SocketException: Software caused
connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at
com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(OutputRecord.java:283)
at
com.sun.net.ssl.internal.ssl.OutputRecord.write(OutputRecord.java:272)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:666)
at
com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:584)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:698)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:624)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:160)
at
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:839)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at org.apache.xmlrpc.DefaultXmlRpcTransport.sendXmlRpc(Unknown Source)
at org.apache.xmlrpc.XmlRpcClientWorker.execute(Unknown Source)
at org.apache.xmlrpc.XmlRpcClient.execute(Unknown Source)
at
TdciXmlRpcCertAuthClient.requestWebIssuanceKey(TdciXmlRpcCertAuthClient.java:166)
at TdciXmlRpcCertAuthClient.main(TdciXmlRpcCertAuthClient.java:63)

Please help.

Thank you.

SamKong Goo

Re: Client not able with perform client-cert authentication with Tomcat 6.0.29 on APR

[Mark Thomas]

On 12/11/2010 16:27, Goo Sam Kong wrote:
 Hi
 
 I am running Tomcat 6.0.29 with JDK 1.6.0_22 on Windows XP.

APR/native connector version? SSL re-negotiation wasn't supported until
recently and the CVE-2009-3555 fixes further complicate things.

 Connector SSLCACertificateFile=C:\usr-files\client-cert-ca.crt
SSLCertificateFile=C:\usr\tomcat\tomcat.crt
SSLCertificateKeyFile=C:\usr\tomcat\tomcat.key
SSLCipherSuite=AES128-SHA:DES-CBC3-SHA
SSLEnabled=true
SSLEngine=on
SSLVerifyClient=optional
maxThreads=150
port=8443
protocol=HTTP/1.1
scheme=https
secure=true
sslProtocol=TLS /

Is SSLEngine a valid attribute here? I don't see it in the Connector docs.
SSLVerifyClient=optional can (should?) be removed.
Is that SSLCipherSuite compatible with your client? Try removing that
setting until everything else is working.

The following settings are known to work:

Connector
  port=8443
  protocol=org.apache.coyote.http11.Http11AprProtocol
  SSLEnabled=true
  maxThreads=150
  scheme=https
  secure=true
  SSLCertificateFile=${catalina.base}/conf/tomcathost-cert.pem
  SSLCertificateKeyFile=${catalina.base}/conf/tomcathost-key.pem
  SSLCACertificateFile=${catalina.base}/conf/cacert.pem /

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Client cert authentication

[acastanheira2001]

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

[Jason Pyeron]

 

 -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

[acastanheira2001]

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

[Mark Thomas]

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

Client cert authentication

[acastanheira2001]

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?

Thanks, 
André
-- 
View this message in context: 
http://old.nabble.com/Client-cert-authentication-tp28287654p28287654.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

[Mark Thomas]

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: Trouble with CLIENT-CERT authentication method

[Martin Gainty]

could you clarify if this failure is from client to server or server to client?
and who/what is generating the cert?


thanks,
Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.



 

 Date: Tue, 23 Feb 2010 15:07:03 -0800
 Subject: Re: Trouble with CLIENT-CERT authentication method
 From: kevmacmi...@gmail.com
 To: users@tomcat.apache.org
 
 On 2/19/10, Christopher Schultz ch...@christopherschultz.net wrote:
  So, with clientAuth=false, how do you get a client certificate to use
  for authentication? Or, does the presence of the CLIENT-CERT in web.xml
  trigger an SSL-renegotiation where the client cert /is/ requested from
  the client.
 
 The presence of CLIENT-CERT:
 
 login-config
 auth-methodCLIENT-CERT/auth-method
 /login-config
 
 in web.xml triggers the renegotiation and the client cert is requested
 from the client. As Mark pointed out, this exposes the TLS bug
 CVE-2009-355 so be warned!
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/

Re: Trouble with CLIENT-CERT authentication method

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin,

On 2/23/2010 6:07 PM, Kevin Mills wrote:
 On 2/19/10, Christopher Schultz ch...@christopherschultz.net wrote:
 So, with clientAuth=false, how do you get a client certificate to use
 for authentication? Or, does the presence of the CLIENT-CERT in web.xml
 trigger an SSL-renegotiation where the client cert /is/ requested from
 the client.
 
 The presence of CLIENT-CERT:
 
  login-config
  auth-methodCLIENT-CERT/auth-method
  /login-config
 
 in web.xml triggers the renegotiation and the client cert is requested
 from the client.  As Mark pointed out, this exposes the TLS bug
 CVE-2009-355 so be warned!

So, setting auth-method to CLIENT-CERT triggers an SSL renegotiation.
What if the Connector is set to clientAuth=want or
clientAuth=true? Will the initial SSL negotiation carry the client
certificate and therefore avoid CVE-2009-355?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuFP6gACgkQ9CaO5/Lv0PAs6gCZAXQ5c1cbjbw8U48p527U08h9
wukAmwZ40uKqBalI+W21EvMrloxLM3Hx
=bTUA
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Mark Thomas]

On 24/02/2010 15:03, Christopher Schultz wrote:

So, settingauth-method  to CLIENT-CERT triggers an SSL renegotiation.
What if theConnector  is set to clientAuth=want or
clientAuth=true? Will the initial SSL negotiation carry the client
certificate and therefore avoid CVE-2009-355?


Yes. But test carefully as there is a wide variety in client behaviour. 
I've heard reports of some mobile clients renegotiating every few 
requests. A real case of YMMV.


Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Kevin Mills]

On 2/19/10, Christopher Schultz ch...@christopherschultz.net wrote:
 So, with clientAuth=false, how do you get a client certificate to use
 for authentication? Or, does the presence of the CLIENT-CERT in web.xml
 trigger an SSL-renegotiation where the client cert /is/ requested from
 the client.

The presence of CLIENT-CERT:

 login-config
 auth-methodCLIENT-CERT/auth-method
 /login-config

in web.xml triggers the renegotiation and the client cert is requested
from the client.  As Mark pointed out, this exposes the TLS bug
CVE-2009-355 so be warned!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason,

On 2/19/2010 1:48 AM, Jason Brittain wrote:
 Nope.  clientAuth=false means that the webapp's web.xml specifies which
 resources require the client certificate.

Gotcha: I thought that false would cause the connector to ignore all
client cert info, while want would collect it but not process it,
while true would perform the checks for you.

Instead, false and want are essentially the same (right?) and true
does the checks for you. If you have want or false, plus a
web-resource-collection that demands CLIENT-AUTH, then it will be used
for identification purposes, but not actually checked against a valid
certificate chain.

Do I have that right?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt+wY0ACgkQ9CaO5/Lv0PDbcwCeMk2ae1G85O64nNhCU/orDBxK
Qg4An3sHZYQ68DAB5KEWTsW65zugvSBK
=cbwC
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Kevin Mills]

On 2/18/10, Christopher Schultz ch...@christopherschultz.net wrote:

 Stupid question: don't you want clientAuth=true?


In this particular case, no.  I don't want to force client certificate
authentication for all SSL connections coming to port 8443.  Instead,
I am looking to do client certificate authentication on a per-webapp
basis.  As Mark pointed out, however, this opens up a potential
man-in-the-middle attack so I'm still investigating other ways to
accomplish this.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Kevin Mills]

On 2/19/10, Christopher Schultz ch...@christopherschultz.net wrote:
 On 2/19/2010 1:48 AM, Jason Brittain wrote:
 Nope.  clientAuth=false means that the webapp's web.xml specifies which
 resources require the client certificate.

 Gotcha: I thought that false would cause the connector to ignore all
 client cert info, while want would collect it but not process it,
 while true would perform the checks for you.

 Instead, false and want are essentially the same (right?) and true
 does the checks for you. If you have want or false, plus a
 web-resource-collection that demands CLIENT-AUTH, then it will be used
 for identification purposes, but not actually checked against a valid
 certificate chain.

 Do I have that right?

The behavior I see is this:  false does not request the client
certificate at all.  want requests it, but allows the connection to
go through if no client certificate is presented.  true requires a
client certificate and kills the connection if no client certificate
(or an unacceptable one)  is presented.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin,

On 2/19/2010 2:18 PM, Kevin Mills wrote:
 On 2/19/10, Christopher Schultz ch...@christopherschultz.net wrote:
 On 2/19/2010 1:48 AM, Jason Brittain wrote:
 Nope.  clientAuth=false means that the webapp's web.xml specifies which
 resources require the client certificate.

 Gotcha: I thought that false would cause the connector to ignore all
 client cert info, while want would collect it but not process it,
 while true would perform the checks for you.

 Instead, false and want are essentially the same (right?) and true
 does the checks for you. If you have want or false, plus a
 web-resource-collection that demands CLIENT-AUTH, then it will be used
 for identification purposes, but not actually checked against a valid
 certificate chain.

 Do I have that right?
 
 The behavior I see is this:  false does not request the client
 certificate at all.  want requests it, but allows the connection to
 go through if no client certificate is presented.  true requires a
 client certificate and kills the connection if no client certificate
 (or an unacceptable one)  is presented.

So, with clientAuth=false, how do you get a client certificate to use
for authentication? Or, does the presence of the CLIENT-CERT in web.xml
trigger an SSL-renegotiation where the client cert /is/ requested from
the client.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt+6XQACgkQ9CaO5/Lv0PCSLQCfZkZ+Seia0JZmq+CcgXobgv2I
Ly8AniUQwHgGu9YHZH8Prr8qMwBVF+D3
=QNkD
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Kevin Mills]

On 2/17/10, Mark Thomas ma...@apache.org wrote:
  CVE-2009-3555?

Now that this is working, I'd like to ask what other options exist for
using client certificate authentication on a per-webapp basis.
Requiring my customers to enable a feature
(allowUnsafeLegacyRenegotiation) that exposes them to a potential
man-in-the-middle attack doesn't seem like a good idea! (Heck, it even
says Unsafe in the property name!)

I saw mention of overriding the SSL implementation with
sslImplementation=classname... does that still work in 6.x?  Is that
a good option?  And what about an Authentication Valve, is that the
right direction?

Thanks!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Mark Thomas]

On 18/02/2010 16:30, Kevin Mills wrote:
 On 2/17/10, Mark Thomas ma...@apache.org wrote:
  CVE-2009-3555?
 
 Now that this is working, I'd like to ask what other options exist for
 using client certificate authentication on a per-webapp basis.
 Requiring my customers to enable a feature
 (allowUnsafeLegacyRenegotiation) that exposes them to a potential
 man-in-the-middle attack doesn't seem like a good idea! (Heck, it even
 says Unsafe in the property name!)
 
 I saw mention of overriding the SSL implementation with
 sslImplementation=classname... does that still work in 6.x?  Is that
 a good option?  And what about an Authentication Valve, is that the
 right direction?

No. The TLS protocol is broken. You need to avoid renegotiation or wait
for the updated protocol and Sun to implement the fix in JSSE or an
OpenSSL release with the fix.

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin,

On 2/17/2010 7:24 PM, Kevin Mills wrote:
 Sure thing - here is my Connector element:
 
 Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=50 scheme=https secure=true
keystoreFile=.../tomcat.keystore keystorePass=...
clientAuth=false sslProtocol=TLS

Stupid question: don't you want clientAuth=true?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt9sR0ACgkQ9CaO5/Lv0PDsVgCgkR1Md/xdnO14MU3ZWMXQz13l
gCAAniGMybkQIU3VghXUj4G0l0OfrE2w
=m/Iy
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Jason Brittain]

Christopher:

Nope.  clientAuth=false means that the webapp's web.xml specifies which
resources require the client certificate.  See the Connector doc page's
description of the accepted values for the clientAuth attribute:

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

clientAuth is a rather confusing name for this attribute since a value of
false makes it appear as though client certs won't be used, which isn't
really how it works.  Less confusing names might be clientAuthChallenge or
clientAuthRequired with values such as always, want, and protected.

--
Jason Brittain


On Thu, Feb 18, 2010 at 1:29 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Kevin,

 On 2/17/2010 7:24 PM, Kevin Mills wrote:
  Sure thing - here is my Connector element:
 
  Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true
 maxThreads=50 scheme=https secure=true
 keystoreFile=.../tomcat.keystore keystorePass=...
 clientAuth=false sslProtocol=TLS

 Stupid question: don't you want clientAuth=true?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAkt9sR0ACgkQ9CaO5/Lv0PDsVgCgkR1Md/xdnO14MU3ZWMXQz13l
 gCAAniGMybkQIU3VghXUj4G0l0OfrE2w
 =m/Iy
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Jason Brittain

Trouble with CLIENT-CERT authentication method

[Kevin Mills]

Greetings fellow Tomcat-ers:

I'm trying enable client certificate authentication on a per-webapp
basis using Tomcat 6.0.24.  According to the various sources of
documentation I've found, this should be possible by enabling the SSL
Connector (which I've done), getting client certificate authentication
working for the Connector (this works for me), then setting
clientAuth=false on the Connector and placing the following in the
webapp's web.xml:

login-config
auth-methodCLIENT-CERT/auth-method
/login-config

I've tried various combinations of security constraints, roles,
realms, etc. but can never get the CLIENT-CERT authentication to work
for my webapp.  As I mentioned above, all is fine if I set
clientAuth=true but I don't want to impose client certificate
authentication across the whole site.

Searching the archives, I ran across bug 46950
(https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) which looks
to describe my very problem.  However, the bug is marked fixed as of
6.0.21 (I'm using 6.0.24) and I am not seeing the correct behavior.
Furthermore, the issue was reported against the APR Connector and I'm
using the default flavor (which, according to the one of the answering
developers, works for him).

Can anyone tell me what's going on here?

Thank you!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble with CLIENT-CERT authentication method

[Mark Thomas]

On 17/02/2010 23:48, Kevin Mills wrote:
 Can anyone tell me what's going on here?

CVE-2009-3555?

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
search for
allowUnsafeLegacyRenegotiation

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org