SslContextFactory certHosts map results in non-deterministic certificate selection
- Dominant language
- Java
- Stars
- 4.1k
- Forks
- 2k
- Avg merge
- 3d 56m
- Merged PRs (30d)
- 48
Description
The _certHosts map keyed on hostname is populated in the load() method where it will put ALL certificates/aliases into this map based on the host(s) listed for each certificate; this will overwrite existing certificates in the _certHosts map that return the same host.
A keystore may contain multiple certificates for the same host; and this process of populating a _certHosts map and overriding previous entries makes this process unpredictable. The order of the certificates returned by the keystore doesn't appear to always be consistent.
This load step does NOT check the _certAlias attribute to see if an explicit alias has been configured; so there appears to be no way to control which certificate is actually used in the scenario that multiple certificates for the same host are present in the keystore.
The scenario I am facing has a self-signed (key-pair) certificate in the keystore alongside a properly signed certificate (with the associated chain to the root CA cert). Both certificates are for the same host. They have different aliases in the keystore and I am explicitly setting the certAlias attribute to specify the correct (fully signed+chain) cert from the keystore; but on some machines the correctly signed cert is selected, on other machines, the self-signed certificate is selected (which is obviously rejected by the browser as invalid).
I am using the 9.4.50.v20221201 version of jetty-util, but from what I can see the same issue would still occur in the v10 series.
Possibly related to this other issue: #6929, and at least overlap in the same problem space as this issue: #6034
Issue also raised as a StackOverflow question, although via spark-java which uses jetty under the covers:
https://stackoverflow.com/questions/75449183/spark-java-certificate-alias-not-selecting-correct-entry-from-keystore
Contributor guide
Assessment
This issue has not been assessed yet.