--subca-len=X sign-req ca honour user set critical flag in ca

[dekeonus]

During sign_req with crt_type = ca and $EASYRSA_SUBCA_LEN set, check for critical flag presence in existing basicConstraints within the ca file.

Note as the user may have something like:

basicConstraints = critical, CA:TRUE
basicConstraints = CA:TRUE

only check the last occurrence of basicConstraints

While I have used awk to solve this, a grep |tail |grep could also be used:

if grep '^[[:blank:]]*basicConstraints[[:blank:]]*=' "$EASYRSA_EXT_DIR/$crt_type"|tail -n 1|grep -q critical; then

Addresses #691 and partial solution for #448 (noting that build-ca now pulls in COMMON and ca this should be the last piece needed)

[dekeonus]

I do note that the awk check (and example grep-tail-grep pipe) are performed with case sensitive 'critical': openssl rejects as invalid both 'CRITICAL' and 'Critical' (other capitalisation variations were not checked -as they are likely an unintended bug in upstream openssl).

[TinCanTech]

I am leaning more toward having an option something like:

• easyrsa --subca-len=X --bc-critical sign-req ca ca
• easyrsa --bc-critical sign-req server srv
• easyrsa --bc-critical build-ca nopass
• easyrsa --bc-critical build-X-full x1 nopass

Assign basic constraint critical:

	--bc-critical)
		empty_ok=1
		export EASYRSA_BC_CRITICAL="critical, " ;;

sign-req Use basic constraint critical:

	# Support a dynamic CA path length when present:
	# Support basic constraint critical:
	if [ "$crt_type" = "ca" ]; then
		if [ "$EASYRSA_SUBCA_LEN" ]; then print "\
	basicConstraints = ${EASYRSA_BC_CRITICAL}CA:TRUE, pathlen:$EASYRSA_SUBCA_LEN"
		else print "\
	basicConstraints = ${EASYRSA_BC_CRITICAL}CA:TRUE"
		fi
	else print "\
	basicConstraints = ${EASYRSA_BC_CRITICAL}CA:FALSE"
	fi

build-ca Use basic constraint critical:

	# Support basic constraint critical:
	print "basicConstraints = ${EASYRSA_BC_CRITICAL}CA:TRUE"

[dekeonus]

--bc-critical

This seems like a lot of extra work (i.e. always remembering to set the command line arg) for a user who defaults to having basicConstraints = critical [blah] in their x509-types files

With --bc-critical is there any point to modifying the x509-type files as your changes will never automatically make it into the certs.
My expectation is that: if I modify the x509-types files, my changes will show up in the generated certs (unless further overridden by other command line options).

EDIT: To be clear, I think modifying the x509-types files SHOULD be the way supported extensions are set (except for rare circumstances).

[dekeonus]

An additional drawback of --bc-critical is that it would then be inconsistent behaviour with respect to critical appearing in keyUsage, extendedKeyUsage, or other user added/modified extensions

[TinCanTech]

am leaning more toward

I was only leaning.

I agree with your point about permanently editing x509-types/*.

Bottom line: Your awk solution does work, even in Windows.

[TinCanTech]

This has been a long standing issue for EasyRSA, as noted by this comment:

# X509 extensions for a ca

# Note that basicConstraints will be overridden by Easy-RSA when defining a
# CA_PATH_LEN for CA path length limits. You could also do this here
# manually as in the following example in place of the existing line:
#
# basicConstraints = CA:TRUE, pathlen:1

Source: x509-types/ca

It is also a rare use case.

I think this should go into v3.1.1.

[TinCanTech]

@dekeonus this needs a Changelog update, please. I will, if you prefer..

[dekeonus]

• The awkscript is now a text extraction (vs exit code check).
• If the user has commented basicConstraints = blah the code will add a new basicConst line (same as old behaviour).
• If the user already has a pathlen:X option on the line, the code will append an additional pathlen:$X option. Openssl will discard the earlier pathlen:X (from ca file) and only consider the pathlen:X generated from the easyrsa command line --subca-len=X

an example extension_temp generated with pathlen:9 in x509-types/ca

# X509 extensions added to every signed cert

# This file is included for every cert signed, and by default does nothing.
# It could be used to add values every cert should have, such as a CDP as
# demonstrated in the following example:

crlDistributionPoints = URI:http://example.net/pki/git_subtCA.crl

# The authority information access extension gives details about how to access
# certain information relating to the CA.

authorityInfoAccess = caIssuers;URI:http://example.net/pki/git_subtCA.crt
# X509 extensions for a ca

# Note that basicConstraints will be overridden by Easy-RSA when defining a
# CA_PATH_LEN for CA path length limits. You could also do this here
# manually as in the following example in place of the existing line:
#
# basicConstraints = CA:TRUE, pathlen:1

basicConstraints = CA:TRUE, pathlen:9
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
keyUsage = cRLSign, keyCertSign
basicConstraints = CA:TRUE, pathlen:9, pathlen:1

results in a cert with pathlen:1
openssl x509 -noout -ext basicConstraints -in ssub2CA.crt

X509v3 Basic Constraints: 
    CA:TRUE, pathlen:1

[TinCanTech]

There is also a basicConstraints in openssl-easyrsa.cnf for easyrsa_ca.

Due to complications, this has to be moved to v3.1.2 - Planned changes milestone.

[dekeonus]

There is also a basicConstraints in openssl-easyrsa.cnf for easyrsa_ca.

Without a user calling openssl directly, is there still a code path that doesn't override easyrsa_ca with the extensions in x509-types/ca? As build_ca() now includes the COMMON and ca