Ahoy! My dead simple alternative to using `openssl` and its overwhelming torrent of cryptic command line switches to generate self-signed certificates for use in Geminispace is finally starting to take shape and is now ready for some test driving: https://tildegit.org/solderpunk/gemcert Some example incantations follow. Want to make certificate to use for your server at example.com? Run: gemcert -server -domain example.com and that's it! You'll get, by default, an ECDSA cert valid for any subdomain of example.com for 5 years. Prefer ED25519 and 2 years of validity? Easy: gemcert -server -domain example.com -ed25519 -years 2 Want a long-lived certificate you can use as a client cert for Astrobotany, with the username HirokoAi? Easy: gemcert -client -cn HirokoAi -years 100 You get the idea. It's still a little rough around the edges in some respects (e.g. the output is always saved to cert.pem and key.pem in the pwd), but it should be usable with some care. Feedback very welcome! Cheers, Solderpunk
This looks great, thanks! > Prefer ED25519 I know you mention this on the README, but I just want to remind people that it's probably best to stick with EC keys for now, as not all clients and servers support ed25519. And the size is similar. Also, could you add a go.mod and go.sum file to your repo. You can easily make one with `go mod init`, just make sure the path in go.mod is correct. That would allow using go get on the repo. Thanks, makeworld
Cool! This is very welcome; I scratch my head every time I use openssl. I personally greatly prefer GNU argument conventions, ie. dual dashes for long arguments (--server) and short single-dash versions of the most common arguments (-s). Even if you don't want to implement this now, changing the docs to use the dual dash versions would make changing later possible. https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html I'd also like if the generated filenames contained the domain name. Nice for vhost configurations. -Hannu -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200715/a936 0242/attachment.htm>
Now that I fully read the README, I have to wonder if generating wildcard certs by default is a good idea. I assume the use case is serving different content on different subdomains, right? In that case you need vhost support from the server, and the server should offer support for different certs for each vhost. I'd argue that having a different cert for each subdomain is more flexible because you can later move some of them to different servers. Copying a wildcard cert around is not generally a good idea. This is a minor detail, of course. As long as it's possible to generate non-wildcard certs I'm ok with that. -Hannu -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200715/fd29 2e5d/attachment.htm>
On Wed, Jul 15, 2020 at 11:33:59PM +0300, Hannu Hartikainen wrote: > Cool! This is very welcome; I scratch my head every time I use openssl. > > I personally greatly prefer GNU argument conventions, ie. dual dashes for > long arguments (--server) and short single-dash versions of the most common > arguments (-s). Even if you don't want to implement this now, changing the > docs to use the dual dash versions would make changing later possible. > > https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html > > I'd also like if the generated filenames contained the domain name. Nice > for vhost configurations. > > -Hannu For context, it's this way because solderpunk is using the go `flag` package, which doesn't support GNU flags. Writing it that way would require pulling in some external dependency, and probably doing some rewrites of the CLI flag parsing. ~ lel
On Wed, Jul 15, 2020 at 04:53:43PM -0400, lel wrote: > On Wed, Jul 15, 2020 at 11:33:59PM +0300, Hannu Hartikainen wrote: > > Cool! This is very welcome; I scratch my head every time I use openssl. > > > > I personally greatly prefer GNU argument conventions, ie. dual dashes for > > long arguments (--server) and short single-dash versions of the most common > > arguments (-s). Even if you don't want to implement this now, changing the > > docs to use the dual dash versions would make changing later possible. > > > > https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html > > > > I'd also like if the generated filenames contained the domain name. Nice > > for vhost configurations. > > > > -Hannu > > For context, it's this way because solderpunk is using the go `flag` package, > which doesn't support GNU flags. Writing it that way would require pulling in > some external dependency, and probably doing some rewrites of the CLI flag > parsing. > > ~ lel I sent this a bit early, I also meant to say: ... and honestly I don't think it's worth the effort and dependencies just for the added feature of making the user type an extra dash before their arguments. Sorry for the doublepost. ~ lel
Glad to see that you released this! ^^ One suggestion I have is to implement an option to specify a limit for the serial number's size. Generating a big.Int value that goes below the threshold of 8 bits, 16 bits, etc. in size can help to save a few bytes. Another suggestion is to have a confirmation prompt for overwriting files. This is definitely a small detail, but considering the nature of what's being generated, it might be worth making sure that a user doesn't accidentally write over their private key. Using the same domain name and expiration date, sizes of ed25519 certs through gemcert seem to be a bit larger compared to what I get from a certificate generator that I wrote a few days back (424 bytes versus 262 bytes) despite the x509 templates using the same basic values. ~luna -- Email domain proudly hosted at https://migadu.com
On Wed Jul 15, 2020 at 10:53 PM CEST, lel wrote: > For context, it's this way because solderpunk is using the go `flag` > package, > which doesn't support GNU flags. Writing it that way would require > pulling in > some external dependency, and probably doing some rewrites of the CLI > flag > parsing. Precisely. I would also actually prefer e.g. --domain if I had my choice, but it's hardly important enough to be worth the effort of duplicating standard library functionality. Sorry. Cheers, Solderpunk
On Wed Jul 15, 2020 at 10:33 PM CEST, Hannu Hartikainen wrote: > I'd also like if the generated filenames contained the domain name. Nice > for vhost configurations. That's a good idea, thanks, I will implement that, hopefully soon. I have been wondering how best to name client certificate files. Using the user-provided CN is no good because people may re-use the same username across multiple applications. Cheers, Solderpunk
On Wed Jul 15, 2020 at 8:13 PM CEST, wrote: > Also, could you add a go.mod and go.sum file to your repo. You can > easily > make one with `go mod init`, just make sure the path in go.mod is > correct. > That would allow using go get on the repo. Thanks for the pointers, I will look into this. I'm still relatively green at Go, especially all the packaging infrastructure stuff. Cheers, Solderpunk
On Sun, 19 Jul 2020 at 16:53, Solderpunk <solderpunk at posteo.net> wrote: > Precisely. I would also actually prefer e.g. --domain if I had my > choice, but it's hardly important enough to be worth the effort of > duplicating standard library functionality. Sorry. Oh, but the flag module *does* support double dashes (it always supports both). Thus my suggestion to change all documentation to use --server, --domain and such. You can even add the short versions still using the flag module; there will be undocumented support for --s besides -s and -server besides --server, but that's not a huge problem IMHO. -Hannu
On Sat Jul 18, 2020 at 6:33 AM CEST, luna wrote: > Using the same domain name and expiration date, sizes of ed25519 certs > through gemcert seem to be a bit larger compared to what I get from a > certificate generator that I wrote a few days back (424 bytes versus 262 > bytes) despite the x509 templates using the same basic values. Hmm...any chance that's comparing PEM and DER encodings? I would not expect such a large in an apples-to-apples comparison. Cheers, Solderpunk
> Hmm...any chance that's comparing PEM and DER encodings? I would not > expect such a large in an apples-to-apples comparison. Turns out I must've stayed up too late writing that email because I completely forgot that the size I referred to for my generator didn't take the exported file's PEM encoding into account. Welp, that explains a lot! An updated comparison: 412 bytes from my own program versus 424 bytes from gemcert. Not much of a difference this time around. ~luna -- Email domain proudly hosted at https://migadu.com
---
Previous Thread: Amfora and Bombadillo now at the ssh kiosk!
Next Thread: Status Codes Question (Forbidden/Internal Server Error)