ACME directory returns 404 even through in providers

[cromefire]

When I try to fetch the directory URL the server always returns 404:

Request to /acme/<provisioner>/directory

$ curl -kv -H "Accept: application/json" https://<domain>:9000/acme/crf_acme/directory --resolve <domain>:9000:10.37.48.2 -H "Host: acme.i.cromefire.de"
* Added <domain>:9000:10.37.48.2 to DNS cache
* Hostname <domain> was found in DNS cache
*   Trying 10.37.48.2:9000...
* Connected to <domain> (10.37.48.2) port 9000
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=<redacted>
*  start date: May 10 23:14:00 2025 GMT
*  expire date: May 11 23:15:00 2025 GMT
*  issuer: C=DE; O=Cromefire_; OU=Security; CN=CRF ACME EC R1; emailAddress=<redacted>
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://<domain>:9000/acme/crf_acme/directory
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: <domain>]
* [HTTP/2] [1] [:path: /acme/crf_acme/directory]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: application/json]
> GET /acme/crf_acme/directory HTTP/2
> Host: <domain>
> User-Agent: curl/8.5.0
> Accept: application/json
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 404 
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< x-request-id: 0e4e363a-db3e-456a-b1c3-0b0b5f173ab9
< content-length: 19
< date: Sat, 10 May 2025 23:24:25 GMT
< 
404 page not found
* Connection #0 to host <domain> left intact

As you can see I already spoofed the DNS domain name (after trying just the plain IP and some other permutations) in case that was the issue (can't use the real one yet as the reverse proxy can get an ACME cert...), but it did't help and it should be configured to accept 10.37.48.2 as well (and it successfully added 10.37.48.2 to it's cert at least).

So I went an quadruple checked the provisioners, but /providers shows it being correctly configured:

{
  "provisioners": [
    {
      "type": "ACME",
      "name": "crf_acme",
      "forceCN": true,
      "caaIdentities": [
        "<domain>"
      ],
      "challenges": [
        "http-01",
        "dns-01",
        "tls-alpn-01"
      ],
      "claims": {
        "enableSSHCA": true,
        "disableRenewal": false,
        "allowRenewalAfterExpiry": false,
        "disableSmallstepExtensions": false
      },
      "options": {
        "x509": {},
        "ssh": {}
      }
    }
  ],
  "nextCursor": ""
}

I also tried using acme as name already, but nothing worked.

Am I missing something really obvious here or is there some bug in the latest version or something? I'm using the HSM build here (in docker) with TPM 2.0 and it is able create a valid certificate for it's built-in web server successfully (as can be seen above, "CRF ACME EC R1" is the correct intermediate CA) and isn't logging anything after startup.

Maybe some more helpful error message like provider '<url segment>' not found / of wrong type would be helpful as well to help with debugging.

I found the documentation of the URL here: https://smallstep.com/docs/tutorials/acme-protocol-acme-clients/#directory-url

[cromefire]

It seems like the DB has to be enabled, but there's no warning or anything that the ACME provisioner has been disabled (and it's still listed in the provisioners)...

There's already a bug for that which would be very useful to fix: #2102