Andreas,
On 12/2/25 10:30 AM, Döscher, Andreas (ESI) via dev wrote:
isn't OCSP dead? Let's encrypt stopped OCSP URLs in their
certificates in May 2025 and with the upcoming shorter lifespan of
web-certificates I would expect other CAs to follow.
I completely agree with you, but security controls have a long tail, and
so we will continue to support OCSP as long as the market wants it.
Currently, the phasing-out of OSCP is being driven by the CAs and not by
users. We serve users and not CAs.
What will be interesting is when we have to support bloom-filter-based
CRLs for client certificates.
-chris
-----Ursprüngliche Nachricht-----
Von: Mark Thomas <[email protected]>
Gesendet: Montag, 1. Dezember 2025 15:01
An: Tomcat Developers List <[email protected]>
Betreff: Tomcat Native, OCSP and December releases
WARNING: Do not click links or open attachments unless you recognize the source
of the email and know the contents are safe.
**********************************************************************
All,
As you may be aware, releases have been completed for the Migration tool and
Commons Daemon with a view to including them in the next round of Tomcat
releases.
I also planned to complete a new Tomcat Native release but haven't made much
progress on that yet.
Towards the end of last week I needed to test OCSP for $dayjob. It took me a
day to realise that NIO + OpenSSL behaves differently depending on whether you
define the trusted CAs in a KeyStore or a file. That led to [1]. The test cases
Dimitris wrote were a big help in figuring out what was going on.
Reading through Dimitris's tests also made me realise it shouldn't be too hard
to get OCSP working for JSSE. That got me thinking. If I am going to work on a
Native release, I think it makes sense to include expanding OCSP support. I'm
thinking:
- add OCSP support for all variations of TLS connector
- use common configuration for JSSE and OpenSSL+Tomcat Native and
OpenSSL+FFM where possible
- expose OCSP configuration options in SSLHostConfig
That is probably a reasonable number of days work. So I am thinking about
timing.
A. Do we proceed with the December releases without a new Tomcat Native release
and aim to pick that up in January? (There is probably no more than a day of
prep to do before we are in a position to tag.)
B. Do we delay the December release until a new Tomcat Native release is ready?
C. Do we skip the December release because of the holidays?
Thoughts?
My own thoughts are that I don't think B is a viable option. The earliest we
are likely to have Native release ready is the 8th (and I think that is
optimistic). That means the Tomcat releases are unlikely to be ready earlier
than the 12th which, if there is a regression, is getting very close to folks
not being available. Therefore I think either A or C and, because of the
clustering regression fix, I am thinking A.
Thoughts?
Mark
[1]
https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/2251fb8__;!!L8-7AA!SK8ps8QijvRay_y8kx0uvc9yRdveZM8coe-Ik91fn_V2BR6cgbJppKIEouQ_dv3zAYinymxAPIYLfpQr$
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, notify the sender immediately by return email and delete the message
and any attachments from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
