You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2020/08/18 23:47:22 UTC
Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Something just worked, that I wasn't expecting to work. Or rather, I was
expecting it to work, but kill cert renewal.
The port 80 virtual host had
> RewriteEngine on
> RewriteCond %{HTTP_HOST} !^www\. [NC]
> RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
which I commented out, because https for that virtual host is a pure
front-end for Tomcat, and of course, Certbot needs to stick something on
the server that Let's Encrypt is expecting to be able to find.
So a few minutes ago, just for test purposes, I uncommented the above
lines. Initially, it didn't work (it redirected the browser from
http://foo.bar.com to a nonexistent https://www.foo.bar.com), but when I
removed the "www" in the RewriteRule, changing the block to
> RewriteEngine on
> RewriteCond %{HTTP_HOST} !^www\. [NC]
> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
it worked just fine.
So then, I did a "certbot renew --force-renewal" (expecting it to fail
on the relevant cert, but in fact, it renewed just fine.
Not to look a gift equine in the masticatory orifice, but what am I
missing here? What went right, when I was expecting it to go wrong? Why
didn't the "rewrite" lines break renewal?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/21/20 1:02 PM, logo wrote:
> From my experience I have excluded .well-known from the redirect.
That appears to be the correct answer. I probably didn't see that line
back in August, or I probably would have replied by asking something
like, "Ok, and how do I do that?"
Be that as it may, Andrew Schulman came up with an answer on my
ServerFault thread (https://serverfault.com/a/1041882/498231) to the
effect of changing the rewrite block from:
> RewriteEngine on
> RewriteCond %{HTTP_HOST} !^www\. [NC]
> RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
to:
> RewriteEngine on
> RewriteCond %{HTTP_HOST} !^www\. [NC]
> RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]
While I'm not going to be certain until December, when the cached
challenge expires, it certainly seems to work: if I go to
http://sub.domain.com, it immediately redirects me to
https://sub.domain.com, and I get the Tomcat server, whereas if I try to
go to http://sub.domain.com/.well-known/acme-challenge/foo, it remains
http, and gives me the expected "Not Found" error.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by logo <lo...@kreuser.name>.
Chris
> Am 21.08.2020 um 18:30 schrieb Christopher Schultz <ch...@christopherschultz.net>:
>
> Signierter PGP-Teil
> James,
>
> On 8/18/20 19:47, James H. H. Lampert wrote:
> > Something just worked, that I wasn't expecting to work. Or rather,
> > I was expecting it to work, but kill cert renewal.
> >
> > The port 80 virtual host had
> >> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
> >> RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI}
> >> [R=301,L]
> >
> > which I commented out, because https for that virtual host is a
> > pure front-end for Tomcat, and of course, Certbot needs to stick
> > something on the server that Let's Encrypt is expecting to be able
> > to find.
> >
> > So a few minutes ago, just for test purposes, I uncommented the
> > above lines. Initially, it didn't work (it redirected the browser
> > from http://foo.bar.com to a nonexistent https://www.foo.bar.com),
> > but when I removed the "www" in the RewriteRule, changing the block
> > to
> >> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
> >> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
> >
> > it worked just fine.
> >
> > So then, I did a "certbot renew --force-renewal" (expecting it to
> > fail on the relevant cert, but in fact, it renewed just fine.
> >
> > Not to look a gift equine in the masticatory orifice, but what am
> > I missing here? What went right, when I was expecting it to go
> > wrong? Why didn't the "rewrite" lines break renewal?
>
> Why would you think that redirecting from http -> https would block
> renewal?
>
From my experience I have excluded .well-known from the redirect.
LE will request initially on port 80.
And if the cert hast expired it may be happier when renewing on port 80.
Peter
> -chris
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
I think I found something.
At the very bottom of LE's FAQ page, https://letsencrypt.org/docs/faq
(under "I successfully renewed a certificate but validation . . ."), I
found:
> Once you successfully complete the challenges for a domain, the
> resulting authorization is cached for your account to use again
> later. Cached authorizations last for 30 days from the time of
> validation. If the certificate you requested has all of the necessary
> authorizations cached then validation will not happen again until the
> relevant cached authorizations expire.
In other words, the authorization cache is likely invalidating the tests
I ran with the rewrite in place!
The more you overthink the plumbing, the easier it is to stop up the drain!
Last night, after I discovered this, I set an alarm for myself (using a
1970s-vintage Los Angeles County Fire Station alarm*, because it's
impossible to ignore), to try another forced renewal next month, one
month after the original certificate issuance, and see what happens. If
the renewal fails, it will give me two months to solve the problem.
__
* FWIW, one of many online copies of the Station 51 alarm (from
"Emergency!") can be found at
https://tvshrine.com/Emergency/ebuzzer.wav
____
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by John Dale <jc...@gmail.com>.
I had to write some custom code to look for the lets encrypt headers
then respond appropriately for verification. It wasn't too bad,
although I don't like having that entity-specific code in there so
I've isolated and commented it.
On 8/25/20, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> James,
>
> On 8/24/20 13:24, James H. H. Lampert wrote:
>> On 8/24/20 9:57 AM, Christopher Schultz wrote:
>>> So your RewriteCond[ition] is expected to always be true? Okay.
>>> Maybe remove it, then? BTW I think your rewrite will strip query
>>> strings and stuff like that. Maybe you just want
>>> RedirectPermanent instead of Rewrite(Cond|Rule)?
>>>
>>> Okay, so everyone gets redirected from http://exmaple.com/ to
>>> https://example.com/. If LE requests
>>> http://example.com/.well-known/uherfhuerhfiu then it will be
>>> redirected to https://example.com/.well-known/uherfhuerhfiu,
>>> presumably locate the correct file and authorize the certificate
>>> request, right?
>>>
>>> But you have said that "everything is unconditionally passed to
>>> Tomcat". You posted some config that definitely passes some
>>> things to Tomcat, but without seeing the rest of the
>>> <VirtualHost> configuration it's not possible to know for sure
>>> nothing else is going on.
>>
>> Ok. In the original post, I posted the virtual host configuration
>> as it was at the time, with meaningful domain names and IP
>> addresses redacted, and some commented-out, abandoned-in-place
>> lines removed.
>>
>> Here is what I currently have in place, albeit with names and IP
>> addresses "changed to protect the innocent." I'm sending you the
>> uncensored version off-List.
>>
>> <VirtualHost *:80> ServerName foo.frobozz.com # ServerAlias
>> bar.frobozz.com DocumentRoot /var/www/html/test ServerAdmin
>> info@frobozz.com <Directory /var/www/html/test> AllowOverride All
>> </Directory> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.
>> [NC] RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
>> [R=301,L] </VirtualHost>
>>
>> <IfModule mod_ssl.c> <VirtualHost *:443> ServerName
>> foo.frobozz.com # ServerAlias bar.frobozz.com DocumentRoot
>> /var/www/html/test ServerAdmin info@frobozz.com # <Directory
>> /var/www/html/test> # AllowOverride All # </Directory> # <Proxy
>> "https://foo.frobozz.com/manager/html/*"> # Require ip
>> aa.bb.cc.dd # </Proxy> # <Proxy
>> "https://bar.frobozz.com/manager/html/*"> # Require ip
>> aa.bb.cc.dd # </Proxy> <Location /manager> Require ip aa.bb.cc.dd
>> ww.xx.yy zz pp.dd.qq.xx </Location> <Location /host-manager>
>> Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx </Location>
>> ProxyPass "/" "http://127.0.0.1:8080/" ProxyPassReverse "/"
>> "http://127.0.0.1:8080/" ProxyRequests Off Include
>> /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile
>> /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
>> SSLCertificateKeyFile
>> /etc/letsencrypt/live/foo.frobozz.com/privkey.pem </VirtualHost>
>> </IfModule>
>
> Yeah... that''s pretty straightforward. Hmm.
>
> No other VirtualHosts? Non other web servers in the mix (e.g.
> load-balancer which alreaddy redirects to HTTPS), etc.?
>
> That seems pretty mysterious to me, too.
>
> Are you using VH-based authentication with LE? Meaning, you aren't
> using DNS authentication or anything like that?
>
> I think once you have configured the server once with an LE
> certificate, renewals can use the existing certificate as
> proof-of-ownership without having to put the file into /.well-known.
> Or something. I have forgotten the details.
>
> So maybe that's it: you've already bootstrapped the process and so
> it's smoother, now. Maybe?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9FHD0ACgkQHPApP6U8
> pFi58xAAvux94C7QCOUkLj8MLGiQV57/ImcTa85nMme2H2ywpZ7JQozlssU6CSpH
> FAYFCOP3U3EH6A9AzFeSZhW+sKMeBt6uF3QR/2QF3vGmg5/KcB0srcdBcn6eejVc
> KrUnVKx5lcK+hmyXPlIVdGb+koiDl1D1omkeOxdQOaniNfGvW1LgUxouRXpUBTfJ
> JK5oe7yV5U8Ge5Wm+pOIrpf/4Y0JqluNJplQIEVWv3x7EsJtSKVKIoCXfPyGf36g
> aGmFRsh6XvndllaV/FBxx/K9zh5TG1GijkfO+vsl4l3ZXnljJm1h4Vx/1Y6KEUbM
> x9Zv8QgNpXsmZ+ylfi3hK0l9V7rkUB6ZX5mYJa9ABPXYtkE/rvCpG6RijVgY9WA4
> 4LXKW74+QR9R352OLBCgvE2gjRgVTX/KmoGasBrB3mDYd+vELkBCcXlHAQkYBVqw
> KL4UIL3SUEnV4jDfrJ/g2ujyPKd9+ED7EECM91lWg6Lcunc5865qJfPvykIDaBnZ
> kASElxqRGqmTUEi57z+BKJNRBs+ME9f7JOlT8iaoB2wKJC8CrUnGNtrFpvBxhehb
> GY4uPrUZro7NjuJ/jALnb1CeedeL9+OohxqbTYECaoeS4Op8vNNU6/FtUH9BTjWD
> mlaXkhrGr7puf4AjPg9geE/0h5Bg+ltTh8yrK1o+4jrct34S438=
> =6dbK
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 8/24/20 13:24, James H. H. Lampert wrote:
> On 8/24/20 9:57 AM, Christopher Schultz wrote:
>> So your RewriteCond[ition] is expected to always be true? Okay.
>> Maybe remove it, then? BTW I think your rewrite will strip query
>> strings and stuff like that. Maybe you just want
>> RedirectPermanent instead of Rewrite(Cond|Rule)?
>>
>> Okay, so everyone gets redirected from http://exmaple.com/ to
>> https://example.com/. If LE requests
>> http://example.com/.well-known/uherfhuerhfiu then it will be
>> redirected to https://example.com/.well-known/uherfhuerhfiu,
>> presumably locate the correct file and authorize the certificate
>> request, right?
>>
>> But you have said that "everything is unconditionally passed to
>> Tomcat". You posted some config that definitely passes some
>> things to Tomcat, but without seeing the rest of the
>> <VirtualHost> configuration it's not possible to know for sure
>> nothing else is going on.
>
> Ok. In the original post, I posted the virtual host configuration
> as it was at the time, with meaningful domain names and IP
> addresses redacted, and some commented-out, abandoned-in-place
> lines removed.
>
> Here is what I currently have in place, albeit with names and IP
> addresses "changed to protect the innocent." I'm sending you the
> uncensored version off-List.
>
> <VirtualHost *:80> ServerName foo.frobozz.com # ServerAlias
> bar.frobozz.com DocumentRoot /var/www/html/test ServerAdmin
> info@frobozz.com <Directory /var/www/html/test> AllowOverride All
> </Directory> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.
> [NC] RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
> [R=301,L] </VirtualHost>
>
> <IfModule mod_ssl.c> <VirtualHost *:443> ServerName
> foo.frobozz.com # ServerAlias bar.frobozz.com DocumentRoot
> /var/www/html/test ServerAdmin info@frobozz.com # <Directory
> /var/www/html/test> # AllowOverride All # </Directory> # <Proxy
> "https://foo.frobozz.com/manager/html/*"> # Require ip
> aa.bb.cc.dd # </Proxy> # <Proxy
> "https://bar.frobozz.com/manager/html/*"> # Require ip
> aa.bb.cc.dd # </Proxy> <Location /manager> Require ip aa.bb.cc.dd
> ww.xx.yy zz pp.dd.qq.xx </Location> <Location /host-manager>
> Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx </Location>
> ProxyPass "/" "http://127.0.0.1:8080/" ProxyPassReverse "/"
> "http://127.0.0.1:8080/" ProxyRequests Off Include
> /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile
> /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
> SSLCertificateKeyFile
> /etc/letsencrypt/live/foo.frobozz.com/privkey.pem </VirtualHost>
> </IfModule>
Yeah... that''s pretty straightforward. Hmm.
No other VirtualHosts? Non other web servers in the mix (e.g.
load-balancer which alreaddy redirects to HTTPS), etc.?
That seems pretty mysterious to me, too.
Are you using VH-based authentication with LE? Meaning, you aren't
using DNS authentication or anything like that?
I think once you have configured the server once with an LE
certificate, renewals can use the existing certificate as
proof-of-ownership without having to put the file into /.well-known.
Or something. I have forgotten the details.
So maybe that's it: you've already bootstrapped the process and so
it's smoother, now. Maybe?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9FHD0ACgkQHPApP6U8
pFi58xAAvux94C7QCOUkLj8MLGiQV57/ImcTa85nMme2H2ywpZ7JQozlssU6CSpH
FAYFCOP3U3EH6A9AzFeSZhW+sKMeBt6uF3QR/2QF3vGmg5/KcB0srcdBcn6eejVc
KrUnVKx5lcK+hmyXPlIVdGb+koiDl1D1omkeOxdQOaniNfGvW1LgUxouRXpUBTfJ
JK5oe7yV5U8Ge5Wm+pOIrpf/4Y0JqluNJplQIEVWv3x7EsJtSKVKIoCXfPyGf36g
aGmFRsh6XvndllaV/FBxx/K9zh5TG1GijkfO+vsl4l3ZXnljJm1h4Vx/1Y6KEUbM
x9Zv8QgNpXsmZ+ylfi3hK0l9V7rkUB6ZX5mYJa9ABPXYtkE/rvCpG6RijVgY9WA4
4LXKW74+QR9R352OLBCgvE2gjRgVTX/KmoGasBrB3mDYd+vELkBCcXlHAQkYBVqw
KL4UIL3SUEnV4jDfrJ/g2ujyPKd9+ED7EECM91lWg6Lcunc5865qJfPvykIDaBnZ
kASElxqRGqmTUEi57z+BKJNRBs+ME9f7JOlT8iaoB2wKJC8CrUnGNtrFpvBxhehb
GY4uPrUZro7NjuJ/jALnb1CeedeL9+OohxqbTYECaoeS4Op8vNNU6/FtUH9BTjWD
mlaXkhrGr7puf4AjPg9geE/0h5Bg+ltTh8yrK1o+4jrct34S438=
=6dbK
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/24/20 9:57 AM, Christopher Schultz wrote:
> So your RewriteCond[ition] is expected to always be true? Okay. Maybe
> remove it, then? BTW I think your rewrite will strip query strings and
> stuff like that. Maybe you just want RedirectPermanent instead of
> Rewrite(Cond|Rule)?
>
> Okay, so everyone gets redirected from http://exmaple.com/ to
> https://example.com/. If LE requests
> http://example.com/.well-known/uherfhuerhfiu then it will be
> redirected to https://example.com/.well-known/uherfhuerhfiu,
> presumably locate the correct file and authorize the certificate
> request, right?
>
> But you have said that "everything is unconditionally passed to
> Tomcat". You posted some config that definitely passes some things to
> Tomcat, but without seeing the rest of the <VirtualHost> configuration
> it's not possible to know for sure nothing else is going on.
Ok. In the original post, I posted the virtual host configuration as it
was at the time, with meaningful domain names and IP addresses redacted,
and some commented-out, abandoned-in-place lines removed.
Here is what I currently have in place, albeit with names and IP
addresses "changed to protect the innocent." I'm sending you the
uncensored version off-List.
<VirtualHost *:80>
ServerName foo.frobozz.com
# ServerAlias bar.frobozz.com
DocumentRoot /var/www/html/test
ServerAdmin info@frobozz.com
<Directory /var/www/html/test>
AllowOverride All
</Directory>
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName foo.frobozz.com
# ServerAlias bar.frobozz.com
DocumentRoot /var/www/html/test
ServerAdmin info@frobozz.com
# <Directory /var/www/html/test>
# AllowOverride All
# </Directory>
# <Proxy "https://foo.frobozz.com/manager/html/*">
# Require ip aa.bb.cc.dd
# </Proxy>
# <Proxy "https://bar.frobozz.com/manager/html/*">
# Require ip aa.bb.cc.dd
# </Proxy>
<Location /manager>
Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
</Location>
<Location /host-manager>
Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx
</Location>
ProxyPass "/" "http://127.0.0.1:8080/"
ProxyPassReverse "/" "http://127.0.0.1:8080/"
ProxyRequests Off
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/foo.frobozz.com/privkey.pem
</VirtualHost>
</IfModule>
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't qutite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by Patrick Baldwin <pb...@myersinfosys.com>.
Dr it really does not work
On Thu, Nov 5, 2020, 12:07 PM James H. H. Lampert <ja...@touchtonecorp.com>
wrote:
> On 8/24/20 9:57 AM, Christopher Schultz wrote:
>
> > So your RewriteCond[ition] is expected to always be true? Okay. Maybe
> > remove it, then? BTW I think your rewrite will strip query strings and
> > stuff like that. Maybe you just want RedirectPermanent instead of
> > Rewrite(Cond|Rule)?
>
> Ladies and Gentlemen:
>
> This past Friday, the cached challenge result expired, and so this past
> Monday, I ran another certbot test.
>
> With the rewrite in place for our "subdomain of interest," the cert
> covering everything else served by the httpd server renewed without
> incident, but the separate cert covering this subdomain failed completely.
>
> I commented out the rewrite, and ran the test again, and both renewed
> without incident.
>
> I posted a redacted version of the complete VirtualHost blocks back on
> August 24th. And after I'd run my tests this week, I've also posted it
> to ServerFault, at
> https://serverfault.com/q/1041047/498231
>
> I'm intrigued by Mr. Schultz's suggestion of
>
> > Maybe you just want RedirectPermanent instead of
> > Rewrite(Cond|Rule)?
>
> Would that make a difference? Or is it just a matter of altering the
> RewriteCond clause to specifically ignore anything that looks like a
> Let's Encrypt challenge? Or is there something I can put on the default
> landing page for the subdomain, rather than in the VirtualHost, to cause
> the redirection?
>
> As I recall (unless there's a way to force-expire the cached challenge
> result on a certbot call), I have to wait until December to run another
> test.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 11/5/20 12:07, James H. H. Lampert wrote:
> I'm intrigued by Mr. Schultz's suggestion of
>
>> Maybe you just want RedirectPermanent instead of
>> Rewrite(Cond|Rule)?
>
> Would that make a difference? Or is it just a matter of altering the
> RewriteCond clause to specifically ignore anything that looks like a
> Let's Encrypt challenge? Or is there something I can put on the default
> landing page for the subdomain, rather than in the VirtualHost, to cause
> the redirection?
I'm just thinking that Redirect[*] is a simpler configuration than
Rewrite(Cond|Rule).
> As I recall (unless there's a way to force-expire the cached challenge
> result on a certbot call), I have to wait until December to run another
> test.
You can delete all your stuff, but LE will get upset if you make
requests too frequently. There is a way to ask LE to let you "test"
stuff and they will lower the frequency limits. I have forgotten how to
do that, but it might be a good idea to look into it since you really
are testing things at this point.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/24/20 9:57 AM, Christopher Schultz wrote:
> So your RewriteCond[ition] is expected to always be true? Okay. Maybe
> remove it, then? BTW I think your rewrite will strip query strings and
> stuff like that. Maybe you just want RedirectPermanent instead of
> Rewrite(Cond|Rule)?
Ladies and Gentlemen:
This past Friday, the cached challenge result expired, and so this past
Monday, I ran another certbot test.
With the rewrite in place for our "subdomain of interest," the cert
covering everything else served by the httpd server renewed without
incident, but the separate cert covering this subdomain failed completely.
I commented out the rewrite, and ran the test again, and both renewed
without incident.
I posted a redacted version of the complete VirtualHost blocks back on
August 24th. And after I'd run my tests this week, I've also posted it
to ServerFault, at
https://serverfault.com/q/1041047/498231
I'm intrigued by Mr. Schultz's suggestion of
> Maybe you just want RedirectPermanent instead of
> Rewrite(Cond|Rule)?
Would that make a difference? Or is it just a matter of altering the
RewriteCond clause to specifically ignore anything that looks like a
Let's Encrypt challenge? Or is there something I can put on the default
landing page for the subdomain, rather than in the VirtualHost, to cause
the redirection?
As I recall (unless there's a way to force-expire the cached challenge
result on a certbot call), I have to wait until December to run another
test.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 8/24/20 11:45, James H. H. Lampert wrote:
> On 8/22/20 7:35 AM, Christopher Schultz wrote:
>
>>> (1) every http request is unconditionally redirected to https:
>>>
>>> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
>>> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
>>> [R=301,L]
>>
>> This is not unconditional. That's what "RewriteCond" does: it
>> sets up a condition :)
>>
>> If Let's Encrypt requests http://www.yoursite.com/ then it won't
>> be redirected.
> . . .
>> What domains are you asking LE to certify?
>
> Except that the "www." prefix subdomain is undefined. There's no
> entry for it in Amazon Route 53; it was deliberately *not* given in
> the initial provisioning of the cert from LE, and it's *not* in the
> certbot configuration file for the subdomain.
So your RewriteCond[ition] is expected to always be true? Okay. Maybe
remove it, then? BTW I think your rewrite will strip query strings and
stuff like that. Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?
Okay, so everyone gets redirected from http://exmaple.com/ to
https://example.com/. If LE requests
http://example.com/.well-known/uherfhuerhfiu then it will be
redirected to https://example.com/.well-known/uherfhuerhfiu,
presumably locate the correct file and authorize the certificate
request, right?
But you have said that "everything is unconditionally passed to
Tomcat". You posted some config that definitely passes some things to
Tomcat, but without seeing the rest of the <VirtualHost> configuration
it's not possible to know for sure nothing else is going on.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9D8WcACgkQHPApP6U8
pFiyMRAAyS+lAy91W8/6aB2I1NnbxbmX1EB1pACnr7MzT35Z6LPttNXNRPNXufN0
hxJfoeep/4HBjd3m7v3n/NZAYle2/qfzhEb4LGvkVDwlznXeOYKUr4OV16NkhYvO
G6mtLi+dIe23LCh8hsIeabcT+Ggds59cLyScsV5g9ID+DcAUyDN6XOnZRGjqlGRo
jabdf1Ae+tjaWOSSQ1gseeK5s9ZliFvALh8qNSQMTj4txa5UJ9sUJbBbKm3NtQQT
fFHFw7qeMfP1ROAW49FE8QqHKaVScG1g4xsGbtkgahqiDyS8EF0FTgResxJiVLYy
FM0NZH8q8RAQEyeZUr9Vyq8YsRSII/4NTaeH29oiE8k33ipV8SzC18e58a1Lo1e8
kQj9F8c6cQkZiLDmte0TfeKem+bSv2aUtt6XhVNRBKv28Tvb8Vml+cMiuoMQktyg
8C8tn9ZxRQlsNF1YbpSTRf4xGHEiSg23u5zPWohCMi8nOwom3gf1UexEMIb9hvbj
qn3Or2P7l6nn8Ij3bTYejoIFDo647t1cRmgnb9C4nxXgGFR2kNVLVKZVehnWUYxQ
2A7No7CeLfJSEui3NowKy/WLwUkR+dX65hSaC3qZFpNpg6TzixqqGHOaGLLkCfoZ
jxnfhhs3Zk3j3Ipz2rZsUdT2Mwaytw750UNfZbuSWF9/F0C8f+0=
=50tL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/22/20 7:35 AM, Christopher Schultz wrote:
>> (1) every http request is unconditionally redirected to https:
>>
>> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule
>> ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
>
> This is not unconditional. That's what "RewriteCond" does: it sets up
> a condition :)
>
> If Let's Encrypt requests http://www.yoursite.com/ then it won't be
> redirected.
. . .
> What domains are you asking LE to certify?
Except that the "www." prefix subdomain is undefined. There's no entry
for it in Amazon Route 53; it was deliberately *not* given in the
initial provisioning of the cert from LE, and it's *not* in the certbot
configuration file for the subdomain.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 8/21/20 13:14, James H. H. Lampert wrote:
> On 8/21/20 9:30 AM, Christopher Schultz wrote:
>
>> Why would you think that redirecting from http -> https would
>> block renewal?
>
> Because, at least if I correctly understand what I set up,
>
> (1) every http request is unconditionally redirected to https:
>
> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule
> ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
This is not unconditional. That's what "RewriteCond" does: it sets up
a condition :)
If Let's Encrypt requests http://www.yoursite.com/ then it won't be
redirected.
> (2) every https request is unconditionally passed to Tomcat.
>
> ProxyPass "/" "http://127.0.0.1:8080/" ProxyPassReverse "/"
> "http://127.0.0.1:8080/" ProxyRequests Off
>
> and (3) Let's Encrypt rechecks domain control when it renews, and
> therefore Certbot needs to put something where the Let's Encrypt
> server can find it.
>
> Are any of these assumptions wrong?
What domains are you asking LE to certify?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9BLSAACgkQHPApP6U8
pFjFIQ//cO9QGyqvHZzmWm1m28CCCZ4bjG/LpLH8QbflQHrum39wV1b5l+idWdST
QlnBV9ZWmFlHFqLw/NyHXUW6o3GHZRv0ObKJ+qVBZlSQ2dS1IZ4DQkQBuq7qq2ZK
PNg2Z8Gu9TkaGAbn7G6VqOht+AQ5BdnjSkQLKlA/9goJIx/vt7oqZusXk9eAHL06
hoKr44+LzhgdkoLI4fAFNBeHx9tSnOluovT75/cHRTMcOoyIOAOXn0sjeQTiJZw/
i/yBjp3SkSZCvmzWj0rpOfmrvb3Fe+s/yXtvNWdsWptVUuDEeFcGKq+syVPuRB0I
K37q/FFEKmeQyOsqqKdwHv0kiWOASoFRqt+Or5Rvqo22MhV2abhkJ2P2u23BkLOy
nTA6deeHZOXzSptjzVrgzAXpNO88dL0WFarMONLs/hffCIGVSRbVgzUS3vawS5z1
Ar+DM26Hna2ZB7VjjgpXMivsXAPUJWxxZhMJt0tniq6T1YHHJJdpIUh6QYsGR6Tg
Oo6aSNK7tPPDdgmCEkuqB1S3qEmhNvD4AKVlkZ/L9PVqGOUDEMNn5DRGduobNz+B
eTiYIImIovIQhRy2cRmNmgSotOlwxkJMFX+eat9eJT/0NTKG0tlwajBculzEIPH3
3CConKkHXAuzTj1KZbVMYon2fAfuN6VbOkEdl4bEWNBm2NFnfAk=
=R0qT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with
Tomcat behind httpd
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 8/18/20 19:47, James H. H. Lampert wrote:
> Something just worked, that I wasn't expecting to work. Or rather,
> I was expecting it to work, but kill cert renewal.
>
> The port 80 virtual host had
>> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
>> RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI}
>> [R=301,L]
>
> which I commented out, because https for that virtual host is a
> pure front-end for Tomcat, and of course, Certbot needs to stick
> something on the server that Let's Encrypt is expecting to be able
> to find.
>
> So a few minutes ago, just for test purposes, I uncommented the
> above lines. Initially, it didn't work (it redirected the browser
> from http://foo.bar.com to a nonexistent https://www.foo.bar.com),
> but when I removed the "www" in the RewriteRule, changing the block
> to
>> RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC]
>> RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
>
> it worked just fine.
>
> So then, I did a "certbot renew --force-renewal" (expecting it to
> fail on the relevant cert, but in fact, it renewed just fine.
>
> Not to look a gift equine in the masticatory orifice, but what am
> I missing here? What went right, when I was expecting it to go
> wrong? Why didn't the "rewrite" lines break renewal?
Why would you think that redirecting from http -> https would block
renewal?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8/9qEACgkQHPApP6U8
pFhpGg//cyv9CbQmk1RFVA87af5gg2+3EUeF6usVXRJQJZqf48iqfKoXv8S+qBb3
5enCuLsIlLLJiAJvDYR6OcE5o2IVbCZvX4M+w4M9fN3Y5PP41fW0CfDZL6JCNup7
B5tK4v3pUuRASkSgf9By6fGKo4YUQuHNxgXB+06PdrVJUAo/4OptRgq9VDxGKWCv
wsibld8WwCNO52rU6O0/SA5fn30uw5WwJ0UfhjL2ki5GeFFCKMv61i9m0YhJ6XP2
Cxb8+LBAIG4Dzk8ix6IXiCSA9cfw5TbyVPibjmRhmnovIuHN5KFog14r+R/ucW3C
BzZBhKu/ayqs+JSih7FzbaH9l5UZ8568pz1AxvvbjTD6U4zdSr5Q0xirKBQBBVwW
QF8B0cHbXzEjy9SxNF7iUhMIMOtzkBxQWDTuRbWOWuWV4D8zmbkXO04ZrylKOteV
tl66flpZVwnjAaql4Pts3gsJgH/oWLUz3Q3kp5C6/oG+nwaM/OwI6nJ6Fa5bL9cc
qnVTp+3Stm2v6LQ2J2w8xxwrXE8elns9ueMpVkENPjrsMj4DnyWWBUGA4Sw4x9pb
FycPnlI8hlPAeTVBTGvTSxjM5E3OLfvkEf4flEYS5lN+2dcTlxub20uNoCOhYteT
eS6peArjYiFhgeEkWMQN+haPe2mpjdFUB6aXj62ZLrC8tszN8jg=
=jR6T
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org