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

[David Alvarez]

On 2020-01-13 13:08, Andrew John Hughes wrote:
> 
> 
> On 13/01/2020 20:32, David Alvarez wrote:
>>
>>
>> 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
>>
> 
> Thanks, that'd be great! I just want to keep things as close as possible
> between OpenJDK versions rather than introducing something new.
> 
I initially discarded importing the newer jdk11u certificate because it
was a v3 certificate compared to the rest of the jdk8u certificates that
were v1. However, during the process of recreating the certificates, I
eventually decided to use v3 certificates for jdk8u, I should have
revisited my initial decision at that point.

A quick check of the 11u certificate shows there is nothing on it that
shouldn't work on 8u, so I expect no issue there.

David