No status field on challenges from non-Boulder ACME server

Client dev
1

I’m attempting to troubleshoot an issue submitted to my project from a user trying to use the client against an internal non-Boulder based ACME server called Nexus Certificate Manager.

The root of the problem is that the challenges inside the authorization objects returned by the server don’t contain a status field. My client basically throws an exception when it can’t find that status field. Here’s an example:

{
    "status":  "pending",
    "expires":  "2020-03-16T07:27:24.928304Z",
    "identifier":  {
                       "type":  "dns",
                       "value":  "win.company.test"
                   },
    "challenges":  [
                       {
                           "type":  "http-01",
                           "url":  "https://pgwy.company.test/acme/orders/cKuv-ie0v9qxJ8h-joZ8Qg/authz/oUpOANAEpeAvJW5I8Gp05Q/http-01",
                           "token":  "YvW2iZCps1sdCW-nR70C_w"
                       },
                       {
                           "type":  "dns-01",
                           "url":  "https://pgwy.company.test/acme/orders/cKuv-ie0v9qxJ8h-joZ8Qg/authz/oUpOANAEpeAvJW5I8Gp05Q/dns-01",
                           "token":  "YvW2iZCps1sdCW-nR70C_w"
                       }
                   ]
}

According to RFC8555 section 8, status is a required field in all challenge objects. So at first glance, I’d say my client is adhering to the spec and the user should get the Nexus CM vendor to fix their implementation. However, the user claims other clients such as certbot don’t seem to have a problem with it.

So I’m left wondering. Was challenge status not always a requirement in earlier drafts of the spec? What do clients like certbot do in this situation? Do they just assume all challenge status fields match the parent authorization’s status? Should I alter my client to more gracefully deal with non-compliant servers in general?

2 Likes
2

Looking at that section of the spec only, it seems that the status field was optional until draft-ietf-acme-acme-02, and then became required. That is a very long time ago, though. Way before ACME v2 was a thing.

Certbot looks at the authz status field (auth_handler.py only looks at authzr.body.status), and I would guess that is why it doesn’t crash on Nexus.

This looks like a spec compliance issue in Nexus to me, but I guess you could just look at the authz status instead as a workaround.

4 Likes
3

Thanks @_az! I only started writing my client when ACME v2 became a thing. So I don’t have any knowledge of how different v1 was, but is it plausible this CA is only implementing v1? And if so, might there be additional issues I’d need to accommodate if I were to workaround this issue?

2 Likes
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.