This document provides information regarding the ACME server.
The ACME server enforces rate limits on various endpoints to ensure fair usage and prevent abuse. Below are the default rate limiting values for each endpoint.
Endpoint | Limit | Key Used for Rate Limiting |
---|---|---|
/new-account |
5 requests per hour per IP | IP address |
/new-nonce |
60 requests per minute per IP | IP address |
/new-order |
50 requests per week per account (JWS KID) | JWS Key ID |
/orders/{id} |
5 requests per minute per account (JWS KID) | JWS Key ID |
/authz/{id} |
5 requests per minute per account (JWS KID) | JWS Key ID |
/challenge/{id} |
5 requests per minute per account (JWS KID) | JWS Key ID |
/cert/{id} |
10 requests per hour per account (JWS KID) | JWS Key ID |
/revoke-cert |
5 requests per hour per account (JWS KID) | JWS Key ID |
/directory |
100 requests per hour per IP | IP address |
-
Public Endpoints: Endpoints like
/new-account
,/new-nonce
, and/directory
are accessible without authentication and are rate-limited based on the client's IP address. -
JWS-Protected Endpoints: Endpoints that require JWS authentication (e.g.,
/new-order
,/orders/{id}
,/cert/{id}
) are rate-limited based on the JWS Key ID (kid
), which ties the rate limit to the account rather than the client's IP address.
- These limits are configurable based on the needs of your infrastructure, but it is recommended to follow the values listed above for a balance between availability and security.
- Rate limiting responses will include a
429 Too Many Requests
status code along with aRetry-After
header to indicate when the client can retry the request.
RFC compliant http-01 challenge as specified in RFC 8555, section 7.5.1 Responding to Challenges.
RFC compliant http-01 challenge as specified in RFC 8555, section 8.4 DNS Challenge.
Custom challenge type to support automated EK Certificate installation for the following use cases:
* TPM without manufacturer issued EK cert
* OEMs with custom EK certs
* TPM Simulators
Custom challenge type to support automated device enrollment using the TCG TPM 2.0 Keys for Device Identity and Attestation outlined in Section 6.2 OEM Creation of IAK and IDevID in a Single Pass.
This challenge type uses a modified version of the http-01 challenge that performs 2 round trips to the client.
The first request is make to the /.well-known/acme-challenge/<token>
endpoint defined in http-01, however, instead of providing the key authorization to the challenge token endpoint, the client provides the TCG-CSR-IDEVID instead.
The server receives the TCG-CSR-IDEVID and performs validations per the procedure outlined in Section 6.2 mentioned above.
Upon successful validation, the server sends the client another request on /.well-known/acme-activation/<token>
, providing a "nonce" as generated by TPM2_MakeCredentia and mentioned in the TCG procedure.
The client uses TPM2_ActivateCredential to release the CertInfo data using the EK, and returns the released nonce as the Proof of Possession (POP) of the EK.
The http and device challenge types included in the Trusted Platform allow the CA administrator to define custom ports for the challenge by changing the challenge type from -01
to reflect the port number you wish to serve the challenge.
For example, to perform the http-01 challenge over port 8080, use http-8080
. Likewise, device-8080
would serve the device-01 challenge over port 8080.
If the http-01 challenge type ever offers a new version, such as http-02, the RFC compliant behvior will override the dynamic port allocation behavior in the Trusted Platform.
- **device-01**: This challenge type will be refactored to `enroll-01` upon successful integration of the [acme-device-attest](https://datatracker.ietf.org/doc/html/draft-acme-device-attest-03) challenge type to avoid confusion and more accurately
describe it's intended use.