If a private key has been compromised, revoking X.509 certificates is not enough. The best option is to issue certificates that expire quickly enough so that revocation isn't necessary. In a zero-trust network, it is good practice to let certificates expire sooner, and there is an automatic way to renew certificates.

Let's take a look:

1. Let's check the certificate that we issued to httpbin:

$ cd ~/step

$ step certificate inspect httpbin.crt --short
X.509v3 TLS Certificate (ECDSA P-256) [Serial: 2760...1376]
  Subject: httpbin.istio.io
  Issuer: istio.io
  Valid from: 2019-10-16T13:30:41Z
          to: 2020-01-14T13:30:38Z

Notice that the certificate is only valid for 90 days since we changed the default from 1 day for the purpose of the exercises in this book. There should be an automated process to renew the certificates before they expire and recycle the secrets automatically. 

Let's do this manually.

2. Delete the httpbin-keys secret as we will create a new set of keys:

$ kubectl -n istio-system delete secret httpbin-keys 

3. Regenerate the key and certificate for httpbin.istio.io and bundle the intermediate CA. Specify a password that will be used to generate an intermediate CA private key:

$ step certificate create httpbin.istio.io httpbin.crt httpbin.key --profile leaf --ca istio.crt --ca-key istio.key --no-password --insecure --not-after 2160h
Please enter the password to decrypt istio.key: ☺☺☺☺☺☺☺☺
✔√ Would you like to overwrite httpbin.crt [y/n]: y
✔ Would you like to overwrite httpbin.key [y/n]: y
Your certificate has been saved in httpbin.crt.
Your private key has been saved in httpbin.key.

4. Create a secret for httpbin using a new key and certificate:

$ kubectl -n istio-system create secret generic httpbin-keys --from-file=key=$HOME/step/httpbin.key --from-file=cert=$HOME/step/httpbin.crt 
secret/httpbin-keys created

5. Check the SDS log entry for the certificate that we created to check the key/cert pair has been pushed to the proxy:

$ kubectl -n istio-system logs -l app=istio-ingressgateway -c ingress-sds

6. Run the same curl test against httpbin.istio.io to make sure that the key and certificate rotation has worked. Refresh the browser tab and check the headers:

$ curl -HHost:httpbin.istio.io --resolve httpbin.istio.io:$INGRESS_PORT:$INGRESS_HOST --cacert $HOME/step/istio.crt https://httpbin.istio.io/ip
{
 "origin": "192.168.142.101"
}

This manual process rotates the certificate for the Ingress gateway certificate and key regeneration can be automated with the help of the step-ca tool. This tool runs an online CA, and the client certificates can be requested through the use of step commands. Consult https://github.com/smallstep/certificates for more details.

After working through the simple TLS (a client is not required to present its authenticity), we will now move toward mutual TLS in which a client is also required to present its credentials so that the server knows that the client is authentic.