Re: /.well-known Hidden directory url returns 404
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ian, On 5/2/17 2:15 PM, Ian Brown wrote: > Solved/Worked-around !! (Although there might be a better way) Many > Thanks to Mark and Christopher! > > As Mark indicated the solution is very simple, but what worked on > my system is slightly, but critically different than what works on > Mark's. > > Mark's solution/system: cd webapps/ROOT mkdir .well-known > > I have multiple virtual hosts with multiple apps but what I think > would work on mine (extrapolated from below) is Hmm, multiple VHs will definitely be a problem, unless you either have separate appbase directories (.well-known in each one) or ... something very complicated. Do you have to allow users/apps to specify their own certs, or are you king of the whole castle? > cd webapps mkdir .well-known In other words /ROOT and /.well-known > are at the same level under webapps/ > > Here is what appears to work for me: > > With virtual hosts create the directories for each host you want to > secure ~/webapps/hosteddomain.tld/.well-known and > ~/webapps/hosteddomain.tld/.well-known/acme-challenge replacing > /hosteddomain.tld with the appropriate domain name. > > If you have multiple apps for multiple hosts your directory > structure should follow this pattern. host1.tld/ROOT/ > host1.tld/app1/ host1.tld/.well-known/acme-challenge/ > host2.tld/ROOT/ host2.tld/app1/ > host2.tld/.well-known/acme-challenge/ That will work. > Why it is not obvious to me: I expected all urls to be routed with > the same rules, but that is not what happens. Hidden directories > are routed differently (on my system). That should not happen. Remember: there is no such thing as a "hidden directory". > In my earlier example where I had www.mydomain.tld/stats/ > www.mydomain.tld/.well-known/acme-challenge/test.html 1- the stats > directory was routed to: contextPath= , > servletPath=/stats/index.html 2- the .well-knowndirectory was > routed to: contextPath=/.well-known, > servletPath=/acme-challenge/test.html That's what I'd expect. > In directory terms I expected /stats/index.html > to map to: www.mydomain.tld/ROOT/stats/index.html If you have a /stats application, then the URL will be routed there. Once an application has been selected based upon context-path match (e.g. /stats) Tomcat won't check any other application. So if you have application /stats and look for /stats/no-file.html you'll get a 404 even if ROOT/stats/no-file.html exists. > /.well-known/acme-challenge/test.htmlto map to: > www.mydomain.tld/ROOT/.well-known/acme-challenge/test.html What I > get is /stats/index.html > maps to: www.mydomain.tld/ROOT/stats/index.html > /.well-known/acme-challenge/test.htmlmaps to: > www.mydomain.tld/.well-known/acme-challenge/test.html You haven't told us what apps you have configured, so it's tough to tell what "should" be happening. > Christopher: Would love to hear your talk & meet, but I won't be at > the conference. Thanks for the invitation. We absolutely need a > certbot-auto for tomcat. My goal is to create a script that someone with certbot expertise can use to roll-into certbot. > There a lots of problem reports on the web for getting the > certificate request verified under Tomcat. I think that's because lots of people (a) don't understand the issuance model for LE or (b) don't really know how to configure Tomcat. It's dead simple to get LE to issue a certificate using only Tomcat and a properly-configured DNS name. > The main solution is to put Apache httpd in front of Tomcat so the > url gets routed to the right directory. So I think you will be > seeing this issue again. If you have httpd our front, then issuing a certificate for Tomcat is completely unnecessary, and it's just an academic exercise. Certbot, for instance, can self-host a web server, so if you are going to stand-up httpd just for LE cert issuance, then just allow certbot to host itself instead. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZCeVpAAoJEBzwKT+lPKRYiyAP/0QujIQD6pibcCzsqgl2TIZF x2jgUkCxzTLZ4BjFOlT03IAbrgLcQd928iy8JxrYepNLYq19VSZUDccex7e8pynO mWoAgx0MVB8e5CR+UuMq5B9oJ7H2aA/+ARWYl9mpRrT9rRy/187ATcwA1Y5eQcrP MOSguwt7vpRqBaX925cp/DbAeV6G5P62Wfxd/MKMaX57heC5jICmI085XGGBkeLF XIJhtmzh7fYD/zAJsISjrDuhNeOv1X8ObsJ4po+IYkEIMHTu9DWNchZfIPUFrhqi InKsM/yeLmA2eSK8WhrJwvfuXvdv88TC+admQWHlwJXnfbQDsxYVH11PulWqkSAk 9/W7YQ0uakgS6qE1OoHACgAUGxP0lYekLtExPNCHtgBIuSmD+hRPgG54hLm0c/q1 uPIFxvhKu/7gFBdkbGi0icOAkjLwE+fnXYwzUMClT2oHLK3Z2wByxizbQeJlQB4R mp54XzTh4tMSEsEYmGd1s/x7P6QiFWT31iRLbXpRbHJO1HyYT+ea8j5Aioki0J4h iyy9KnxecoZomDNoUfOmk/c/+fTIuDvVnSVlK+2Ol0EwYHAZv3+UrQK5WFy/C+KD Vxk97pxyE3mXWolHuFvzjfiClhCuWGzzJQYOaESal3JmA+zlnC2QZQOv/50sxIqs olUmniCCe41bIOvIWGXq =PcH6 -END PGP SIGNATURE- - To unsubscribe, e-mail:
Re: /.well-known Hidden directory url returns 404
On 5/1/17 12:11 PM, Ian Brown wrote:
> I am trying to https/SSL enable my tomcat application server and have a
> problem when I request verification from the CA.
> Let's Encrypt requires the certificate request to be placed in
> mydomain.tld/.well-known/acme-challenge/ which they query to check that I
> control the site.
> Tomcat does not appear to handle hidden directories correctly. There as
> several on-line references to Tomcat being an issue, but I have yet to find a
> Tomcat solution.
> (Other than to front tend Tomcat with the Apache httpd server, but I would
> like to find a solution that is pure tomcat.)
> I started with tomcat-7.0.42 Centos 6-8.el6 jdk1.7.0_25, then
> upgraded to tomcat-8.5.14 Centos 6-8.el6jdk1.8.0_131, same problem.
>
> The hidden directory problem manifest in two ways.
> 1. If I create a site/app with th directory /.well-known/ Tomcat creates two
> contexts where there should be one, one for my app and another for
> /.well-known (i.e. a sub directory of the app)
> 2. If I don't create a /.well-known/ directory, but try and do a urlrewrite
> from /.well-known/ to say /well-known/ it still sees the url as trying to
> access a separte context /.well-known/
> and does not rewrite it as expected.
>
> Request-dumper shows ( some lines removed for clarity)
>
> requestURI=/.well-known/acme-challenge/test.html
> contextPath=/.well-known
> serverName=mydomain.tld
> serverPort=80
> servletPath=/acme-challenge/test.html
> status=404
>
> The above fails if /.well-known/acme-challenge/test.html exists or not since
> it is looking in the wrong context path.
>
> Contrasts with a correctly served (not hidden) page.
>
> requestURI=/stats/index.html
> contextPath=
> header=host=www.mydomain.tld
> contextPath=
> serverName=www.mydomain.tld
> serverPort=80
> servletPath=/stats/index.html
> status=200
>
> Has anyone seen an solution to this issue? Any suggestions?
> Thanks for your consideration,
> ian
>
Hi Ian,
Hi Ian,
I worked around this for tomcat by using the "--standalone" option
for certbot. That just requires that you have port 80 and 443
(temporarily) open for all while it does the verification. My
Ansible playbook uses
certbot certonly --noninteractive --agree-tos --standalone --email
{{certbot_admin_email}} -d {{inventory_hostname}}
then
openssl pkcs12 -inkey {{certbot_output_dir}}/privkey.pem -in
{{certbot_output_dir}}/fullchain.pem -export -out
{{tomcat_keystore_dir}}/vlibrary.pfx -password pass:{{key_pwd}}
I agree it would be great to have an auto-install certbot setup for
tomcat, though.
Phil
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: /.well-known Hidden directory url returns 404
Solved/Worked-around !! (Although there might be a better way) Many Thanks to Mark and Christopher! As Mark indicated the solution is very simple, but what worked on my system is slightly, but critically different than what works on Mark's. Mark's solution/system: cd webapps/ROOT mkdir .well-known I have multiple virtual hosts with multiple apps but what I think would work on mine (extrapolated from below) is cd webapps mkdir .well-known In other words /ROOT and /.well-known are at the same level under webapps/ Here is what appears to work for me: With virtual hosts create the directories for each host you want to secure ~/webapps/hosteddomain.tld/.well-known and ~/webapps/hosteddomain.tld/.well-known/acme-challenge replacing /hosteddomain.tld with the appropriate domain name. If you have multiple apps for multiple hosts your directory structure should follow this pattern. host1.tld/ROOT/ host1.tld/app1/ host1.tld/.well-known/acme-challenge/ host2.tld/ROOT/ host2.tld/app1/ host2.tld/.well-known/acme-challenge/ Why it is not obvious to me: I expected all urls to be routed with the same rules, but that is not what happens. Hidden directories are routed differently (on my system). In my earlier example where I had www.mydomain.tld/stats/ www.mydomain.tld/.well-known/acme-challenge/test.html 1- the stats directory was routed to: contextPath= , servletPath=/stats/index.html 2- the .well-known directory was routed to: contextPath=/.well-known, servletPath=/acme-challenge/test.html In directory terms I expected /stats/index.html to map to: www.mydomain.tld/ROOT/stats/index.html /.well-known/acme-challenge/test.html to map to: www.mydomain.tld/ROOT/.well-known/acme-challenge/test.html What I get is /stats/index.html maps to: www.mydomain.tld/ROOT/stats/index.html /.well-known/acme-challenge/test.html maps to: www.mydomain.tld/.well-known/acme-challenge/test.html Caveate: So far I have now successfully created and verified a test certificate. (Huge step forward) I will add or clarify any info on this thread after I have real certificates for multiple domains with multiple apps. Mark: Could very well be caused by some configuration issue, I am no expert at Tomcat. Having said that it has been reliably running multiple domains, with multiple apps for months to years ( depending on the domain & app). It is complex, one site is heavy Perl/cgi, another is multiple apps under one domain, some are crawlers, some are content servers. CATALINA_HOME & CATALINA_BASE are separate directories Christopher: Would love to hear your talk & meet, but I won't be at the conference. Thanks for the invitation. We absolutely need a certbot-auto for tomcat. There a lots of problem reports on the web for getting the certificate request verified under Tomcat. The main solution is to put Apache httpd in front of Tomcat so the url gets routed to the right directory. So I think you will be seeing this issue again. All: I'm good with the proposed solution/work-around. I can move forward with this. If you want to investigate further let me know what specific information you need from me. If it is "everything" we will need a more private way to share. Some Config Info: the mydomain.tld/ROOT/META-INF/context.xml file has one active line WEB-INF/web.xml Exerpts from server.xml file ( has multiple virtual domains) ... mydomain.tld Again Many Thanks to Mark and Christopher! Cheers, ian From: Christopher Schultz <ch...@christopherschultz.net> To: Tomcat Users List <users@tomcat.apache.org>; Ian Brown <it.br...@yahoo.ca.INVALID> Sent: Monday, May 1, 2017 6:12 PM Subject: Re: /.well-known Hidden directory url returns 404 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ian, On 5/1/17 3:11 PM, Ian Brown wrote: > I am trying to https/SSL enable my tomcat application server and > have a problem when I request verification from the CA. > > Let's Encrypt requires the certificate request to be placed in > mydomain.tld/.well-known/acme-challenge/ which they query to check > that I control the site. > > Tomcat does not appear to handle hidden directories correctly. > There as several on-line references to Tomcat being an issue, but I > have yet to find a Tomcat solution. I'm doing this in a completely-scripted environment using certbot-auto, etc. I'm presenting everything at ApacheCon/TomcatCon in two weeks in Miami if you'd like to join us. After my presentation, the slides, etc. will be available online. There is nothing "hidden" about a directory that starts with a period. It's just an indication to "ls" that the directory entry should not be shown unless a certain flag
Re: /.well-known Hidden directory url returns 404
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ian, On 5/1/17 3:11 PM, Ian Brown wrote: > I am trying to https/SSL enable my tomcat application server and > have a problem when I request verification from the CA. > > Let's Encrypt requires the certificate request to be placed in > mydomain.tld/.well-known/acme-challenge/ which they query to check > that I control the site. > > Tomcat does not appear to handle hidden directories correctly. > There as several on-line references to Tomcat being an issue, but I > have yet to find a Tomcat solution. I'm doing this in a completely-scripted environment using certbot-auto, etc. I'm presenting everything at ApacheCon/TomcatCon in two weeks in Miami if you'd like to join us. After my presentation, the slides, etc. will be available online. There is nothing "hidden" about a directory that starts with a period. It's just an indication to "ls" that the directory entry should not be shown unless a certain flag is present. Tomcat is ignorant of that convention, and the "hiddenness" of your directory is a red herring. > The hidden directory problem manifest in two ways. 1. If I create a > site/app with th directory /.well-known/ Tomcat creates two contexts where there should be one, one for my app and another for /.well-known (i.e. a sub directory of the app) What is your application's context-path? If it's anything other than "" (empty string, for the ROOT web application) then requests to /.well-known won't be served by your application. Period. > 2. If I don't create a /.well-known/ directory, but try and do a urlrewrite from /.well-known/ to say /well-known/ it still sees the url as trying to access a separte context /.well-known/ > and does not rewrite it as expected. Note that url-rewrite must be configured within an application -- it can't be done globally. Basically, if you want to serve responses to a URL like /.well-known/whatever, then you either need an application with a context-path of "/.well-known", or you need the ROOT application to respond to those requests. > Request-dumper shows ( some lines removed for clarity) > > requestURI=/.well-known/acme-challenge/test.html > contextPath=/.well-known serverName=mydomain.tld serverPort=80 > servletPath=/acme-challenge/test.html status=404 > > The above fails if /.well-known/acme-challenge/test.html exists or > not since it is looking in the wrong context path. What context-path did you expect? > Contrasts with a correctly served (not hidden) page. > > requestURI=/stats/index.html contextPath= > header=host=www.mydomain.tld contextPath= > serverName=www.mydomain.tld serverPort=80 > servletPath=/stats/index.html status=200 Those are all being served by the ROOT web application. Why not put your /.well-known files within the ROOT web application? Or leave them in /.well-known as above? Please post some more details for what you are doing in case #1 above where the context-path of the application is /.well-known. For example, what files are on the disk, and where? Where is the defined? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZB7KtAAoJEBzwKT+lPKRY+IMP/2MJNzFeD932piXkF/ky2QiD DNIUDrX4RDMwBucKNf9jDT96GE3VwmmpDsFDNvcmjveGROfgEf/wTwFKqWhwSdYr pYNquHTyGMUh2flfUZfjgQbuCArmyCzrr80GaoDe5g3TpZ8SbyupzEYylhZ9QiZr eNzjeWAQOa6UsSXZ9vqPM/nf2rB5i2A2P3eoggyduGFzM1r6UkQ9I5LWwIdY/2gS V9HlW1TSRbrR+FhVvACZx8+p8GtxpG6Es+wKck7LhwX6UhCtMiZyKlcn/bl0XS2G EW9vmTAo6myt6Avk0QAZG4s8fJWASmxA2nJP9c0RQhyueaoGwWvasgsVbbMnGT3N ojw98bQq4SYIJoUi+ypGN93xyOqxU0ihdwEdrunxRe1HKXVsDaXiriS6WOyhWgNd c9VRut4SfnHVdQPibiifLd6A2VNlCFC7t/fgkkSI7/uiZGwOM7sqDOFJ5UMlrvQ+ BbaRZgzVycjjz3ARM+/5Scwi9UHqnq1Zli96KmBs+28SY6lV8h7y+voqz7gD+82k 7Z2wHuyXP0ElY91w6VTIexmOxfXzaVv+qNdAZhuiylRnZKpI5Hux1JlSvbXil6WX s1TTEW0K7sIBA+9AqRWczHL+fJyb866XIgaRaOU2WU2ivwh7ZIQ2wEQzRcpfFBvW SZ8mmcjXFMpoTTw5n7SF =DQYr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: /.well-known Hidden directory url returns 404
On 01/05/17 20:11, Ian Brown wrote: > I am trying to https/SSL enable my tomcat application server and have > a problem when I request verification from the CA. Let's Encrypt > requires the certificate request to be placed in > mydomain.tld/.well-known/acme-challenge/ which they query to check > that I control the site. Tomcat does not appear to handle hidden > directories correctly. There as several on-line references to Tomcat > being an issue, but I have yet to find a Tomcat solution. (Other than > to front tend Tomcat with the Apache httpd server, but I would like > to find a solution that is pure tomcat.) I started with tomcat-7.0.42 > Centos 6-8.el6 jdk1.7.0_25, then upgraded to tomcat-8.5.14 > Centos 6-8.el6jdk1.8.0_131, same problem. This works out of the box for me. Just: cd webapps/ROOT mkdir .well-known > The hidden directory problem manifest in two ways. > 1. If I create a site/app with th directory /.well-known/ Tomcat creates two > contexts > where there should be one, one for my app and another for > /.well-known (i.e. a sub directory of the app) Please explain exactly how you configured this starting from a clean Tomcat install. 2. If I don't create a > /.well-known/ directory, but try and do a urlrewrite from > /.well-known/ to say /well-known/ it still sees the url as trying to > access a separte context /.well-known/ and does not rewrite it as > expected. Again, please explain exactly how you configured the rewrite. > Request-dumper shows ( some lines removed for clarity) > > requestURI=/.well-known/acme-challenge/test.html > contextPath=/.well-known serverName=mydomain.tld serverPort=80 > servletPath=/acme-challenge/test.html status=404 > > The above fails if /.well-known/acme-challenge/test.html exists or > not since it is looking in the wrong context path. > > Contrasts with a correctly served (not hidden) page. > > requestURI=/stats/index.html contextPath= > header=host=www.mydomain.tld contextPath= > serverName=www.mydomain.tld serverPort=80 > servletPath=/stats/index.html status=200 > > Has anyone seen an solution to this issue? Any suggestions? Thanks > for your consideration, ian Looks like the Tomcat configuration is not correct. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
