Correctly handle client certificate custom extensions#16634
Closed
mattcaswell wants to merge 2 commits intoopenssl:masterfrom
Closed
Correctly handle client certificate custom extensions#16634mattcaswell wants to merge 2 commits intoopenssl:masterfrom
mattcaswell wants to merge 2 commits intoopenssl:masterfrom
Conversation
Normally we expect a client to send new extensions in the ClientHello, which may be echoed back by the server in subsequent messages. However the server can also send a new extension in the certificate request message to be echoed back in a certificate message Fixes openssl#16632
Test the scenario where we add a custom extension to a cetificate request and expect a response in the client's certificate message.
paulidale
approved these changes
Sep 20, 2021
Contributor
|
Good for all the branches. |
Collaborator
|
This pull request is ready to merge |
openssl-machine
pushed a commit
that referenced
this pull request
Oct 11, 2021
Normally we expect a client to send new extensions in the ClientHello, which may be echoed back by the server in subsequent messages. However the server can also send a new extension in the certificate request message to be echoed back in a certificate message Fixes #16632 Reviewed-by: Paul Dale <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #16634)
openssl-machine
pushed a commit
that referenced
this pull request
Oct 11, 2021
Test the scenario where we add a custom extension to a cetificate request and expect a response in the client's certificate message. Reviewed-by: Paul Dale <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #16634)
openssl-machine
pushed a commit
that referenced
this pull request
Oct 11, 2021
Normally we expect a client to send new extensions in the ClientHello, which may be echoed back by the server in subsequent messages. However the server can also send a new extension in the certificate request message to be echoed back in a certificate message Fixes #16632 Reviewed-by: Paul Dale <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #16634) (cherry picked from commit cbb862f)
openssl-machine
pushed a commit
that referenced
this pull request
Oct 11, 2021
Test the scenario where we add a custom extension to a cetificate request and expect a response in the client's certificate message. Reviewed-by: Paul Dale <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #16634) (cherry picked from commit 0db3a99)
openssl-machine
pushed a commit
that referenced
this pull request
Oct 11, 2021
Normally we expect a client to send new extensions in the ClientHello, which may be echoed back by the server in subsequent messages. However the server can also send a new extension in the certificate request message to be echoed back in a certificate message Fixes #16632 Reviewed-by: Paul Dale <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #16634) (cherry picked from commit cbb862f)
openssl-machine
pushed a commit
that referenced
this pull request
Oct 11, 2021
Test the scenario where we add a custom extension to a cetificate request and expect a response in the client's certificate message. Reviewed-by: Paul Dale <[email protected]> Reviewed-by: Tomas Mraz <[email protected]> (Merged from #16634) (cherry picked from commit 0db3a99)
Member
Author
|
Pushed to master, 3.0 and 1.1.1 |
dstebila
pushed a commit
to open-quantum-safe/openssl
that referenced
this pull request
Mar 15, 2022
Most extensions are initially sent in the ClientHello and then (optionally) responded to in subsequent messages from the server. However client Certificate messages work differently. In this case the initial extension is added to the server's CertificateRequest message, and the client then may (optionally) respond with the same extension in it's Certificate message.
This was not handled correctly for custom extensions meaning that it was not possible to add custom extensions to a client certificate message.
This should go to 3.0 and 1.1.1. It mostly cherry-picks ok to 1.1.1 but with a trivial conflict in the test. Since its trivial I won't create a separate PR for that branch.
Fixes #16632