feat: Cert rotation utilities and docs

[johanandren]

References

• #2884

Provides both docs and some convenience APIs for loading certs and an out-of-the-box cert reload/refresh/rotator.

[johanandren]

@jroper this adds cert rotation and easier loading of certs/private key when they are in PEM format, that doesn't cover mTLS though. Do you think we should have additional easy-load factories, for example PKCS#12 or JKS to simplify or how would you normally get the trust store and certs in for example k8?

[jroper]

I think I would start with just PEM, PEM is the standard that every other platform other than the JDK uses. One thing that I would probably consider with a higher priority is supporting keys other than RSA. ECDSA is the main one that is replacing RSA.

Support ECDSA means adding support for two different formats. Firstly, there's the OpenSSL ASN.1 encoding of ECDSA keys, which is identified with BEGIN EC PRIVATE KEY. We already do ASN.1 parsing of RSA keys, we should be able to do it for ECDSA keys too, I think they only have two things encoded in them, the curve, and the key. The bouncycastle parsing is here:

https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/sec/ECPrivateKey.java

Secondly, there's the PKCS8 encoding, identified as BEGIN PRIVATE KEY, which is used for all PKCS8 encoded keys, including RSA, ECDSA and Ed25519. The JDK has built in support for parsing ECDSA (and other) keys from PKCS8, what the JDK doesn't provide though is a means to check the type of key encoded in a PKCS8 sequence of bytes, you have to know the type up front, which is, in true JDK crypto key API fashion, not very helpful. But, again, this can be done using an ASN.1 parsing. Here's the RFC for PKCS8, so you want to extract out that algrothim identifier (and maybe validate the version). I think this is the RFC for the algorithm identifier.

[johanandren]

Ready for final review