Re: Host based logging
HI i know. that comment block was just an example, my real config has several host sections, none of them with commented blocks I should over un-commented before i posted here on the mailinglist to prevent confusion. Its really about host, and perhaps headers. Regards Alexander On Sat, 29 Feb 2020 at 14:04, Konstantin Kolinko wrote: > сб, 29 февр. 2020 г. в 15:33, Alexander Curvers : > > > > > > Note the "". Those are comment wrappers in XML. > The above definition is commented-out and thus is ignored. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Client cert auth on demand
Am 2020-02-29 um 15:12 schrieb Mark Thomas: On 29/02/2020 13:05, Thomas Meyer wrote: Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : On 29/02/2020 11:23, Michael Osipov wrote: Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:40, Michael Osipov wrote: Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. Really? If I say require client cert auth on the connector, it will be enforced even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark, this makes me wonder whether Tomcat properly implements RFC 7540, section 9.2.1 and RFC 8740, section 3. From my understanding the configuration you have described MUST fail here. Those aspects of those specs are implemented correctly. Authentication will fail for both HTTP/2 and TLS 1.3 if a web application level security constraint tries to trigger renegotiation. For HTTP/2 and/or TLS 1/3 you can only configure client certificate authentication on the Connector. Hi, Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3 For HTTP/2, yes because of the multiplexing. HTTP/2 explicitly prohibits renegotiation. For TLS 1.3 there is post handshake authentication but the JSSE implementation doesn't support that. However... If NIO/NIO2 is used with OpenSSL or if the APR/Native Connector is used then post-handshake authentication is supported for TLS 1.3 and CLIENT-CERT auth triggered by security constraints works as expected. But I hope this only applies to HTTP/1.1, does it? Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Thanks! I actually needed proxyPort="443" to make the URL https://localhost, but your suggestion did the trick. On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas wrote: > > > > On 28/02/2020 22:26, Martynas Jusevičius wrote: > > Yes the clients connect only directly to nginx. > > > > So the proxy config within 2 pairs of containers is like this: > > > > # website service; clientAuth=false > > nginx:80 -> tomcat:8080 > > nginx:443 -> tomcat:8443 > > > > # API service; clientAuth=true > > nginx-api:90 -> tomcat-api:8080 > > nginx-api:5443 -> tomcat-api:8443 > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this > instance. That should do the trick. > > Mark > > > > > > nginx and nginx-api ports are exposed to the Docker host and that is > > where the clients access them, therefore the host name the webapp sees > > is localhost (as in my rewrite example). > > > > What I'm trying to do is to fool the webapp on tomcat-api into > > thinking it's being accessed on localhost:80/443 instead of > > localhost:90/5443. > > > > Absolute URIs matter in this case because they are used for direct > > lookups in an RDF triplestore and RDF uses absolute URIs. > > > > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote: > >> > >> On 28/02/2020 21:00, Martynas Jusevičius wrote: > >>> Setting up a second container with a different port was easy enough. > >>> > >>> However I got stuck on the URL mapping/rewriting. Using nginx as a > >>> proxy, I don't think it's possible to rewrite headers with the > >>> upstream module: > >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html > >>> > >>> As I understand it just forwards raw traffic, so the URL rewriting > >>> would have to be done on the Tomcat's side. Basically I want to > >>> rewrite: > >>> > >>> https://localhost:5443/ => https://localhost/ > >>> > >>> which requires rewriting the Host request header, I think. > >>> > >>> I was looking at the RewriteValve, but it says: > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not > >>> automatically support absolute URLs (the specific redirect flag must > >>> be used to be able to specify an absolute URLs, see below) or direct > >>> file serving." > >>> > >>> Is there a way to rewrite the hostname/port in configuration? > >>> Something placed in context.xml would be ideal. > >> > >> > >> What port is nginx listening on? > >> > >> What port is Tomcat listening on? > >> > >> I assume the client connects directly to nginx. > >> > >> Mark > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
On 29/02/2020 13:05, Thomas Meyer wrote: > Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : >> On 29/02/2020 11:23, Michael Osipov wrote: >>> Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: > Am 2020-02-29 um 12:05 schrieb Mark Thomas: >> On 29/02/2020 10:40, Michael Osipov wrote: >>> Tomcat does not support renegotiation of TLS contexts based >>> on URLs like HTTPd. >> >> Yes it does. >> >> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will >> trigger a renegotiation when one of those URLs is requested. >> >> You don't have the same fine-grained control you have in httpd but >> you >> can replicate the typical use cases. > > Really? If I say require client cert auth on the connector, it will >> be > enforced even on those contexts which do not require >> authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can >> require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. >>> >>> Mark, >>> >>> this makes me wonder whether Tomcat properly implements RFC 7540, >>> section 9.2.1 and RFC 8740, section 3. From my understanding the >>> configuration you have described MUST fail here. >> >> Those aspects of those specs are implemented correctly. Authentication >> will fail for both HTTP/2 and TLS 1.3 if a web application level >> security constraint tries to trigger renegotiation. >> >> For HTTP/2 and/or TLS 1/3 you can only configure client certificate >> authentication on the Connector. > > Hi, > > Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on > http2 or something in tls1.3, or asked the oth way around, will it fail only > for http2 && tls1.3 or for http2 || tls1.3 For HTTP/2, yes because of the multiplexing. HTTP/2 explicitly prohibits renegotiation. For TLS 1.3 there is post handshake authentication but the JSSE implementation doesn't support that. However... If NIO/NIO2 is used with OpenSSL or if the APR/Native Connector is used then post-handshake authentication is supported for TLS 1.3 and CLIENT-CERT auth triggered by security constraints works as expected. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 2020-02-29 um 14:05 schrieb Thomas Meyer: Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : On 29/02/2020 11:23, Michael Osipov wrote: Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:40, Michael Osipov wrote: Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. Really? If I say require client cert auth on the connector, it will be enforced even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark, this makes me wonder whether Tomcat properly implements RFC 7540, section 9.2.1 and RFC 8740, section 3. From my understanding the configuration you have described MUST fail here. Those aspects of those specs are implemented correctly. Authentication will fail for both HTTP/2 and TLS 1.3 if a web application level security constraint tries to trigger renegotiation. For HTTP/2 and/or TLS 1/3 you can only configure client certificate authentication on the Connector. Hi, Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3 I recently made some research on the toptic for work. As far as I understand there is no renogotiation in TLS 1.3 anymore. It has been replaced with PHA (post-handshake authentication). Because of, as you properly noticed, parallel streams you'd suffer from race conditions if one stream for a URL would request PHA and another won't. Here is a very helpful read: https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0001.html So doing VerifyClient require is unusable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas : >On 29/02/2020 11:23, Michael Osipov wrote: >> Am 2020-02-29 um 12:13 schrieb Mark Thomas: >>> On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05 schrieb Mark Thomas: > On 29/02/2020 10:40, Michael Osipov wrote: >>> >>> >>> >> Tomcat does not support renegotiation of TLS contexts based >> on URLs like HTTPd. > > Yes it does. > > If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will > trigger a renegotiation when one of those URLs is requested. > > You don't have the same fine-grained control you have in httpd but >you > can replicate the typical use cases. Really? If I say require client cert auth on the connector, it will >be enforced even on those contexts which do not require >authentication?! >>> >>> If you required auth on the connector it always applies. >>> >>> However, if you don't require it at the connector level you can >require >>> it for a subset of URLs with security constraints and Tomcat will >>> trigger any required renegotiations. >> >> Mark, >> >> this makes me wonder whether Tomcat properly implements RFC 7540, >> section 9.2.1 and RFC 8740, section 3. From my understanding the >> configuration you have described MUST fail here. > >Those aspects of those specs are implemented correctly. Authentication >will fail for both HTTP/2 and TLS 1.3 if a web application level >security constraint tries to trigger renegotiation. > >For HTTP/2 and/or TLS 1/3 you can only configure client certificate >authentication on the Connector. Hi, Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3 > >Mark > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Host based logging
сб, 29 февр. 2020 г. в 15:33, Alexander Curvers : > > Note the "". Those are comment wrappers in XML. The above definition is commented-out and thus is ignored. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Host based logging
Hi I would like to request some help, on a vm I run tomcat behind nginx, nginx is configured as following: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Server $http_host; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; proxy_intercept_errors on; proxy_cookie_path~*^/.* /; proxy_pass http://127.0.0.1:8080 /ap-system; The thing is, on tomcat i try to configure logging, based on hostname it does take effect only
Re: Client cert auth on demand
On 29/02/2020 11:23, Michael Osipov wrote: > Am 2020-02-29 um 12:13 schrieb Mark Thomas: >> On 29/02/2020 11:07, Michael Osipov wrote: >>> Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:40, Michael Osipov wrote: >> >> >> > Tomcat does not support renegotiation of TLS contexts based > on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. >>> >>> Really? If I say require client cert auth on the connector, it will be >>> enforced even on those contexts which do not require authentication?! >> >> If you required auth on the connector it always applies. >> >> However, if you don't require it at the connector level you can require >> it for a subset of URLs with security constraints and Tomcat will >> trigger any required renegotiations. > > Mark, > > this makes me wonder whether Tomcat properly implements RFC 7540, > section 9.2.1 and RFC 8740, section 3. From my understanding the > configuration you have described MUST fail here. Those aspects of those specs are implemented correctly. Authentication will fail for both HTTP/2 and TLS 1.3 if a web application level security constraint tries to trigger renegotiation. For HTTP/2 and/or TLS 1/3 you can only configure client certificate authentication on the Connector. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:40, Michael Osipov wrote: Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. Really? If I say require client cert auth on the connector, it will be enforced even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark, this makes me wonder whether Tomcat properly implements RFC 7540, section 9.2.1 and RFC 8740, section 3. From my understanding the configuration you have described MUST fail here. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 2020-02-29 um 12:13 schrieb Mark Thomas: On 29/02/2020 11:07, Michael Osipov wrote: Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:40, Michael Osipov wrote: Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. Really? If I say require client cert auth on the connector, it will be enforced even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. I wasn't aware of that. Thank you for the enlightment! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
On 29/02/2020 11:07, Michael Osipov wrote: > Am 2020-02-29 um 12:05 schrieb Mark Thomas: >> On 29/02/2020 10:40, Michael Osipov wrote: >>> Tomcat does not support renegotiation of TLS contexts based >>> on URLs like HTTPd. >> >> Yes it does. >> >> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will >> trigger a renegotiation when one of those URLs is requested. >> >> You don't have the same fine-grained control you have in httpd but you >> can replicate the typical use cases. > > Really? If I say require client cert auth on the connector, it will be > enforced even on those contexts which do not require authentication?! If you required auth on the connector it always applies. However, if you don't require it at the connector level you can require it for a subset of URLs with security constraints and Tomcat will trigger any required renegotiations. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 2020-02-29 um 12:05 schrieb Mark Thomas: On 29/02/2020 10:40, Michael Osipov wrote: Am 2020-02-29 um 10:09 schrieb Thomas Meyer: Hi, Instead of configuring the container for client cert Auth change the webapp: 1) define a realm in local context.xml 2) add resp security constraint only for rest api calls This will not help. In this case that appears to be correct although it isn't generally correct. You cannot configure cert-based auth from the context.xml. True. You do that in web.xml. Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. Really? If I say require client cert auth on the connector, it will be enforced even on those contexts which do not require authentication?! M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
On 29/02/2020 10:40, Michael Osipov wrote: > Am 2020-02-29 um 10:09 schrieb Thomas Meyer: >> Hi, >> >> Instead of configuring the container for client cert Auth change the >> webapp: >> 1) define a realm in local context.xml >> 2) add resp security constraint only for rest api calls > > This will not help. In this case that appears to be correct although it isn't generally correct. > You cannot configure cert-based auth from the > context.xml. True. You do that in web.xml. > Tomcat does not support renegotiation of TLS contexts based > on URLs like HTTPd. Yes it does. If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will trigger a renegotiation when one of those URLs is requested. You don't have the same fine-grained control you have in httpd but you can replicate the typical use cases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 2020-02-29 um 10:09 schrieb Thomas Meyer: Am 27. Februar 2020 10:58:01 MEZ schrieb "Martynas Jusevičius" : Hi list, I'm using a Docker image based on tomcat:8.0-jre8. It serves as an end-user facing webapp but also as a REST API which authenticates using client certificates. The same URLs serve both purposes, however only administrators are using the API. The Connector is configured using clientAuth="want". This works fine with API calls which are run from shell scripts. In the browser however it prompts a certificate selection (if there are any client certs). This would not be a problem if the webapp would not be user-facing, but since it is the certificate prompt can be confusing to many users and increase our bounce rate. I'm looking for some workaround that would not require changing the whole design. For example asking for the client cert only when a certain flag is set, such as a query param or request header. Or somehow not asking for it but still accepting it :) But I guess that's not how TLS works... Any ideas? Thanks. Martynas atomgraph.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi, Instead of configuring the container for client cert Auth change the webapp: 1) define a realm in local context.xml 2) add resp security constraint only for rest api calls This will not help. You cannot configure cert-based auth from the context.xml. Tomcat does not support renegotiation of TLS contexts based on URLs like HTTPd. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
On 28/02/2020 22:26, Martynas Jusevičius wrote: > Yes the clients connect only directly to nginx. > > So the proxy config within 2 pairs of containers is like this: > > # website service; clientAuth=false > nginx:80 -> tomcat:8080 > nginx:443 -> tomcat:8443 > > # API service; clientAuth=true > nginx-api:90 -> tomcat-api:8080 > nginx-api:5443 -> tomcat-api:8443 Try using proxyPort="5443" on the HTTPS connector in Tomcat for this instance. That should do the trick. Mark > > nginx and nginx-api ports are exposed to the Docker host and that is > where the clients access them, therefore the host name the webapp sees > is localhost (as in my rewrite example). > > What I'm trying to do is to fool the webapp on tomcat-api into > thinking it's being accessed on localhost:80/443 instead of > localhost:90/5443. > > Absolute URIs matter in this case because they are used for direct > lookups in an RDF triplestore and RDF uses absolute URIs. > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas wrote: >> >> On 28/02/2020 21:00, Martynas Jusevičius wrote: >>> Setting up a second container with a different port was easy enough. >>> >>> However I got stuck on the URL mapping/rewriting. Using nginx as a >>> proxy, I don't think it's possible to rewrite headers with the >>> upstream module: >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html >>> >>> As I understand it just forwards raw traffic, so the URL rewriting >>> would have to be done on the Tomcat's side. Basically I want to >>> rewrite: >>> >>> https://localhost:5443/ => https://localhost/ >>> >>> which requires rewriting the Host request header, I think. >>> >>> I was looking at the RewriteValve, but it says: >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not >>> automatically support absolute URLs (the specific redirect flag must >>> be used to be able to specify an absolute URLs, see below) or direct >>> file serving." >>> >>> Is there a way to rewrite the hostname/port in configuration? >>> Something placed in context.xml would be ideal. >> >> >> What port is nginx listening on? >> >> What port is Tomcat listening on? >> >> I assume the client connects directly to nginx. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OpenSSL config for Tomcat 7
On 29/02/2020 00:22, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: > Hello, > > We're running Tomcat 7 and need to implement SSL. We are using APR/OpenSSL, > but I can't get the intermediate certificates pulled in when starting Tomcat. > The > server certificate is recognized and used but not the other two. I have tried > the following in PEM format. > > > * Stacking them in one file and using the "SSLCertificateFile" directive > * Using the "SSLCertificateFile" directive for the server cert, and > "SSLCertificateChainFile" directive for the CA and root cert > > > * APR 1.4.8 > * Tomcat 7.0.39 > > Any additional information needed please let me know. Any insight would be > greatly appreciated. The exact connector configuration you are using for each test case along with a description of how you created the files referenced in each configuration. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client cert auth on demand
Am 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
