Closed TinCanTech closed 5 months ago
If this PR is merged then the following are required:
gen-req
requires support for --san
: Use OpenSSL command req -addext
OSSL v1 and 3.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.
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..
Superseded-by: #1096
--san|--subject-alt-name
current behavior is to append any value toEASYRSA_EXTRA_EXTS
and repeatedly insert OpenSSL labelsubjectAltName
. 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 whatEASYRSA_EXTRA_EXTS
external definition is intended for.EASYRSA_EXTRA_EXTS
is still used by commandrenew
but only for SAN.Create
EASYRSA_SAN
for explicitsubjectAltName
use.This change correctly formats
EASYRSA_SAN
, to only begin with the labelsubjectAltName =
and append user SAN values to that string.Example Command line:
Resulting certificate:
The originally required command string:
is also still supported.