From 9f22f38fa76f26c7db6ef7641d307314a548a459 Mon Sep 17 00:00:00 2001 From: Jonathan Springer Date: Thu, 6 Dec 2018 09:12:55 -0500 Subject: [PATCH] Update https.cnf - Clarify extfile directions Directions around `extfile.cnf` for client certificates was somewhat confusing. Edited the document to clarify that a separate file was to be created, not append a line to the file that had just been created for the server. --- engine/security/https.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/engine/security/https.md b/engine/security/https.md index 5e23fb18d9..e0d4ed7132 100644 --- a/engine/security/https.md +++ b/engine/security/https.md @@ -113,24 +113,24 @@ request: $ openssl req -subj '/CN=client' -new -key key.pem -out client.csr -To make the key suitable for client authentication, create an extensions +To make the key suitable for client authentication, create a new extensions config file: - $ echo extendedKeyUsage = clientAuth >> extfile.cnf + $ echo extendedKeyUsage = clientAuth > extfile-client.cnf Now, generate the signed certificate: $ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \ - -CAcreateserial -out cert.pem -extfile extfile.cnf + -CAcreateserial -out cert.pem -extfile extfile-client.cnf Signature ok subject=/CN=client Getting CA Private Key Enter pass phrase for ca-key.pem: After generating `cert.pem` and `server-cert.pem` you can safely remove the -two certificate signing requests: +two certificate signing requests and extensions config files: - $ rm -v client.csr server.csr + $ rm -v client.csr server.csr extfile.cnf extfile-client.cnf With a default `umask` of 022, your secret keys are *world-readable* and writable for you and your group.