[8u] RFR: [TESTBUG] Some ssl jtreg tests fail due to usage of a secp256k1 ECDSA certificate

David Alvarez alvdavi at amazon.com
Mon Jan 13 20:32:26 UTC 2020



On 2020-01-13 12:19, Andrew John Hughes wrote:
> On 17/12/2019 21:51, David Alvarez wrote:
>> Hi Severin,
>>
>> You're right the same cert is in 11u, but I don't think it is being used
>> anymore. The same certificate store contains another certificate with
>> alias ecdsasecp256r1 serial number 46646443, and that one is being used
>> for the two jtreg tests I mentioned in the bug that fail. As the alias
>> indicates, the certificate is based on curve secp256r1, that was not
>> disabled. That certificate was added by 8196584: TLS 1.3 Implementation [1].
>>
>> David
>>
>> --
>> [1] https://bugs.openjdk.java.net/browse/JDK-8196584
>>
>> On 2019-12-17 06:42, Severin Gehwolf wrote:
>>> Hi David,
>>>
>>> On Fri, 2019-11-08 at 13:24 -0800, David Alvarez wrote:
>>>> Hi,
>>>>
>>>> Requesting review for:
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233864
>>>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8233864/webrev.8u.00/
>>>>
>>>> After 8u232, certain Tier2 jtreg ssl tests started to fail as they were
>>>> relying on a certificate based on curve secp256k1. That curve is no
>>>> longer enabled for ssl (disabled by JDK-8228825 [1]).
>>>>
>>>> The specific certificate is located in:
>>>> test/sun/security/ssl/etc/keystore
>>>> and
>>>> test/sun/security/ssl/etc/truststore
>>>>
>>>> This patch fixes those tests by recreating the certificate stores with
>>>> new certificates. The generated ECDSA certificate uses secp256r1. These
>>>> certificates are v3 instead of v1 as the originals, but we have seen no
>>>> failures caused by this.
>>>>
>>>> This change includes binary changes. A patch file with binary changes is
>>>> located here:
>>>> http://cr.openjdk.java.net/~alvdavi/patches/8233864.8u.00.patch
>>>
>>> Why is this a problem specific to 8u? I see the same cert in 11u's
>>> keystore, Serial number: 57399c1d, alias dummyecdsa.
>>>
>>> For the time being I'll remove the jdk8u-fix-request label until it's
>>> clear this is actually an 8u only problem.
>>>
>>> Thanks,
>>> Severin
>>>
>>>> Thanks,
>>>> --
>>>> David Alvarez
>>>>
>>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5456f24496f4#l1.18
>>>>
>>>
>>
> 
> Is it not possible to backport the additional 11u certificate rather
> than creating new ones?
> 
> But generally, I agree this needs to be fixed. We've been seeing such
> failures downstream for a long time, as we've generally only shipped
> secp256r1, secp384r1 & secp521r1, so it would be good to see this fixed.
> 
> Thanks,
> 

Sure, I will update the webrev this week with the jdk11
truststore/keystore certificates this week and confirm there are no issues

David


More information about the jdk8u-dev mailing list