[Bug]: cannot import root certificate from `mkcert`

[userid0x0]

Steps to Reproduce

https://github.com/userid0x0/step-ca-mkcert-problem

Your Environment

• OS - Linux using Docker
• step-ca Version
  

        "Id": "sha256:9c6a2d85468e45cd6c44bf39241a1781230b259954644d34c724cce948747b84",
        "RepoTags": [
            "smallstep/step-ca:latest"
        ],
        "RepoDigests": [
            "smallstep/step-ca@sha256:a8308bddba866f5fccb2740c8bb2e5dea8cdde4b5856058539a7f5170894a9c0"
        ],
        "Parent": "",
        "Comment": "buildkit.dockerfile.v0",
        "Created": "2024-11-20T20:05:39.162646425Z"

Expected Behavior

Step-Ca can import a root certificate from mkcert.

Actual Behavior

Error message tls: failed to verify certificate: x509: too many intermediates for path length constraint on Traefik & Step-CA side.

Additional Context

If I skip the --root & --key parameters to import the existing certificate step-ca works as expected.
Of course it generates a new root certificate.

Contributing

No response

[hslatman]

Hey @userid0x0,

It looks like mkcert will always create a root certificate with a max path length of zero, with it being enforced as zero (MaxPathLenZero): https://github.com/FiloSottile/mkcert/blob/master/cert.go#L327-L348. This means that the root that is created by mkcert is not suitable for a PKI that involves an additional intermediate, which is what step-ca uses by default.

The error you're seeing is the result of certificate path validation (correctly) determining that the chain is not valid: if you create an intermediate CA from a root CA that has a maximum path length set of 0, then the chain is invalid. Generally path validation is done by TLS clients, although servers can do parts of it to in order to prevent potential misconfigurations. In this case the fact that the CA doesn't work with the mkcert root is not the actual bug, but I can understand you conclusion, and I think we could improve a bit by adding a check that the CA has a valid chain to start with. We should either prevent the CA from starting using an invalid chain, don't allow an invalid configuration to be created in the first place, or a combination of both.

If you really want to use the mkcert generated root, a potential workaround would be to first generate a new step-ca configuration, including a new root and intermediate, and to then replace both the root and intermediate with your mkcert certificate and key. Note that this is not a fully supported operation mode, and it would require the mkcert root certificate and key to be always available when the CA is running (i.e. "online"; generally step-ca has an "offline" root).

[userid0x0]

Hi @hslatman ,
thank you very much for the detailed answer. For me (a non openssl expert) it was the easiest to enable TLS in my homelab using mkcert. For that reason I tried to reuse my mkcert root CA.

Feel free to close the issue - I will mark my Github example as 'non working'/'wrong' just to be sure nobody tries to reproduce it.

[hslatman]

I'll keep it open for a bit, because I'd like to add some additional guard rails to our CA initialization and/or startup process so that this case surfaces earlier in the process.