You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Justin Y <ju...@yunke.us> on 2024/03/17 15:26:52 UTC
TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files
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/
<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
--
Justin Yunke<ju...@yunke.us>
Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files
Posted by Justin Y <ju...@yunke.us>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
--
Justin Y <ju...@yunke.us>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files
Posted by Mark Thomas <ma...@apache.org>.
On 19/03/2024 07:54, Ivano Luberti wrote:
> Could there be a regression also in 9.0.86
Yes. It will be fixed in 9.0.88.
Mark
>
> 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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files
Posted by Ivano Luberti <lu...@archicoop.it.INVALID>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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/
Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files
Posted by Mark Thomas <ma...@apache.org>.
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.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org