Adjust reload keystore test to pass in FIPS

[jkakavas]

In KeystoreWrapper class we determine if the error to decrypt a
given keystore is caused by a wrong password based on the exception
that the SunJCE implementation of AES is throwing
(AEADBadTagException). Other implementations from other Security
Providers might cause decryption to fail in a different way and cause
us to throw a generic error message.
We handle this in this test by matching both possible
exception messages.

Relates: #56889

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Settings)

[elasticmachine]

Pinging @elastic/es-security (:Security/Security)

[rjernst]

LGTM. This matches with the check we do in packaging tests.

One question: should we change the exception catching code to still give a good error message for common security providers?

[ywangd]

LGTM. Also second @rjernst's question. Maybe we could list "wrong password" alongside "corrupted or tampered with"?

[jkakavas]

One question: should we change the exception catching code to still give a good error message for common security providers?

Yes, I will look into it. This Q prompted me to do some initial investigation and I might be mistaken here regarding the cause of the different Exceptions thrown. I now think this has to do with #28515 and how read() and readFully() operates on the CipherInputStream based on the Cipher implementation (read: the SecurityProvider that implements it ) . It turns out that we throw on

elasticsearch/server/src/main/java/org/elasticsearch/common/settings/KeyStoreWrapper.java

Line 379 in c117c0c

throw new SecurityException("Keystore has been corrupted or tampered with");

and not on

elasticsearch/server/src/main/java/org/elasticsearch/common/settings/KeyStoreWrapper.java

Line 385 in c117c0c

throw new SecurityException("Keystore has been corrupted or tampered with", e);

as I assumed. We added the original code in #28515 and then check for the AEADBadTagException later on in the reloading secure settings work and never made the connection nor investigated it in detail until now.

I'd still like to merge this with an updated description to make CI green and then spend the proper time to figure out how we can handle the differences in a consistent way so that we can throw a proper error in all applicable cases

Also second @rjernst's question. Maybe we could list "wrong password" alongside "corrupted or tampered with"?

I wouldn't like us returning an "Error, this might be this or that or the other thing" so I think we could do our best to match expected

[jkakavas]

I opened #57132