BCJSSE TLS 1.3 certificate reuse failing

[Martin Kempe]

Dear BC devs and followers,

 

I am failing to use my current TLS server certificate with TLS 1.3 It works perfectly with TLS 1.2 on BCJSSE 1.68, though. The only thing I change on runtime is the required TLS version when creating my SSLContext and SSLEngine objects.

 

I activated logging to maybe get a grip of something:

 

# TLS 1.2

2021-03-03T11:23:09,634  INFO [Thread] -  Mar 03, 2021 11:23:09 AM org.bouncycastle.jsse.provider.ProvX509KeyManagerSimple chooseKeyBC

FINE: Found matching key, from alias: key.tls.srv

2021-03-03T11:23:09,634  INFO [Thread] -  Mar 03, 2021 11:23:09 AM org.bouncycastle.jsse.provider.ProvTlsServer selectServerCredentials12

FINE: Server (1.2) selected credentials for signature scheme 'ecdsa_secp256r1_sha256(0x403)' (keyType 'ECDHE_ECDSA'), with private key algorithm 'EC'

 

# TLS 1.3

2021-03-03T11:15:44,732  INFO [Thread] -  Mar 03, 2021 11:15:44 AM org.bouncycastle.jsse.provider.ProvX509KeyManagerSimple chooseKeyBC

FINE: No matching key found

2021-03-03T11:15:44,732  INFO [Thread] -  Mar 03, 2021 11:15:44 AM org.bouncycastle.jsse.provider.ProvTlsServer selectServerCredentials13

FINER: Server (1.3) found no credentials for signature scheme 'ecdsa_secp256r1_sha256(0x403)' (keyType 'EC')

 

With studying the code of ProvTlsServer I found that the TLS 1.2 keyType differs because there is a “legacy” use case that gets activated. So the keyType=ECDHE_ECDSA

The TLS 1.3 keyType simply gets set to keyType=EC. The “no matching key found” logging tells me, that the following call to manager.chooseServerKey fails with TLS 1.3 and returns null. With TLS 1.2 this call grabs the key of my TLS certificate for scheme 0x403. I can’t find code that distinguishes Between TLS 1.2 and TLS 1.3 when choosing the server key. That is where I got lost.

 

Generally it is said, that a certificate working with TLS 1.2 should also be good for TLS 1.3. Is it possible that my TLS server certificate doesn’t meet some TLS 1.3 requirements? I could not find descriptions of that online. Maybe it is of interest that the certificate key material is based on brainpoolP256r1.

 

I would be really happy if you could give me a hand on this.

 

Best regards

Martin Kempe

[Peter Dettman-3]

Hi Martin,
Thanks for reporting this, it appears to be a bug in the KeyManager that
will prevent finding "EC" keys under TLS 1.3 (for the server).

We should be able to get a beta out in a few days with the fix.

Regards,
Pete Dettman

On 3/5/2021 5:25 PM, Martin Kempe wrote:

> Dear BC devs and followers,
>
>  
>
> I am failing to use my current TLS server certificate with TLS 1.3 It
> works perfectly with TLS 1.2 on BCJSSE 1.68, though. The only thing I
> change on runtime is the required TLS version when creating my
> SSLContext and SSLEngine objects.
>
>  
>
> I activated logging to maybe get a grip of something:
>
>  
>
> # TLS 1.2
>
> 2021-03-03T11:23:09,634  INFO [Thread] -  Mar 03, 2021 11:23:09 AM
> org.bouncycastle.jsse.provider.ProvX509KeyManagerSimple chooseKeyBC
>
> FINE: Found matching key, from alias: key.tls.srv
>
> 2021-03-03T11:23:09,634  INFO [Thread] -  Mar 03, 2021 11:23:09 AM
> org.bouncycastle.jsse.provider.ProvTlsServer selectServerCredentials12
>
> FINE: Server (1.2) selected credentials for signature scheme
> 'ecdsa_secp256r1_sha256(0x403)' (keyType 'ECDHE_ECDSA'), with private
> key algorithm 'EC'
>
>  
>
> # TLS 1.3
>
> 2021-03-03T11:15:44,732  INFO [Thread] -  Mar 03, 2021 11:15:44 AM
> org.bouncycastle.jsse.provider.ProvX509KeyManagerSimple chooseKeyBC
>
> FINE: No matching key found
>
> 2021-03-03T11:15:44,732  INFO [Thread] -  Mar 03, 2021 11:15:44 AM
> org.bouncycastle.jsse.provider.ProvTlsServer selectServerCredentials13
>
> FINER: Server (1.3) found no credentials for signature scheme
> 'ecdsa_secp256r1_sha256(0x403)' (keyType 'EC')
>
>  
>
> With studying the code of ProvTlsServer I found that the TLS 1.2 keyType
> differs because there is a “legacy” use case that gets activated. So the
> keyType=ECDHE_ECDSA
>
> The TLS 1.3 keyType simply gets set to keyType=EC. The “no matching key
> found” logging tells me, that the following call to
> manager.chooseServerKey fails with TLS 1.3 and returns null. With TLS
> 1.2 this call grabs the key of my TLS certificate for scheme 0x403. I
> can’t find code that distinguishes Between TLS 1.2 and TLS 1.3 when
> choosing the server key. That is where I got lost.
>
>  
>
> Generally it is said, that a certificate working with TLS 1.2 should
> also be good for TLS 1.3. Is it possible that my TLS server certificate
> doesn’t meet some TLS 1.3 requirements? I could not find descriptions of
> that online. Maybe it is of interest that the certificate key material
> is based on brainpoolP256r1.
>
>  
>
> I would be really happy if you could give me a hand on this.
>
>  
>
> Best regards
>
> Martin Kempe
>

[Peter Dettman-3]

Actually, on reflection this was left disabled because we didn't have a
mechanism to restrict the curve according to the TLS 1.3 rules. So it
will be a little longer in coming but still in the next release.

That you are using brainpool is an extra complication, but I've gone
ahead and implemented RFC 8734 to add support for them, so that
shouldn't be a problem.

Regards,
Pete Dettman


On 3/5/2021 8:58 PM, Peter Dettman wrote:

> Hi Martin,
> Thanks for reporting this, it appears to be a bug in the KeyManager that
> will prevent finding "EC" keys under TLS 1.3 (for the server).
>
> We should be able to get a beta out in a few days with the fix.
>
> Regards,
> Pete Dettman
>
> On 3/5/2021 5:25 PM, Martin Kempe wrote:
>> Dear BC devs and followers,
>>
>>  
>>
>> I am failing to use my current TLS server certificate with TLS 1.3 It
>> works perfectly with TLS 1.2 on BCJSSE 1.68, though. The only thing I
>> change on runtime is the required TLS version when creating my
>> SSLContext and SSLEngine objects.
>>  
>>
>> Generally it is said, that a certificate working with TLS 1.2 should
>> also be good for TLS 1.3. Is it possible that my TLS server certificate
>> doesn’t meet some TLS 1.3 requirements? I could not find descriptions of
>> that online. Maybe it is of interest that the certificate key material
>> is based on brainpoolP256r1.
>>
>>  
>>
>> I would be really happy if you could give me a hand on this.
>>
>>  
>>
>> Best regards
>>
>> Martin Kempe
>>
>
>

[Martin Kempe]

Thank you so much for evaluating the problem, Peter.
Now I can focus on different tasks until I get a new BC release to integrate and try again.

Best regards,
Martin

-----Ursprüngliche Nachricht-----
Von: Peter Dettman <[hidden email]>
Gesendet: Dienstag, 9. März 2021 07:06
An: Martin Kempe <[hidden email]>; [hidden email]
Betreff: Re: [dev-crypto] BCJSSE TLS 1.3 certificate reuse failing

Actually, on reflection this was left disabled because we didn't have a mechanism to restrict the curve according to the TLS 1.3 rules. So it will be a little longer in coming but still in the next release.

That you are using brainpool is an extra complication, but I've gone ahead and implemented RFC 8734 to add support for them, so that shouldn't be a problem.

Regards,
Pete Dettman


On 3/5/2021 8:58 PM, Peter Dettman wrote:

> Hi Martin,
> Thanks for reporting this, it appears to be a bug in the KeyManager
> that will prevent finding "EC" keys under TLS 1.3 (for the server).
>
> We should be able to get a beta out in a few days with the fix.
>
> Regards,
> Pete Dettman
>
> On 3/5/2021 5:25 PM, Martin Kempe wrote:
>> Dear BC devs and followers,
>>
>>  
>>
>> I am failing to use my current TLS server certificate with TLS 1.3 It
>> works perfectly with TLS 1.2 on BCJSSE 1.68, though. The only thing I
>> change on runtime is the required TLS version when creating my
>> SSLContext and SSLEngine objects.
>>  
>>
>> Generally it is said, that a certificate working with TLS 1.2 should
>> also be good for TLS 1.3. Is it possible that my TLS server
>> certificate doesn't meet some TLS 1.3 requirements? I could not find
>> descriptions of that online. Maybe it is of interest that the
>> certificate key material is based on brainpoolP256r1.
>>
>>  
>>
>> I would be really happy if you could give me a hand on this.
>>
>>  
>>
>> Best regards
>>
>> Martin Kempe
>>
>
>