💾 Archived View for makeworld.gq › gemlog › 2020-07-06-openssl.gmi captured on 2020-11-07 at 01:02:11. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Last updated: 2020-07-09
Note this document may be updated at any time.
----
There's been a lot of certificate, TLS, and TOFU discussion on Gemini recently - mostly instigated by me I think? :)
Anyway, I have figured out some useful openssl commands to generate certificates that are good for Gemini usage. Solderpunk is working on a Go tool that will generate certs easily with sane defaults, which will be *the way* to do this once that tool comes out, but for now I hope these commands are useful.
If you run a Gemini server, you may want to use these, to make your certs smaller and longer lasting. If you're thinking about changing your certs, the best time is now! Or you can wait until right *after* they expire.
All examples use example.com as the root domain. Change this to your domain.
This command generates a general-purpose Gemini certificate that lasts for 5 years (at Solderpunk's recommendation), and uses a small but secure key. The command does not require any interaction.
This command is also great for creating client certificates (a discussion for another post). Just replace example.com with whatever the CN should be for the app. Maybe a username...
openssl req -new -subj "/CN=example.com" -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 1825 -nodes -out cert.pem -keyout key.pem
EC keys are elliptic curve keys, which can be smaller than RSA keys (which are usually 2048 bits) but still stay secure. The above command generates an EC key with the curve called "prime256v1". This creates a secure 256-bit key, it's the curve Let's Encrypt uses by default for example.
in practice, average clients only support two curves, the ones which are designated in so-called NSA Suite B: these are NIST curves P-256 and P-384 (in OpenSSL, they are designated as, respectively, "prime256v1" and "secp384r1"). If you use any other curve, then some widespread Web browsers (e.g. Internet Explorer, Firefox...) will be unable to talk to your server.
Source: Security StackExchange - "Which elliptic curve should I use?"
This command generates a wildcard certificate, meaning it is valid for example.com, but also any subdomain of example.com, such as test.example.com, dev.example.com, etc. It is not valid for a sub-subdomain, like hello.world.example.com. This is useful if you plan on having multiple services on your server (think of mozz with mozz.us, astrobotany, and chat), but don't want to have to create a new cert each time.
An alternate method of doing this would be to generate different certs for each subdomain, using the command above. Jetforce currently doesn't support multiple TLS certs, so you can use this command instead.
The cert generated is valid for 5 years and uses the same key type as the previous command. Also note that this command requires OpenSSL version 1.1.1 or above. You can check this by running `openssl version`.
The command does not require any interaction.
openssl req -new -subj "/CN=*.example.com" -addext "subjectAltName = DNS:example.com, DNS:*.example.com" -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 1825 -nodes -out cert.pem -keyout key.pem
Note that some parts of the command prepend an asterisk and dot to example.com. This is important.
This section was added on 2020-07-07, after the original posting.
This command is similar to the other ones above, but it allows you to generate one certificate that is valid for multiple domains. It is NOT a wildcard cert. Keep in mind that it's usually better to use multiple certs for each domain if possible.
This command requires OpenSSL version 1.1.1 or above.
This command creates a cert and key valid for example.com as well as example2.com.
openssl req -new -subj "/CN=example.com" -addext "subjectAltName = DNS:example.com, DNS:example2.com" -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 1825 -nodes -out cert.pem -keyout key.pem
As you can see, the additional domain name goes in the "subjectAltName" section. Note that the domain in the CN section is repeated in "subjectAltName", this is intentional.
You can add more domains by adding a comma and space to the end of that part of the command, and following the format of: DNS:domain.tld