Hi Christopher,
> This should be okay, though it is a little unusual to use the same keystore
> for both "keys" and "trusted certs".
> Can you confirm the contents + types of everything in the keystore?
After your approach from the end of your response, I exported the certificate
of main and st
Mark --
Got it. So TCP retransmits can impact tomcat processing time under certain
conditions, more likely due to issues with receiving requests from the client
than sending responses.
-Eric
> -Original Message-
> From: Mark Thomas
> Sent: Tuesday, September 8, 2020 4:05 PM
> To: user
On 08/09/2020 21:46, Eric Robinson wrote:
> Hi Mark --
>
> "If the request is split across multiple packets the timer starts when Tomcat
> reads the first byte of the request from the first packet.
> Tomcat stops the timer on a request after the last byte of the response has
> been accepted by t
Hi Mark --
"If the request is split across multiple packets the timer starts when Tomcat
reads the first byte of the request from the first packet.
Tomcat stops the timer on a request after the last byte of the response has
been accepted by the network stack."
Now we're getting somewhere. If to
On 08/09/2020 21:19, Eric Robinson wrote:
> Hi Mark and Christopher,
>
> For clarification, suppose a client sends and HTTP POST request which
is bigger than the PMTU and has to be broken into multiple packets. It
sounds like you're saying that the request is buffered by the network
stack, and the
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.
Hi Mark and Christopher,
For clarification, suppose a client sends and HTTP POST request which is bigger
than the PMTU and has to be broken into multiple packets. It sounds like you're
saying that the request is buffered by the network stack, and the stack does
not send it up to tomcat until th
James,
> -Original Message-
> From: James H. H. Lampert
> Sent: Tuesday, September 08, 2020 2:13 PM
> To: Tomcat Users List
> Subject: Re: SSL debug?
>
> I'm finally back on this problem.
>
> >> We are once again having SSL difficulties with our webapp connecting
> >> with an outside w
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 no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric,
On 9/8/20 13:46, Eric Robinson wrote:
> It is my understanding that the AccessLogValve %D field records the
> time from when the last byte of the client's request is received
> to when the last byte of the server's response is placed on the
>
On 08/09/2020 18:46, Eric Robinson wrote:
> It is my understanding that the AccessLogValve %D field records the time from
> when the last byte of the client's request is received to when the last byte
> of the server's response is placed on the wire. Is that correct? If so, would
> TCP retransmi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 9/8/20 03:58, David Weisgerber wrote:
> I have some weird problem or bug with the HTTPS Connector. In our
> product, that ships with tomcat we want to achieve the following:
>
> There is one keystore where the customer puts its server
> ce
It is my understanding that the AccessLogValve %D field records the time from
when the last byte of the client's request is received to when the last byte of
the server's response is placed on the wire. Is that correct? If so, would TCP
retransmissions impact the timer? If there are connectivity
Hi Luis,
My keystore (for HTTPs):
-rw-r--r-- 1 root root 4067 Sep 8 10:27 /diagdata/keystore.jks
General Java Keystore:
-rw-r--r-- 1 root root 149549 Sep 8 09:32 /etc/ssl/certs/java/cacerts
lrwxrwxrwx 1 root root 27 Apr 18 14:25
/usr/lib/jvm/java-14-openjdk-amd64/lib/security/cacerts ->
/etc/s
Hello David,
That error usually happens when the java process (tomcat) can not access
the truststore file. May I ask you to check permissions and ownership of
the truststore file? You can always add -Djavax.net.debug=all to your
CATALINA_OPTS, it will give you way more information about the issue.
Hi,
I have some weird problem or bug with the HTTPS Connector. In our product, that
ships with tomcat we want to achieve the following:
There is one keystore where the customer puts its server certificate for HTTPs
as well as (if intended) zero or one certificate for client authentication. The
c
16 matches
Mail list logo
