[Bug]: step ca sign with local challenge: "The server could not connect to validation target"

[cmjdiff]

Steps to Reproduce

The documentation states that a CSR can be signed locally (i.e. without connecting to a remote subject) with the following:

Sign a CSR using the step CA ACME server and a standalone server to serve the challenges locally (standalone mode is the default):

$ step ca sign foo.csr foo.crt --provisioner my-acme-provisioner

There does not appear to be any way to produce debug info that might prove useful, such as the precise address it's trying to connect to and why it fails. Setting STEPDEBUG=1 doesn't return anything useful beyond a stack trace on the client.

The ACME provisioner is accessible from the client, and the certificate the provisioner uses is trusted. Actual domain names are redacted below - this is internal infra and the names all resolve internally.

Your Environment

• OS - Debian 12.7
• step-ca Version - 0.28-1

Expected Behavior

Provided CSR signed and certificate produced

Actual Behavior

✔ Provisioner: acme (ACME)
Using Standalone Mode HTTP challenge to validate [SAN] ........... Error!

Unable to validate challenge: The server could not connect to validation target 

Additional Context

Config:

{
        "root": "/etc/step-ca/certs/root-ca.crt",
        "federatedRoots": null,
        "crt": "/etc/step-ca/certs/acme-ca.crt",
        "key": "/etc/step-ca/secrets/acme-ca.key",
        "address": ":8443",
        "insecureAddress": "",
        "dnsNames": [
                "acme.example.com"
        ],
        "logger": {
                "format": "text"
        },
        "db": {
                "type": "badgerv2",
                "dataSource": "/etc/step-ca/db",
                "badgerFileLoadingMode": ""
        },
        "authority": {
                "provisioners": [
						{
                                "type": "ACME",
                                "name": "acme",
                                "claims": {
                                    "maxTLSCertDuration": "2160h",
                                    "defaultTLSCertDuration": "2160h"
                                }
                        }
                ],
                "template": {},
                "backdate": "1m0s"
        },
        "tls": {
                "cipherSuites": [
                        "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
                        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
                ],
                "minVersion": 1.2,
                "maxVersion": 1.3,
                "renegotiation": false
        }
}

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[hslatman]

Hey @cmjdiff, yes, signing a CSR should be possible using the ACME flow. The CA will always reach out to the domain/IP requested in the CSR (except for DNS challenges), because that's how the ACME protocol works.

In general, there's a few things to verify in case ACME validation fails. Can the ACME client machine be pinged from the CA server? Can you check that the firewall allows connections on port 80 (and 443) to the machine running the ACME client (the cli in this case)? In some cases you may need to start the CA with --resolver <dns-resolver> to make it use a different resolver to correctly resolve local domains.