Crate acme

source ·
Expand description

Provisioning certificates from ACME (Automatic Certificate Management Environment) providers such as Let’s Encrypt.

It follows the RFC 8555 spec, using ACME v2 to issue and manage certificates.

Usage

  • This crate exposes a library which is referenced as acme. This name is used throughout these docs, not acme_rfc855, which would be awkward to write every time.
  • TODO

Examples

Complete usage examples are provided in the source repository for these challenge types:

Domain Ownership

Most website TLS certificates tries to prove ownership/control over the domain they are issued for. For ACME, this means proving you control either:

  • a server answering TLS or HTTP requests for that domain;
  • the DNS server answering name lookups against the domain.

To use this library, there are points in the flow where you would need to modify either the web server or DNS server before progressing to get the certificate.

See tls_alpn_challenge, http_challenge, and dns_challenge.

Multiple Domains

When creating a new order, it’s possible to provide multiple alt-names that will also be part of the certificate. The ACME API requires you to prove ownership of each such domain. See authorizations.

Rate Limits

The ACME API provider Let’s Encrypt uses rate limits to ensure the API is not being abused. It might be tempting to put the delay really low in some of this library’s polling calls, but balance this against the real risk of having access cut off.

Use Staging For Development!

Especially take care to use the Let’s Encrypt staging environment for development where the rate limits are more relaxed. See DirectoryUrl::LetsEncryptStaging.

Modules

  • JSON API payloads.
  • Order life cycle.

Structs

  • Account with an ACME provider.
  • Encapsulated certificate and private key.
  • Entry point for accessing an ACME API.

Enums

Functions

  • Make a P-256 private key (from which we can derive a public key).