Add support to use keys and certificates from PKCS#11 provider #15587
+244
−26
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Jakuje
force-pushed
the
pkcs11-provider
branch
4 times, most recently
from
fbd381a to
dff373e
Compare
|
Analysis of PR #15587 at dff373e6: Test 1478 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 91 different CI jobs (the link just goes to one of them). Generated by Testclutch |
Jakuje
force-pushed
the
pkcs11-provider
branch
7 times, most recently
from
59ed6b6 to
e38ad12
Compare
Jakuje
force-pushed
the
pkcs11-provider
branch
2 times, most recently
from
1076a74 to
a8a79ad
Compare
|
Seems like the windows build issue is resolved now. The test |
bagder
reviewed
Dec 26, 2024
In OpenSSL < 3.0, the modularity was provided by mechanism called "engines". This is supported in curl, but the engines got deprecated with OpenSSL 3.0 in favor of more versatile providers. This adds a support for OpenSSL Providers, to use PKCS#11 keys, namely through the pkcs11 provider. This is done using similar approach as the engines and this is automatically built in when the OpenSSL 3 and newer is used. Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Jakuje
force-pushed
the
pkcs11-provider
branch
from
a8a79ad to
fed1dc9
Compare
bagder
approved these changes
Jan 1, 2025
|
Thanks! |
|
I believe there is an error when trying to use a pkcs11 uri as key. I have provided a fix: |
pps83
pushed a commit
to pps83/curl
that referenced
this pull request
Apr 26, 2025
In OpenSSL < 3.0, the modularity was provided by mechanism called "engines". This is supported in curl, but the engines got deprecated with OpenSSL 3.0 in favor of more versatile providers. This adds a support for OpenSSL Providers, to use PKCS#11 keys, namely through the pkcs11 provider. This is done using similar approach as the engines and this is automatically built in when the OpenSSL 3 and newer is used. Signed-off-by: Jakub Jelen <jjelen@redhat.com> Closes curl#15587
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In OpenSSL < 3.0, the modularity was provided by mechanism called "engines". This is supported in curl, but the engines got deprecated with OpenSSL 3.0 in favor of more versatile providers.
This adds a support for OpenSSL Providers, to use PKCS#11 keys, namely through the pkcs11 provider (https://github.com/latchset/pkcs11-provider). This is done using similar approach as the engines and this is automatically built in when the OpenSSL 3 and newer is used.
Tested locally with the same steps we had for the engines (just with new OpenSSL and pkcs11-provider installed) and the basic tests worked fine. I can add some more extensive one if needed.