EasyRSA Behavior Change - 3.0.8 - 3.2.0 - EASYRSA_REQ_CN / --req-cn /--subject-alt-name

[joubertdj]

EasyRSA Behavior Change - 3.0.8 - 3.2.0 - EASYRSA_REQ_CN / --req-cn /--subject-alt-name

[TinCanTech]

@joubertdj relax .. you can leave this open, for now.

[joubertdj]

@TinCanTech : Hehehe ... yeah, please don't ask why I never used the FQDN ... I think I "did" at one point but when I placed an "explanation" instead of FQDN it "looked better" (or something like that ... there was also some RFC that indicated CN's aren't really used/considered but the SAN is the priority (this works with most/all our systems ... ))

Ah well, thanks, I will just have to amend though then ...

[TinCanTech]

@joubertdj Please show the command and output using the --verbose switch.

[joubertdj]

@TinCanTech : Thanks for the quick response.
I was able to add the SAN stuff via the "--san" option when doing a "sign-req". But the CN I am still "stumped" ...

The command:
./easyrsa --req-cn="Trapeze South Africa - TSA-HTE - Router1 Server" --verbose gen-req "router1" nopass
The output of the above command with "--verbose" is:

select_vars: PWD/pki/vars 
Using Easy-RSA 'vars' configuration:
* /mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/pki/vars
source_vars: CLEAN '/mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/pki/vars'
source_vars: sourced OK '/mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/pki/vars'
mutual_exclusions: COMPLETED
 > EASYRSA_EXT_DIR: /mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/x509-types
> EASYRSA_SSL_CONF: /mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/openssl-easyrsa.cnf
  > EASYRSA_TOOLS_LIB: undefined
  locate_support_files: COMPLETED
  verify_ssl_lib():
Using SSL:
* openssl OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
  verify_working_env: BEGIN
  secure_session: CREATED: /mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/pki/ba92208a
  write_easyrsa_ssl_cnf_tmp: SSL config EXISTS
  write_easyrsa_ssl_cnf_tmp: SSL config IGNORED
  easyrsa_mktemp: ssl_cnf_tmp OK: /mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/pki/ba92208a/temp.0.1
  write_easyrsa_ssl_cnf_tmp: SSL config using temp-file
  verify_algo_params: Params verified for algo 'rsa'
  verify_working_env: COMPLETED Handover-to: gen-req

EasyRSA version 3.2.0

Error
-----
Option conflict --req-cn:
* 'gen-req' does not support setting an external commonName

  mktemp_counter: 1 uses
  remove_secure_session: DELETED: /mnt/c/Data/Work/Trapeze/Projects/2024/TSA-HTE/Backups/Certificate Authority/Current/pki/ba92208a
  Exit: Known errors = true

[joubertdj]

When I try to use the sign-req for the --req-cn it also complains about that ...

[TinCanTech]

@joubertdj Thanks.

First: Upgrading from v3.0.8 to v3.2.0-D is understanably difficult.

With regard to your SAN use, you have figured out the solution. 👍

With regard to your use of --req-cn, that is no longer supported.

The commonName must be the same as the file_name_base.
The exception is build-ca, which allows setting the CA commonName.

This change was made in commit: 7227909

I will expand on this decision later.

However, you have to accept that your use of --req-cn is obscure and bizarre.

[VVD]

My usage is more easy:

/usr/local/bin/easyrsa gen-req "${USER}" nopass batch
/usr/local/bin/easyrsa --batch --passin=pass:"$CA_PASSWORD" sign-req client "${USER}"

but it is broken now too with same error:

EasyRSA version 3.2.0

Error
-----
Option conflict --req-cn:
* 'gen-req' does not support setting an external commonName

# /usr/local/bin/easyrsa --verbose gen-req USERNAME nopass batch
  # select_vars: PWD/pki/vars
Using Easy-RSA 'vars' configuration:
* /usr/local/etc/openvpn/pki/vars
  # source_vars: CLEAN '/usr/local/etc/openvpn/pki/vars'
  # source_vars: sourced OK '/usr/local/etc/openvpn/pki/vars'
  # mutual_exclusions: COMPLETED
  # > EASYRSA_EXT_DIR: /usr/local/share/easy-rsa/x509-types
  # > EASYRSA_SSL_CONF: /usr/local/etc/openvpn/pki/openssl-easyrsa.cnf
  # > EASYRSA_TOOLS_LIB: undefined
  # locate_support_files: COMPLETED
  # verify_ssl_lib():
Using SSL:
* openssl OpenSSL 1.1.1w-freebsd  11 Sep 2023
  # verify_working_env: BEGIN
  # secure_session: CREATED: /usr/local/etc/openvpn/pki/23c4b028
  # write_easyrsa_ssl_cnf_tmp: SSL config EXISTS
  # write_easyrsa_ssl_cnf_tmp: SSL config IGNORED
  # easyrsa_mktemp: ssl_cnf_tmp OK: /usr/local/etc/openvpn/pki/23c4b028/temp.0.1
  # write_easyrsa_ssl_cnf_tmp: SSL config using temp-file
  # verify_algo_params: Params verified for algo 'ed'
  # verify_working_env: COMPLETED Handover-to: gen-req

EasyRSA version 3.2.0

Error
-----
Option conflict --req-cn:
* 'gen-req' does not support setting an external commonName

  # mktemp_counter: 1 uses
  # remove_secure_session: DELETED: /usr/local/etc/openvpn/pki/23c4b028
  # Exit: Known errors = true

It'm using /usr/local/etc/openvpn/pki/vars with EASYRSA_REQ_CN set to our FQDN of the OpenVPN server:

# grep EASYRSA_REQ_CN /usr/local/etc/openvpn/pki/vars
set_var EASYRSA_REQ_CN          "hostname.domain.name"

[VVD]

Commented in gen_req():

#       [ "$EASYRSA_REQ_CN" = ChangeMe ] || user_error "\
#Option conflict --req-cn:
#* '$cmd' does not support setting an external commonName"

Got same error, but for sign_req, commented in sign_req():

#       [ "$EASYRSA_REQ_CN" = ChangeMe ] || user_error "\
#Option conflict --req-cn:
#* '$cmd' does not support setting an external commonName"

After this my commands work as before (probably).

[TinCanTech]

It is good to see that EasyRSA code is easy to customise.

Version 3.1.7 also has the functionality that you desire.

Version 3.2.0 is a development snapshot.

[joubertdj]

@TinCanTech : This was the RFC I was referring to that indicated that the CN isn't preferred anymore, but SAN: https://www.rfc-editor.org/rfc/rfc2818.html, this portion:

"If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead."

[TinCanTech]

@joubertdj Thank you, I am aware of RFC2818.