From 18662f92e227764007c2cd53b8142fa982d0cee3 Mon Sep 17 00:00:00 2001 From: Solderpunk Date: Sat, 1 Aug 2020 18:53:46 +0200 Subject: [PATCH] Update documentation to reflect recent changes. Use -- option notation in all examples. --- README.md | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 5f250aa..15d11cd 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ Use the following command to generate a self-signed certificate to use with a Gemini server: ``` -gemcert -server -domain example.com +gemcert --server --domain example.com ``` This will generate a certificate with a CommonName of example.com, but will @@ -27,7 +27,13 @@ field. In other words, gemcert generates wildcard certificates by default. Because many Gemini clients use the TOFU model, frequent certificate changes should be avoided wherever possible, so it's better to remain flexible at the outset - you might have no plans to use subdomains right now, but are you sure -you won't change your mind next year? +you won't change your mind next year? Oh, you are? Then you can use: + +``` +gemcert --server --nowild --domain example.com +``` + +To get a certificate valid only for `example.com`. ## Client certificates @@ -35,7 +41,7 @@ Use the following command to generate a self-signed certificate to use as a client certificate: ``` -gemcert -client +gemcert --client ``` The x.509 standard allows a certificate's Subject to be empty, but not its @@ -50,8 +56,8 @@ username in the application. You can use the `-cn` option to specify your own Subject CN in certs destined for use with such an application: ``` -gemcert -client -cn username -gemcert -client -cn "Gus Grissom" +gemcert --client --cn username +gemcert --client --cn "Gus Grissom" ``` ## Certificate lifetimes @@ -60,10 +66,10 @@ The validity period of a certificate always begins at the time it was generated. By default, server certificates are valid for 5 years beyond that time, and client certificates for 1 day. No matter which certificate type you are creating, you can easily specify the validity lifetime you would like using any -combination of the `-years`, `-months`, `-days` and `-hours` options: +combination of the `--years`, `--months`, `--days` and `--hours` options: ``` -gemcert -server -domain example.com -years 3 -months 6 -days 12 -hours 4 +gemcert --server --domain example.com --years 3 --months 6 --days 12 --hours 4 ``` ## Key types @@ -76,10 +82,10 @@ of cert seems to represent the best current trade-off between small certificate size and broad compatibility. As a single alternative, gemcert can also produce keys for the ED25519 -signature scheme, via the `-ed25519` option: +signature scheme, via the `--ed25519` option: ``` -gemcert -server -ed25519 -domain example.com +gemcert --server --ed25519 --domain example.com ``` The resulting certificates will be even smaller, and many consider them more @@ -94,7 +100,9 @@ and a particular application server you want to use both support ED25519. ## Output files -Whether you are making a server or client certificate, gemcert will produce the -output in PEM formatted files named `key.pem` and `cert.pem` in the current -working directory, and will not ask before overwriting existing files, so use -with caution! +Server certificate and key files will be written to files with names derived +from the domain, e.g. `example.com.crt` and `example.com.key`. Client +certificates are written instead to `key.pem` and `cert.pem` (an ugly +inconsistency which is not long for this world). Either way, the files will +be written to the current working directory, will be in PEM format, and gemcert +will not ask before overwriting existing files, so use with caution!