Custom KeyCertOptions for short-lived certificates

[Andrei Iacob]

Hello,

does anyone have experience with implementing KeyCertOptions for supporting short-lived certificates?

I have a hold of a Java Keystore with an update event but when trying to wire it inside my vert.x application, I'm running into two issues:either certificates loaded initially but not updating or certificates not loaded at all

What I've done is implemented the getKeyManagerFactory in various forms, all similar to this, by returning an instance to an implementation of KeyManagerFactory.

I tried the exact approach here (only with my own keystore) but my result is that the certs are not loaded at all (getting no cipher suites in common which is a sign that the SSL context is initialized with an empty KeyManager array) although the telemetry shows me that the update functions are called (so is getKeyManagerFactory) so is there a specific layout that the keystore needs to have in terms of the alias names when initializing such a KeyManagerFactory? My keystore uses the filename from where the certs were loaded in the first place as the aliases. I don't have a need for SNI so I skipped implementing the key mapping fuctions but I did try (with no success) to re-add everything based on the CNs and SANs but with the same result.

I tried to vary the update hook when the certificates rotate (what to change when the keystore itself changes):

- when I update the KeyManager itself (as the example above), I get the no cipher suites error

- when I update KeyManagerFactorySpi (used when creating the KeyManagerFactory) and have that one keep and update the KeyManager array returned here I get the connection established but the server is oblivious to the certificates being changed, although my
KeyManagerFactorySpi does update the array.

- I get the same result as above if I introduce another level of indirection by wrapping the KeyManager array in a separate class which I update manually when the cert changes (I also tried to replace the array elements in-place but yeah, that also didn't work out).

So I guess my question is also related to the lifetime/access of the particular objects which are used when establishing the https connection when it comes to the key manager. Which one should be changed when the certificates are rotated? Should it be the KeyManagerFactorySpi, KeyManager[] array or the KeyManager inside the array? If the latter, is there something I need to keep in mind about the KeyStore's layout?

Thanks,

Andrei

[Andrei Iacob]

For posterity, I figured it out.

Rookie mistake, I had to override chooseEngineServerAlias in my custom X509ExtendedKeyManager to return the alias I had in the KeyStore. I assumed the method was used solely for SNI, which is indeed the case but not returning the right alias (or null, or throwing an UnsupportedOperationException) will break the ssl handshake in very confusing ways.