Using ANY environment variables in X509-types files is NOT officially supported

[Yannik]

I'm currently having issues signing a CSR for a Sub-CA (Windows ADCS):

After importing the csr, sign-req results in:

root@linux-ca:~# /usr/share/easy-rsa/easyrsa  --pki-dir=/etc/pki/r1 --days=500 --batch sign-req ca windows-sub-ca
Using SSL: openssl OpenSSL 1.1.1n  15 Mar 2022
Using configuration from /etc/pki/r1/easy-rsa-97041.vut21K/tmp.yirdjz
Enter pass phrase for /etc/pki/r1/private/ca.key:
ca: Error on line 8 of config file "/etc/pki/r1/easy-rsa-97041.vut21K/tmp.asUh5l"
140304590972224:error:0E065068:configuration file routines:str_copy:variable has no value:../crypto/conf/conf_def.c:638:line 8

Easy-RSA error:

signing failed (openssl output above may have more detail)

I have checked line 8 of the config file, it is [ CA_default ], so I don't really know how this could cause an issue. Full config file here: https://pastebin.com/u8HfYDXK

I'm using easy-rsa 3.0.8 from the debian repo.

[Yannik]

I was able to solve this:

By commenting out [ -z "$EASYRSA_TEMP_DIR_session" ] || rm -rf "$EASYRSA_TEMP_DIR_session" in /usr/share/easy-rsa/easyrsa, I could keep the temporary config file. Turns out that it is dynamically generated from various files, and this issue was caused by a line in x509-types/COMMON which used $ENV::CA_NAME for the crlDistributionPoints. Setting that variable fixed the issue.

[TinCanTech]

@Yannik Hi, thanks for reporting this and taking time to try to solve it.

However, your solution is certainly not an acceptable fix, so I'm reopening this for further investigation.

Is there a specific reason why you only put your openssl config file on pastebin ? Do you mind if I paste it here for the record ?

[Yannik]

Hey @TinCanTech

The issue was caused by having added the line

crlDistributionPoints = URI:http://pki.XX.de/$ENV::CA_NAME.crl

to the COMMON file of the x509-types and not having $CA_NAME set.

So it is an issue that is not present with the default easy-rsa config.

However, I would like to suggest to add an parameter to easyrsa which allows keeping (instead of removing) the dynamically generated temporary openssl config.

This would've made debugging this much easier, cause I wouldn't have needed to understand and then modify easyrsa to keep the config and find the root cause for this issue.

[TinCanTech]

I would like to suggest to add an parameter to easyrsa which allows keeping (instead of removing) the dynamically generated temporary openssl config.

This would've made debugging this much easier

That is certainly possible via a --debug switch or something like that. I have been trying to improve debug-ability moving forward.

[TinCanTech]

The issue was caused by having added the line

crlDistributionPoints = URI:http://pki.XX.de/$ENV::CA_NAME.crl

to the COMMON file of the x509-types and not having $CA_NAME set.

So

Ok. That is a nice catch. I'll have to think about some documentation or input checking for such.

[TinCanTech]

We don't need your SSL config, so I will not post that but I will leave this open as a reminder to look into it soon.

[Yannik]

I would like to suggest to add an parameter to easyrsa which allows keeping (instead of removing) the dynamically generated temporary openssl config. This would've made debugging this much easier

That is certainly possible via a --debug switch or something like that. I have been trying to improve debug-ability moving forward.

On a further note, I also needed to comment out the following lines for debugging another issue

        rm -f "$easyrsa_openssl_conf"
        rm -f "$easyrsa_extra_exts"

I have opened a separate issue #610 to track this.

[TinCanTech]

The absolute bottom line is this:

• If you use new variables in any SSL config file then that is on you. PRs concerning the use thereof can be considered.

• easyrsa only has to provide support where LibreSSL is concerned. If you are using LibreSSL then a PR is mandatory for consideration.

[TinCanTech]

To remain open, indefinitely.

[TinCanTech]

https://github.com/OpenVPN/easy-rsa/issues/673#issuecomment-1317526358