You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The same entity may have multiple provisioners for authorizing different
380
380
types of certs. Each of these provisioners must have unique keys.
381
381
382
+
## Use Custom Claims for Provisioners to Control Certificate Validity etc
383
+
384
+
It's possible to configure provisioners on the CA to issue certs using propoerties specific to their target environments. Most commonly different validity periods and disabling renewals for certs. Here's how:
385
+
386
+
```bash
387
+
$ step ca init
388
+
# complete the init steps
389
+
$ step ca provisioner add --create dev@smallstep.com
390
+
# lets create a provisioner for dev certs
391
+
Please enter a password to encrypt the provisioner private key? password
392
+
# add claims inside a provisioner element in ~/.step/config/ca.json
Please enter the password to decrypt ~/.step/secrets/intermediate_ca_key: password
424
+
2019/02/21 12:09:51 Serving HTTPS on :9443 ...
425
+
```
426
+
427
+
Please [`step ca provisioner`](https://smallstep.com/docs/cli/ca/provisioner/)'s docs for details on all available claims properties. The durations are strings which are a sequence of decimal numbers, each with optional fraction and a unit suffix, such as "300ms" or "2h45m". Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
428
+
429
+
Now certs issued by the `dev@smallstep.com` provisioner will be valid for two hours and deny renewals. Command line flags allow validity extension up to 12h, please see [`step ca certificate`](https://smallstep.com/docs/cli/ca/certificate/)'s docs for details.
430
+
431
+
```bash
432
+
# grab a cert, will also work with 'step ca token' flow
Copy file name to clipboardexpand all lines: examples/README.md
+63
Original file line number
Diff line number
Diff line change
@@ -555,6 +555,69 @@ Hello kube_client (cert issued by 'Smallstep Kubernetes Root CA') at 2019-01-28
555
555
556
556
Since the demo server is enrolled with the federated `Cloud CA` that trusts certs issued by the `Kubernetes CA` through federation the connection is successfully established.
557
557
558
+
## Custom certificate validity periods using Custom Claims
559
+
560
+
Bring up the certificate authority with the example:
The example comes with multiple provisioner options, two of which have custom claims to expand the validity of certificates:
568
+
569
+
```sh
570
+
$ step ca provisioner list | jq '.[] | "\(.name): \(.claims.defaultTLSCertDuration)"'
571
+
# null means step default of 24h for cert validity
572
+
"mariano@smallstep.com: null"
573
+
"mike@smallstep.com: 2m0s"
574
+
"decade: 87600h0m0s"
575
+
"90days: 2160h0m0s"
576
+
```
577
+
578
+
A closer look at a duration-bound provisioner, `90days` for instance, reveals the custom configuration for certificate validity.
579
+
580
+
```sh
581
+
$ step ca provisioner list | jq '.[3].claims'
582
+
{
583
+
"maxTLSCertDuration": "2160h0m0s",
584
+
"defaultTLSCertDuration": "2160h0m0s"
585
+
}
586
+
```
587
+
588
+
Certificates with different validity periods can be generated using the respective provisioners.
589
+
The durations are strings which are a sequence of decimal numbers, each with optional fraction and a unit suffix, such as "300ms" or "2h45m". Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
590
+
591
+
Please see [Getting Started](https://github.com/smallstep/certificates/blob/master/docs/GETTING_STARTED.md) in the docs directory to learn what custom claims configuration options are available and how to use them.
592
+
593
+
```sh
594
+
$ step ca certificate decade decade.crt decade.key
0 commit comments