On Thu, 29 Jan 2026 18:15:07 GMT, Artur Barashev <[email protected]> wrote:
>> src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line >> 148: >> >>> 146: // the deflated certificate data in a memory cache statically >>> and avoid >>> 147: // compressing local certificates repeatedly for every >>> handshake. >>> 148: private static final Cache<CompCertCacheKey, byte[]> CACHE = >> >> I was just wondering about the multiple tenant systems, where one JVM may be >> used by multiple users with different key and certificates. The system may >> run many weeks, and the tenants sign on and off, new and old tenants come in >> and out. Will this CACHE keep the record for each key-cert for each tenant? >> Could it be a potential problem? Does it sound like a direction to cache >> the compressed certificate in where the certificate come from, for example >> key manager instance or SSLContext instance, without using static field? > > Yes, I'm actually currently thinking whether to attach this cache to > SSLContext instance or not. Not sure about it. This cache implementation has > LRU mechanism, so it will simply keep the last 12 compressed certs in memory > which should be fine for most scenarios. It's also an easier to maintain code > where we have all the pieces in a single file. Currently we have only session > caches attached to SSLContext and quite a few static caches like this one in > JSSE code. I had a quick search of the existing cache. There are some global cache for default security parameters and configuration. For example, default trust anchor, default context and default managers. I think it is fine as default one always use the same configuration and can be shared. The compressed certificate cache looks different, as it is not for default key/cert configuration. Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747291754
