Sudden urn:ietf:params:acme:error:unauthorized Errors Occurring

Thank you for all of your responses! Your comments helped through the investigation.

The :443 in the domain was being used to evaluate the domain in our backend system which caused the main issue. The CAA issue was on my end from some initial troubleshooting but has been corrected.

The only remaining question is: where is the :443 originating from in the Acme Challenge url?

4 Likes

From you :slight_smile: The Let's Encrypt server always starts an HTTP challenge with an HTTP URL. You are redirecting that request to HTTPS:// with the :443

You can reproduce with curl

curl -I http://woollastudio.com/.well-known/acme-challenge/SampleToken

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Location: https://woollastudio.com:443/.well-known/acme-challenge/SampleToken
Content-Length: 264
Date: Fri, 06 May 2022 18:28:45 GMT
4 Likes

The Host header is allowed to include a port: RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. The RFC doesn't say under what conditions it should or must be sent.

MDN says:

If no port is included, the default port for the service requested is implied (e.g., 443 for an HTTPS URL, and 80 for an HTTP URL).

Note that that only goes one direction. AFAICT it's allowed for clients to send Host: example.com or Host: example.com:443, at their discretion. And depending on implementation details it's quite possible servers would respond differently based on that.

Some real-life Let's Encrypt users on lighttpd ran into issues with extraneous port numbers being sent, back in 2015:

5 Likes

Based on the above, I believe it's the case that Go's net/http library won't strip :443 (or :80) from hosts in URLs. I quickly peeked at the source for net/http and that seems to be the case, though I haven't confirmed with a test.

That means if you redirect to https://example.com:443/, your server will see Host: example.com:443. If you redirect to https://example.com/, your server will see Host: example.com. I believe this is a valid implementation choice for Go, even though curl and possibly other implementations seem to differ.

As @MikeMcQ says, the kinda-superfluous port in the redirect URL is probably an issue with your code that redirects to HTTPS. Perhaps that's a RewriteRule in your Apache config?

It's worth noting, there are two possible fixes: your system that looks up challenges could detect and handle port numbers; or you could change your redirect logic not to add the :443.

I'm still not sure what could have changed to trigger this issue. AFAIK the way net/http handles port numbers hasn't changed recently. We did upgrade from Go 1.17 to Go 1.18 recently, but looking at the release notes there are no relevant changes.

9 Likes

Thanks, @jsha! I didn't know that or didn't remember it.

5 Likes

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