Some applications fail to parse the certificate if the CN is not set,
even if they (correctly) check SANs before the CN when validating a
hostname. Even though the CN should be ignored if a matching SAN
hostname was found, we can prevent the parse from failing by also
including the hostname as the CN.
Additionally, switch from maps to slices to prevent DNS names and IP
addresses from being reordered when added to the certificate template.
This commit changes three things with cert generation.
- The extended key usage field has been removed since specifying the
extended key usage field prevents the cert from working with firefox
even when it specifies it can be used as a server
- Creates a random serial number since browsers like firefox and chrome
won't accept two certificates with the same issuer and serial number
- Adds the digital signature key usage capability since some validators
like node.js expect that instead of key encipherment
btcd, btcwallet, and an upcomming standalone tool to generate the TLS
certificates all need a way to generate TLS certificate pairs. This
function, adapted from the cert gen code in btcd, abstracts this logic
so all programs can reuse the code.
Unlike the older btcd certificate generation code, this new function
allows specifying additional hostnames and IPs to add to the list of
addresses for which the cert is valid.
