Open g0lgs opened 4 weeks ago
@g0lgs Easy-RSA no longer applies a default SAN to every certificate.
The short answer is, use global option --auto-san
to enable the old behavior. Using v3.1.7
is also still supported.
Default SAN removed: https://github.com/OpenVPN/easy-rsa/pull/1091
Auto SAN added: https://github.com/OpenVPN/easy-rsa/pull/1180
An axample from 'openssl req -in requests/test.req -text' (on original request or on a new one) is:
Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:test, DNS:test.local, IP Address:192.168.1.50
FTR: Easy-RSA has never provided both a DNS and an IP as a default SAN, for a single certificate.
FTR: Easy-RSA has never provided both a DNS and an IP as a default SAN, for a single certificate.
I'm not sure what you mean by that statement
my original request was like:
easyrsa --batch --req-cn="test" --subject-alt-name="DNS:test, DNS:test.local, IP:192.168.1.50" gen-req test nopass
so if I then use 3.1.7 like 'easyrsa sign-req server test'
then 'openssl x509 -in issued/test.crt -text' shows:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:test, DNS:test.local, IP Address:192.168.1.50
but 3,2,1 shows no SAN.
@TinCanTech
The short answer is, use global option
--auto-san
to enable the old behavior. Usingv3.1.7
is also still supported.
For me that only creates a SAN with the same name as the request filename not the other two (or more) that I had in my request:
X509v3 Subject Alternative Name:
DNS:test
@g0lgs It is the responsibility of the signing CA to verify the requested attributes.
If you implicitly trust the external request then use global option --copy-ext
.
This can also be set in your `vars file:
set_var EASYRSA_CP_EXT 1
Also, EASYRSA_CP_EXT
is set by default for command build-*-full
.
In future, EASYRSA_CP_EXT
will also be added to vars.example
.
@g0lgs Using v3.2.1
, does command renew
work correctly ?
After downloading 'easyrsa-tools.lib' into the pwd I see that it shows the SAN with all the other Details
Then I get:
Enter pass phrase for <redacted>/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
<REDACTED>
ERROR: adding extensions in section default
139854181107008:error:22075075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported option:../crypto/x509v3/v3_alt.c:551:name=IP Address
139854181107008:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=subjectAltName, value=DNS:test, DNS:test.local, IP Address:192.168.1.50
Easy-RSA error:
easyrsa_openssl - Command has failed:
* openssl ca -utf8 -batch -in <redacted>/pki/reqs/test.req -out <redacted>/pki/17104f3c/temp.3.1 -extfile <redacted>/pki/17104f3c/temp.2.1 -days 1095
EasyRSA Version Information
Version: 3.2.1
Generated: Fri Sep 13 13:04:18 CDT 2024
SSL Lib: OpenSSL 1.1.1f 31 Mar 2020
Git Commit: 3f60a68702713161ab44f9dd80ce01f588ca49ac
Source Repo: https://github.com/OpenVPN/easy-rsa
Host: 3.2.1 | nix | Linux | /bin/bash
Notice
------
Renew FAILED but files have been successfully restored.
Hi,
same here: A "renew" fails with an "unsupported option" error. As a workaround, I used "expire" and "sign-req" and got a certificate with SANs in but also a warning that reads:
WARNING INCOMPLETE Inline file created:
- /usr/share/easy-rsa/pki/inline/hostname.inline
However, the certificate is usable and includes all configured SANs.
(easyrsa 3.2.1 on Debian Trixie)
@dj0nz
Hi,
same here: A "renew" fails with an "unsupported option" error.
What is the option that you are trying to use ?
As a workaround, I used "expire" and "sign-req" and got a certificate with SANs in but also a warning that reads:
WARNING INCOMPLETE Inline file created:
- /usr/share/easy-rsa/pki/inline/hostname.inline
However, the certificate is usable and includes all configured SANs.
(easyrsa 3.2.1 on Debian Trixie)
The warning only indicates that the inline file is incomplete. Either the private key and/or the TLS key are missing.
This is not an error, only user information.
I am using DNS name and IP address as subject alternative names in the conf file. Like this:
[req_cert_extensions] subjectAltName=@subject_alt_name
[ subject_alt_name ] DNS.1 = hostname.local.domain.tld IP.1 = 192.0.2.12
This works when issuing certificates but not when renewing them with "easyrsa renew hostname". As I said before, expiring the certificate and re-issuing it with sign-req is a valid workaround for me.
BTW: For certificates without SANs, the renew command works, but it also generates the "incomplete inline file" warning.
@g0lgs I have identified the bug which causes your error:
ERROR: adding extensions in section default
139854181107008:error:22075075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported option:../crypto/x509v3/v3_alt.c:551:name=IP Address 139854181107008:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:../crypto/x509v3/v3_conf.c:47:name=subjectAltName, value=DNS:test, DNS:test.local, IP Address:192.168.1.50
IP Address:192.168.1.50
should be IP:192.168.1.50
@dj0nz
same here: A "renew" fails with an "unsupported option" error.
What is the option that you are trying to use ?
IP Address:192.168.1.50
should beIP:192.168.1.50
As fas as I can tell my requests created with 3.1.7 were with the 'IP:192.168.1.50' form but viewing the request with 'openssl req' shows the 'IP Address:192.168.1.50' format.
As a test I just created another with 3.1.7 using:
./easyrsa --batch --req-cn="test" --subject-alt-name="DNS:test, DNS:test.local, IP:192.168.0.50" gen-req test nopass
and openssl req still shows:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:test, DNS:test.local, IP Address:192.168.0.50
The same with a new request created with 3.2.1
@g0lgs I have identified the problem: https://github.com/OpenVPN/easy-rsa/issues/1250
I have applied bugfix #1251 #1253 to easyrsa-tools.lib
.
Please, download and replace your current easyrsa-tools.lib
with this new file and test renew
with an IP:n.n.n.n
SAN.
Hi,
I have several Certs used for my Internal Network VM's and devices that are due to expire in the next 14 days or so, each of these appears to have been created using EasyRSA 3.1.7 (as that is waht I had on the VM I used to create them before), but if I try to re-sign the original requests with 3.2.1 then the SANs are not added to the Certs (same applies if I create a new CA and generate the same requests and sign those)
An axample from 'openssl req -in requests/test.req -text' (on original request or on a new one) is:
Any new cert created using 3.2.1 does not contain any SAN and hence Chrome / Opera (at least) refuse to accept the new Certs.
I tried adding '-verbose' option to see if I was missing anything, but that still showed no problems or errors.
If I revert back to using 3.1.7 then I get the SANs
What am I doing wrong ?