Wrong handling of subjectAltName (SAN)

[holmboe]

Hello Brian,

I have researched tools to use for our internal PKI and quite like pkictl. However I have noticed a problem.

In https://github.com/brianclements/pkictl/blob/6d1e76ffa893b61f33107641c8d04017a26a65f3/myorg.local-node.tls.sub.root.ee.conf#L4 you specify a SAN. Doing it this way currently poses a couple of problems:

1. Specifying the apex of your domain in each TLS certificate allows each and every one of the certs issued by the CA to serve content not only by it's FQDN but also at the apex domain. This might be a security issue.
2. When you specify a subjectAltName with a DNS entry the CN is skipped altogether by most (compliant) implementations. Hardcoding a SAN thus makes it mandatory to also include the hostname of the CN as a SAN.

More information on this in this SO answer. The relevant parts of RFCs are also provided. Perhaps they do a better job than me in explaining the issues:

https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together

To work around this I do this for a cert with a single DNS:

SAN=DNS:www.example.com pkictl/pkictl eecert request node.tls.class1 tls.class1 www.example.com

This will override the default provided by the configuration file above, and properly set both the CN and SAN to the correct value.

If I do want an apex domain SAN do this to get a certificate with correct handling of CN and SAN:

SAN=DNS:www.example.com,DNS:example.com pkictl/pkictl eecert request node.tls.class1 tls.class1 www.example.com

To provide additional SANs I do this:

SAN=DNS:test.example.com,DNS:foo.example.com,DNS:bar.example.com pkictl/pkictl eecert request node.tls.class1 tls.class1 test.example.com