Failing to register an ACME account

Help
5

I am using an email address. This certbot command worked (registered an account and then obtained a certificate, on a fresh Alpine container):

certbot certonly --standalone -d test.example.ac.uk \
    --server https://one.digicert.com/mpki/api/v1/acme/v2/directory \
    --eab-kid x --eab-hmac-key y \
    --register-unsafely-without-email

I did some digging… managed to obtain the payloads for newAccount (the call that’s failing) from Caddy and uacme to compare. Aside from what I presume are expected differences, the Caddy request contains an empty orders field which uacme omits.

The other difference I noted was, within the decoded payload, that Caddy is requesting a P-256 key where uacme is requesting a RSA key. (I did try asking uacme to use a EC key - with -t EC - but it didn’t seem to make a difference to the account registration phase)

I don’t know enough about the ACME protocol to know if orders is allowed to be present in a newAccount request. A quick skim of RFC 8555: Automatic Certificate Management Environment (ACME) (section 7.3) suggests it’s not expected … but, assiming I’m right, I don’t know what a server should do if it sees a value it’s not expecting.

Caddy

{
  "status": "",
  "contact": [
    "mailto:..."
  ],
  "termsOfServiceAgreed": true,
  "externalAccountBinding": {
    "protected": "xxx",
    "payload": "yyy",
    "signature": "zzz"
  },
  "orders": ""
}

uacme

{
  "termsOfServiceAgreed": true,
  "contact": [
    "mailto:..."
  ],
  "externalAccountBinding": {
    "protected": "xxx",
    "payload": "yyy",
    "signature": "zzz"
  }
}
1 Like