@@ -21,7 +21,7 @@ the token does contain the root fingerprint then it is simpler to use:
21
21
client , err := ca.Bootstrap (token)
22
22
```
23
23
24
- After the initialization there are examples of all the client methods. These
24
+ After the initialization, there are examples of all the client methods. These
25
25
methods are a convenient way to use the CA API. The first method, ` Health ` ,
26
26
returns the status of the CA server. If the server is up it will return
27
27
` {"status":"ok"} ` .
@@ -77,7 +77,7 @@ if err != nil { ... }
77
77
```
78
78
79
79
The following methods are for inpsecting Provisioners.
80
- One method that returns a list of provisioners or a the encrypted key of one provisioner.
80
+ One method that returns a list of provisioners or an encrypted key of one provisioner.
81
81
82
82
``` go
83
83
// Without options it will return the first 20 provisioners.
@@ -98,7 +98,7 @@ key, err := client.ProvisionerKey("DmAtZt2EhmZr_iTJJ387fr4Md2NbzMXGdXQNW1UWPXk")
98
98
```
99
99
100
100
The following example shows how to create a
101
- tls.Config object that can be injected into servers and clients. By default these
101
+ tls.Config object that can be injected into servers and clients. By default, these
102
102
methods will spin off Go routines that auto-renew a certificate once (approximately)
103
103
two thirds of the duration of the certificate has passed.
104
104
@@ -184,7 +184,7 @@ resp, err := client.Get("https://localhost:8443")
184
184
```
185
185
186
186
We will demonstrate the mTLS configuration in a different example. In this
187
- examplefor we will configure the server to only verify client certificates
187
+ example we will configure the server to only verify client certificates
188
188
if they are provided.
189
189
190
190
To being with let's start the Step CA:
@@ -226,7 +226,7 @@ If you'd like to turn off curl's verification of the certificate, use
226
226
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.
227
227
```
228
228
229
- Now lets use the root certificate generated for the Step PKI. It should work.
229
+ Now let's use the root certificate generated for the Step PKI. It should work.
230
230
231
231
``` sh
232
232
certificates $ curl --cacert examples/pki/secrets/root_ca.crt https://localhost:8443
@@ -236,7 +236,7 @@ Hello nobody at 2018-11-03 01:49:25.66912 +0000 UTC!!!
236
236
Notice that in the response we see ` nobody ` . This is because the server did not
237
237
detected a TLS client configuration.
238
238
239
- But if we create a client with it's own certificate (generated by the Step CA),
239
+ But if we create a client with its own certificate (generated by the Step CA),
240
240
we should see the Common Name of the client certificate:
241
241
242
242
``` sh
@@ -304,7 +304,7 @@ We can use the bootstrap-server to demonstrate certificate rotation. We've
304
304
added a second provisioner, named ` mike@smallstep.com ` , to the CA configuration.
305
305
This provisioner is has a default certificate duration of 2 minutes.
306
306
Let's run the server, and inspect the certificate. We can should be able to
307
- see the certificate rotate once approximately 2/3rds of it's lifespan has passed.
307
+ see the certificate rotate once approximately 2/3rds of its lifespan has passed.
308
308
309
309
``` sh
310
310
certificates $ export STEPPATH=examples/pki
@@ -320,7 +320,7 @@ The exact formula is `<duration>-<duration>/3-rand(<duration>/20)` (`duration=12
320
320
in our example).
321
321
322
322
We can use the following command to check the certificate expiration and to make
323
- sure the certificate changes after 74-80 seconds.
323
+ sure the certificate changes after 74-80 seconds.
324
324
325
325
``` sh
326
326
certificates $ step certificate inspect --insecure https://localhost:8443
0 commit comments