Detailed Steps to implements CRL logic ?

[sc-sityad]

Discussed in https://github.com/smallstep/certificates/discussions/1422

^{Originally posted by **sc-sityad** June 7, 2023} - How to get CRL http URL to store the ca.url. I followed all the steps mentioned in ENABLE ACTIVE REVOCATION ON YOUR INTERMEDIATE CA. - I have enable the crl in ca.json `"crl": { "enabled": true, "generateOnRevoke": true }` - I create a certificate using root_ca.crt using following command `step ca certificate emqx emqx.crt emqx.key --kty RSA`. - Now I want to revoke it using comand. `step ca revoke --cert emqx.crt --key emqx.key`. - The certificate is revoked but how the CRLs is updated in this case, I am not able to understand. - What is the use of index.txt, Do I have to manually add the revoked data in that file? - How the whole CRL support works in this case?

[maraino]

We need to add docs for this. I can give you some points, but where are the steps you mention?

• Your configuration is the right one.
• The CRL is available at https://<ca-url>/1.0/crl. You can inspect it with the following command:

  step crl inspect --ca $(step path)/certs/root_ca.crt https://localhost:9000/1.0/crl

• With "generateOnRevoke": true as soon as you revoke a certificate (either using --cert/--key flags or using the serial number, you should see the serial number in the CRL.
• Without that option, the CRL is automatically regenerated every 16h and with a validity of 24h. You can change those with renewPeriod and cacheDuration. All the options are here: https://github.com/smallstep/certificates/blob/96dcab88ac900ddcbf7ff966a6189ad3676b3d78/authority/config/config.go#L88-L94
• The CRL has its own CRL in an extension called Issuing Distribution Point by default, it will use your first DNS Name, but you can configure it using idpURL. Remember to add the full URL, e.g., "idpURL": "https://ca.internal/1.0/crl".
• There's nothing that you need to do with an index.txt. Before we had support for CRLs, you were able to use OpenSSL to create the CRL, and that index.txt was the OpenSSL database of revoked certificates.
• You will get an error if you're trying to renew a revoked certificate.
• The CRL doesn't do anything on its own, the clients of the certificates can check it to see if a certificate has been revoked. But with short-live certificates, this is less important.
• The certificates that CA signs won't have, by default, the CRL distribution points in the certificate. To add it you need to set a certificate template at the provisioner level. The ca.json will look like this:

  {
  "root": "/path/step/certs/root_ca.crt",
  "...": "...",
  "provisioners": [
   {
      "type": "...",
      "...": "...",
      "options": {
        "x509": {
           "templateFile": "/path/step/templates/leaf.tpl"
        }
      }
   }
  ]
  }

  And that leaf.tpl needs a crlDistributionPoints property, for example:

  {
  "subject": {{ toJson .Subject }},
  "sans": {{ toJson .SANs }},
  {{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
  "keyUsage": ["keyEncipherment", "digitalSignature"],
  {{- else }}
  "keyUsage": ["digitalSignature"],
  {{- end }}
  "extKeyUsage": ["serverAuth", "clientAuth"],
  "crlDistributionPoints": ["https://ca.internal/1.0/crl"]
  }

  This way, if the clients can download and check the CRL, a regular client won't do it by default.

[sc-sityad]

hi @maraino

• Can I have the same IDPurl and https://<ca-url>/1.0/crl some thing like https://localhost:8081/1.0/crl ?

[hslatman]

@sc-sityad yes, that's the usual configuration. Using that, the issued leaf certificate will contain the IDP url in the template, so that a system looking to verify the CRL can look it up where it's hosted by the CA. It's configurable, because there's also ways to host the CRL in a different location, not hosted by the CA itself.

I noticed you also asked about the CRL being available on HTTP instead of HTTPS, but removed that part of the question. I assume you found the "insecureAddress" setting, which will make it become available on HTTP?

[sc-sityad]

Yes, I got that.

• If I want to use the CRL hosted by the CA. It is safe and secure right.
• If I want to host the CRL in different location like http://localhost:80/crl. So I need to change the only IDP url right? or I have to some change more in ca.json or template.leaf etc other than IDP.
• When I run this step crl inspect --insecure http://localhost:80/crl I got 404 error because there is nothing on this path. How do I initialise the crl file in der format so that I put the crl.der file in path and get started.
• After changing the IDP url I still ge the revoked status in https://localhost:8081/1.0/crl hosted by the CA. I want the status in new url.

[hslatman]

Yes, I got that.

* If I want to use the CRL hosted by the CA. It is safe and secure right.

It's OK to let the CA host it.

* If I want to host the CRL in different location like `http://localhost:80/crl`. So I need to change the only IDP url right? or I have to some change more in ca.json or template.leaf etc other than IDP.

If you want to change the IDP URL, you'll need to ensure that its address resolves to the host the CA is running on, as well as for the path to match the endpoint the CA (or another system) hosts the CRL. You'll need to ensure the value matches what ends up in the leaf certificate, as mentioned before.

* When I run this `step crl inspect --insecure http://localhost:80/crl` I got 404 error because there is nothing on this path. How do I initialise the crl file in der format so that I put the crl.der file in path and get started.

Did you already revoke a certificate? If not, the file does not exist.

* After changing the IDP url I still ge the revoked status in `https://localhost:8081/1.0/crl` hosted by the CA. I want the status in new url.

The IDP URL ends up being recorded in the CRL. It doensn't change where the CRL is hosted. If you let the CA host it, it has to match the existing CRL endpoint /1.0/crl and has to resolve to the CA host.

[sc-sityad]

Ok thanks I will use the CRL hosted by the CA.

[sc-sityad]

Hi, @hslatman If I want to clear the CRL revoked certificate list how can I do that. The CRL url is https://localhost:8081/1.0/crl ?

[maraino]

The revoked certificates will automatically disappear when they expire, and the crl is regenerated. Removing it from the database without destroying it is possible but it is "hard", you might need to make a program for it.

[sc-sityad]

@maraino

• I am facing an issue while enable crl on dev server with ssl . I am getting this error error downloading crl: Get "https://localhost:8585/1.0/crl": x509: certificate signed by unknown authority while running command step crl inspect --ca $(step path)/certs/root_ca.crt https://localhost:8585/1.0/crl.
• In local it works fine. In the logs it shows 2023/07/12 07:39:49 net/http/server.go:3228: http: TLS handshake error from 127.0.0.1:42858: remote error: tls: bad certificate

[hslatman]

@sc-sityad did you run step ca bootstrap (--install) on the server you're running that command? It sounds like the root isn't trusted on the system you're checking the CRL from.

You can also configure the CA to serve the CRL on an HTTP endpoint through the insecureAddress. That way you won't have issues with HTTPS when requesting the CRL.

[sc-sityad]

Yes, now its working But I want to know one thing I have installed step-ca, step on dev server, the link is https://{dev-ip}:8585/1.0/crl and I want to use the CRL link in uat server while running mqtt broker. I am not able to access this crl link from UAT server.

[hslatman]

@sc-sityad you'll need to install step on your UAT server too, and do step ca bootstrap (--install) there too for the CA root to be trusted. With --install, the root gets trusted by other tools on the system that use the system roots as their trust bundle.

Besides that, you'll need to ensure that the CA can be reached from the other machine(s) too. That means the port must be open, the UAT server must have a route to the network, etc.

If you need a strict separation of "trust domains" for your dev vs. UAT environment, then you may want to run another CA for your UAT environment (assuming you're referring to UAT as user acceptance testing).

[rk-c]

I'm not sure that I fully understand. The Documentation says: "step-ca does not currently support active revocation mechanisms like a Certificate Revocation List (CRL)" Do I understand correctly that the active revocation is supported?

[Bartosz-lab]

Hi, I see that the endpoint https://<ca-url>/1.0/crl uses the HTTPS protocol, but as far as I know, the recommended practice is to use HTTP for CRL lists.

Edit: I found the insecureAddress config option in config/ca.json, which serves that endpoint over HTTP.

[hslatman]

I'm not sure that I fully understand. The Documentation says: "step-ca does not currently support active revocation mechanisms like a Certificate Revocation List (CRL)" Do I understand correctly that the active revocation is supported?

Yes, it's supported and contributed by the community.