[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.

[cmjdiff]

Hi @hslatman,

So in this particular case, the client was being run on the same host as the CA, so if the CA can't ping itself then that would be a much bigger problem. Thankfully, it can indeed ping itself. I eventually managed to sign the CSR using offline mode, but this is clearly less than ideal.

There does not appear to be an issue with name resolution itself, as other devices on the network are able to successfully obtain certificates. Hence my initial comment about needing to determine what address it's trying to reach in order to establish why it's failing.

[hslatman]

On what port are you running the CA? And did the CSR contain the domain name and/or IP pointing to that same machine?

I agree that the CA could do a much better job in terms of showing what goes wrong, especially when ACME is in use. There have been issues created for that before, but so far we haven't had time to prioritize those. I have some ideas for quick wins, so maybe we can make some progress on that soon.

[cmjdiff]

The CA is running on port 8443, and the subject on the CSR was the machine I needed to sign the certificate for, since it wasn't able to obtain one itself. Though if the CA was trying to reach out to that host, rather than the one where the commands were running, that means:

• this was just reflecting whatever issue was preventing the original machine from obtaining a certificate; and
• the CA was possibly trying to solve the challenges on that original machine, rather than from where the client was running as the document suggests.

To be clear, I can successfully resolve and ping, as well as connect to on both 80 and 443, the intended subject from the machine running the CA.