Subject-Alt-Name: Correct behavior of global option --san

[TinCanTech]

--san|--subject-alt-name current behavior is to append any value to EASYRSA_EXTRA_EXTS and repeatedly insert OpenSSL label subjectAltName. This label should be specified once only.

This change leaves EASYRSA_EXTRA_EXTS completely unchanged and outside of EasyRSA scope. This is done due to the lack of definition as to what EASYRSA_EXTRA_EXTS external definition is intended for.

EASYRSA_EXTRA_EXTS is still used by command renew but only for SAN.

Create EASYRSA_SAN for explicit subjectAltName use.

This change correctly formats EASYRSA_SAN, to only begin with the label subjectAltName = and append user SAN values to that string.

Example Command line:

--san=DNS:server3 --san=DNS:swerveur3 --san=IP:10.2.2.2 --san=IP:10.1.1.1
  --nopass build-server-full s3

Resulting certificate:

X509v3 Subject Alternative Name:
    DNS:server3, DNS:swerveur3, IP Address:10.2.2.2, IP Address:10.1.1.1

The originally required command string:

--san=DNS:server3,DNS:swerveur3,IP:10.2.2.2,IP:10.1.1.1 build-server-full s3

is also still supported.

[TinCanTech]

If this PR is merged then the following are required:

• SAN must be completely separated from Extra extensions...
• gen-req requires support for --san: Use OpenSSL command req -addext OSSL v1 and 3.
• The confirmations lists must show the correct and requested SAN. Signing may want to over write the CSR SAN.
• help must be corrected.
• renew may be difficult.

Also, separating --san from the highly ambiguous and undefined EASYRSA_EXTRA_EXTS allows EASYRSA_EXTRA_EXTS to continue to function as-is, what-ever that may be -- I think it is highly unlikely that this is ever used.

In short, the CA Admin must have ultimate control; Signed certificates must be allowed to change request details.

For Easy-RSA, this currently only concerns the distinguished name and the annoying SAN.

[TinCanTech]

I must make this point clear: easyrsa is causing more headaches from OLD code than OpenSSL.

The last commit f6a6e75ec95f7db4fa9ccc5aba7ff68f5fcd4d18 was to remove default SAN. I stand by this decision because there is no RFC which clearly defines an alternate name.

This PR is not going to be merged because something more drastic is required.

This PR approach can still be used. However, use of --san must still trigger the EASYRSA_EXTRA_EXTS code, for the time being..

[TinCanTech]

Superseded-by: #1096