TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

[Justin Y]

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.


  I'm using the /TLSCertificateReloadListener/ 
 
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/ 
 
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

--
Justin Yunke

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

[Justin Y]

Hi Mark --

  Ha!  I just ran a test (while you were responding) and made the same 
confirmation:  TLSCertificateReloadListener in 10.1.18 works, 
TLSCertificateReloadListener in 10.1.19 doesn't.


  Thank you!  Happy to confirm 10.1.20 for you; just ask.  And, by the 
way, I've seen 'markt' showing up in those Changelogs for quite some 
time and it's a genuine pleasure to have a conversation with you.  
You've contributed so much to the Tomcat world, and I appreciate what 
you do.


-- Justin

On 3/18/24 3:20 PM, Mark Thomas wrote:

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


--
--

Justin Y 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org