Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upuse ECDSA, e.g., if it's all we have #2237
Comments
mattcaswell
added this to the 1.1.1 milestone
Jan 18, 2018
richsalz
added
after 1.1.1
and removed
after 1.1.1
labels
May 6, 2018
richsalz
modified the milestones:
1.1.1,
Post 1.1.1
May 6, 2018
This comment has been minimized.
This comment has been minimized.
|
We will not delay 1.1.1 for this. |
This comment has been minimized.
This comment has been minimized.
vdukhovni
commented
May 6, 2018
•
|
A simple short-term fix is possible. If we have exactly one certificate, then don't check its conformance with client's "supported " extensions. Provided the leaf public key is acceptable, proceed with the handshake. This will cover the vast majority of cases. In most of the other cases we'll have a vanilla RSA cert and an ECDSA cert, and the vanilla RSA cert will be fine. |
This was referenced May 21, 2018
mattcaswell
referenced this issue
Oct 18, 2018
Closed
tls connection fails when server uses brainpool certificate #7435
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
richsalz commentedJan 16, 2017
From @vdukhovni in the thread on #1597
we must not fail to use an ECDSA certificate (supposing it is the only one we have) even if we share no curves with the client. That's a more complex fix, since it will likely require a second pass over the shared ciphersuites with a less stringent filter. I'd suggest a separate PR for that. This is also needed for supported signature algorithms (SHA1 cert when client only offers SHA256, ...)