Thanks to all, for both satisfying my morbid curiosity and verifying
that it's the customer's problem, not mine.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
On 1/6/21 3:46 PM, Robert Turner wrote:
You'll want to set the protocols, ciphers, and honorCipherOrder ...
The precise wording in the error message is:
. . . but the server presented a certificate signed using a weak
signature algorithm (such as SHA-1). . . .
Which is to say, it doesn't
We just had our first Tomcat 8.5 installation on a customer's AS/400.
The customer apparently has his own CA (they're a big company), and when
I installed SSL in their Tomcat, and tested it with a browser, it
complained, something to the general effect of "weak signature algorithm."
While
On 12/22/20 10:51 AM, Christopher Schultz wrote:
I would try to lock-down that IP range as much as you can, rather than
either removing the Valve (which would allow connections from anywhere)
or specifying something like ".*" in the "allow" attribute (which is a
regular expression which will
A few months back, as I recall, I ran into some "gotchas" in connection
with the manager context, while setting up Tomcat 8.5 on one of our AWS
EC2 instances. As I recall, I had to do something special, somthing I
don't have to do with Tomcat 7, in order to make the manager context
reachable
Ladies and Gentlemen:
The same customer installation that required 104 (but with the 103
catalina.sh, to avoid Bug 64501) back in June is now demanding an update
to 106 because of the CVE-2020-13935 vulnerability.
Two questions:
1. Is the problem from June fixed in 106?
2. Does 106 take
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
First, thanks once again, Mr. Schultz, for getting back to me.
I noticed something rather promising: it seems that maxThreads for the
Port 443 connector were set at 150 for System "A" (problem box), but 400
for System "J" (box that's quite happy).
I've restarted Tomcat with the maxThreads
This is related to my query (thanks, Mr. Gregg) about "Tenured SOA."
It seems that on one of our customer installations, our webapp gets into
a state of running very slowly, and the dedicated subsystem it's running
in is showing massive levels of page-faulting.
I've compared the GC stats of
In at least two of our Tomcat installations, the Server Status page of
Manager is showing "tenured-SOA" around 3G, while the other pools are
showing much lower. What exactly *is* "tenured-SOA," and should this be
cause for alarm?
--
JHHL
On 10/20/20 1:26 PM, Christopher Schultz wrote:
Theoretically, it should not be possible to cause a JVM to crash with
pure Java code.
Thanks.
Of course, we all know that while theory and practice are the same in
theory, they aren't always in practice. ;-P
--
JHHL
We had a Tomcat crash on a customer box, a few hours ago (a simple
restart got them back up and running), and it produced a whole bunch of
errors in the general vein of
*** Invalid JIT return address 0006E2E2E400 in 0001A83C5210
before finally failing with a null pointer exception,
On 10/6/20 2:48 PM, Christopher Schultz wrote:
Thanks for mentioning LEGO. Any time I've been mentioning certbot, you
can replace that with $your-favorite-acme-client.
You're welcome.
LEGO definitely cut my Gordian Knot on that particular project, wherein
Certbot absolutely, positively,
called "LEGO." It *does* require one to shut the Tomcat
server down during the renewal process (because it has to take over the
port briefly), but it also *does* play nicely with a Tomcat server
that's doing its own SSL.
--
James H.
On 9/8/20 1:12 PM, john.e.gr...@wellsfargo.com.INVALID wrote:
I don't remember the precise problem, but verbose SSL will tell you
what trust store and key store you're using, among other things.
I don't blame you. It's been close to a month since I last attempted to
do something about this.
I'm finally back on this problem.
We are once again having SSL difficulties with our webapp connecting
with an outside web service: the java.security override that had solved
the problem in the past (specifically, removing "DESede" from the
"jdk.tls.disabledAlgorithms" in an override file) is
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
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
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
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,
Well, today, I brought the Tomcat server back up, and put the Virtual
Host back into conf.d, and it worked.
Then I learned that my whole silly-go-round of a few months ago, trying
to add the new subdomain to the existing certs, was completely
unnecessary, that each subdomain's virtual host
Permit me to clarify:
1. The existing httpd server on this box, and its certbot setup may be
extended/expanded, but not otherwise disturbed.
2. Running Tomcat independently of httpd on this box is not an option,
because *both* are to be visible to the outside world on port 443 of the
same
Now (as John Cleese would say) for something completely different.
I've got my indpendent Tomcat and httpd servers on the development box
(the Amazon Linux "Not 2" instance) successfully obtaining, using and (I
hope) auto-renewing a Let's Encrypt cert via Lego. (I'll know more on
September
Question:
We are once again having SSL difficulties with our webapp connecting
with an outside web service: the java.security override that had solved
the problem in the past (specifically, removing "DESede" from the
"jdk.tls.disabledAlgorithms" in an override file) is now failing with
43" to the lego
invocation may help.
3. If one is having trouble getting Tomcat to use .crt and .key files,
it is not difficult to turn them into a PKCS12 keystore, which Tomcat
can then use. (Again, thanks, Mr. Schultz!)
--
generating a PKCS12 keystore, rather than using
the certificate and key files directly, I was able to cut out making
local copies of those files, and just reference the ones that Lego put
in /opt/trac-1.2.3-11/letsencrypt/certificates/ directly.
--
On 8/6/20 9:37 AM, Christopher Schultz wrote:
$ openssl pkcs12 -export \
-inkey /etc/tomcat8/test.foo.net.key \
-
Dear Mr. Schultz:
Is there supposed to be something after that last hyphen? When I type
that command, I just get a terminal window full of helptext.
And if I try the
On 8/6/20 9:37 AM, Christopher Schultz wrote:
. . .
As a short-term workaround, you can load your stuff into a keystore
like this:
$ openssl pkcs12 -export \
-inkey /etc/tomcat8/test.foo.net.key \
-
$ openssl pkcs12 -export \
-in /etc/tomcat8/test.foo.net.crt \
-inkey
On 8/5/20 5:04 PM, calder wrote:
Caused by: java.security.KeyStoreException:
Cannot store non-PrivateKeys
If you pasted the full stack trace, then here we have the last "caused by",
showing one issue
at
sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261)
I wrote:
. . .
It seems that with the unwanted update to 7.0.57 that happened on
launching the test spot instances, the Let's Encrypt certs worked just
fine.
But applying the procedure to the *real* development instance (7.0.40)
blew up in my face, failing to open the connectors. Here is an
Ladies and Gentlemen:
I've now proceeded to the "real" server, with the Tomcat portion of the
procedure refined to give me plenty of "undo" capability. And it turns
out I need it.
It seems that with the unwanted update to 7.0.57 that happened on
launching the test spot instances, the Let's
Jon Mcalexander wrote:
Most likely then you need to find a cypher list that is valid for TLSv1.2. Such
as below:
ACCEPTABLE
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
On 8/5/20 10:43 AM, calder wrote:
certificateVerificationh="none"
there's one issue (misspelling), though may not be a contributing
factor.
Corrected; no effect.
Jon McAlexander wrote:
I believe that
protocols="TLSv1.2">
should be
sslEnabledProtocol="TLSv1.2"
My understanding of the
certificateFile="/etc/tomcat8/test.foo.net.crt"
certificateKeyFile="/etc/tomcat8/test.foo.net.key"
certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/>
Can anybody shed any light on what I did wrong?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
xml.
Yet, as I said, Manager is disabled.
Can anybody shed any light on what happened?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Mark Thomas and Christopher Schultz wrote:
You want:
sslProtocol="TLS" sslEnabledProtocols="TLSv1.2"
And to answer my question above, because that is the way the JSSE
API has been written.
We should probably just merge these into a single attribute and "do
the right thing":
1. If not
On 7/17/20 2:36 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:
This looks like a cipher, not an alias
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256
As I said, of course it's a cipher. I said up front that the lines were
truncated, in order to fit in an email.
I can't imagine
On 7/17/20 2:36 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:
This looks like a cipher, not an alias
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256
It is. The lines are truncated at 72 characters for the email.
--
JHHL
Running two connectors seems to work just fine, but I'm having trouble
getting one of them to only take TLS 1.2
In reply to my query:
Given all this, is it possible to (1) have Tomcat listen on two separate
HTTPS ports, and (2) have one of the ports require TLS 1.2, but the
other accept
equire TLS 1.2, but the
other accept something our AS/400 can use?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 6/20/20 8:41 AM, Mark Thomas wrote:
7.0.105 hasn't been released yet. You can use catalina.sh from 7.0
103 or the latest version from source control.
Where would I find "the latest version from source control"?
--
JHHL
-
On 6/19/20 3:20 PM, Mark Thomas wrote:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64501
Hmm. I'm now looking through the entire catalina.sh script in both
versions. (First, I looked through the startup.sh script; that appears
to be identical in both versions.)
First thing I noticed was
On 6/19/20 2:27 PM, calder wrote:
a) it's worth asking the obvious ... are the file permissions correct for
the new TCp installation, i.e , such as read/write in "logs" subdir and
execute permissions for the TC scripts?
Unless something weird is going on with the apache-tomcat-7.0.104.zip
On 6/19/20 1:24 PM, Christopher Schultz wrote:
My guess is that the system-property-setting part of catalina.sh (or
some other script) is getting fouled-up. What script(s) are you
running to start Tomcat?
Remember, we're talking about IBM Midrange systems, not *nix. So bash is
entirely
On 6/19/20 1:24 PM, Christopher Schultz wrote:
My guess is that the system-property-setting part of catalina.sh (or
some other script) is getting fouled-up. What script(s) are you
running to start Tomcat?
Remember, we're talking about IBM Midrange systems, not *nix. So bash is
entirely
On 6/19/20 1:26 PM, calder wrote:
a) are both Tomcat instances installed on that same server?
Yes
b) if yes, is the 7.0.93 instance running when you launch the 7.0.104
instance?
No.
We've done this procedure before: installing a new version, doing the
setup in the new version, then
Ladies and Gentlemen:
In preparation for updating a customer box, I installed Tomcat 7.0.104
on our own AS/400 (64-bit Java 6 JVM).
7.0.93 works just fine on our box, but 7.0.104 seems to crash on
takeoff, producing no log files, just a spool file consisting of the
single line
*-D
Any
I'm hoping to get the one web server we still have on a cert we have to
pay for switched over to Let's Encrypt, and so I cloned the server in
question to a spot instance.
The server in question is an EC2 instance running Amazon Linux (not
Amazon Linux 2), with a Bitnami Trac/SVN stack on it,
a
demonstration webapp, and can be removed and/or replaced like any other
webapp. Our normal "new installation" procedure, for example, is to
remove everything but manager and host-manager, and plug our own webapp
in as the ROOT context.
--
James H. H. Lampert
Touchtone C
Dear Mr. Schultz:
Delighted to hear from you, and delighted that you weighed in on this.
You've already earned my undying respect and gratitude. This also allows
us to drop one more cert that we have to pay for, and I think it could
lead to an easy way to drop yet another.
On 4/9/20 3:31
On 4/9/20 1:37 PM, Peter Kreuser wrote:
It should be sufficient to just do a Location directive and then Require.
Require
Dear Herr Kreuser:
Thanks. I was beginning to wonder if Location might be the answer.
--
JHHL
On 4/6/20 2:13 PM, Mark Eggers wrote:
# Secure your proxy - localhost for now - this is IMPORTANT
Require ip 127
Dear Mr. Eggers:
It seems I was right about how what you said about this, and what the
docs say about it, appeared to contradict each other: with that in the
VirtualHost
On 4/8/20 4:57 PM, Mark Eggers wrote:
See
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy
for some examples.
Yes. That's the very point in the documentation that has my head spinning:
For example, the following will allow only hosts in
yournetwork.example.com to access content via
On 4/8/20 3:52 PM, Mark Eggers wrote:
Require ip 127
Dear Mr. Eggers (et al.):
I'm still not clear on what that even *does* (and the official docs
leave me even more confused: "only allow hosts in . . . to access
content via your proxy"); could you (or somebody else) explain it?
Dear Mr. Eggers, et al.:
Well, after running test installations of Tomcat on a whole string of
EC2 spot instances, I went ahead and installed it on the target server.
I've got it running, and enabled to start automatically, and I've added
a security group to temporarily open 8080 to my office
I don't have enough reputation points to comment on your question on
serverfault.
Is your DocumentRoot (/var/www/html/test) underneath the default
DocumentRoot (normally /var/www/html)?
I found the problem, and it wasn't a [profanity] server problem; it was
a [profanity] client problem!
As it happens, I'm now struggling with an issue just trying to get a new
virtual host up and running on the httpd server. I've put it on Server
Fault, at: https://preview.tinyurl.com/rr3rxwa
While it may not be necessary to solve this problem in order to get the
httpd server to proxy the
First of all, thank you, Mr. Malcom, Herr Kreuser, and Mr. Eggers.
One thing I will note is that near as I can tell, mod_proxy and
mod_proxy_http are already present on the system (I can find
"mod_proxy.so" and "mod_proxy_http.so"), but mod_jk does not appear to
be present (no sign of a
good?
Third, am I correct in assuming that all we need to do in order for the
existing Let's Encrypt setup to cover the new "qux" and "corge"
subdomains is to add them to the SANs already listed?
Finally, are there any "gotchas" I need to be concerned w
Question:
I'm looking at the header of a "java.security" properties file. And I see:
# This is the "master security properties file".
#
# An alternate java.security properties file may be specified
# from the command
we can put the
classes?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 3/24/20 2:25 PM, Christopher Schultz wrote:
I don't understand exactly how X-Frame-Options (which is what the
HttpHeaderSecurityFilter is configuring) is being used by your
application, but I believe X-Frame-Options is essentially being
replaced by various features of Content-Security-Policy.
On 3/24/20 2:25 PM, Christopher Schultz wrote:
. . .
Your problem may stem from the same, related issues we were having. . .
Dear Mr. Schultz:
Thank you very much. I've passed on your reply to our webapp and
mobile-app team.
--
JHHL
on to our webapp/mobile app team.
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 3/18/20 4:03 AM, Mark Thomas replied to my questions:
But I'm not sure (1) how security constraints interact with other
security constraints, and
See section 13.8.1 of the Servlet 4.0 spec.
(2) whether they can go in the conf/web.xml as
well as individual webapps' web.xml files.
Yes
On 3/19/20 12:26 PM, Christopher Schultz wrote:
In case(2) can you show us what certificates are present in your keystore?
Something like:
$ keytool -verbose -list -keystore server.jks
Dear Mr. Schultz, et al:
Actually, at least with the version of keytool I have, it would be more
like:
We maintain a bunch of Tomcat 7 servers for various customers, all using
JSSE security, with a JKS.
All of them show a complete certificate chain when accessed from a
browser. Some (if TLSv1.2 is not enabled, and especially those running
on boxes that don't have Java 7 or Java 8) get
On 3/18/20 1:16 AM, Olaf Kock wrote:
Are you sure that this is for tomcat, not for your own application?
Actually, since on-screen it looks like one of ours, I was already
leaning to that conclusion, and had brought it to the attention of our
webapp developer.
Thanks for all the responses
On 3/17/20 3:50 PM, Mark Thomas wrote:
The XXS might be valid. I assume the tool provided a sample URL you
could use to validate the finding. That should point you in the right
direction but feel free to ask here if more help is required.
Near as I can tell, it did but it didn't provide a
On 3/17/20 3:34 PM, Martin Grigorov wrote:
Reading the quoted text I'd suggest you to throw this tool in the bin.
I hope you didn't pay for it.
Are you suggesting that we throw a paying customer "in the bin?"
It is not OUR audit; it is the CUSTOMER's audit (the report
self-identifies as
On 3/17/20 3:18 PM, Martynas Jusevičius wrote:
why should DELETE or OPTIONS not be enabled? They are standard HTTP methods.
True, but (quoting the audit report)
. . . [DELETE] may allow a remote attacker to delete arbitrary files . . . .
and (again quoting the report)
Web servers that
Ladies and Gentlemen:
One of our customers did a security audit on the Tomcat server we
maintain on their system, and it found a few issues:
First, it found a cross-site scripting vulnerability.
Second, it found the HTTP DELETE method enabled.
Third, it found a click-jacking vulnerability.
This was not a client box, nor one of our cloud boxes; it's our own
production box.
Shortly after I posted my query to the List, I was directed to re-IPL
the system. I initiated the requested restart, and went to lunch.
That worked. The Tomcat server is back up, with all contexts running.
Ladies and Gentlemen of the Tomcat List:
We have a situation.
Earlier today, something (we don't know what) caused the Tomcat (7.0.93)
server on our AS/400 to go crazy, producing a 70G+ catalina.out file,
and rendering the machine generally unresponsive.
Once I was able to get a terminal
Last night, we switched the customer box in question from running Tomcat
under Java 7 (64-bit) to Java 8 (64-bit), and all day today, the
processor load from the Tomcat server has been dramatically lighter. I
haven't seen the overall CPU over around 70% today, and haven't seen the
Tomcat's JVM
From the :
How many VPs does your partition have?
Hardware: Power7 vs Power8/Power9?
How many GC threads?
I wish I knew how to determine the answers to these. What I *do* know is
that the box in question self-IDs as model "22A" (which I've never heard
of, which in itself suggests Power9),
I've got some more detailed GC stats. The full report runs 600 pages for
just the last 300 GC cycles, so I've just included three cycles worth of
data:
GC Cycle Number : 1801
Basic GC Cycle Information:
On 2/12/20 5:37 AM, Niranjan Babu Bommu wrote:
have you turned on codecahe , if that is true can you monitor codecahe?
known issue with codecache in java 7, when codecache fills up the compiler
may not get get restarted even after the codecache occupancy drops down to
half after the emergency
switching to Java 8 help? Would switching to 7.0.93 help?
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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
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
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
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
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
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
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
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
$ 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
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
ts certs (and a cron job reloading
them), without understanding what I'd done to get Tomcat showing up on
443 to the outside world, but it would be nice if I *did* understand
what I'd done.
--
James H. H. Lampert
-
To unsubscribe, e-m
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
d Tomcat sharing the same actual certificate and private key *files*
that HTTPD uses, then the only other thing I have to automate would be a
cron job to either restart Tomcat, or just do a programmatic "re-read
TLS configuration," whenever the regular Let's Encrypt job for H
o look like port 443
to the outside world, because I honestly can't remember what I did (even
though it looks like it's only been six months since I did it).
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tom
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
1 - 100 of 292 matches
Mail list logo
