add pluggable crypto provider by jgreeer · Pull Request #450 · rustls/rcgen

jgreeer · 2026-09-02T15:24:58Z

Adds a pluggable cryptography provider API to rcgen, allowing applications to use custom backends without depending on Ring or AWS-LC. This design is inspired by rustls and jsonwebtoken.

This PR is a follow up on #414. The goal is to support our own external SymCrypt provider crate.

Ring and AWS-LC remain available through built-in provider implementations.

Added a CryptoProvider trait providing:
- Hashing
- Key generation
- Private-key loading
- Signature verification
Updated APIs for key generation/loading, certificate signing, CRL signing, CSR parsing, and convenience helpers to take a provider explicitly.
Removed process-wide provider state and automatic provider selection.
Moved Ring and AWS-LC operations into independent provider modules.
Made KeyPair backend-neutral by storing a SigningKey trait object instead of concrete Ring/AWS-LC key types.
Routed certificate serial-number and key-identifier hashing through CryptoProvider::hash.
Routed CSR self-signature verification through CryptoProvider::verify instead of x509-parser crypto features.
Made P-521 algorithm metadata available to custom providers.
Brought over ML-DSA support in the AWS-LC provider (Take advantage of stable ML-DSA in aws-lc-rs #447).
Added provider documentation and end-to-end custom-provider tests.

Built-in providers must now be enabled and selected explicitly:

rcgen does not enable Ring or AWS-LC by default.
The ring feature exposes the built-in Ring provider.
The aws_lc_rs feature exposes the built-in AWS-LC provider.
If both are enabled, the application still chooses which provider to pass.

Providers are passed directly to APIs:

let provider = rcgen::crypto::ring::default_provider();

let key = KeyPair::generate(provider)?;
let cert = params.self_signed(&key, provider)?;

Resolves #228

cpu · 2026-09-02T15:32:49Z

Thanks for picking this up.

Custom providers can either be installed once:
...
Or passed directly to explicit APIs:
...
The explicit form is intended for libraries and avoids process-global state.

I think we should probably model this like rustls main and not like rustls 0.23. E.g. splitting the providers we offer first-party into their own crates in the workspace, and requiring all the library code consumers to instantiate the provider explicitly, not doing any kind of default in rcgen's lib code itself based on feature flags.

@djc Are we on the same page there?

djc

Thanks! This looks directionally right to me.

djc · 2026-09-02T15:34:35Z

+	fn load_private_key(
+		&self,
+		key_der: PrivateKeyDer<'static>,
+		algorithm: Option<&'static SignatureAlgorithm>,


Why do we need algorithm here?

i think this is for compatibility with from_der_and_sign_algo. the old KeyPair was already bound to SignatureAlgorithim. this could be changed to have the signing algorithim desicion happen at the time of actual signing though.

I think we want to the signing algorithm to be committed rather than being a per-signature decision. I think we should ditch from_der_and_sign_algo() and from_pem_and_sign_algo().

In fact, with this PR, not sure the KeyPair type still has value? Seems to me that Box<dyn SigningKey> should basically replace it.

(Maybe that could be a separate PR?)

I think we want to the signing algorithm to be committed rather than being a per-signature decision. I think we should ditch from_der_and_sign_algo() and from_pem_and_sign_algo().

I'm good with this, do we keep the from_pkcs8 variants though? So we'd have from_pem , from_der, from_pkcs8_pem, and from_pkcs8_der

In fact, with this PR, not sure the KeyPair type still has value? Seems to me that Box should basically replace it.

It's almost just a wrapper for CryptoProvider, but one use is that we have a struct to keep the private key DER. Maybe there's a better abstraction for it though.

jgreeer · 2026-09-02T16:01:17Z

Thanks for picking this up.

Custom providers can either be installed once:
...
Or passed directly to explicit APIs:
...
The explicit form is intended for libraries and avoids process-global state.

I think we should probably model this like rustls main and not like rustls 0.23. E.g. splitting the providers we offer first-party into their own crates in the workspace, and requiring all the library code consumers to instantiate the provider explicitly, not doing any kind of default in rcgen's lib code itself based on feature flags.

@djc Are we on the same page there?

hey! thanks for the quick review. just before i change anything, are you in agreement with this as well @djc?

djc · 2026-09-02T17:25:16Z

I agree that we should not have a default provider or enable any provider by default, and API that needs it should take one explicitly. I don't think it's worth splitting the providers out into separate crates at this point? We're not close to API stability and I feel like rcgen is much less likely than rustls to end up deeper in dependency graphs.

cpu · 2026-09-02T17:32:03Z

I don't think it's worth splitting the providers out into separate crates at this point?

That's fine with me 👍

djc · 2026-09-07T15:04:48Z

            - run: cargo clippy --no-default-features --features aws_lc_rs_unstable,pem,x509-parser --all-targets
            - run: cargo clippy --no-default-features --features aws_lc_rs --all-targets
-            - run: cargo clippy --no-default-features --features fips,pem,x509-parser --all-targets
+            - run: cargo clippy --no-default-features --features aws_lc_rs,fips,pem,x509-parser --all-targets


Why is this necessary?

i coupled aws_lc_rs + fips together as flags in this PR, but it's ultimately irrelevant to the actual provider abstration. since we're going to rewrite that in the future anyways, should i just revert to previous behaviour?

I went ahead and removed this for now, I'm not sure if the way the flag works right now is how it's intended to?

djc · 2026-09-07T15:11:06Z

+	#[cfg(all(
+		test,
+		feature = "x509-parser",
+		any(feature = "ring", feature = "aws_lc_rs")


I don't think we need the any here?

yeah, there are some other lines where this was added too. took those out as well

the test module in certificate.rs pulls in a provider through crate::test_provider(), so we actually do have to keep this.

djc · 2026-09-07T15:12:51Z

+		&self,
+		writer: &mut DERWriterSeq,
+		pub_key_spki: Option<&[u8]>,
+		provider: Option<&dyn CryptoProvider>,


The separate Options for pub_key_spki and provider don't make sense.

do you mean combining them into one parameter? the only thing with that is that it's different from the shape of the other functions

djc · 2026-09-07T15:15:26Z

+		})
+	}
+
+	fn validate(&self, issuer: &Issuer<'_, impl SigningKey>) -> Result<(), Error> {


Why move this into a separate method?

If you're only going to get your LLM to iterate on this PR we might as well stop reviewing this here, or your employer can pay me for my time.

Yeah, that change doesn't really make sense, will revert. I try to review the commits, but clearly some nonsensical changes slipped in. After reviewing the rest of your comments, I'll go through and make sure there aren't any more unrelated additions here, sorry about that. Thanks so much for the reviews.

It is really not great that you're getting volunteers to review something that you haven't even reviewed yourself.

jgreeer · 2026-09-09T13:50:42Z

Reverted many of the unnecessary changes, remaining edits should be only crypto provider related

Changes:

Removed the changing of the fips flag logic, it now behaves exactly like it used to. This does mean that the testing functions in certificate.rs require the flag in the any section of the config now.
Removed other changes to README, the only README change is the new Cryptography providers section, which simply explains that you need to enable a provider now and pass it through the functions & the provider in the example
cargo.toml now has the original feature flags, except for crypto which we agreed to remove
Derive the SKI inline instead of before calling write_x509_extension in certificate.rs, same change in serialize_der from crl.rs
Switch back to retrieving the private key via private_key.contents() in key_pair.rs, the provider calls clone_key later for ownership.
Restore original shape of serialize_pem in key_pair.rs where we assign serialize_der to `contents
Returned the SPKI parsing flow in from_der in key_pair.rs to its original form
Removed boxed blanket implementations for PublicKeyData and SigningKey in key_pair.rs
Added back inline certificate parsing in self_signed in lib.rs
Use to_vec() and 0..20 in the derive function in KeyIdMethod
Revert changes entirely to string.rs, nothing should be touched there
In aws-lc-rs.rs
- Variables have been renamed to match their original names in key_pair.rs
- ECSDA keys use from EcdsaKeyPair::from_pkcs8 instead of load_with_algorithm
- Wrapped match in Ok in the implementation of sign instead of around each signature to match original function
In ring.rs
- Restored original variable names
- Use ecdsa_from_pkcs8 instead of load_with_algorithim for ECDSA keys
- Return a Ok(KeyPair) out in each if block like the generate
- Changed SigningKey implementation to be like original KeyPair.rs
Drop unneeded test in custom_provider.rs

jgreeer · 2026-09-09T14:13:37Z

 	}

-	/// Obtains the key pair from a DER formatted key
+	/// Obtains the key pair from a PEM formatted key


this change isn't relevant, but i do think this comment is wrong? (copy pasted from from_pkcs8_der_and_sign_algo maybe). but could break this change off into another PR

djc · 2026-09-10T13:56:40Z

+	fn load_private_key(
+		&self,
+		key_der: PrivateKeyDer<'static>,
+		algorithm: Option<&'static SignatureAlgorithm>,


I think we want to the signing algorithm to be committed rather than being a per-signature decision. I think we should ditch from_der_and_sign_algo() and from_pem_and_sign_algo().

In fact, with this PR, not sure the KeyPair type still has value? Seems to me that Box<dyn SigningKey> should basically replace it.

(Maybe that could be a separate PR?)

djc reviewed Sep 2, 2026

View reviewed changes

Comment thread rcgen/src/certificate.rs Outdated

cpu reviewed Sep 4, 2026

View reviewed changes

Comment thread rcgen/src/certificate.rs Outdated

djc reviewed Sep 4, 2026

View reviewed changes

Comment thread rcgen/src/crypto/mod.rs Outdated

Comment thread rcgen/src/certificate.rs Outdated

djc reviewed Sep 7, 2026

View reviewed changes

jgreeer commented Sep 9, 2026

View reviewed changes

jgreeer added 19 commits September 9, 2026 15:37

add pluggable crypto provider

c1eeacb

restore docs

3c970a4

add back stable ML-DSA for AWS-LC

ec2e9ce

clean up readme

f7a4a19

fips doesn't enable aws-lc

045718e

fix formatting issues

8767056

combine generate_rsa into generate

f33a3b8

no default/global + cryptoProvider trait + use rustls hash setup

c08876a

bump to 0.15 since this is a breaking change

76af07c

fix aws-lc-rs-unstable feature

9366cbe

remove "crypto" flag

a8830d8

use ring for digest generation

6253efe

nit: add empty line

3d34d22

switch argument order for the verify method on the provider

db5eb07

remove sized bounds

4e251d1

remove validate function

848e7f9

remove provider feature flag cfg from some x509 parser fuctions

38a40ef

add back provider feature flags to x509 parser functions

3d6d00b

restore original code

c08332c

jgreeer force-pushed the add-pluggable-crypto-provider branch from ec38547 to c08332c Compare September 9, 2026 15:40

djc reviewed Sep 10, 2026

View reviewed changes

swap method order + remove cargo tree step

cbc3a7d

Uh oh!

Conversation

jgreeer commented Sep 2, 2026 • edited by cpu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cpu commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djc Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jgreeer commented Sep 2, 2026

Uh oh!

djc commented Sep 2, 2026

Uh oh!

cpu commented Sep 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jgreeer commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

djc Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

jgreeer commented Sep 2, 2026 •

edited by cpu

Loading

cpu commented Sep 2, 2026 •

edited

Loading

djc Sep 10, 2026 •

edited

Loading

jgreeer commented Sep 9, 2026 •

edited

Loading

djc Sep 10, 2026 •

edited

Loading