bcgit
"Ignoring unsupported entry" in DisabledAlgorithmConstraints
HI all,
Last month we switch from the SunJSSE to BCJSSE for normal operation and fips mode. But now we encounter the logs:
- org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints: [jul] Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': include jdk.disabled.namedCurves
- org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints: [jul] Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 usage SignedJAR & denyAfter 2019-01-01
- org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints: [jul] Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
Looking into the code and debugging of DisabledAlgorithmConstraints we see the TODO's and that indeed the code does read the entry correctly although the code ignore it.
My question is are there plans to solve these todo's and when
And how can we workaround the ignored features
- 'SHA1 usage SignedJAR & denyAfter 2019-01-01'
- SHA1 jdkCA & usage TLSServer
used versions (from pom.xml)
@dirk-gerrit-oort @marnix
The whole disabledAlgorithms ball-of-wax is a very complicated corner of the JDK, so I'll do my best, but you may have to ask more specific questions later about anything confusing.
The first thing to point out is that, as java.security states regarding jdk.certpath.disabledAlgorithms:
# Note: This property is currently used by Oracle's PKIX implementation. It
# is not guaranteed to be examined and used by other implementations.
Indeed the BC (and BCFIPS) providers don't make any use at all of this system property. So in particular the PKIX CertPath implementations there don't examine or use it (of course BCFIPS applies FIPS-specific requirements during CertPath validation).
BCJSSE does examine it (and partially use it as you show) because it's also picked up by SunJSSE (which is not documented in java.security) in close proximity to the jdk.tls.disabledAlgorithms system property that we were adding support for in BCJSSE. (There are caveats there too i.e. situations where SunJSSE also ignores jdk.certpath.disabledAlgorithms; see sun.security.ssl.SSLAlgorithmConstraints.enabledX509DisabledAlgConstraints if you are particularly curious).
In JSSE it is possible to set a custom AlgorithmConstraints on the SSLParameters for a connection. I just want to note that several of these CA/Certpath-related later additions to the disabledAlgorithms system properties use internal-only implementation (not in the public API), so are not amenable to that sort of user configuration.
OK, now to the specific unsupported entries:
include jdk.disabled.namedCurves:
Historically these have not mentioned any curves that are in the default list of named groups for BCJSSE. Already a couple of years ago they removed this entry entirely (i.e. defaults to not set) and trimmed their built-in list in the code. If you do need to be explicit about the supported groups you can use the "jdk.tls.namedGroups" system property (or in recent JDKs SSLParameters.setNamedGroups is also available - or our extension API BCSSLParameters in all versions). BCJSSE in FIPS mode also restricts the named groups automatically.
SHA1 usage SignedJAR & denyAfter 2019-01-01:
jar-signing (verification) is not performed by BCJSSE, so this is benign.
SHA1 jdkCA & usage TLSServer:
"jdkCA" refers to any certificate contained in the cacerts file of the JRE (specifically JAVA_HOME/lib/security/cacerts) where the keystore alias contains the substring " [jdk". "usage TLSServer" constrains this to validating a TLS server's certificate chain.
A BCJSSE server never validates a CertPath for usage TLSServer, so it's not relevant (if running a server you might want to check that you are not using SHA1 in your server cert chain(s) to avoid client rejection).
That leaves the case of a BCJSSE client connecting to a server where the server cert chains to a trust anchor in cacerts. In that case ignoring the constraint means that BCJSSE wouldn't disable SHA1 (i.e. signatures) in such a chain.
How exactly to workaround that is going to depend a lot on the specific case, so if this is your situation we could perhaps discuss it in more detail.
Based on the above I would say that "usage TLSServer" is the next thing to get working, then maybe jdkCA. This work is not really on our roadmap yet though, so we can't just jump into it.
@peterdettman Thanks for that thorough answer! We will study it.
For my part this issue can be closed; in case we have more questions later, either @dirk-gerrit-oort or myself will reopen it.
Thanks again!
