[Bug]: Error on Windows CRYPT_E_NO_REVOCATION_CHECK root_ca not in cert store

[muuvmuuv]

Steps to Reproduce

I ran the bootstrap command with --install on a Windows 10 and 11 but cannot find the trusted certificate in the trusted computer store nor does a curl command respond without an error. This results in Apache not being able to call /directory to our step-ca server. The command itself reports the installation succeeded.

Your Environment

Windows 10 Pro 22H2
Windows 11 Pro 24H2
Smallstep CLI/0.28.2 (windows/amd64)
Release Date: 2024-11-20T19:14:16Z

Expected Behavior

.

Actual Behavior

curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - Die Sperrfunktion konnte keine Sperrprüfung für das Zertifikat durchführen.

Additional Context

No response

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]

Have you checked the system certificate store as well as the user certificate store?

I assume the error is shown when a curl request is made towards https://your-step-ca, not during installation? Did you enable CRL generation?

[muuvmuuv]

Found it at the user certificate store, the computer cert store is empty. I don't know what a system cert store is.

Yeah, the curl fails, not the installation itself. It works on our Debian VM's.

How do I tell curl to use the cert store? I tried the bootstrap with and without admin permissions. No difference. Also curl with --native-ca.

We don't have a CRL set up, we only use step-ca internally for our dev-nodes. Is that required? I thought it's just for security for active revocation if the intermediate gets compromised.

[muuvmuuv]

Adding the root ca to both trusted stores also does not work, even after restart, with and without admin permssions.

[hslatman]

It sounds like the root certificate was installed correctly, so that part is down.

The CRYPT_E_NO_REVOCATION_CHECK error is a different issue. Windows is looking for a CRL endpoint, but if you have not configured that to be part of your certificate, it'll fail. You can run the curl command with --ssl-no-revoke to disable the CRL check, and then it should succeed.

Then onto the Apache server: is that also running on Windows, and under the same user?

[muuvmuuv]

Great, --ssl-no-revoke works.

Yes, the Apache runs on Windows as the same user as I used for the bootstrap command.

[muuvmuuv]

Hm, OK, seems Apache has a similar option with SSLCARevocationCheck. I set it to none but it still gives me errors.

[hslatman]

SSLCARevocationCheck

I see that it might be addressed by supporting that in mod_md based on what's in icing/mod_md#361? That would be great 🙂

You could enable CRL support, and add the distribution point to your certificate template. That way you shouldn't have the error, and the CRL check would still be performed, albeit with an empty CRL (in general). See the crl option at https://smallstep.com/docs/step-ca/configuration/#configuration-options and template options at https://smallstep.com/docs/step-ca/templates/#arbitrary-x509-extensions.

There's not a whole lot more that we can do on the CA side: it's some behavior specific to cURL (and other tools using SChannel) on Windows. One thing that we could do is address #1846, which would add the CRL distribution point to the CA leaf certificate, but that doesn't solve it for all certificates issued, which has to be configured through a template.