Is it allowed for an ACME server to use the same token for several authorizations?

Client dev
1

I facing a problem with an ACME server (LiteSSL) that behave unexpectedly.
The server uses the same token for 2 authorizations (wildcard / non-wildcard).

From my reading of the RFC:

Token Entropy

The http-01 and dns-01 validation methods mandate the use of a random
token value to uniquely identify the challenge. The value of the
token is required to contain at least 128 bits of entropy for the
following security properties.
RFC 8555: Automatic Certificate Management Environment (ACME)

I think this is not a valid behavior.

WDYT?

I know this is not related to Let's Encrypt, but maybe someone here will have the right pointer inside the RFC to help me.

2

Can you provide log which shows this?

3

This LiteSSL?

5 Likes
4

This is actually pretty wild. It sounds like they had a bug that allowed one ACME account to obtain arbitrary wildcard certs previously issued for other accounts.

7 Likes
5

acme auth doesn't have token: challenges have them: I think they may reusing challenges instead of auth like other CAs?

edit : tried to test them but they require phone number to register an account :unamused_face:

3 Likes
6

Same reaction on my side: I will not provide my phone number to this weird ACME server.

But I asked a user to give me an example.

This is 2 different authorizations (wildcard and non-wilcard for the same domain):

Authz 
{
  "identifier": {
    "type": "dns",
    "value": "example.com"
  },
  "status": "pending",
  "expires": "2026-02-05T09:42:18Z",
  "challenges": [
    {
      "type": "dns-01",
      "url": "https://acme.litessl.com/acme/v2/acct/bdGVI7q2A/authz/1ceb7f87febbb8b3589659e7698c1e9af00b0d54086e7003ccd82a61f427f5cb/chall/TpzCvXH4-aUsgJkZOaTu_g",
      "token": "85o69g5qv3bwfw05zpbptrwt071jxwdm",
      "status": "pending"
    }
  ],
  "wildcard": true
}

{
  "identifier": {
    "type": "dns",
    "value": "example.com"
  },
  "status": "pending",
  "expires": "2026-02-05T09:42:15Z",
  "challenges": [
    {
      "type": "dns-01",
      "url": "https://acme.litessl.com/acme/v2/acct/bdGVI7q2A/authz/6b00e9053cbb8b9f43c77cdb8b968a0d44923bc4eac08f2f6a90b158898c8d26/chall/huMz5IVrG3mc_7fon6DxTg",
      "token": "85o69g5qv3bwfw05zpbptrwt071jxwdm",
      "status": "pending"
    },
    {
      "type": "http-01",
      "url": "https://acme.litessl.com/acme/v2/acct/bdGVI7q2A/authz/6b00e9053cbb8b9f43c77cdb8b968a0d44923bc4eac08f2f6a90b158898c8d26/chall/Y8DfZzfnqTGx2pFtfOruXQ",
      "token": "85o69g5qv3bwfw05zpbptrwt071jxwdm",
      "status": "pending"
    }
  ]
}

As you can see the 2 authorizations are using the same token.

Using the same token for the challenges related to an authorization is right (DNS, HTTP), but between 2 authorization seems wrong.

1 Like
7

that surely looks weird: need an actual account to confirm though

8

This is confirmed by multiple users.

I'm looking for something inside the RFC about this specific behavior, because I don't want to implement something that doesn't conform to it.

FYI, this is an intentional behavior. I asked a user to contact LiteSSL: they intentionally reuse the same DNS-01 token/value when requesting a base domain and its wildcard in the same order.

1 Like
9

CAB BR allows using "Request Token" for validation token, that generated per certificate request. and if those auths are from same certificate request, so I think while it's weird but legal:

Request Token: A value, derived in a method specified by the CA which binds this demonstration
of control to the certificate request. The CA SHOULD define within its CPS (or a document clearly
referenced by the CPS) the format and method of Request Tokens it accepts.

edit: but because it used same token for http-01 challenge, and it's defined differently from normal http update DCV in 3.2.2.4.18 but point to rfc 8555 which mandates using random value for this, I think it may caused misissuance.

10

Are they doublechecking the number entered?

11

The number is required to get a code to validate the account.

I don't know the rest of the process.