x/crypto/acme: WaitOrder returns an order without a URI

[jameshartig]

Go version

go version go1.24.2 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/user/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/user/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1406465788=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/user/repos/backend/vigilante/go.mod'
GOMODCACHE='/home/user/go/pkg/mod'
GONOPROXY='gitlab.com/levenlabs'
GONOSUMDB='gitlab.com/levenlabs'
GOOS='linux'
GOPATH='/home/user/go'
GOPRIVATE='gitlab.com/levenlabs'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/home/user/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I haven't quite narrowed down the exact state that Let's Encrypt is in (though I believe "ready") for the order but when WaitOrder is called it can return a order object that doesn't have a URI.

What did you see happen?

The URI on the order is empty but the order is otherwise okay.

What did you expect to see?

I expected the URI to always be there. Should we be filling in the URI from the URI used to fetch it if it wasn't returned in the Location header?

[gabyhelp]

Related Issues

• x/crypto/acme: CreateOrderCert returning Order's status ('valid') is not acceptable for finalization #42278
• x/crypto/acme: CreateOrderCert should not return whilst order is (still) Ready #52597

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[sigmavirus24]

The URI on the order is empty but the order is otherwise okay.

When you say this, do you have logs or something else that show the other fields populated?

Is there additional context you can give around what you're seeing? This is a bit vague

[jameshartig]

After further debugging, when you fetch a Order via a GET Let's Encrypt does NOT return a Location header. It seems like the acme client assumes that it does.

Here are the headers from the order GET inside WaitOrder:

map[Cache-Control:[public, max-age=0, no-cache] Content-Length:[361] Content-Type:[application/json] Date:[Wed, 07 May 2025 17:34:21 GMT] Link:[<https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"] Replay-Nonce:[4Z2vPyrtwm7DQAHvCm2rTLFGCdoRtTob-bY8hwwVYRvEyPSs5kw] Server:[nginx] Strict-Transport-Security:[max-age=604800] X-Frame-Options:[DENY]]

[sigmavirus24]

Seems this should be a bug against let's encrypt as RFC 8555 specifics that header on that endpoint iirc. I can grab references when I get back to a laptop

[sigmavirus24]

From Section 7.4 https://www.rfc-editor.org/rfc/rfc8555#section-7.4

   If a request to finalize an order is successful, the server will
   return a 200 (OK) with an updated order object.  The status of the
   order will indicate what action the client should take:

   o  "invalid": The certificate will not be issued.  Consider this
      order process abandoned.

   o  "pending": The server does not believe that the client has
      fulfilled the requirements.  Check the "authorizations" array for
      entries that are still pending.

   o  "ready": The server agrees that the requirements have been
      fulfilled, and is awaiting finalization.  Submit a finalization
      request.

   o  "processing": The certificate is being issued.  Send a POST-as-GET
      request after the time given in the Retry-After header field of
      the response, if any.

   o  "valid": The server has issued the certificate and provisioned its
      URL to the "certificate" field of the order.  Download the
      certificate.

   HTTP/1.1 200 OK
   Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
   Link: <https://example.com/acme/directory>;rel="index"
   Location: https://example.com/acme/order/TOlocE8rfgo

   {
     "status": "valid",
     "expires": "2016-01-20T14:09:07.99Z",

     "notBefore": "2016-01-01T00:00:00Z",
     "notAfter": "2016-01-08T00:00:00Z",

     "identifiers": [
       { "type": "dns", "value": "www.example.org" },
       { "type": "dns", "value": "example.org" }
     ],

     "authorizations": [
       "https://example.com/acme/authz/PAniVnsZcis",
       "https://example.com/acme/authz/r4HqLzrSrpI"
     ],

     "finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",

     "certificate": "https://example.com/acme/cert/mAt3xBGaobw"
   }

pages 48 and 49 in particular.

Nothing explicitly requires the Location header, but I'd argue that it is intended to be there and a bug that it's missing from Let's Encrypt/Boulder

[seankhliao]

I don't think we should fill in a value if it isn't in the response.
The user already has the information since they provide the value in the first place.
If there is a bug, it would be with https://github.com/letsencrypt/boulder

[sigmavirus24]

As a follow-up to this, I went looking through Errata and found https://www.rfc-editor.org/errata/eid5979 from 2020 that was held for document update. It hasn't been verified, so there may be merit to this bug. But, I have to say that I agree with the Errata report there.

[sigmavirus24]

I filed letsencrypt/boulder#8197 as I don't feel this is controversial either way (for this client to reuse the specified URL or for Boulder to fix it).