TLS Toolkit should provide SAN by default

As of Chrome 58, the browser will only use the SubjectAlternativeName entries to determine hostname verification, rather than the CN. This is specified in RFC 6215 [1], TLS hostname verification must attempt to use the SAN entries first and may only use the CN entry if no SAN entries are available.

Chrome takes this a step further [2]:

During Transport Layer Security (TLS) connections, Chrome browser checks to make sure the connection to the site is using a valid, trusted server certificate.

For Chrome 58 and later, only the subjectAlternativeName extension, not commonName, is used to match the domain name and site certificate. The certificate subject alternative name can be a domain name or IP address. If the certificate doesn’t have the correct subjectAlternativeName extension, users get a NET::ERR_CERT_COMMON_NAME_INVALID error letting them know that the connection isn’t private. If the certificate is missing a subjectAlternativeName extension, users see a warning in the Security panel in Chrome DevTools that lets them know the subject alternative name is missing.

As this will cause issues for users who do not manually provide a SAN when generating their certificates using the TLS Toolkit, the toolkit should be modified to automatically include the provided CN as a SAN entry, in addition to any manually-provided SAN entries.

[1] https://tools.ietf.org/html/rfc6125#section-6.4.4
[2] https://support.google.com/chrome/a/answer/7391219?hl=en