RE: /manage/text/list fails in 9.0.31, works in 9.0.27

2020-02-27 Thread Vishal Agrawal
Hello Chris,

I uninstalled existing tomcat and cleaned up /opt/tomcat folder before 
installing 9.0.31 or 9.0.27.

Thanks,
Vishal

-Original Message-
From: Christopher Schultz  
Sent: Thursday, February 27, 2020 3:57 PM
To: users@tomcat.apache.org
Subject: Re: /manage/text/list fails in 9.0.31, works in 9.0.27

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vishal,

On 2/26/20 13:56, Vishal Agrawal wrote:
> Hello,
>
> I have manager endpoint enabled in my tomcat install.
>
> When I list the manager endoing in tomcat 9.0.31, I get a 401 
> Unauthorized error -
>
> curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list
>
>  "http://www.w3.org/TR/html4/strict.dtd;>   401 
> Unauthorized ... 
>
>
> However, when I call it in tomcat 9.0.27 it works as expected...
>
> curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in 
> tomcat 9.0.27 it works as expected... OK - Listed applications for 
> virtual host [localhost] /manager:running:0:manager
>
> The password is configured in tomcat-users.xml using the output from 
> /opt/tomcat/bin/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdi
> gest.sh=E,1,iNYuMwbX1rmQeOFzhvx9FnB7uAef4peghBPRYSNlsHcL8eUumVj-lixL
> EQftagDyvdZD0599zUvhRCjcseLjOOlV7M7QsrQxsalxBJxEWbM9BNpunaYFFp8,=
> 1 -a sha-512 -h 
> org.apache.catalina.realm.MessageDigestCredentialHandler secret
> secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92
a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63
d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82
>
>
>> cat /opt/tomcat/conf/tomcat-users.xml
> ...   password="7244776efd3bbf6f9a56dfdc6443f898d39b13623ea349929ecf66748cde
0923$1$22aab528369d6c453adca7e4928fff24f77110d15bd2e9786554c2dcdf628847a
88f9a459e8cec0c942545a83156ca737eb0edb700563d00f926cb8f29fc4d73"
> roles="manager-script"/> ...
>
> I compared the conf folders in both 9.0.27 and 9.0.31 and they appear 
> to be identical.
>
> Can someone please help me what I may need to configure more?

Did you upgrade from one to the other? If you upgraded, then you likely have a 
new tomcat-users.xml file in the new Tomcat 9.0.31 directory, and it does not 
contain the users and/or roles that your
9.0.27 install has.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - 
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.enigmail.net%2f=E,1,VK6kGGDXroqi-2uJxZQX9CEubnndF3hGheso8Xf1o0tH_A7fkt8BQnPyOM9gjkfKOMbwgZULJ9ptsLram0mptHVyTfCuIiugi6Sfq7NsSRrtS2rw=1

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5YOzAACgkQHPApP6U8
pFhwrg//UIUGtAH5eRo6BHmcvnKGURU3+9GKp3+zwyJwHY5sb9bM05uewSV8MVDy
+vaIJzJJpKM+iLtCrDNUjW7V0f1fcr8tt+wmD1JJgHPElkFaT3R2H6XKSNgM9y9I
SNTtv79AoJED0zswj71Q+4DHMsl+ryLqKf+AzTSkqU7nnqXIeD0P2bUwUd8VP9WS
mxayr/yYTZk5wKrRi2xgPw4vTmMtditxAGNWdBhOaWejLHi73vHgYh33B219OzkL
BWWgzCahpr6bFPgPMkNQcxP//YQVyz9HTyXgc1cdD/TOPMk21FHW/4Hiuzq+pPYL
4NPY2uAQdZ1Q8tVxcVTHM3E1AbUfzytGswtRSDrrs5g9iity/d6fKb/Xa33X5Y3p
BcPsArExDiYAbDL/iftXHSgcembNC6XxNpPUMFtETRsOAiMLk8c3YTuD+hj4yPyw
+mTLV9QVicBK9xJw/f3X8Oohl1nIPT7zgxs9jABLn0tNljgKlGN4O+DzM6B2Fz3J
WM7oQgHdI/dpTS3EVinbthJY4gEnSbZz/rDSgYJXw2prbVq/eCWrmWSM/OhDBr5s
d9zzlZDNeednxWQEb7xB2S3UcwILktFIG/tGLZYDyIS9Svu72pBpqF/ovYqnrxBN
cpmAYuq8AMFzjgnIhv7c/14co4p0Hwi3EMbCqqPEWnq1RwQArNo=
=JLXl
-END PGP SIGNATURE-

-
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: /manage/text/list fails in 9.0.31, works in 9.0.27

2020-02-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vishal,

On 2/26/20 13:56, Vishal Agrawal wrote:
> Hello,
>
> I have manager endpoint enabled in my tomcat install.
>
> When I list the manager endoing in tomcat 9.0.31, I get a 401
> Unauthorized error -
>
> curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list
>
>  "http://www.w3.org/TR/html4/strict.dtd;>   401
> Unauthorized ... 
>
>
> However, when I call it in tomcat 9.0.27 it works as expected...
>
> curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in
> tomcat 9.0.27 it works as expected... OK - Listed applications for
> virtual host [localhost] /manager:running:0:manager
>
> The password is configured in tomcat-users.xml using the output
> from /opt/tomcat/bin/digest.sh -a sha-512 -h
> org.apache.catalina.realm.MessageDigestCredentialHandler secret
> secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92
a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63
d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82
>
>
>> cat /opt/tomcat/conf/tomcat-users.xml
> ...   password="7244776efd3bbf6f9a56dfdc6443f898d39b13623ea349929ecf66748cde
0923$1$22aab528369d6c453adca7e4928fff24f77110d15bd2e9786554c2dcdf628847a
88f9a459e8cec0c942545a83156ca737eb0edb700563d00f926cb8f29fc4d73"
> roles="manager-script"/> ...
>
> I compared the conf folders in both 9.0.27 and 9.0.31 and they
> appear to be identical.
>
> Can someone please help me what I may need to configure more?

Did you upgrade from one to the other? If you upgraded, then you
likely have a new tomcat-users.xml file in the new Tomcat 9.0.31
directory, and it does not contain the users and/or roles that your
9.0.27 install has.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5YOzAACgkQHPApP6U8
pFhwrg//UIUGtAH5eRo6BHmcvnKGURU3+9GKp3+zwyJwHY5sb9bM05uewSV8MVDy
+vaIJzJJpKM+iLtCrDNUjW7V0f1fcr8tt+wmD1JJgHPElkFaT3R2H6XKSNgM9y9I
SNTtv79AoJED0zswj71Q+4DHMsl+ryLqKf+AzTSkqU7nnqXIeD0P2bUwUd8VP9WS
mxayr/yYTZk5wKrRi2xgPw4vTmMtditxAGNWdBhOaWejLHi73vHgYh33B219OzkL
BWWgzCahpr6bFPgPMkNQcxP//YQVyz9HTyXgc1cdD/TOPMk21FHW/4Hiuzq+pPYL
4NPY2uAQdZ1Q8tVxcVTHM3E1AbUfzytGswtRSDrrs5g9iity/d6fKb/Xa33X5Y3p
BcPsArExDiYAbDL/iftXHSgcembNC6XxNpPUMFtETRsOAiMLk8c3YTuD+hj4yPyw
+mTLV9QVicBK9xJw/f3X8Oohl1nIPT7zgxs9jABLn0tNljgKlGN4O+DzM6B2Fz3J
WM7oQgHdI/dpTS3EVinbthJY4gEnSbZz/rDSgYJXw2prbVq/eCWrmWSM/OhDBr5s
d9zzlZDNeednxWQEb7xB2S3UcwILktFIG/tGLZYDyIS9Svu72pBpqF/ovYqnrxBN
cpmAYuq8AMFzjgnIhv7c/14co4p0Hwi3EMbCqqPEWnq1RwQArNo=
=JLXl
-END PGP SIGNATURE-

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



RE: /manager/text/list fails in 9.0.31, works in 9.0.27

2020-02-27 Thread Vishal Agrawal
Hello Enrico,

I build an RPM from source file 
(https://archive.apache.org/dist/tomcat/tomcat-9/v%{version}/bin/apache-tomcat-%{version}.tar.gz)
 with manager application enabled. 

In both tests I had installed the RPM fresh and generated the hash of password 
using /opt/tomcat/bin/digest.sh file. Strangely, I had failure with 9.0.30 as 
well. 

Btw, I'm installing the tomcat on CentOS 8.1 with jre1.8 (1.8.0_162). Please do 
let me know if you need any other information from my system.

Thanks,
Vishal

-Original Message-
From: Enrico Olivelli  
Sent: Thursday, February 27, 2020 5:11 AM
To: Tomcat Users List 
Subject: Re: /manager/text/list fails in 9.0.31, works in 9.0.27

I am investingating this issue with NetBeans and Tomcat 9.0.31
https://issues.apache.org/jira/browse/NETBEANS-3917

This problem report MAY be related, NetBeans is not able to list applications 
or to access the /manager/text API.
It works well with 9.0.30.

I will be back with news if it is a Tomcat issue or a NetBeans one.
From Tomcat release notes I see nothing about a potential breakage.
Using a fresh new untarred Tomcat 9.0.31 does not work.
If I remove the "lib" directory and I replace it with the one from Tomcat 
9.0.30 all works as expected.

Regards
Enrico


Il giorno gio 27 feb 2020 alle ore 09:07 Mark Thomas  ha 
scritto:
>
> On 26/02/2020 18:57, Vishal Agrawal wrote:
> > Hello,
> >
> > I have manager endpoint enabled in my tomcat install.
> >
> > When I list the manager endoing in tomcat 9.0.31, I get a 401 
> > Unauthorized error -
> >
> > curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list
> >
> >  > "http://www.w3.org/TR/html4/strict.dtd;>
> > 
> > 
> >   401 Unauthorized
> > ...
> > 
> >
> >
> > However, when I call it in tomcat 9.0.27 it works as expected...
> >
> > curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in tomcat 
> > 9.0.27 it works as expected...
> > OK - Listed applications for virtual host [localhost] 
> > /manager:running:0:manager
> >
> > The password is configured in tomcat-users.xml using the output from
> > /opt/tomcat/bin/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2f
> > digest.sh=E,1,3tDk5vwY_zoM19PIwVKe3fyfwRAXV_7a8MrPXyx5XiQ5db4bmp89
> > IB1v74yX6cNBQO6ob5X1vfgWGe5Fe0T0DHm6eweKRmHiAyvxG_4cIwsd218AJPe3
> > o=1 -a sha-512 -h 
> > org.apache.catalina.realm.MessageDigestCredentialHandler secret
> > secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab
> > 92a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a009515
> > 61cf63d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82
> >
> >> cat /opt/tomcat/conf/tomcat-users.xml
> > ...
> >   
> >> password="7244776efd3bbf6f9a56dfdc6443f898d39b13623ea349929ecf66748cde0923$1$22aab528369d6c453adca7e4928fff24f77110d15bd2e9786554c2dcdf628847a88f9a459e8cec0c942545a83156ca737eb0edb700563d00f926cb8f29fc4d73"
> >  roles="manager-script"/> ...
> >
> > I compared the conf folders in both 9.0.27 and 9.0.31 and they appear to be 
> > identical.
> >
> > Can someone please help me what I may need to configure more?
>
> I've just tested the latest 9.0.x code and this works as expected for 
> me. There have been no code changes in this area since 9.0.31. 
> Further, I don't see anything likely to be relevant in the history 
> between 9.0.27 and 9.0.31.
>
> I've tested the "ca858..." and the "72447..." credential string above.
> The "ca858..." string works. The "72447..." does not. Not sure what 
> went wrong but that incorrect credential string is the issue.
>
> 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: /manager/text/list fails in 9.0.31, works in 9.0.27

2020-02-27 Thread Enrico Olivelli
I am investingating this issue with NetBeans and Tomcat 9.0.31
https://issues.apache.org/jira/browse/NETBEANS-3917

This problem report MAY be related, NetBeans is not able to list
applications or to access the /manager/text API.
It works well with 9.0.30.

I will be back with news if it is a Tomcat issue or a NetBeans one.
>From Tomcat release notes I see nothing about a potential breakage.
Using a fresh new untarred Tomcat 9.0.31 does not work.
If I remove the "lib" directory and I replace it with the one from
Tomcat 9.0.30 all works as expected.

Regards
Enrico


Il giorno gio 27 feb 2020 alle ore 09:07 Mark Thomas
 ha scritto:
>
> On 26/02/2020 18:57, Vishal Agrawal wrote:
> > Hello,
> >
> > I have manager endpoint enabled in my tomcat install.
> >
> > When I list the manager endoing in tomcat 9.0.31, I get a 401 Unauthorized 
> > error -
> >
> > curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list
> >
> >  > "http://www.w3.org/TR/html4/strict.dtd;>
> > 
> > 
> >   401 Unauthorized
> > ...
> > 
> >
> >
> > However, when I call it in tomcat 9.0.27 it works as expected...
> >
> > curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in tomcat 
> > 9.0.27 it works as expected...
> > OK - Listed applications for virtual host [localhost] 
> > /manager:running:0:manager
> >
> > The password is configured in tomcat-users.xml using the output from
> > /opt/tomcat/bin/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdigest.sh=E,1,3tDk5vwY_zoM19PIwVKe3fyfwRAXV_7a8MrPXyx5XiQ5db4bmp89IB1v74yX6cNBQO6ob5X1vfgWGe5Fe0T0DHm6eweKRmHiAyvxG_4cIwsd218AJPe3=1
> >  -a sha-512 -h org.apache.catalina.realm.MessageDigestCredentialHandler 
> > secret
> > secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82
> >
> >> cat /opt/tomcat/conf/tomcat-users.xml
> > ...
> >   
> >> password="7244776efd3bbf6f9a56dfdc6443f898d39b13623ea349929ecf66748cde0923$1$22aab528369d6c453adca7e4928fff24f77110d15bd2e9786554c2dcdf628847a88f9a459e8cec0c942545a83156ca737eb0edb700563d00f926cb8f29fc4d73"
> >  roles="manager-script"/> ...
> >
> > I compared the conf folders in both 9.0.27 and 9.0.31 and they appear to be 
> > identical.
> >
> > Can someone please help me what I may need to configure more?
>
> I've just tested the latest 9.0.x code and this works as expected for
> me. There have been no code changes in this area since 9.0.31. Further,
> I don't see anything likely to be relevant in the history between 9.0.27
> and 9.0.31.
>
> I've tested the "ca858..." and the "72447..." credential string above.
> The "ca858..." string works. The "72447..." does not. Not sure what went
> wrong but that incorrect credential string is the issue.
>
> 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

2020-02-27 Thread 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

2020-02-27 Thread 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

2020-02-27 Thread 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

2020-02-27 Thread 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

2020-02-27 Thread 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: /manager/text/list fails in 9.0.31, works in 9.0.27

2020-02-27 Thread Mark Thomas
On 26/02/2020 18:57, Vishal Agrawal wrote:
> Hello,
> 
> I have manager endpoint enabled in my tomcat install.
> 
> When I list the manager endoing in tomcat 9.0.31, I get a 401 Unauthorized 
> error -
> 
> curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list
> 
>  "http://www.w3.org/TR/html4/strict.dtd;>
> 
> 
>   401 Unauthorized
> ...
> 
> 
> 
> However, when I call it in tomcat 9.0.27 it works as expected...
> 
> curl -u tomcat:secret http://127.0.0.1:8080/manager/text/list in tomcat 
> 9.0.27 it works as expected...
> OK - Listed applications for virtual host [localhost] 
> /manager:running:0:manager
> 
> The password is configured in tomcat-users.xml using the output from
> /opt/tomcat/bin/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdigest.sh=E,1,3tDk5vwY_zoM19PIwVKe3fyfwRAXV_7a8MrPXyx5XiQ5db4bmp89IB1v74yX6cNBQO6ob5X1vfgWGe5Fe0T0DHm6eweKRmHiAyvxG_4cIwsd218AJPe3=1
>  -a sha-512 -h org.apache.catalina.realm.MessageDigestCredentialHandler secret
> secret:ca858d2d5c3e86702ed03b90b1808205a4dc795330deac90380dd3642bcab92a$1$b5affd62902693d01f95bb8798b9c02982dbe58038d5e5064a77fa8a00951561cf63d5491a33d86fb2bee930335f3e3ceb324a8a8459d2966231392072ff4d82
> 
>> cat /opt/tomcat/conf/tomcat-users.xml
> ...
>   
>password="7244776efd3bbf6f9a56dfdc6443f898d39b13623ea349929ecf66748cde0923$1$22aab528369d6c453adca7e4928fff24f77110d15bd2e9786554c2dcdf628847a88f9a459e8cec0c942545a83156ca737eb0edb700563d00f926cb8f29fc4d73"
>  roles="manager-script"/> ...
> 
> I compared the conf folders in both 9.0.27 and 9.0.31 and they appear to be 
> identical.
> 
> Can someone please help me what I may need to configure more?

I've just tested the latest 9.0.x code and this works as expected for
me. There have been no code changes in this area since 9.0.31. Further,
I don't see anything likely to be relevant in the history between 9.0.27
and 9.0.31.

I've tested the "ca858..." and the "72447..." credential string above.
The "ca858..." string works. The "72447..." does not. Not sure what went
wrong but that incorrect credential string is the issue.

Mark


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