rcgen

CSR handling has been updated to allow direct creation from parameters and uses a new params type for loading.

Creating a CSR:

Instead of issuing a certificate first, create a CertificateSigningRequest directly from CertificateParams using CertificateParams::serialize_request(subject_key_pair). You can then call .der() or .pem() on the resulting CertificateSigningRequest.

Loading a CSR:

To load an existing CSR from PEM or DER, use the CertificateSigningRequestParams type:

• CertificateSigningRequestParams::from_pem(data)
• CertificateSigningRequestParams::from_der(data)

Issuing a Certificate from a CSR:

To sign a CSR, use CertificateSigningRequestParams::signed_by(issuer_certificate, issuer_key_pair).

The rustls-cert-gen tool generates a Root CA and an end-entity certificate, along with their respective private keys. The end-entity certificate is automatically signed by the generated Root CA.

To use the tool, compile it and pass an output directory using the -o flag. The tool will populate the specified directory with the following files:

• cert.pem: The end-entity's X.509 certificate (signed by the Root CA).
• cert.key.pem: The end-entity's private key.
• root-ca.pem: The Root CA's self-signed X.509 certificate.

To see all available command-line options, run rustls-cert-gen --help.

cargo run -- -o output/dir

After generating a certificate using rcgen, you can verify its contents and structure using the OpenSSL CLI. This is useful for checking if the Subject Alternative Names or other extensions were applied correctly.

openssl x509 -in certs/cert.pem -text -noout

CRL creation and serialization have been updated to follow the new signing pattern.

Creating a CRL:

Instead of CertificateRevocationList::from_params(), use CertificateRevocationListParams::signed_by(issuer_certificate, issuer_key_pair).

Serializing a CRL:

To serialize the CRL to DER or PEM, call the methods directly on the CertificateRevocationList instance:

• CertificateRevocationList::der()
• CertificateRevocationList::pem()

In rcgen 0.13, CertificateParams and Certificate no longer manage private key data automatically. You must now handle KeyPair creation explicitly.

Key Changes:

• Creation: Instead of leaving the key_pair field empty in CertificateParams, use KeyPair::generate(), KeyPair::generate_for(), or KeyPair::generate_rsa_for() to create a key pair first, then provide it to your certificate parameters.
• Serialization: To serialize a private key to DER or PEM, call .serialize_der() or .serialize_pem() directly on the KeyPair instance, rather than calling serialization methods on a Certificate object.

// Example of the new pattern:
let key_pair = KeyPair::generate(&KeyPairParams::default())?;
// Use key_pair in CertificateParams...
let der = key_pair.serialize_der()?;
let pem = key_pair.serialize_pem()?;

The API for issuing certificates has moved from Certificate::from_params() to specialized methods on CertificateParams to ensure that issuance is handled upfront and serialization is idempotent.

Issuance Patterns:

• Simple Self-Signed: Use generate_simple_self_signed(). This now returns a CertifiedKey containing both the cert (the Certificate) and the key_pair (KeyPair).
• Custom Self-Signed: Use CertificateParams::self_signed(subject_key_pair).
• Signed by an Issuer: Use CertificateParams::signed_by(subject_key_pair, issuer_certificate, issuer_key_pair).

Serialization:

In 0.13, calling serialization methods no longer issues a new certificate. To get the encoded data, use:

• Certificate::pem() for PEM encoding.
• Certificate::der() for DER encoding.

You can use certificates generated by rcgen to run QUIC servers and clients using the quinn crate. To test this workflow, run the rcgen project to generate certs, then point the quinn server example to the generated .pem files and the client to the .der CA certificate.

cargo run
cd ../quinn
cargo run --example server -- --cert ../rcgen/certs/cert.pem --key ../rcgen/certs/key.pem ./
cargo run --example client -- --ca ../rcgen/certs/cert.der https://localhost:4433/README.md

A SignatureAlgorithm represents a cryptographic signing method used in certificates. It encapsulates:

1. OIDs: The Object Identifiers used to identify the algorithm in DER encoding.
2. SignAlgo: The internal cryptographic implementation (used when the crypto feature is enabled).
3. Parameters: Specific configuration for the algorithm, such as salt length for RSA-PSS.

Commonly, you will interact with these via the algo module constants or by resolving them from OIDs using from_oid().

When creating a CA certificate, you can use the BasicConstraints enum to set an upper limit on the length of the intermediate certificate chain allowed for this CA (not including the end entity certificate).

• BasicConstraints::Unconstrained: No limit on the chain length.
• BasicConstraints::Constrained(u8): Limits the number of intermediate certificates allowed.

pub enum BasicConstraints {
	Unconstrained,
	Constrained(u8),
}

The IsCa enum controls the BasicConstraints extension in the generated certificate:

• IsCa::NoCa: The certificate is not a CA.
• IsCa::ExplicitNoCa: The certificate is explicitly marked as CA:FALSE.
• IsCa::Ca(BasicConstraints): The certificate is a CA. BasicConstraints can be Unconstrained or Constrained(path_len) (limiting the path length).

You can include information in a CRL about where it can be retrieved from using CrlIssuingDistributionPoint. This is configured via the issuing_distribution_point field in CertificateRevocationListParams.

Components

• CrlDistributionPoint: Contains a list of uris (e.g., HTTP or LDAP URIs) where the CRL is hosted.
• CrlScope: An optional field to restrict the scope of the CRL:
  • CrlScope::UserCertsOnly: The CRL contains only end-entity user certificates.
  • CrlScope::CaCertsOnly: The CRL contains only CA certificates.
  • If omitted, the CRL may contain both user and CA certificates.