update AdvancedTlsX509KeyManager to support key alias for reloaded cert

[zhangweikop]

Overview

Make the alias in AdvancedTlsX509KeyManager dynamic so it can be used with Netty's
OpenSslCachingX509KeyManagerFactory to update key material after reload.

Fixes #12670

Problem

When using SslProvider.OPENSSL, each TLS handshake must encode Java key material into a native
buffer consumed by OpenSSL, which can account for ~8% of server CPU. Netty's
OpenSslCachingX509KeyManagerFactory avoids this by caching the encoded buffer keyed by alias —
but the previous implementation always returned "default", so the factory could never detect
credential rotations and create a new cache entry on cert reload.

Details

• The alias is now set to key-<N> (e.g. key-1, key-2, ...) and incremented on every
  updateIdentityCredentials call, ensuring the same alias always maps to the same key material.
• A new constructor AdvancedTlsX509KeyManager(int revisionWarningThreshold) allows customizing
  the soft warning threshold (default: 1024, matching OpenSslCachingX509KeyManagerFactory's
  default maxCachedEntries). A warning is logged when the counter reaches the threshold, since
  beyond that point new aliases won't be cached and per-handshake encoding overhead resumes. The
  key manager remains fully functional past this threshold.
• All alias methods return null before any credentials are loaded.
• Recommended usage with OpenSSL:

new OpenSslCachingX509KeyManagerFactory(
    new KeyManagerFactoryWrapper(advancedTlsKeyManager))

[ejona86]

I don't think using AdvancedTlsX509KeyManager with OpenSslCachingKeyMaterialProvider is all that good an approach with this, because it essentially leaks all prior keys in memory. If the life of the process after a year has 5 versions, that's not that big of a deal. But if it changes ever hour, that's not good. I don't think we're going to put random detection code in AdvancedTlsX509KeyManager to just warn you that things have gone wrong either.

[zhangweikop]

I don't think using AdvancedTlsX509KeyManager with OpenSslCachingKeyMaterialProvider is all that good an approach with this, because it essentially leaks all prior keys in memory. If the life of the process after a year has 5 versions, that's not that big of a deal. But if it changes ever hour, that's not good. I don't think we're going to put random detection code in AdvancedTlsX509KeyManager to just warn you that things have gone wrong either.

Yes, I think it should be used with caution.
In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.
To support users who require more frequent key rotation, Netty's OpenSslCachingKeyMaterialProvider would need to remove old keys.

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?

[ejona86]

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?

Yes, that's tracked by #12485 . This PR doesn't actually address that, as it ignores the alias being used. I imagined keeping one older version around to handle in-progress handshakes. Since you're talking about every configuration having its own alias name, if the key manager mutates faster than handshakes complete (such that the alias is really old) then we could trigger an error in some way.

In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.

Okay. I'm fine with using a new alias each mutation in this key manager, but that should be consistent; for example, getPrivateKey() shouldn't return the new key when passed the old alias. That applies equally to all methods that receive the alias.

And we won't have the "this sure seems like a lot of mutations" warning.

At that point, if someone so desires they can improve OpenSslCachingKeyMaterialProvider to become an LRU cache (or introduce a new class). Then you could use a cache size of two.

[zhangweikop]

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?

Yes, that's tracked by #12485 . This PR doesn't actually address that, as it ignores the alias being used. I imagined keeping one older version around to handle in-progress handshakes. Since you're talking about every configuration having its own alias name, if the key manager mutates faster than handshakes complete (such that the alias is really old) then we could trigger an error in some way.

In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.

Okay. I'm fine with using a new alias each mutation in this key manager, but that should be consistent; for example, getPrivateKey() shouldn't return the new key when passed the old alias. That applies equally to all methods that receive the alias.

And we won't have the "this sure seems like a lot of mutations" warning.

At that point, if someone so desires they can improve OpenSslCachingKeyMaterialProvider to become an LRU cache (or introduce a new class). Then you could use a cache size of two.

I think the idea of "keeping one older version around" makes sense.
Updated the change to keep the previous one. Previous keyinfo can be accessed using the previous alias.
While the method chooseClientAlias will always return "current".

Also removed the warning part.
Will directly rely on the OpenSslCachingKeyMaterialProvider PR for the cache eviction support.