rcgen Support for all RFC5280 standard extensions

Hi,

first of all, thank you for this project.

Over the past few months, I have started writing and increasingly enjoying Rust. To be in full control of my PKI, develop a better understanding of the x.509 standard and hone my programming abilities, I set out do write a simple certificate management application that provides defaults that are to my liking, which is how I ended up here.

Going by ./rcgen/src/certificate.rs, not all extensions defined in RFC5280 are built-in to this library but instead, support for more extensions is provided via the CustomExtension and Attribute structs.

The missing standard extensions seem to be:

4.2.1.4. Certificate Policies
4.2.1.5. Policy Mappings
4.2.1.7. Issuer Alternative Name
4.2.1.8. Subject Directory Attributes
4.2.1.11. Policy Constraints
4.2.1.14. Inhibit anyPolicy
4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)
4.2.2.1. Authority Information Access
4.2.2.2. Subject Information Access

I think the ones that are not part of CertificateParams and not mentioned in the list above are automatically provided when signing but didn't confirm.

For now, I was looking to implement the Certificate Policies extension on my own but found myself unable to due to my missing experience in ASN.1 encoding (or encoding in general).

To be successful in implementing the extension(s) correctly, I'd like to ask for some guidance. If my Implementation is good enough, maybe I could re-contribute them to this project. Please don't expect too much though as I currently have little time to spare for these projects.

Best, Gab

P.S.: While I'm already asking, I noticed that this Rust codebase as well as many other popular Rust projects seem to use few long over many short files which is the opposite of what I would usually do. For example, you decided to use one file for OIDs (oid.rs) and a 1496 line file (certificate.rs) for extensions and certificate parameters. I would usually have created an extensions module with one file per extension to keep the files short and easy to understand as well as avoid merge conflicts to the greatest extend possible. How come long files are the preferred way?

P.P.S.: Are there any resources besides RFC5280 that I am missing? Going by the IETF datatracker, it is still just a proposed standard but all implementations I know of reference 5280. Is there no actual, reliable standard around PKI?

Aug 11 '25 15:08 Gabgobie

I don't think we should do completeness-for-completeness's sake. There is a lot of crap in this space, and implementing it all is largely not a good use of time.

P.P.S.: Are there any resources besides RFC5280 that I am missing? Going by the IETF datatracker, it is still just a proposed standard but all implementations I know of reference 5280. Is there no actual, reliable standard around PKI?

https://datatracker.ietf.org/doc/html/rfc7127#section-3 covers this terminology.

Aug 11 '25 15:08 ctz

Thank you for the quick response and pointing me to 7127.

I don't think we should do completeness-for-completeness's sake. There is a lot of crap in this space, and implementing it all is largely not a good use of time.

I wholeheartedly agree with the argument about completeness-for-completeness's sake. An official implementation is by no means necessary, I just wanted to offer recontributing the extension(s) I write. The CustomExtension should be enough.

I was mostly seeking for guidance or a good starting point for learning to correctly implement the extensions I need. For now that would be Certificate Policies.

Aug 11 '25 18:08 Gabgobie

P.S.: While I'm already asking, I noticed that this Rust codebase as well as many other popular Rust projects seem to use few long over many short files which is the opposite of what I would usually do. For example, you decided to use one file for OIDs (oid.rs) and a 1496 line file (certificate.rs) for extensions and certificate parameters. I would usually have created an extensions module with one file per extension to keep the files short and easy to understand as well as avoid merge conflicts to the greatest extend possible. How come long files are the preferred way?

In my experience making many small files makes navigating a project harder rather than easier. Although certificate.rs is surely on the large side and we might redistribute some of its code if we find decent abstraction boundaries, so far we've found its size to be manageable.

I was mostly seeking for guidance or a good starting point for learning to correctly implement the extensions I need. For now that would be Certificate Policies.

There is some discussion of this extension here:

https://github.com/rustls/webpki/issues/30

(That's the verification side of the project, which might be more stringent. It would be good if you can explain the use case you have for this extension.)

Aug 12 '25 10:08 djc

There is some discussion of this extension here:

rustls/webpki#30

The conversations seem to mostly revolve around the validation of critical policies. The code from the linked merge requests did give me a little more understanding of the structure of the extension but seems to use certificate data that has already been deserialised, matching only the last number of the OID.

const CERTIFICATE_POLICIES_OID: &[u64] = &[2, 5, 29, 32]; // Is this correct or do I only need the 32?

/// anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
const ANY_POLICY_OID: &[u64] = &[2, 5, 29, 32, 0]; // Is this correct or do I only need the 0?

Going by oid.rs, I need the full OID and not just the subdomain/last element/however one would call it.

Assuming my usecase, I'd like to include an ExplicitText. That is nested pretty deep in other structures but I have absolutely no idea how to represent that as a Vec<u8>. I think, I need to include the ANY_POLICY_OID with the UserNotice to avoid validation errors in case a validator supports certifiacte policies.

So to my understanding, to build the extension, I need to instantiate a CustomExtension with the &[u64] OID and criticality set to false. Now the hard part that I don't understand is how I get the contents of the extension as Vec.

use rcgen::CustomExtension;

const CERTIFICATE_POLICIES_OID: &[u64] = &[2, 5, 29, 32];

pub fn get_certificate_policy(explicit_text: String) -> CustomExtension {
    CustomExtension::from_oid_content(
        CERTIFICATE_POLICIES_OID,
        "SomeText".into() // This is probably incorrect, especially when considering, that the extension should be a nested struct containing the text.
    )
}

I tried taking write_general_subtrees() for reference but can't quite follow what's happening. After taking a look at the DERWriter, it looks to me like the outermost writer is writing the already to DER converted inner elements. The innermost elements need to have a bytes representation ready to be converted. You already provided the string types that can be converted to bytes but how is this done for structs, enums and Vecs?

[...] It would be good if you can explain the use case you have for this extension.)

I am looking to have the PKI of my intranet as constrained as possible. A lot of the constraints can be conveyed via the NameConstraints extension, enforcing Rfc822Name(String), DnsName(String), DirectoryName(DistinguishedName) and IpAddress(CidrSubnet) but some of the intentions need to be part of a UserNotice with ExplicitText.

I also like to include a UserNotice about explicit distrust towards a certificate in those I use for development. These certificates need to - at least temporarily - be in a trust store and be valid so I can test systems and trust etc. but I want it to be clear that this is not a trustworthy certificate in case cleanup fails for any reason. Without the notice, it may reside in the trust store and there is no good way to tell it apart from those certificates that should be trusted.

Note that there may be some inconsistencies in my writing as I have been trying to do my research to answer my questions myself while writing over the past few hours. Thanks for your patience

Aug 12 '25 20:08 Gabgobie

[...] It would be good if you can explain the use case you have for this extension.)

I am looking to have the PKI of my intranet as constrained as possible. A lot of the constraints can be conveyed via the NameConstraints extension, enforcing Rfc822Name(String), DnsName(String), DirectoryName(DistinguishedName) and IpAddress(CidrSubnet) but some of the intentions need to be part of a UserNotice with ExplicitText.

I also like to include a UserNotice about explicit distrust towards a certificate in those I use for development. These certificates need to - at least temporarily - be in a trust store and be valid so I can test systems and trust etc. but I want it to be clear that this is not a trustworthy certificate in case cleanup fails for any reason. Without the notice, it may reside in the trust store and there is no good way to tell it apart from those certificates that should be trusted.

Note that there may be some inconsistencies in my writing as I have been trying to do my research to answer my questions myself while writing over the past few hours. Thanks for your patience

Do you know for a fact that other parts of your environment in fact support (this part of) the extension? Presumably putting UserNotice stuff in your certificate is pointless unless the tools you're using to handle these certificates actually communicate the notice to the user. My impression is that there isn't broad support for some of this stuff that you might think there is based on it being specified in RFC 5280.

Aug 13 '25 10:08 djc

Actually every single tool I use supports it. (Only tested with ExplicitText, please excuse the German system)

Windows ("Krypto-Shellerweiterungen")

If a certificate contains a UserNotice, an additional button is shown that reveals the ExplicitText.

OpenSSL

openssl x509 -in certs/localhost.crt -text -noout

Firefox

Chromium (tested on Edge)

Chromium seems to try to hide certificates from user inspection in general but once you found the button, it's there:

Other

The certificate (chain) was created with a Python script and pyca/cryptography. I can share the code if it is of any use but would need to look through the hardcoded values first. It's not pretty, I just remembered having it around from when I was initially trying to learn PKI.

Aug 13 '25 13:08 Gabgobie

Okay -- not sure what other maintainers think, but I think that's enough proof that some support in rcgen might be useful.

Aug 13 '25 13:08 djc

I also like to include a UserNotice about explicit distrust towards a certificate in those I use for development

It seems to me that if your test environment doesn't require an identical certificate trust anchor profile as your non-testing environment (which seems implied, since you're adding a special UserNotice to the test-only variant), then you would be better off making this distinction in the trust anchor subject details (O, OU, etc). Those fields are much more common, and wouldn't require as much digging around through the UI.

Is this the only reason you want to see user notice supported?

Aug 13 '25 13:08 cpu

The specific testing scenario, was figuring out how PKI validation works and how I can further constrain my planned production PKI. I can't use the subject details / distinguished name since it's subject to the DirectoryName NameConstraints.

As for the production environment, I can imply how a certificate is to be handled through the BasicConstraints path length, NameConstraints and the distinguished name but at the end of the day, other than an explicit note, these values are subject to (mis-)interpretation.

To name an example outside a theoretical multi-branch org, I am promoting digital sovereignty through the many branches of my family. To do so without compromising the UX, I need to build the PKI - one of the core pillars - in a way that makes it as hard to misuse as possible. That includes constraints, an extensive DN (basically all supported fields are used) and usually a user-notice.

Aug 13 '25 14:08 Gabgobie

I can't use the subject details / distinguished name since it's subject to the DirectoryName NameConstraints.

I imagine you could adjust the constraints in the test certificate to match the test subject(s) as well, no?

at the end of the day, other than an explicit note, these values are subject to (mis-)interpretation.

I think the user studies done over the years looking at the HTTPS flow in web browsers has shown fairly conclusively that regular users aren't digging into certificate chain details to find and correctly interpret data embedded in X.509 certificates.

I'm not strictly opposed to support if you can write a clean PR with appropriate test coverage without a lot of guidance[^1] but I'm having a hard time seeing this as a genuine use case that will benefit a large enough number of people to be worth the ongoing maintenance.

[^1]: Other maintainers may have more capacity to coach you through this but realistically I don't think I'll have the bandwidth personally.

Aug 13 '25 14:08 cpu

I'm not strictly opposed to support if you can write a clean PR with appropriate test coverage without a lot of guidance1 but I'm having a hard time seeing this as a genuine use case that will benefit a large enough number of people to be worth the ongoing maintenance.

Same here -- if you can submit something that matches the coding style here and comes with some basic tests (and some screenshots that show it working with the platforms you have), I can review the PR.

Aug 13 '25 14:08 djc

I can't use the subject details / distinguished name since it's subject to the DirectoryName NameConstraints.

I imagine you could adjust the constraints in the test certificate to match the test subject(s) as well, no?

I'd need to try it out. That would at the very least require the text to be duplicated between the constraints and the subject and require all subsequent subjects to match the text instead of having their own. I think it might be possible depending on the ordering of the DN fields.

I think the user studies done over the years looking at the HTTPS flow in web browsers has shown fairly conclusively that regular users aren't digging into certificate chain details to find and correctly interpret data embedded in X.509 certificates.

I'm not strictly opposed to support if you can write a clean PR with appropriate test coverage without a lot of guidance1 but I'm having a hard time seeing this as a genuine use case that will benefit a large enough number of people to be worth the ongoing maintenance.

Footnotes
1. Other maintainers may have more capacity to coach you through this but realistically I don't think I'll have the bandwidth personally. [↩](#user-content-fnref-1-db183e2704be81e0d7312f2bb29f2a88)

Sounds fair to me. I'll look into it but it will probably take some time for me to get the encoding right on my own.

Edit:

I didn't feel comfortable just leaving this here in absolute silence but also didn't want to ping anyone unnecessarily. I had to drop all of my PKI-related activities for the time being but will come back to this when I find the time.

I'll leave this resource I just found for myself for when I come back: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/

Edit2: Switch out the link because the original one quickly went off-topic

Aug 13 '25 14:08 Gabgobie