Could there be a regression also in 9.0.86
Because I had a similar issue (reload tls didn't work) but It was the
first time I was doing that on that tomcat instance and I had assumed
there was some misconfiguration, even though certificates where server
correctly but the wrong expiration date and after restarting tomcat the
certificates were served with correct dates
Il 18/03/2024 21:20, Mark Thomas ha scritto:
On 18/03/2024 08:21, Mark Thomas wrote:
On 17/03/2024 15:26, Justin Y wrote:
Hi Everyone --
I've spent a few hours scratching my head and then diving into
the source code of 10.1.19 to figure out what's going on.
Could you test with 10.1.18? I'm wondering if the user provided
SSLContext changes in 10.1.19 have triggered a regression.
Never mind. I've just confirmed that those changes did trigger a
regression. I'll commit a fix shortly and it will be in the next round
of releases.
Mark
Mark
I'm using the /TLSCertificateReloadListener/
<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 & 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
out the "sslContext" on line 102 of AbstractJsseEndpoint.
From what I can tell, the SSLHostConfigCertificate objects keep a
copy of an SSLContext and during the JMX unregister and register the
same SSLContext is transferred, which never takes in the same files.
From my limited knowledge, it appears the files will never be
loaded unless a new instance of SSLContext is created.
I've tried both APR (OpenSSL) and native JSSE configurations. One
thing of note - during testing, I'm only using PEM-based cert and
key files (no CA).
I have tried writing my own /TLSCertificateReloadListener/
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d>
implementation but have found no clear way to null the SSLContext of
the (determined expired) SSLHostConfigCertificate objects to allow a
reload.
I appreciate any suggestions!
-- Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
2003 n. 196
per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa
<http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf>
Il contenuto di questo messaggio e dei suoi eventuali allegati è
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di
contattare telefonicamente o via e-mail il mittente ai recapiti sopra
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo
sistema senza farne copia o diffonderli. Le opinioni espresse sono
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the
intended recipient, please telephone or email the sender and delete this
message and any attachment from your system. If you are not the intended
recipient you must not copy this message or attachment or disclose the
contents to any other person. Any opinions presented are solely those of
the author and do not necessarily represent those of the Company.
dott. Ivano Mario Luberti
Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa
tel.: +39 050/580959 | fax: +39 050/8932061
web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/
