From af76a07ef9ebeba666a9024846c4ee92c8a6d440 Mon Sep 17 00:00:00 2001 From: Lukasz Lobocki <125857607+lukasz-lobocki@users.noreply.github.com> Date: Tue, 6 Aug 2024 09:59:56 +0200 Subject: [PATCH 1/8] Add direct built-in support for CRL. Update certificate-authority-server-production.mdx --- step-ca/certificate-authority-server-production.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index 3ba96422..17bf92b6 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -187,8 +187,9 @@ So, you're stuck having to rotate your root CA too, and that's a much bigger pro To avoid this scenario, you can use _active revocation_ on your intermediate CA certificate, making it possible to immediately revoke a compromised intermediate. -While `step-ca` doesn't directly support active revocation mechanisms like Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP), -you can independently manage your own CRL if you like. +While `step-ca` does directly support Certificate Revocation Lists (CRLs) it does not directly support Online Certificate Status Protocol (OCSP). + +In order to enable. #### Create an intermediate CA with a CRL distribution endpoint From 3f8b176f012c4dcba0b2ca26104920c51dad57ce Mon Sep 17 00:00:00 2001 From: lukasz-lobocki Date: Tue, 6 Aug 2024 10:27:02 +0200 Subject: [PATCH 2/8] Change crl management to use built-in distribution point. --- ...ertificate-authority-server-production.mdx | 90 +++++++++---------- 1 file changed, 42 insertions(+), 48 deletions(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index 17bf92b6..35033d32 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -187,9 +187,7 @@ So, you're stuck having to rotate your root CA too, and that's a much bigger pro To avoid this scenario, you can use _active revocation_ on your intermediate CA certificate, making it possible to immediately revoke a compromised intermediate. -While `step-ca` does directly support Certificate Revocation Lists (CRLs) it does not directly support Online Certificate Status Protocol (OCSP). - -In order to enable. +While `step-ca` does directly support Certificate Revocation Lists (CRLs) it does not directly support Online Certificate Status Protocol (OCSP). In order to enable CRL distribution use the following approach. #### Create an intermediate CA with a CRL distribution endpoint @@ -207,7 +205,7 @@ This setup is more complex than the default `step-ca` PKI, but it offers an insu "maxPathLen": 0 }, "crlDistributionPoints": - ["http://crl.example.com/crl/ca.crl"] + ["http://ca.internal/1.0/crl"] } } ``` @@ -229,59 +227,55 @@ This setup is more complex than the default `step-ca` PKI, but it offers an insu $(step path)/secrets/intermediate_ca_key ``` -2. Create an empty CRL file and sign it with your root CA key: +2. Add the following to `ca.json` file: - ```bash - cat < openssl.conf - [ ca ] - default_ca = CA_default - - [ CA_default ] - default_crl_days = 30 - database = index.txt - default_md = sha256 - EOF - touch index.txt - openssl ca \ - -config openssl.conf \ - -gencrl \ - -keyfile $(step path)/secrets/root_ca_key \ - -cert $(step path)/certs/root_ca.crt \ - -out ca.crl.pem - openssl crl \ - -inform PEM \ - -in ca.crl.pem \ - -outform DER \ - -out ca.crl + ```json + "...", + "insecureAddress": ":9001", + "..." ``` -3. Upload the DER-formatted `ca.crl` file to the distribution point URL you specified in the template. -4. Finally, configure your `step-ca` server to use the intermediate CA you created. + ```json + "...", + "crl": { + "enabled": true, + "idpURL": "http://ca.internal/1.0/crl" + }, + "..." + ``` +3. Enable `crlDistributionPoints` within your default template: - -
- Your CRL will expire, so you will need to generate and push a new empty CRL file regularly. We recommend updating the CRL once two-thirds of its lifetime has elapsed. Configuring automated CRL renewal is beyond the scope of this document. -
- + ``` + { + "subject": {{ toJson .Subject }}, + "sans": {{ toJson .SANs }}, + {{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }} + "keyUsage": ["keyEncipherment", "digitalSignature"], + {{- else }} + "keyUsage": ["digitalSignature"], + {{- end }} + "extKeyUsage": ["serverAuth", "clientAuth"], + "crlDistributionPoints": ["http://ca.internal/1.0/crl"]} + ``` -#### Revoke A Certificate +4. The approach above assumes serving CRL over http. If you use Caddy to proxy the traffic add the following to `Caddyfile` to allow hosts to reach the CRL distribution point over http: -To revoke a certificate, add it to the `index.txt` file before regenerating the CRL file. The format for this CRL database file is: + ``` + # This serves crl over http + http://ca.external { + # Backend connection to step-ca + reverse_proxy http://ca.internal:9001 + } + ``` + +5. Finally, configure your `step-ca` server to use the intermediate CA you created. -- One certificate per line -- Each line is tab-delimited -- The tab-delimited fields are: - 1. **Entry type.** May be `V` (valid), `R` (revoked) or `E` (expired). - An expired certificate may have the type `V` because the type has not been updated. - `openssl ca updatedb` does such an update. - 2. **Expiration datetime.** Format is `yymmddHHMMSSZ`. - 3. **Revokation datetime** and **optional revocation reason**. Must be set for any entry of the type `R`. Format is `yymmddHHMMSSZ[,reason]`. - 4. **Certificate serial number** in uppercase hexidecimal, eg. `804A72D941DB451A0123BA4706446D1F`. - 5. **File name** This doesn't seem to be used, ever, so use the value `unknown`. - 6. **Certificate subject** eg. `CN=Test Intermediate CA,O=Smallstep Labs\, Inc` +6. Once you revoke an x509 certificate, check the CRL served: -Source: [OpenSSL PKI Tutorial](https://pki-tutorial.readthedocs.io/en/latest/cadb.html) + ```bash + step crl inspect --ca $(step path)/certs/root_ca.crt http://ca.internal:9001/1.0/crl + ``` ### Use Templates With Care From 74e38cb57cddec19a68ee4df84fe0b7f127c8d0b Mon Sep 17 00:00:00 2001 From: Carl Tashian Date: Tue, 27 Aug 2024 14:26:55 -0700 Subject: [PATCH 3/8] Updates to the CRL documentation --- ...ertificate-authority-server-production.mdx | 245 +++++++++++------- 1 file changed, 155 insertions(+), 90 deletions(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index 35033d32..a1fff5f4 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -19,7 +19,7 @@ safely and securely in a production environment. - [Avoid Storing Passwords In Environment Variables](#avoid-storing-passwords-in-environment-variables) - [Replace Your Default Provisioner](#replace-your-default-provisioner) - [Use Short-Lived Certificates](#use-short-lived-certificates) - - [Enable Active Revocation On Your Intermediate CA](#enable-active-revocation-on-your-intermediate-ca) + - [Consider Active Revocation](#consider-active-revocation) - [Use Templates With Care](#use-templates-with-care) - [Create a Service User to Run `step-ca`](#create-a-service-user-to-run-step-ca) - [Operational Concerns](#operational-concerns) @@ -163,8 +163,7 @@ You can [configure certificate lifetimes](./configuration.mdx#basic-configuratio
- Short-lived certificates are not a replacement for active revocation using certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP). - Automatic active revocation is not available in step-ca, but you can manually manage a CRL for your CA certificates. See below. + Short-lived certificates are not a replacement for active revocation using certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP). They offer an alternative that's easier to deploy and maintain.
@@ -175,107 +174,173 @@ So do some certificates. But it can be difficult to operationalize such short-lived certificates. -### Enable Active Revocation On Your Intermediate CA +### Consider Active Revocation -The value of a two-tiered PKI is that you can add your root CA certificate to the certificate trust store on all of your nodes, and store your root private key completely offline. -A leaf certificate signed by the CA always comes in a bundle that contains the intermediate CA certificate alongside the leaf certificate. -With this bundle, any client that trusts your root CA can verify the complete chain of trust. +You may require Active Revocation if you need immediate certificate revocation, +or if you are issuing long-lived certificates. +For this purpose, +`step-ca` contains a built-in, +minimalist Certificate Revocation List (CRL) server. + +This section describes how to enable CRL for your intermediate CA and leaf certificates. + + +
+ The support for active revocation in `step-ca` is designed to be minimalistic. + If you need OCSP, check out Smallstep's commercial offerings. +
+ + +#### When To Use Active Revocation? + +The value of a two-tiered PKI is in the decoupling of root and intermediate CAs. +You can add your root CA certificate to the certificate trust store on all of your nodes, +and store your root private key completely offline. +When `step-ca` issues a certificate to a client, +it comes inside a PEM bundle that contains both the intermediate CA certificate(s) and the end entity certificate. +When establishing a TLS connection, +any client that trusts your root CA can use this bundle to verify a complete chain of trust. Now, what if one day your intermediate CA key is compromised? -You could issue a new intermediate using your root CA key, but your old intermediate has a 10 year validity period! -So, you're stuck having to rotate your root CA too, and that's a much bigger project because you have to distribute the new root certificate to everyone and ensure the old one is no longer trusted. -To avoid this scenario, you can use _active revocation_ on your intermediate CA certificate, -making it possible to immediately revoke a compromised intermediate. - -While `step-ca` does directly support Certificate Revocation Lists (CRLs) it does not directly support Online Certificate Status Protocol (OCSP). In order to enable CRL distribution use the following approach. - -#### Create an intermediate CA with a CRL distribution endpoint - -Let's make it possible to revoke your intermediate CA down the road if necessary. -This setup is more complex than the default `step-ca` PKI, but it offers an insurance policy for a compromised intermediate CA. - -1. Create an intermediate CA that includes a CRL endpoint. Save the following template to `intermediate.tpl`: - - ```json - { - "subject": {{ toJson .Subject }}, - "keyUsage": ["certSign", "crlSign"], - "basicConstraints": { - "isCA": true, - "maxPathLen": 0 - }, - "crlDistributionPoints": - ["http://ca.internal/1.0/crl"] - } - } - ``` +You could issue a new intermediate using your root CA key, +but your old intermediate had a 10 year validity period! +So, you're stuck having to rotate your root CA too, +and that may be a big project: +you have to distribute the new root certificate to clients, +and ensure the old one is no longer trusted. - You'll need this template to manually create your intermediate CA. - The CRL endpoint here should be an HTTP URL; the CRL file itself is signed. - The CRL will be a static file, so you you might choose an object storage or CDN endpoint here. - - Use the template to create your intermediate CA. You will need your root CA certificate and key: - - ```bash - $ step certificate create \ - --template intermediate.tpl \ - --ca $(step path)/certs/root_ca.crt \ - --ca-key $(step path)/secrets/root_ca_key \ - --not-after 87660h \ - "Example Intermediate CA" \ - $(step path)/certs/intermediate_ca.crt \ - $(step path)/secrets/intermediate_ca_key - ``` +To avoid this scenario, you can use _active revocation_, +making it possible to immediately revoke a compromised certificate. -2. Add the following to `ca.json` file: +Active revocation can also be used on leaf certificates. +If a long-lived leaf certificate is compromised, +it can be rendered unusable by an attacker through revocation. - ```json - "...", - "insecureAddress": ":9001", - "..." - ``` +But there are downsides: +CRL adds a service dependency to your PKI. +Clients check the CRL endpoint on every new connections, +adding significant latency to the TLS handshake, +and load on your CRL endpoint. - ```json - "...", - "crl": { - "enabled": true, - "idpURL": "http://ca.internal/1.0/crl" - }, - "..." - ``` +You can add active revocation to your Intermediate CA, +to your leaf certificates, +or both, +using the instructions below. -3. Enable `crlDistributionPoints` within your default template: +#### Enable CRL for an Intermediate CA - ``` - { - "subject": {{ toJson .Subject }}, - "sans": {{ toJson .SANs }}, - {{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }} - "keyUsage": ["keyEncipherment", "digitalSignature"], - {{- else }} - "keyUsage": ["digitalSignature"], - {{- end }} - "extKeyUsage": ["serverAuth", "clientAuth"], - "crlDistributionPoints": ["http://ca.internal/1.0/crl"]} - ``` +To use active revocation on an Intermediate CA certificate, +you'll need a new Intermediate CA that contains your CRL server URL. -4. The approach above assumes serving CRL over http. If you use Caddy to proxy the traffic add the following to `Caddyfile` to allow hosts to reach the CRL distribution point over http: +If you're planning to use `step-ca`'s built in CRL server, +the CRL will be hosted at `/1.0/crl`. - ``` - # This serves crl over http - http://ca.external { - # Backend connection to step-ca - reverse_proxy http://ca.internal:9001 - } - ``` +1. First, enable the built-in CRL server. -5. Finally, configure your `step-ca` server to use the intermediate CA you created. + Add the following to the top level of your `$(step path)/config/ca.json` file: -6. Once you revoke an x509 certificate, check the CRL served: + ```json + "insecureAddress": ":9001", + "crl": { + "enabled": true, + "idpURL": "http://ca.example.com/1.0/crl" + }, + ``` - ```bash - step crl inspect --ca $(step path)/certs/root_ca.crt http://ca.internal:9001/1.0/crl - ``` + Reload the configuration by restarting `step-ca` or sending it a `HUP` signal. + +2. Create an intermediate CA that includes a CRL endpoint. Save the following template to `intermediate.tpl`: + + ```json + { + "subject": {{ toJson .Subject }}, + "keyUsage": ["certSign", "crlSign"], + "basicConstraints": { + "isCA": true, + "maxPathLen": 0 + }, + "crlDistributionPoints": + ["http://ca.example.com/1.0/crl"] + } + } + ``` + + You'll need this template to manually create your intermediate CA. + The CRL endpoint in this example will be served by `step-ca` as configured below; the CRL file itself is signed. + + Use the template to create your intermediate CA. You will need your root CA certificate and key: + + ```bash + $ step certificate create \ + --template intermediate.tpl \ + --ca $(step path)/certs/root_ca.crt \ + --ca-key $(step path)/secrets/root_ca_key \ + --not-after 87660h \ + "Example Intermediate CA" \ + $(step path)/certs/intermediate_ca.crt \ + $(step path)/secrets/intermediate_ca_key + ``` + +2. Retart `step-ca`. + Clients will be able to renew certificates that were issued by your previous intermediate CA. + +#### Enable CRL for Leaf Certificates + +Let's add the CRL server URL to every leaf certificate issued by `step-ca`. + +If you're planning to use `step-ca`'s built in CRL server, +the CRL will be hosted at `/1.0/crl`. + +1. If you haven't done so already, enable the built-in CRL server: + + Add the following to the top level of your `$(step path)/config/ca.json` file: + + ```json + "insecureAddress": ":9001", + "crl": { + "enabled": true, + "idpURL": "http://ca.example.com/1.0/crl" + }, + ``` + + Reload the configuration by restarting `step-ca` or sending it a `HUP` signal. + + +1. Add an X.509 certificate template, and enable `crlDistributionPoints` in the template: + + ```bash + cd $(step path)/templates + mkdir -p x509 + cat < x509/leaf.tpl + { + "subject": {{ toJson .Subject }}, + "sans": {{ toJson .SANs }}, + {{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }} + "keyUsage": ["keyEncipherment", "digitalSignature"], + {{- else }} + "keyUsage": ["digitalSignature"], + {{- end }} + "extKeyUsage": ["serverAuth", "clientAuth"], + "crlDistributionPoints": ["http://ca.example.com/1.0/crl"] + } + EOF + ``` + +3. Configure your `step-ca` provisioners to use the template you created. + + You can use, for example, `step ca provisioner update` with `--x509-template x509/leaf.tpl`. + Or add the template to provisioner definitions in `ca.json`. + See [Configuring `step-ca` to Use Templates](https://smallstep.com/docs/step-ca/templates/#configuring-step-ca-to-use-templates) for an example. + +4. Create a test certificate using the provisioner you just reconfigured, and check that the correct CRL endpoint is shown. + +5. Confirm your CRL. Revoke the certificate you just created (using `step ca revoke`), then check the CRL served by `step-ca`: + + ```bash + step crl inspect --ca $(step path)/certs/root_ca.crt http://ca.example.com:9001/1.0/crl + ``` + + Your certificate's serial number should be listed in the CRL. ### Use Templates With Care From 185c98cb51759b76de5bc41321e1f23b885c8c19 Mon Sep 17 00:00:00 2001 From: Carl Tashian Date: Thu, 29 Aug 2024 12:45:33 -0700 Subject: [PATCH 4/8] Update step-ca/certificate-authority-server-production.mdx Co-authored-by: Herman Slatman --- step-ca/certificate-authority-server-production.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index a1fff5f4..d0d5e834 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -180,7 +180,7 @@ You may require Active Revocation if you need immediate certificate revocation, or if you are issuing long-lived certificates. For this purpose, `step-ca` contains a built-in, -minimalist Certificate Revocation List (CRL) server. +minimal Certificate Revocation List (CRL) server. This section describes how to enable CRL for your intermediate CA and leaf certificates. From f305416efa15ce699facefb8fee893f9e6935395 Mon Sep 17 00:00:00 2001 From: Carl Tashian Date: Thu, 29 Aug 2024 12:47:19 -0700 Subject: [PATCH 5/8] Update step-ca/certificate-authority-server-production.mdx Co-authored-by: Herman Slatman --- step-ca/certificate-authority-server-production.mdx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index d0d5e834..d485f640 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -259,9 +259,7 @@ the CRL will be hosted at `/1.0/crl`. "isCA": true, "maxPathLen": 0 }, - "crlDistributionPoints": - ["http://ca.example.com/1.0/crl"] - } + "crlDistributionPoints": ["http://ca.example.com/1.0/crl"] } ``` From 4b226f4f2cc119f4d9eb8d617b9c52ab5f4e72dc Mon Sep 17 00:00:00 2001 From: Carl Tashian Date: Thu, 29 Aug 2024 12:47:40 -0700 Subject: [PATCH 6/8] Update step-ca/certificate-authority-server-production.mdx Co-authored-by: Herman Slatman --- step-ca/certificate-authority-server-production.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index d485f640..5bc147f8 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -218,7 +218,7 @@ it can be rendered unusable by an attacker through revocation. But there are downsides: CRL adds a service dependency to your PKI. -Clients check the CRL endpoint on every new connections, +Clients check the CRL endpoint on every new connection, adding significant latency to the TLS handshake, and load on your CRL endpoint. From 80417d736887b5b71db41c324ca3f96e9875414b Mon Sep 17 00:00:00 2001 From: Carl Tashian Date: Thu, 29 Aug 2024 12:59:57 -0700 Subject: [PATCH 7/8] Add nuance about short-lived certificates --- step-ca/certificate-authority-server-production.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index a1fff5f4..c1db891f 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -163,7 +163,7 @@ You can [configure certificate lifetimes](./configuration.mdx#basic-configuratio
- Short-lived certificates are not a replacement for active revocation using certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP). They offer an alternative that's easier to deploy and maintain. + Short-lived certificates are not a full replacement for active revocation using certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP). They offer an alternative that's easier to deploy and maintain.
From 7d4d3a3023d71c99d33d04235737e21fb985efe5 Mon Sep 17 00:00:00 2001 From: Carl Tashian Date: Tue, 3 Sep 2024 12:51:29 -0700 Subject: [PATCH 8/8] Capitalization fix --- ...ertificate-authority-server-production.mdx | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/step-ca/certificate-authority-server-production.mdx b/step-ca/certificate-authority-server-production.mdx index 47622bae..639ec89a 100644 --- a/step-ca/certificate-authority-server-production.mdx +++ b/step-ca/certificate-authority-server-production.mdx @@ -193,20 +193,20 @@ This section describes how to enable CRL for your intermediate CA and leaf certi #### When To Use Active Revocation? -The value of a two-tiered PKI is in the decoupling of root and intermediate CAs. -You can add your root CA certificate to the certificate trust store on all of your nodes, -and store your root private key completely offline. +The value of a two-tiered PKI is in the decoupling of Root and Intermediate CAs. +You can add your Root CA certificate to the certificate trust store on all of your nodes, +and store the private key completely offline. When `step-ca` issues a certificate to a client, -it comes inside a PEM bundle that contains both the intermediate CA certificate(s) and the end entity certificate. +it comes inside a PEM bundle that contains both the Intermediate CA certificate(s) and the end entity certificate. When establishing a TLS connection, -any client that trusts your root CA can use this bundle to verify a complete chain of trust. +any client that trusts your Root CA can use this bundle to verify a complete chain of trust. -Now, what if one day your intermediate CA key is compromised? -You could issue a new intermediate using your root CA key, -but your old intermediate had a 10 year validity period! -So, you're stuck having to rotate your root CA too, +Now, what if one day your Intermediate CA key is compromised? +You could issue a new Intermediate using your root CA key, +but your old Intermediate had a 10 year validity period! +So, you're stuck having to rotate your Root CA too, and that may be a big project: -you have to distribute the new root certificate to clients, +you have to distribute the new CA certificate to clients, and ensure the old one is no longer trusted. To avoid this scenario, you can use _active revocation_, @@ -217,7 +217,7 @@ If a long-lived leaf certificate is compromised, it can be rendered unusable by an attacker through revocation. But there are downsides: -CRL adds a service dependency to your PKI. +Hosting a Certificate Revocation List (CRL) adds a service dependency to your PKI. Clients check the CRL endpoint on every new connection, adding significant latency to the TLS handshake, and load on your CRL endpoint. @@ -249,7 +249,7 @@ the CRL will be hosted at `/1.0/crl`. Reload the configuration by restarting `step-ca` or sending it a `HUP` signal. -2. Create an intermediate CA that includes a CRL endpoint. Save the following template to `intermediate.tpl`: +2. Create an Intermediate CA that includes a CRL endpoint. Save the following template to `intermediate.tpl`: ```json { @@ -263,10 +263,10 @@ the CRL will be hosted at `/1.0/crl`. } ``` - You'll need this template to manually create your intermediate CA. + You'll need this template to manually create your Intermediate CA. The CRL endpoint in this example will be served by `step-ca` as configured below; the CRL file itself is signed. - Use the template to create your intermediate CA. You will need your root CA certificate and key: + Use the template to create your Intermediate CA. You will need your root CA certificate and key: ```bash $ step certificate create \ @@ -280,7 +280,7 @@ the CRL will be hosted at `/1.0/crl`. ``` 2. Retart `step-ca`. - Clients will be able to renew certificates that were issued by your previous intermediate CA. + Clients will be able to renew certificates that were issued by your previous Intermediate CA. #### Enable CRL for Leaf Certificates