[RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Langer, Christoph christoph.langer at sap.com
Thu Jul 13 06:59:18 UTC 2017

Hi Sean,

> > So, I guess I would be fine if this could at least be changed for JDKs <= 8 for
> compatibility reasons. I can understand if for JDK >= 9 we say this is a new
> release and the standard algorithm names shall be enforced. Wouldn't that
> be a good compromise?
> Yes. In fact I think the most robust solution (even for 9 and later) is
> to look at the encoded AlgorithmId in the X.509 certificate to determine
> what signature algorithm is being used, and this would eliminate the
> compatibility risk with third party providers using non-standard Java
> names. This is exactly what X509CertImpl.getSigAlgName() is doing.

OK, I will file a bug and post a change for review.

I then suggest to also revert JDK10 and 9 to use X509CertImpl.getSigAlgName() for the time being until some better check to go for the encoded AlgorithmId. Would you be fine with that?

> Also, note that you can probably also workaround this issue by adding a
> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
> security property.

Hm, I thought with that property you would only define a negative list of algorithms that are not supported (out of the known ones). But is it possible to specify an unknown algorithm name to whitelist?


More information about the security-dev mailing list