mike
/
gemcert
forked from solderpunk/gemcert
1
0
Fork 0
Code Pull Requests Activity

Update documentation to reflect recent changes. Use -- option notation in all examples.

This commit is contained in:
Solderpunk 2020-08-01 18:53:46 +02:00
parent 4a3291f662
commit 18662f92e2
1 changed files with 21 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
README.md
View File

@ -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!