Edit this page | Blame

uACME Error: "urn:ietf:params:acme:error:unauthorized"

Tags

  • status: closed, completed
  • priority: high
  • type: bug
  • assigned: fredm
  • keywords: uacme, certificates, "urn:ietf:params:acme:error:unauthorized"

Description

Sometimes, when we attempt to request TLS certificates from Let's Encrypt using uacme, we run into an error of the following form:

uacme: polling challenge status at https://acme-v02.api.letsencrypt.org/acme/chall/2399017717/599167439271/jFB2Pg
uacme: challenge https://acme-v02.api.letsencrypt.org/acme/chall/2399017717/599167439271/jFB2Pg failed with status invalid
uacme: the server reported the following error:
{
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "128.xxx.xxx.xxx: Invalid response from http://sparql.genenetwork.org/.well-known/acme-challenge/N-P-mhiK04c-Iophbem4iFYsaB
yeaxeSyXHSijx3e6k: 404",
    "status": 403
}
uacme: running /gnu/store/zwqavgjqyk0f0krv8ndwhv3767f6cnx1-uacme-hook failed http-01 sparql.genenetwork.org N-P-mhiK04c-Iophbem4iFYsaBy
eaxeSyXHSijx3e6k N-P-mhiK04c-Iophbem4iFYsaByeaxeSyXHSijx3e6k.9dRdXFhCbqeDGWYndRd_hTh920rplmy-ef-_aLgjJJE
uacme: failed to authorize order at https://acme-v02.api.letsencrypt.org/acme/order/2399017717/438986245271

From the above error, we note that the request for the "/.well-known/..." path fails with a 404 code: Why.

Let's try figuring it out; connect to the running container:

$ sudo guix container exec 89086 /run/current-system/profile/bin/bash --login
root@sparql /# cd /var/run/acme/acme-challenge/
root@sparql /var/run/acme/acme-challenge# while true; do ls; sleep 0.5; clear; done

In a separate terminal, connect to the same container and run `/usr/bin/acme renew`.

The loop we created to list what files are created in the challenge directory outputs the file

root@sparql /var/run/acme/acme-challenge# while true; do ls; sleep 0.5; clear; done
Rm7qCec3naVvqPldGSGI9W4i9AceW0X3MUNSAbC7SVE
Rm7qCec3naVvqPldGSGI9W4i9AceW0X3MUNSAbC7SVE
⋮

but we are still getting the same error:

uacme: challenge https://acme-v02.api.letsencrypt.org/acme/chall/2399017717/599184604221/7mTNdA failed with status invalid
uacme: the server reported the following error:
{   
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "128.169.5.101: Invalid response from http://sparql.genenetwork.org/.well-known/acme-challenge/Rm7qCec3naVvqPldGSGI9W4i9AceW0X3MUNSAbC7SVE: 404",
    "status": 403
}
uacme: running /gnu/store/zwqavgjqyk0f0krv8ndwhv3767f6cnx1-uacme-hook failed http-01 sparql.genenetwork.org Rm7qCec3naVvqPldGSGI9W4i9AceW0X3MUNSAbC7SVE Rm7qCec3naVvqPldGSGI9W4i9AceW0X3MUNSAbC7SVE.9dRdXFhCbqeDGWYndRd_hTh920rplmy-ef-_aLgjJJE
uacme: failed to authorize order at https://acme-v02.api.letsencrypt.org/acme/order/2399017717/438997397751

meaning that somehow, nginx is not able to serve up this file.

Discovered Cause: 2025-10-20

There are 2 layers of nginx, the host nginx, and the internal/container nginx.

The host nginx was proxying directly to the virtuoso http server rather than proxying to nte internal/container nginx. This led to the failure because the internal/container nginx handles the TLS/SSL certificates for the site. The host nginx should have offloaded the handling of the TLS/SSL certificates to the internal/container nginx, but since it was not going through the internal nginx, that led to the failure.

A simile of the error condition and the solution are in the sections below:

Error Condition: Wrong proxying

In host's "nginx.conf":

⋮
 proxy_pass http://localhost:<virtuoso-http-server-port>;
⋮

In internal/container "nginx.conf":

⋮
 proxy_pass http://localhost:<virtuoso-http-server-port>;
⋮

Solution/Fix

In host's "nginx.conf":

⋮
 proxy_pass http://localhost:<container-nginx-http-port>;
⋮

In internal/container "nginx.conf":

⋮
 proxy_pass http://localhost:<virtuoso-http-server-port>;
⋮
(made with skribilo)