Add Subject Alt Name (fixes #1)

[developit]

This was my reason for forking. If merged I'll point preact-cli back to the proper devcert package.

[davewasmer]

Thanks @developit, was meaning to get around to that!

Not sure we want to hardcode to localhost though - what if someone is using /etc/host? That was the rationale for passing in the app name to getDevelopmentCertificate (which should probably be renamed to domain instead of app name).

[developit]

domain name works, though I think the SAN field accepts a CSV?

[davewasmer]

I haven't done much digging on the SAN field, so not sure ...

[mike-north]

I don't think this is necessary

[mike-north]

Multiple subjectAltName values are possible, either by

subjectAltName = DNS:localhost, DNS:lvh.me, IP:127.0.0.1, IP:127.0.0.2

or

subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
DNS.2 = lvh.me
IP.1 = 127.0.0.1
IP.2 = 127.0.0.2

My thinking is that this list of domains and IP addresses should be

1) The following, by default

DNS.1 = localhost
DNS.2 = lvh.me
IP.1 = 127.0.0.1

Use case: I'm working on an app that can be hosted on a single domain, and wish to develop with HTTPS on localhost.

2) Added to, machine-wide at the developer's discretion

Use case: I have a static IP address or host name on my corporate network, and want ANY devcert certificate to facilitate TLS connections for that IP/hostname.

3) Added to, by request of the requestor of a certificate (and ideally at the explicit consent of the machine owner), on a per-certificate basis

Use case: I work on an app that involves multiple subdomains, even in development (i.e. we are building something like *.github.io, where users create their own subdomains)

[mike-north]

My thoughts as to the most straightforward way to implement these

1. Can be done right now with no risk or harm to existing users or future APIs, by adding the above to the openssl configuration template.

   • This library would have to be modified so that the openssl config in ~/.config/devcert is "upgraded", since as-is, it's created when the cert authority is set up and then never touched again.
   • I don't believe there's any harm in "updating" the openssl config as each signed certificate is generated, providing the treatment of serial number and database remain unchanged.

2. Can be accomplished by just providing instructions for editing ~/.config/devcert/openssl.conf (and the equivalent for windows/linux) in README.md

3. Could be implemented by adding the ability to pass an optional options object to the devcert function, with devcert presenting a blocking Y/N confirmation prompt to the user, listing the domains to the console (thus making it more difficult for the user to be tricked into creating trusted certificates for api.my-online-bank.com)

[mike-north]

Related: webpack/webpack-dev-server#987
While reviewing the webpack-dev-server PR, I suggested that IPv6 loopback domains be added as well. There are a bunch of edge case situations we may as well hit properly if this PR is going to be merged (i.e., localhost.localdomain).

[davewasmer]

Going to close this PR, since SAN is now supported in the just-landed refactor on master branch. But I'd like to make sure we address all the points mentioned here.

@mike-north in general, I'd like to keep devcert as a low-level library that other tools can build on top of. To that end, I'd like to keep the assumptions to a minimum - I'd rather provide no default domains, and let whatever tool / library / framework that builds on top of devcert provide whatever defaults make the most sense there.

I wasn't aware of the IP syntax in the SAN field, good to know. Perhaps we should auto-detect when someone asks for a localhost domain cert, and add the IPv4 and IPv6 loopback addresses as well?