[Bug]: Error on Windows curl CRYPT_E_NO_REVOCATION_CHECK

[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 https://github.com/icing/mod_md/issues/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.

[muuvmuuv]

Yes, the mod_md change will fix it, I will check it once it has a release-build.

Nevertheless, I have also enabled CRL on our step-ca server to give it a try and to just avoid such errors in the future. I have followed the steps here, but still have this error popping. I use HTTPS as the protocol in the templates, as I don't want to allow insecure access to that server. Calling curl on that endpoint works and downloads that CRL file, but the Windows machine's curl does get the same error. The intermediate certs are generated again and I can also call crl inspect successfully on the Windows machine:

[hslatman]

You may need to follow this instead: https://smallstep.com/docs/step-ca/certificate-authority-server-production/#enable-crl-for-leaf-certificates.

I don't know if Windows will accept/use HTTPS URLs for CRLs.

[muuvmuuv]

I enabled both ofc, just didn't want to link both ^^ I will test again with unsecure port. The docs btw should also include that the port is mandatory when using http protocol when no proxy is used and the port is something like 9001.

[hslatman]

The docs btw should also include that the port is mandatory when using http protocol when no proxy is used and the port is something like 9001.

Which port? The HTTP port for CRLs? It's not mandatory, as not everyone uses CRLs, and there are also systems that support CRLs via HTTPS.

[muuvmuuv]

But I wont get the crl response from something like http://ca.ecample.com/1.0/crl if the unsecure port ist 9001.

Anyway I still cant get it to work even with curl on Windows. Do I need to regenerate the root_ca? I just regenerated the intermediate as described in the docs. The acme and jwk provisioners both have the leaf template but they arent important at this step since I cant even curl the directory path so something before that must be wrong

[muuvmuuv]

Ok, this is interesting, even with explicitly giving him the ca it fails:

PS C:\Users\admin> curl https://ca.xxxx.de/ --cacert .\.step\certs\root_ca.crt --verbose
* Host ca.xxxxxxx.de:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.xxx.x
*   Trying 192.168.xxx.x:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* schannel: added 1 certificate(s) from CA file '.\.step\certs\root_ca.crt'
* schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
* closing connection #0
curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

[muuvmuuv]

Ok, I think I found the error cause, when I do a step certificate inspect https://ca.xxxxx.de on the client and step-ca server I see that the intermediate certificate in /etc/step-ca/certs has a

            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://ca.xxxx.de:9426/1.0/crl

but the windows client has none. So I guess step-ca picks the wrong one somewhere for its server?

[muuvmuuv]

Today I have created a new server which I have added a Caddyserver and now I am getting "error decoding template: illegal base64 data at input byte 9". Haven't had that before so I guess that also comes from the crl setup part. I have now followed the docs again 1:1 without luck. Is it correct that template will be inlined into ca.json after --x509-template? What is the reason for that, instead of the actual file path in /templates/?

[lumarel]

I had the same, or a similar issue, and wanted to report how we solved the issue:

• we are centrally serving the CRL file (beside the public keys) on a seperate webserver
• the CRL file is in this case served via a proxy rewrite http://crl.example.com/issueca.crl -> https://issueca.example.int/crl
• further we use a custom leaf certificate template with "crlDistributionPoints": ["http://crl.example.com/issueca.crl"], "issuingCertificateURL": "http://crl.example.com/issueca.crt" set
• finally, "crl.enabled": true, "crl.idpURL": "http://crl.example.com/issueca.crl" has to be set

so, only after having matching attributes in the CRL file and in the leaf certificates SChannel started to behave