I generated two orders for one domain name under the same account simultaneously, but the challenge tokens returned by the two orders are the same. Is this situation correct? Suppose I am a service provider providing free certificates to my customers. In that case, this means that when two of my customers apply for one certificate simultaneously, those who do not have control over the domain name can also obtain the corresponding certificate. If an account is created for each user separately, the problem of rate limiting is not easy to solve either, and there are restrictions such as IP when creating an account. Has anyone encountered the same problem?
This is “order reuse”: if the same account creates two identical calls to NewOrder, the same order will be reused.
As a service provider, you’ll have to make sure you keep your customers separate, for example by disallowing the same domain on multiple accounts.
6 Likes
LE reuses authorization too, so server likely skip validation for already validated for that account for about a month.
3 Likes
Osiris
August 27, 2024, 7:52am
4
I do hope you have some kind of check if a customer is allowed to request certs for e.g. whitehouse.gov
before you send the request to the ACME server, right?
1 Like
Yeah it's not your customers that are creating the certificate order, you are - they just asked via your service, but your service completed the request for them. If you enable it, they can do it.
3 Likes
Also, be sure to read through the Integration Guide:
And many of these kinds of specifics, of how Let's Encrypt implements the ACME spec, are also documented:
# Boulder implementation details
The ACME specification ([RFC 8555]) clearly dictates what Clients and Servers
must do to properly implement the protocol.
The specification is intentionally silent, or vague, on certain points to give
developers freedom in making certain decisions or to follow guidance from other
RFCs. Due to this, two ACME Servers might fully conform to the RFC but behave
slightly differently. ACME Clients should not "over-fit" on Boulder or the
Let's Encrypt production service, and aim to be compatible with a wide range of
ACME Servers, including the [Pebble](https://github.com/letsencrypt/pebble)
test server.
The following items are a partial listing of RFC-conformant design decisions
Boulder and/or LetsEncrypt have made. This listing is not complete, and is
based on known details which have caused issues for developers in the past. This
listing may not reflect the current status of Boulder or the configuration of
LetsEncrypt's production instance and is provided only as a reference for client
developers.
This file has been truncated. show original
# Boulder divergences from ACME
While Boulder attempts to implement the ACME specification ([RFC 8555]) as strictly as possible there are places at which we will diverge from the letter of the specification for various reasons. This document describes the difference between [RFC 8555] and Boulder's implementation of ACME, informally called ACMEv2 and available at https://acme-v02.api.letsencrypt.org/directory. A listing of RFC conformant design decisions that may differ from other ACME servers is listed in [implementation_details](https://github.com/letsencrypt/boulder/blob/main/docs/acme-implementation_details.md).
Presently, Boulder diverges from the [RFC 8555] ACME spec in the following ways:
## [Section 6.3](https://tools.ietf.org/html/rfc8555#section-6.3)
Boulder supports POST-as-GET but does not mandate it for requests
that simply fetch a resource (certificate, order, authorization, or challenge).
## [Section 6.6](https://tools.ietf.org/html/rfc8555#section-6.6)
For all rate-limits, Boulder includes a `Link` header to additional documentation on rate-limiting. Only rate-limits on `duplicate certificates` and `certificates per registered domain` are accompanied by a `Retry-After` header.
## [Section 7.1.2](https://tools.ietf.org/html/rfc8555#section-7.1.2)
Boulder does not supply the `orders` field on account objects. We intend to
support this non-essential feature in the future. Please follow Boulder Issue
[#3335](https://github.com/letsencrypt/boulder/issues/3335).
This file has been truncated. show original
4 Likes
system
Closed
September 26, 2024, 1:42pm
7
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.