Incorrect SAN entries presented on signing confirmation

[agowa]

Hi, when signing a csr the confirmation screen shows different SAN entries than the final certificate will contain.

E.g. ./easyrsa --san="ipaddress:127.0.0.1" --san="DNS:localhost.localdomain" sign-req server myCSR

The confirmation screen will show the SAN entries as:

X509v3 Subject Alternative Name:
        ipaddress:127.0.0.1
DNS:localhost.localdomain

Type the word 'yes' to continue(...)

but the final certificate will only have the last one "DNS:localhost.localdomain" within the SAN section.

I also tried these formats: `--san="ipaddress:127.0.0.1,DNS:localhost.localdomain" as well as with a semicolon instead of the comma. However this madethe signing just fail.

Also the help (./easyrsa help options) for this parameter is incorrect. It lists says "Add a subjectAltName." where as in reality it overwrites any and all requested subjectAltNames. So it replaces all subjectAltNames in the request with the ones provided on the CLI instead of amending the requested ones.

Version info:

Version: 3.1.7
Generated: Fri Oct 13 17:27:51 CDT 2023
SSL Lib: OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)
Git Commit: 3c233f....08f0c0f

Edit: The ./easyrsa help altname page correctly states "further invocations of this option will REPLACE the value", HOWEVER the validation screen still shows them. Therefore the open tasks are:

• [ ] Signing validation screen should only show what is left after parsing and what will actually end up in the CRT.
• [ ] Providing --san multiple times eihter should work as expected OR it should throw an exception. But it must not appear to work (esp. in the validate screen) and then cause an incorrect certificate to be signed.
• [ ] "ipaddress:" should be an accepted alias for "IP:"
• [ ] An additional sanity check and warning should be provided when the data from the final certificate differs from the data shown on the validate screen.

[TinCanTech]

Hi, when signing a csr the confirmation screen shows different SAN entries than the final certificate will contain.

E.g. ./easyrsa --san="ipaddress:127.0.0.1" --san="DNS:localhost.localdomain" sign-req server myCSR

The confirmation screen will show the SAN entries as:

X509v3 Subject Alternative Name:
        ipaddress:127.0.0.1
DNS:localhost.localdomain

Type the word 'yes' to continue(...)

but the final certificate will only have the last one "DNS:localhost.localdomain" within the SAN section.

Acknowledged.

Likely, caused by adding the new $EASYRSA_EXTRA_EXTS to the current $EASYRSA_EXTRA_EXTS: https://github.com/OpenVPN/easy-rsa/blob/6f45b81a87b036b563a5061cda1d75fe6ffe2a7f/easyrsa3/easyrsa#L5447-L5451

The only example of such "option addition" in easyrsa.

• [ ] Signing validation screen should only show what is left after parsing and what will actually end up in the CRT.

• [ ] Providing --san multiple times eihter should work as expected OR it should throw an exception. But it must not appear to work (esp. in the validate screen) and then cause an incorrect certificate to be signed.

• [ ] An additional sanity check and warning should be provided when the data from the final certificate differs from the data shown on the validate screen.

Agreed.

• [ ] "ipaddress:" should be an accepted alias for "IP:"

Negative.

[TinCanTech]

This seems to be a left-over from some obscure, early incantation of SAN as an easyrsa option.

The idea that a LF, inside an option that easyrsa intends passing to openssl, as a suitable solution to anything is questionable.

What-ever solution is applied, backward compatibility is not possible.