04aa708d> to reload files that will be (eventually) managed by Let's Encrypt.
Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are
used forever, causing the trigger to reoccur again and again.
The only way
Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are
used forever, causing the trigger to reoccur again and again.
The only way I can get the system to function correctly is if I,
during debugging in Ecli
che/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d>
to reload files that will be (eventually) managed by Let's Encrypt.
Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are
used forever, causing the
r/
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> to reload files that will be (eventually) managed by Let's Encrypt.
Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert &
log that things were
reloaded, the new files are never read and the old cert & key are used
forever, causing the trigger to reoccur again and again.
The only way I can get the system to function correctly is if I,
during debugging in Eclipse with the matching Tomcat source, null o
to reload files that will be (eventually) managed by Let's Encrypt.
Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are used
forever, causing the trigger to reoccur again and again.
The only way I
Bill,
On 9/22/23 13:25, Bill wrote:
Hello All,
I may have started my SSL Cert install & config at step 2 instead of
step 1... :-(
Most mistakes are recoverable :)
Basically I have created my key store, my p12 file and have my cert all in
a sub directory of the conf directory.
Al
Hello All,
I may have started my SSL Cert install & config at step 2 instead of
step 1... :-(
Basically I have created my key store, my p12 file and have my cert all in
a sub directory of the conf directory.
I have updated the server xml with my connectors per online directions.
Yet my
o demand that all clients connecting also present a
client-certificate to authenticate."
Which of the above is it?
I believe I can live with #1. I'm using a self-signed cert for sure.
Okay, that's good because it reduces the complexity of this whole
operation by ~50%.
Because
> On Jun 15, 2022, at 7:45 AM, Christopher Schultz
> wrote:
>
> Rob,
>
>> On 6/14/22 15:38, Rob Sargent wrote:
>> On 6/14/22 13:06, Christopher Schultz wrote:
>> Thanks so much for your perseverance.
>
> No problem. Anything to avoid doing $work.
Away from my desk this morning but will re
something to the CA.
2. "I want to get Tomcat working as a server with a TLS Certificate,
AND I want to demand that all clients connecting also present a
client-certificate to authenticate."
Which of the above is it?
I believe I can live with #1. I'm using a self-signed
rtificate,
AND I want to demand that all clients connecting also present a
client-certificate to authenticate."
Which of the above is it?
I believe I can live with #1. I'm using a self-signed cert for sure.
My server gets the locations from a properties file and uses
ents (connecting you your Tomcat, right?) are using
keystores, then... it sounds like you want option #2
It all boils down to this:
1. Every pair of entities in a TLS connection are called "peers".
2. Any peer can choose to require the other one to authenticate.
3. In practice, servers
On 6/14/22 12:43, Rob Sargent wrote:
On 6/2/22 16:06, Rob Sargent wrote:
I'm starting both the server and the client with both key and
trust. Does that bite?
I would avoid giving access to the key to anything that doesn't
absolutely need it. Usually, only the server needs access to the
On 6/2/22 16:06, Rob Sargent wrote:
I'm starting both the server and the client with both key and trust.
Does that bite?
I would avoid giving access to the key to anything that doesn't
absolutely need it. Usually, only the server needs access to the key.
-chris
-
I'm starting both the server and the client with both key and trust.
Does that bite?
I would avoid giving access to the key to anything that doesn't
absolutely need it. Usually, only the server needs access to the key.
-chris
---
it pointing to)? Remember that ccan specify both
keystore (for identifying itself) and truststore (for identifying
clients, which you don't need AIUI).
To your latest
I add my cert to truststore.
Which one? Are you using client certs for mutual-TLS or just
plain-old "I
java -Djavax.net.ssl.keyStore=/ppr/certs/sgstrust.p12
-Djavax.net.ssl.keyStoreType=PKCS12
-Djavax.net.ssl.keyStorePassword=p1
-Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
-Djavax.net.ssl.trustStoreType=PKCS12
-Djavax.net.ssl.trustStorePassword=p2
--oper=1 --seg=id
s3 cp sgstrust.p12
s3://691459864434-sgs-source/certs/sgstrust.p12
aws s3 cp sgstrust.p12 s3://691459864434-sgs-source/certs/sgstrust.p12
upload: ./sgstrust.p12 to
s3://691459864434-sgs-source/certs/sgstrust.p12
## program downloads p12 filesfrom s3
To your latest
I add my cert to t
anks Chris, given your vote of confidence I realized I had not updated
the keystore file with my recently regenerated cert.
Also forgot to mention this is tomcat 9.0.63 embedded in my app, running
java17 (correto) at AWS
But I think I'm going backwards.
my actual java command is pretty much
ris, given your vote of confidence I realized I had not
updated the keystore file with my recently regenerated cert.
Also forgot to mention this is tomcat 9.0.63 embedded in my app,
running java17 (correto) at AWS
But I think I'm going backwards.
Hang on. I'm panicking. I have a plane
ized I had not updated
the keystore file with my recently regenerated cert.
Also forgot to mention this is tomcat 9.0.63 embedded in my app, running
java17 (correto) at AWS
But I think I'm going backwards.
my actual java command is pretty much this:
java -Djavax.net.ssl.keyS
Rob,
On 6/2/22 01:13, Rob Sargent wrote:
This part always confuses me
I supply the trust and key store files on the command line and I see the
SAN for the tomcat server IP (in ObjectId #3). I try to connect to
tomcat by host-IP and port. Here's the text of the keystore sent in.
Keystor
This part always confuses me
I supply the trust and key store files on the command line and I see the
SAN for the tomcat server IP (in ObjectId #3). I try to connect to
tomcat by host-IP and port. Here's the text of the keystore sent in.
Keystore type: PKCS12
Keystore provider: SUN
Chris,
Appreciate your guidance.
Will post errors, if there are any.
Best
Paul
-Original Message-
From: Christopher Schultz
Sent: Thursday, February 10, 2022 1:15 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.56 Windows - Assistance with using cert and key
generated using MS
Paul,
On 2/9/22 13:41, paul@stgconsulting.com wrote:
Could someone point me to a how to SSL configuration using cert and key
generated using MS AD Cert server for internal use?
Assuming that "MS AD Cert Server" generates normal X.509 certificates,
it shouldn't matter tha
All,
Could someone point me to a how to SSL configuration using cert and key
generated using MS AD Cert server for internal use?
I have attempted to follow examples in Tomcat docs, as well as examples
found through internet searches.
I have attempted various configurations using either
resent in the cacerts file.
So for your old and new certificate this should all work out if DST Root
CA X3 is in your cacerts file.
And it is not:
$ keytool -list -v -keystore ${JAVA_HOME}jre/lib/security/cacerts | grep
'DST Root'
[nothing]
$
For the next new cert you will have tw
dd intermediate certificates to your
truststore. Your SSL-ified services presents his public certificate and
the certificate chain (all intermediates) to a client. The client
verifies the certificate chain you provided and checks the last
certificate against its truststore containing all root CAs.
So
... 70 more
[..]
[..]
Okay, so it can't validate the server's certificate. Hmm. I thought I
would have fixed that by adding the new cert to the trust store. Maybe
it's using a different trust store.
$ find / -name truststore.jks
/home/jasperreports/jasperserver-to
Maybe try removing the old cert as its not expired yet?
On 25/01/2021 16:10, Christopher Schultz wrote:
Alias name: letsencrypt
Creation date: Dec 12, 2016
Entry type: trustedCertEntry
Owner: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Issuer: CN=DST Root CA X3, O=Digital
ight to
me, that's the only thing that looked off.
HTH
- Jim
-Original Message-
From: Christopher Schultz
Sent: Monday, January 25, 2021 11:11 AM
To: Tomcat Users List
Subject: [OT] Spring Security LDAPS authenticator won't trust TLS cert
CAUTION EXTERNAL EMAIL: This email origi
p.core.support.LdapContextSource.getDirContextInstance(LdapContextSource.java:43)
at
org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:254)
... 70 more
[..]
[..]
Okay, so it can't validate the server's certificate
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: users-h...@
On Wed, Jan 06, 2021 at 03:34:17PM -0800, James H. H. Lampert wrote:
> 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
> complain
James,
> Am 07.01.2021 um 00:34 schrieb James H. H. Lampert :
>
> 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,
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 sou
You'll want to set the protocols, ciphers, and honorCipherOrder attributes
on either the Connector or the SSLHostConfig objects in your server.xml
file to restrict the available TLS/SSL protocols and ciphers available to
avoid using weak ones.
See the documentation here for details:
https://tomcat
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 it'
On 8/6/20 10:10 AM, Christopher Schultz wrote:
$ openssl pkcs12 -export \ -in /etc/tomcat8/test.foo.net.crt \
-inkey /etc/tomcat8/test.foo.net.key \ -certfile
/etc/tomcat8/test.foo.net.issuer.crt \ -out
/etc/tomcat8/test.foo.net.p12 \ -chain
Then reconfigure your to use your keystore.
Dear M
together to make sure everything is okay.
You may not need -chain but I seem to always do it.
My slides for Let's Encrypt + Tomcat say:
$ openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain]
- -out [p12file]
So maybe you don't need the -chain.
- -chris
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 se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 8/6/20 13:03, James H. H. Lampert wrote:
> 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.f
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 /etc/tomcat8
3)
*sigh*
Okay,
>>
this is a confluence of:
1. You are using PEM files instead of a Java keystore
1a. Tomcat handles this by creating an in-memory KeyStore and loading
your key + certificate into it
2. Java 1.8 doesn't like non-private keys in KeyStores for some reason
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)
On Wed, Aug 5, 2020, 18:46 James H. H. Lampert
wrote:
> 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
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 e
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 E
Added as https://bz.apache.org/bugzilla/show_bug.cgi?id=64353
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Mark,
Am 2020-04-15 um 13:44 schrieb Mark Thomas:
> On 15/04/2020 12:06, Osipov, Michael wrote:
>> Folks,
>>
>> is there any way to access the server certififace from a valve which has
>> been used to establish the TLS context? I haven't found an easy way. I
>> don't want to traverse request.getC
On 15/04/2020 12:06, Osipov, Michael wrote:
> Folks,
>
> is there any way to access the server certififace from a valve which has
> been used to establish the TLS context? I haven't found an easy way. I
> don't want to traverse request.getConnector().findSslHostConfigs()
> because it would make it
Folks,
is there any way to access the server certififace from a valve which has
been used to establish the TLS context? I haven't found an easy way. I
don't want to traverse request.getConnector().findSslHostConfigs()
because it would make it more complex than necessary or even unreliable,
es
My bad - I was looking in the catalina log, not the localhost log...
Now I see the config being parsed:
01-Mar-2020 21:12:49.147 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.startInternal Read
configuration from: /WEB-INF/rewrite.config
01-Mar-2020 21:12:49.155 FINE
No matter where I place the rewrite.config, cannot get the
RewriteValve to find it.
I tried:
* /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml and
/usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
* /usr/local/tomcat/conf/context.xml and
/usr/local/tomcat/conf/localhost/rewrite.config
The
I hit a snag with the query string. In some cases it contains the
webapp base URI in a query parameter, such as:
/admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
So I'm trying to rewrite those as well, from
https%3A//localhost%3A5443/ to https%3A//local
:05 schrieb Mark Thomas:
On 29/02/2020 10:40, Michael Osipov wrote:
Tomcat does not support renegotiation of TLS contexts based
on URLs like HTTPd.
Yes it does.
If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You
Thanks! I actually needed proxyPort="443" to make the URL
https://localhost, but your suggestion did the trick.
On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas wrote:
>
>
>
> On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > Yes the clients connect only directly to nginx.
> >
> > So the proxy conf
t; Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>>>
>>>>
>>>>
>>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>>> on URLs like HTTPd.
>&
:40, Michael Osipov wrote:
Tomcat does not support renegotiation of TLS contexts based
on URLs like HTTPd.
Yes it does.
If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained co
gt; On 29/02/2020 10:40, Michael Osipov wrote:
>>>
>>>
>>>
>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>> on URLs like HTTPd.
>>>>>
>>>>> Yes it does.
>>>>>
>>>>
t;>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>> on URLs like HTTPd.
>>>>
>>>> Yes it does.
>>>>
>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>> trigger a renegotiatio
CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained control you have in httpd but you
can replicate the typical use cases.
Really? If I say require client cert auth on the connector, it will be
enf
CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained control you have in httpd but you
can replicate the typical use cases.
Really? If I say require client cert auth on the connector, it will be
enf
On 29/02/2020 11:07, Michael Osipov wrote:
> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>> On 29/02/2020 10:40, Michael Osipov wrote:
>>> Tomcat does not support renegotiation of TLS contexts based
>>> on URLs like HTTPd.
>>
>> Yes it does.
>>
>
Am 2020-02-29 um 12:05 schrieb Mark Thomas:
On 29/02/2020 10:40, Michael Osipov wrote:
Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
Hi,
Instead of configuring the container for client cert Auth change the
webapp:
1) define a realm in local context.xml
2) add resp security constraint only
On 29/02/2020 10:40, Michael Osipov wrote:
> Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
>> Hi,
>>
>> Instead of configuring the container for client cert Auth change the
>> webapp:
>> 1) define a realm in local context.xml
>> 2) add resp security const
rts). This would not be a problem if the webapp would
not be user-facing, but since it is the certificate prompt can be
confusing to many users and increase our bounce rate.
I'm looking for some workaround that would not require changing the
whole design. For example asking for the client cert o
On 28/02/2020 22:26, Martynas Jusevičius wrote:
> Yes the clients connect only directly to nginx.
>
> So the proxy config within 2 pairs of containers is like this:
>
> # website service; clientAuth=false
> nginx:80 -> tomcat:8080
> nginx:443 -> tomcat:8443
>
> # API service; clientAuth=true
). This would not be a problem if the webapp would
>not be user-facing, but since it is the certificate prompt can be
>confusing to many users and increase our bounce rate.
>
>I'm looking for some workaround that would not require changing the
>whole design. For example asking
Yes the clients connect only directly to nginx.
So the proxy config within 2 pairs of containers is like this:
# website service; clientAuth=false
nginx:80 -> tomcat:8080
nginx:443 -> tomcat:8443
# API service; clientAuth=true
nginx-api:90 -> tomcat-api:8080
nginx-api:5443 -> tomcat-api:8443
ng
On 28/02/2020 21:00, Martynas Jusevičius wrote:
> Setting up a second container with a different port was easy enough.
>
> However I got stuck on the URL mapping/rewriting. Using nginx as a
> proxy, I don't think it's possible to rewrite headers with the
> upstream module:
> https://nginx.org/en/d
e both purposes, however
> > >>> only administrators are using the API.
> > >>>
> > >>> The Connector is configured using clientAuth="want".
> > >>> This works fine with API calls which are run from shell scripts.
> > >&g
ere
> >>> are any client certs). This would not be a problem if the webapp would
> >>> not be user-facing, but since it is the certificate prompt can be
> >>> confusing to many users and increase our bounce rate.
> >>>
> >>> I'm looking fo
e run from shell scripts.
>>> In the browser however it prompts a certificate selection (if there
>>> are any client certs). This would not be a problem if the webapp would
>>> not be user-facing, but since it is the certificate prompt can be
>>> confusing
not be a problem if the webapp would
> > not be user-facing, but since it is the certificate prompt can be
> > confusing to many users and increase our bounce rate.
> >
> > I'm looking for some workaround that would not require changing the
> > whole design. For
t be a problem if the webapp would
> not be user-facing, but since it is the certificate prompt can be
> confusing to many users and increase our bounce rate.
>
> I'm looking for some workaround that would not require changing the
> whole design. For example asking for the cli
nfusing to many users and increase our bounce rate.
I'm looking for some workaround that would not require changing the
whole design. For example asking for the client cert only when a
certain flag is set, such as a query param or request header.
Or somehow not asking for it but still accepti
Thanks Mark, will do!
-Original Message-
From: Mark Thomas
Sent: Thursday, October 31, 2019 3:04 PM
To: Tomcat Users List ; George Stanchev
Subject: Re: Client Cert TLS issue
On 16/10/2019 18:55, George Stanchev wrote:
> And this is not where it hangs. I stepped through the c
On 16/10/2019 18:55, George Stanchev wrote:
> And this is not where it hangs. I stepped through the code through the
> handshaker but still haven't been able to figure out the hang point as I am
> not familiar with the details of that portion of TC code . I've attached two
> cacerts that you ca
: users@tomcat.apache.org
Subject: Re: Client Cert TLS issue
Just a note to say I haven't forgotten this. I hope to look at this this week
unless someone beats me to it.
Mark
On 16/10/2019 17:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>&g
the debug logs if
>> requested. The cacerts we use is whatever comes with Azul's Java distro
>> which has ~150 entries + the custom cert for testing. The issue comes from
>> how the connector deals with trusted certs because if I reduce the cacerts
>> to contain only th
Hi Chris,
This didn't make a difference and no difference in CPU utilization was
observed. The lockup happens before server request the client cert so you can
drop my big fat cacerts in a TC instance create a client-cert connector, in our
case we set the " javax.net.ssl.trus
Timeout(0)). I have enabled the client side SSL trace
>> and everything goes well until ECDH key exchange (for brevity I
>> have enabled only one TLS suite
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug
>> logs if requested. The cacerts we
enabled only one TLS suite
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
> requested. The cacerts we use is whatever comes with Azul's Java distro which
> has ~150 entries + the custom cert for testing. The issue comes from how the
> connector deals with tr
enabled only one TLS suite
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
> requested. The cacerts we use is whatever comes with Azul's Java distro which
> has ~150 entries + the custom cert for testing. The issue comes from how the
> connector deals with tr
ug logs if
requested. The cacerts we use is whatever comes with Azul's Java distro which
has ~150 entries + the custom cert for testing. The issue comes from how the
connector deals with trusted certs because if I reduce the cacerts to contain
only the test certificate, the request is being se
se SSLVerifyClient=none, the browser complains
> >
> > This site can’t provide a secure connection login-test.foo.com sent an
> > invalid response.
> > ERR_SSL_PROTOCOL_ERROR
>
> What did you expect?
>
> You told the Connector - explicitly - not to ask for CLIENT-CE
> This site can’t provide a secure connection login-test.foo.com sent an
> invalid response.
> ERR_SSL_PROTOCOL_ERROR
What did you expect?
You told the Connector - explicitly - not to ask for CLIENT-CERT
authentication.
You told the application to require CLIENT-CERT authentication.
It
net.shibboleth.idp.authn.impl.X509AuthServlet
3
X509AuthHandler
/Authn/X509
X509AuthHandler
/Authn/X509
CONFIDENTIAL
X509
CLIENT-CERT
2. server.xml
t session tickets, the client has to provide the cert and the full
chain in the handshake. With OpenSSL session tickets the server caches
the client cert but not the full chain.
The above is only as accurate at the last time I dug into this. There
are lots of variables, JRE version, JSSE vs OpenSSL, O
Thanks for the very quick response! Out of curiosity is this ensured by some
sort of caching in the Tomcat server after the TLS handshake? Or is it
expected that the client would send the certificate with each post handshake
request. I ask as I'm seeing intermittent requests that do not have
On 12/07/2019 08:22, Martynas Jusevičius wrote:
> In my experience with 8.x -- on all requests.
The above is correct for JSSE based TLS connections. It also applies to
most OpenSSL based connections.
There is one edge case that can cause problems. If:
- OpenSSL based TLS connections are used;
-
In my experience with 8.x -- on all requests.
On Fri, Jul 12, 2019 at 3:06 AM Wilmoth, Jon
wrote:
>
> I was hoping to get some clarification on when to expect client x509 certs in
> http requests where the Tomcat server (v9.x) has been configured to “want” or
> “need” client auth.
> https://j
I was hoping to get some clarification on when to expect client x509 certs in
http requests where the Tomcat server (v9.x) has been configured to “want” or
“need” client auth.
https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
says:
“If there is an SSL certifica
wow. All working now. (I think- verifying the Client Cert prompt - borwser
is NOT prompting, but I may not have a cert for it to send)
certificateKeystoreFile etc instead of certificateKeyFile
and
truststoreFile instead of caCertificateFile
( I spent a lot of time searching and trying things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John,
On 2/11/19 10:42, John Palmer wrote:
> I'm new to implementing APR/tc-natiive for SSL/TLS on Windows
> Server 2008R2, attepting to usse tomcat 8.5.37 specifying PKCS12
> format in the SSLHostConfig/Certificate elements for the keystore
> and t
I'm new to implementing APR/tc-natiive for SSL/TLS on Windows Server
2008R2, attepting to usse tomcat 8.5.37 specifying PKCS12 format in the
SSLHostConfig/Certificate elements for the keystore and truststore..
(I would prefer to drop the JKS format for several reasons)
questions are:
is this al
Thanks Chris
> It's worth stopping here to note that
> Tomcat's keystore and truststore
> configuration only effect the connections
> coming into Tomcat.over
> whatever
> is being configured with those stores.
I thought that may be the case, but needed someone to confirm. I assumed I
would h
ection back to the same app A
> cert was created for each server and the keystore file updated with
> the information.
It's worth stopping here to note that Tomcat's keystore and truststore
configuration only effect the connections coming into Tomcat.over
whatever is being configured
1 - 100 of 295 matches
Mail list logo
