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
<WatchedResource>WEB-INF/web.xml</WatchedResource>
Exerpts from server.xml file ( has multiple virtual domains)
<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on" />
<!--ITB Removed on upgrade, not using JSP, Initialize Jasper prior to webapps
are loaded. Documentation at /docs/jasper-howto.html
<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.GlobalResourcesLifecycleListener" />
<Listener
className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<Service name="Catalina">
<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000"
redirectPort="8443" />
...
<Host name="localhost" appBase="/usr/share/www/onedomain.com"
unpackWARs="true" autoDeploy="true" >
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="localhost_access." suffix=".log" pattern="combined" />
</Host>
<Host name='www.mydomain.tld' appBase='/usr/share/www/mydomain.tld'
unpackWARs='true' autoDeploy='true'>
<Valve className='org.apache.catalina.valves.AccessLogValve'
prefix='mydomain.tld/access_' suffix='.log' pattern='combined' />
<Alias>mydomain.tld</Alias>
</Host>....
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 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 <Context> 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
