Description

When we are sending a TLS-1.2 brainpool keyshare (brainpoolP256r1) instead of a TLS-1.3 brainpool keyshare (brainpoolP256r1tls13), then the connection is not established. I would expect, since it is just a key share, the server would discard that, send HRR, and negotiate the brainpoolP256r1tls13.

Also, while sending the brainpoolP256r1 key share in TLS 1.3 is technically non-compliant, since previously OpenSSL would negotiate brainpoolP256r1 in TLS 1.3, it is something that the server should be tolerant of.

Version

Compiled code from the master branch on 15/08/25 (3897288).

Steps to reproduce

1. Create an ECDSA key pair and cert:

for i in server client; do openssl ecparam -genkey -name "prime256v1" -out $i.key; openssl req -new -key $i.key -out $i.csr -subj "/CN=localhost"; openssl x509 -req -days 3650 -in $i.csr -signkey $i.key -out $i.cert; rm -rf $i.csr; done

2. Create a server:

openssl s_server -www -key server.key -cert server.cert -sigalgs "?ecdsa_brainpoolP256r1_sha256:ECDSA+SHA256" --groups "*brainpoolP256r1:?brainpoolP256r1tls13:secp256r1"

3. Connect with the client:

openssl s_client -connect localhost:4433 -sigalgs "?ecdsa_brainpoolP256r1_sha256:ECDSA+SHA256" --groups "*brainpoolP256r1:?brainpoolP256r1tls13:secp256r1"

Error

80D2A142C17F0000:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl/record/rec_layer_s3.c:916:SSL alert number 80