Currently, (in most cases) Tomcat creates an in-memory keystore and initializes 
kmf as follows: KeyManagementFactory.getInstance(algo).init(keystore, kspass). 
The in-memory keystore has the key, the certificate and the chain and nothing 
else. This works fine in most cases but we've ran into a situation where this 
is not sufficient. I am running TC with BC as JSSE provider in FIPS-approved 
only mode and in certain use cases we're running into issues with RSA key 
reuse. FIPS states that an RSA key should be used for encryption/decryption or 
for signature/verification but not for both. So when one browser (in our case 
it was FF) selects TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, BC's key manager 
marks and remembers the key usage, then another browser (Chrome) settles for 
TLS_RSA_WITH_AES_128_GCM_SHA256 BC throws an key-reuse exception since the 
latter suite uses RSA for key exchange and the former for authentication. The 
BC key manager has the ability to select a different key based on KeyUsage 
extension, so it is possible to have multiple RSA keys in memory that would be 
used according to their certificates KeyUsage policy. However TC feeds only one 
certificate to the KM.

Here is a thread [1] that I ran into that shows someone else running into the 
issue and response from BC developer.

To be fair, BCFIPS does have a -D override for the key usage override for RSA 
keys in approved-only mode but according to this thread [2], the property is 
there for completely different purpose and running it to get around the TC 
issue is not FIPS compliant.

So having looked at the code in SSLUtilBase#getKeyManagers(), is it worth 
opening a BZ request to have some solution to this issue - perhaps if alias is 
omitted in configuration and the keystore is of transferrable type (not ms, 
hardware, etc) then transfer all entries to the KM and let it do the selection?



Reply via email to