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
Dr it really does not work
On Thu, Nov 5, 2020, 12:07 PM 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
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
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
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
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 wrote:
> -BEGIN PGP SIGNED
-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
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
-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
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
-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,
Chris
> Am 21.08.2020 um 18:30 schrieb Christopher Schultz
> :
>
> 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
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,
On 1/9/20 1:24 AM, Mark Thomas wrote:
The moderators are aware of the situation. The subscriber in question
was blocked from making further posts an hour or so ago.
I'm glad to see that I'm not the only one who looked at those posts, and
found them less-than-helpful (I think every link he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Everyone,
On 1/9/20 4:24 AM, Mark Thomas wrote:
> On 09/01/2020 08:27, calder wrote:
>> Moderators ?
>
> The moderators can be contacted via users-ow...@tomcat.apache.org
>
> The moderators are aware of the situation. The subscriber in
>
James,
Am 2020-01-09 00:58, schrieb James H. H. Lampert:
I wrote:
Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
and ".key" files directly, instead of the Java Keystore file?
On 12/30/19 1:41 PM, Peter Kreuser wrote:
Correct!
I tried an experiment this afternoon:
I
On 09/01/2020 08:27, calder wrote:
> Moderators ?
The moderators can be contacted via users-ow...@tomcat.apache.org
The moderators are aware of the situation. The subscriber in question
was blocked from making further posts an hour or so ago.
Blocking a user is not a decision the moderators
Moderators ?
On Wed, Jan 8, 2020, 20:44 Zahid Rahman wrote:
>
> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>
> I went to college and studied IT before finding a job. My teacher explained
> to me that you
The second technique is to use the *.nix command.
The result is as below
diff a.out b.out I draw your attention to third line in FILE b.out
5,7c5,7
< SSLEnabled="true" scheme="https" secure="true"
< keystoreFile="[REDACTED]" keyAlias="[REDACTED]" ciphers="[REDACTED]"
< clientAuth="false"
http://tomcat.10.x6.nabble.com/Can-t-Get-SSL-to-Work-in-8-5-td5071245.html
On Thu, 9 Jan 2020, 03:01 Zahid Rahman, wrote:
>
> https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html
>
> On Thu, 9 Jan 2020, 02:44 Zahid Rahman, wrote:
>
>>
https://confluence.atlassian.com/confkb/ssl-connector-fails-to-initialize-during-tomcat-startup-646251490.html
On Thu, 9 Jan 2020, 02:44 Zahid Rahman, wrote:
>
> https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
>
> I
https://stackoverflow.com/questions/46786046/severe-main-org-apache-catalina-core-standardservice-initinternal-failed-to-in
I went to college and studied IT before finding a job. My teacher explained
to me that you should always look at the first error and ignore the rest.
First error.
I wrote:
Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt"
and ".key" files directly, instead of the Java Keystore file?
On 12/30/19 1:41 PM, Peter Kreuser wrote:
Correct!
I tried an experiment this afternoon:
I made a copy of the existing server.xml file, and I changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/8/20 12:35 PM, James H. H. Lampert wrote:
> On 1/8/20 5:18 AM, Christopher Schultz wrote: . . .
>> Now the URL line becomes (for me, using a management port):
>>
>> http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtoco
On 1/8/20 5:18 AM, Christopher Schultz wrote:
. . .
Now the URL line becomes (for me, using a management port):
http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa
ndler,port%3D8215=reloadSslHostConfigs
. . .
Have you configured any elements, or are you using the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/7/20 8:24 PM, James H. H. Lampert wrote:
> On 1/7/20 4:19 PM, Christopher Schultz wrote:
>
>> You probably "spelled" something incorrectly. It might be a
>> quoting/escaping issue. It might be a literal misspelling/typo.
>>
>> The
On 1/7/20 4:54 PM, Christopher Schultz wrote:
I have further confused you, because TCP packets+connections also have
state, and I misspoke.
Think nothing of it: at my age, I'm easily confused.
--
JHHL
-
To unsubscribe,
On 1/7/20 4:19 PM, Christopher Schultz wrote:
You probably "spelled" something incorrectly. It might be a
quoting/escaping issue. It might be a literal misspelling/typo.
The JMXProxyServlet shouldn't NPE like that, though.
I'll take a look and see if we can give you a better error message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/7/20 7:22 PM, James H. H. Lampert wrote:
> On 1/7/20 4:17 PM, Christopher Schultz wrote:
>> iptables doesn't work on pipes, it works on packets. So you have
>> to redirect both incoming AND outgoing packets. That's why you
>> have the
On 1/7/20 4:17 PM, Christopher Schultz wrote:
iptables doesn't work on pipes, it works on packets. So you have to
redirect both incoming AND outgoing packets. That's why you have the
"output redirect" as well as the (more obvious) "input redirect".
Well, that just leaves me more puzzled than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/7/20 1:33 PM, James H. H. Lampert wrote:
> This just gets weirder and weirder.
>
> I added manager-jmx to the admin account. I continued to get "401
> unauthorized."
>
> I then tried setting up another user, temporarily, with a
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/7/20 12:28 PM, James H. H. Lampert wrote:
> On 1/7/20 7:32 AM, Christopher Schultz wrote:
>> Hah, sorry about that. Nobody thought of specifying that only
>> root can view the iptables stuff. :)
>
> Not your fault, nor that of anybody
This just gets weirder and weirder.
I added manager-jmx to the admin account. I continued to get "401
unauthorized."
I then tried setting up another user, temporarily, with a URL-friendly
user-ID and password. If I just gave that user "manager-gui," I got "403
access denied" instead,
On 1/7/20 7:32 AM, Christopher Schultz wrote:
Hah, sorry about that. Nobody thought of specifying that only root can
view the iptables stuff. :)
Not your fault, nor that of anybody else here; I blame the author of
iptables and iptables-save: it should either (a) allow *anybody* to
*see* the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/6/20 9:10 PM, James H. H. Lampert wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly
> brace, and an embedded question mark.
>
> If I do this (the names have been changed to protect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/6/20 4:28 PM, James H. H. Lampert wrote:
> I think I found something, with the help of "MLu" on ServerFault:
>
> He advised me to try "iptables -L" and "iptables-save" again, only
> this time "sudo" them.
Hah, sorry about that. Nobody
James,
> Am 07.01.2020 um 03:11 schrieb James H. H. Lampert :
>
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly brace, and
> an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent, and the
> -k!)
>
https://stackoverflow.com/questions/17560858/command-prompt-having-trouble-escaping-quotes-and-braces
You can use curl -g to turn off globbing:
On Tue, 7 Jan 2020, 02:11 James H. H. Lampert,
wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly
Dear Mr. Schultz, et al.:
The manager password on this Tomcat server has an embedded curly brace,
and an embedded question mark.
If I do this (the names have been changed to protect the innocent, and
the -k!)
curl -k
Ladies and Gentlemen:
As I said earlier today, I have
# Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020
*filter
:INPUT ACCEPT [5018099:5766179544]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [400:2863742410]
COMMIT
# Completed on Mon Jan 6 21:17:22 2020
# Generated by
Heureka!
Actually, I was thinking more "Sokath, his eyes uncovered!"
And actually, at this point, I'm thinking I'm better off with Apache
httpd handling port 80, since it would only be used for Let's Encrypt,
and Let's Encrypt and certbot currently play much more nicely with it
than with
James,
>> Am 06.01.2020 um 22:28 schrieb James H. H. Lampert
>> :
>>
>> I think I found something, with the help of "MLu" on ServerFault:
>>
>> He advised me to try "iptables -L" and "iptables-save" again, only this time
>> "sudo" them.
>>
>> When I did "iptables -L" under root
I think I found something, with the help of "MLu" on ServerFault:
He advised me to try "iptables -L" and "iptables-save" again, only this
time "sudo" them.
When I did "iptables -L" under root privileges, I still only got column
headings, but when I did "iptables-save" under root privileges,
On 1/6/20 11:29 AM, Christopher Schultz wrote:
I think Route 53 always uses a load-balancer, doesn't it?
No. A load balancer implies the existence of a cluster, and this is a
single instance, with a fixed IP address, and that is the address in the
A record under Route 53.
And if a load
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/6/20 13:05, James H. H. Lampert wrote:
>> $ host foo.bar.net
>>
>> And check the IP versus the IP of the Tomcat node?
>
> Doing a "host" on the domain gives me the same IP address where
> the instance itself lives, which is also the
$ host foo.bar.net
And check the IP versus the IP of the Tomcat node?
Doing a "host" on the domain gives me the same IP address where the
instance itself lives, which is also the address given in Route 53.
--
JHHL
-
To
> Did I? I don't recall recommending purchasing a certificate
Purchase a domain name not certificate.
On Mon, 6 Jan 2020, 16:45 Christopher Schultz,
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Zahid,
>
> On 1/6/20 10:08, Zahid Rahman wrote:
> > 》> If, however, I do curl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Zahid,
On 1/6/20 10:08, Zahid Rahman wrote:
> 》> If, however, I do curl https://foo.bar.net from my Mac, I get a
>> response, but if I do curl https://localhost, it doesn't get
>> anywhere.
>
> This may be relevant. In the video mentioned earlier
》> If, however, I do curl https://foo.bar.net from my Mac, I get a
> response, but if I do curl https://localhost, it doesn't get
> anywhere.
This may be relevant. In the video mentioned earlier in the thread the
let's encrypt expert says let's encrypt doesn't work on localhost but
it only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/3/20 13:47, James H. H. Lampert wrote:
> On 1/3/20 9:57 AM, Christopher Schultz wrote:
>> Is perhaps the AWS firewall (which is a Load Balancer, right?)
>> redirecting the port?
>>
>> Easy test (from the server):
>>
>> $ telnet
On 1/3/20 9:57 AM, Christopher Schultz wrote:
Is perhaps the AWS firewall (which is a Load Balancer, right?)
redirecting the port?
Easy test (from the server):
$ telnet localhost 443
I hadn't thought of that. But alas, that instance doesn't have Telnet on it.
If it connects, you have
how.
>
> * Just as it was when I *was* setting this thing up in the first
> place, httpd configuration files (that can be all over the place)
> make me long for the simplicity of Tomcat configuration files.
>
> I *think* I can *probably* get Apache (and a cron job running
> cer
t was when I *was* setting this thing up in the first place,
httpd configuration files (that can be all over the place) make me long
for the simplicity of Tomcat configuration files.
I *think* I can *probably* get Apache (and a cron job running certbot)
on Let's Encrypt, and Tomcat using i
Chris & James,
Sorry for topposting.
Is Tomcat really the SSL endpoint that takes the cert? Then it wouldn’t matter
if there is a loadbalancer or the like.
Maybe it’s just authbind or iptables natting? that would be a common way to
have a non-root service to listen externally on 443.
If not
James,
> Am 28.12.2019 um 00:33 schrieb James H. H. Lampert :
>
>
>>>
>>> Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" and
>>> ".key" files directly, instead of the Java Keystore file?
Correct!
> If so, then that could potentially simplify things: if I have HTTPD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Andrew,
On 12/27/19 17:23, Andrew Stanton wrote:
> Hi All,
>
> If possible, I think it's better to let 443 (https) requests
> hitting an instance be redirected to 80 so you don't have to
> configure an SSL locally in the instance itself. It's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 12/27/19 17:07, James H. H. Lampert wrote:
>>> As it happens, one way or another (and I'm not entirely sure
>>> *which* way; I'd have to look at my notes), we *do* have
>>> Tomcat listening directly on 443 (but not 80; nothing there is
Chris,
Peter Kreuser
> Am 27.12.2019 um 21:14 schrieb Christopher Schultz
> :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>>
> but the idea is that certbot has "plug-ins" and we'd need to
> supply a "tomcat" plug-in that did things like this. I'm not sure
> where the best
Something else I noticed, just now:
If I do an "ss -tulwn" on the EC2 instance under discussion, it only
lists 8443, not 443. And yet if I look at the AWS management console,
the security group I set up allows 443, but not 8443, and I don't see
anything external to the box that would be doing
As it happens, one way or another (and I'm not entirely sure
*which* way; I'd have to look at my notes), we *do* have Tomcat
listening directly on 443 (but not 80; nothing there is currently
listening on 80) on that particular EC2 instance (and I'm pretty
sure we have HTTPD running on a
Hi All,
If possible, I think it's better to let 443 (https) requests hitting an
instance be redirected to 80 so you don't have to configure an SSL locally
in the instance itself. It's very cumbersome to do it that way.
You can also use a single instance behind an AWS LB if you only have one
As it happens, one way or another (and I'm not entirely sure
*which* way; I'd have to look at my notes), we *do* have Tomcat
listening directly on 443 (but not 80; nothing there is currently
listening on 80) on that particular EC2 instance (and I'm pretty
sure we have HTTPD running on a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 12/27/19 14:22, James H. H. Lampert wrote:
> On 12/26/19 8:31 PM, Igal Sapir wrote:
>> You should check out Chris' presentations on the topic. He
>> outlines a very efficient process. There is probably more
>> materials out there, but a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter,
On 12/27/19 11:27, logo wrote:
> Am 2019-12-27 16:40, schrieb Christopher Schultz: That's the plan.
> In Las Vegas, Christopher Tubbs did say to me "aw, I was really
> hoping for you to tell us that you just set letsEncrypt="true" in
> your
On 12/26/19 8:31 PM, Igal Sapir wrote:
You should check out Chris' presentations on the topic. He outlines a very
efficient process. There is probably more materials out there, but a quick
search brings up the video [1] and slides [2] from his presentation at
ApacheCon earlier this year, as
wrote:
We have a Tomcat (8.5.40) server running on an Amazon EC2
instance, currently using a Java Keystore for the SSL support.
We would like to be able to use Let's Encrypt, but I've learned
that Let's Encrypt and Tomcat don't get along all that well
together. The best I've found so far are a
We have a Tomcat (8.5.40) server running on an Amazon EC2
>> instance, currently using a Java Keystore for the SSL support.
>>
>> We would like to be able to use Let's Encrypt, but I've learned
>> that Let's Encrypt and Tomcat don't get along all that well
>> together
gt;>
>>> We have a Tomcat (8.5.40) server running on an Amazon EC2
>>> instance, currently using a Java Keystore for the SSL support.
>>>
>>> We would like to be able to use Let's Encrypt, but I've learned
>>> that Let's Encrypt and
jam...@touchtonecorp.com> wrote:
> We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
> currently using a Java Keystore for the SSL support.
>
> We would like to be able to use Let's Encrypt, but I've learned that
> Let's Encrypt and Tomcat don't get along all that well toge
e able to use Let's Encrypt, but I've learned that
Let's Encrypt and Tomcat don't get along all that well together. The
best I've found so far are article at:
<
https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
>
and this thread in the Let's Encrypt com
, but I've learned that
> Let's Encrypt and Tomcat don't get along all that well together. The
> best I've found so far are article at:
>
> <
> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
> >
>
> and this thread in the Let's Encrypt community
, but I've learned that
> Let's Encrypt and Tomcat don't get along all that well together. The
> best I've found so far are article at:
>
> <
> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
> >
>
> and this thread in th
We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
currently using a Java Keystore for the SSL support.
We would like to be able to use Let's Encrypt, but I've learned that
Let's Encrypt and Tomcat don't get along all that well together. The
best I've found so far are article
73 matches
Mail list logo
