feat: load every certificate in the rotating keys engine ca-cert-file

[pjfanning]

Motivation

RotatingKeysSSLEngineProvider reads ca-cert-file with CertificateFactory.generateCertificate, which stops at the first PEM block. A CA file that bundles more than one certificate — a root plus the intermediates it delegates to, or two roots while a CA is being rotated — was therefore only half trusted, and peers presenting a certificate issued by any of the other CAs in the bundle were rejected.

Modification

• Add PemManagersProvider.loadCertificates, which uses generateCertificates and closes the stream. loadCertificate now closes its stream too, which it never did.
• buildTrustManagers and buildKeyManagers take the whole Seq[Certificate]; every CA certificate is stored under its own alias, so all of them become trust anchors.
• The chain attached to the key entry is built by walking from the node certificate upwards, taking as the issuer the CA certificate whose public key verifies the signature of the certificate below it. Matching on the subject alone is not enough: a CA rotation that keeps the distinguished name leaves two certificates with the same subject in the bundle, and only one of them signed any given certificate. A CA that did not issue the node certificate (an unrelated root kept around for a rotation, say) is trusted without being sent to the peer.
• When no CA in the bundle issued the node certificate, the node certificate is sent on its own.
• readFiles fails with SslTransportException when the CA file yields no certificate, instead of passing a null certificate on.
• Document the bundle support on ca-cert-file in reference.conf.

Result

ca-cert-file may bundle any number of certificates and all of them are trusted. Single-certificate configurations behave exactly as before.

Tests

New cases in PemManagersProviderSpec, backed by two bundle resources:

• ssl/exampleca-bundle.crt (exampleca.crt + pem/selfsigned-certificate.pem) — two unrelated CAs: the trust manager's accepted issuers contain both certificates, and the key manager's chain for the node certificate contains only the CA that issued it.
• ssl/exampleca-rotated-bundle.crt (exampleca.crt + the new exampleca-rotated.crt) — two CA certificates sharing exampleCA's subject but holding different keys, as a rotation that keeps the distinguished name would leave them, with the one that signed the node certificate listed first. The presented chain must hold that one and not the other.

Both bundles, and the rotated CA, are generated by the new ssl/gen-ca-bundles.sh, which gencerts.sh now calls so they survive a regeneration of the folder.

Run locally:

• sbt "remote/testOnly org.apache.pekko.remote.artery.tcp.ssl.*" — 16 passed, 1 ignored
• sbt "remote/scalafmtCheck" "remote/Test/scalafmtCheck" — passed
• sbt "remote/mimaReportBinaryIssues" — passed

References

None — follow-up on multi-certificate ca-cert-file support

[samueleresca]

Given 2 certificates with the same subject, only 1 will be returned from buildCertificateChain. Does this have implications?

[pjfanning]

I'll look into adding test coverage in this area and seeing which solution makes most sense

[pjfanning]

The duplicate-subject case was real, the chain is now picked by signature. There is now the exampleca-rotated-bundle.crt test.

These cert files are expected to be carefully created by trusted people involved in the deployment. There is no expectation that someone would load a badly formatted cert file. Still no harm in trying to make the code deterministic.