X509 certificate configuration file syntax, documentation, and examples use obsolete mechanisms

[briansmith]

A linkerd user pointed out that our examples generate certificates that are using X509v1, not X509v3. Also, those certificates don't have a subjectAltName dNSName extension.

One effect of these two issues is that the initial TLS support in Conduit won't even be able to access services that use certificates generated based on the linkerd documentation, since the underlying crypto library webpki currently enforces the use of modern mechanisms.

Another effect of these two issues is that a release of Chrome that's due to be released very soon will not accept these certificates either, as it will be (is?) enforcing the same rules that webpki has been enforcing.

The issue extends to the documentation. The documentation frequently mentions the "common name" of the certificate, e.g. at https://linkerd.io/doc/0.7.4/linkerd/client_tls/. That's an obsolete field that webpki and (soon) Chrome don't support. We need to update all references to "common name" to refer to the subjectAltName dNSNames.

Similarly, the linkerd configuration file syntax uses "commonName" and similar as field names. We should create aliases like "dNSName" or "subject" or similar that can be used instead of "commonName", and deprecate "commonName".

The goals here is to maximize interoperability, especially between Conduit and linkerd.

[briansmith]

openssl, up until the very latest, is very annoying with respect to generating certificates that have subjectAltName set. We should consider providing examples using a different tool, like CFSSL, in addition to or instead of OpenSSL.