OpenVPN\Certificate Creation SSL Errors
-
Hello All,
I am at a loss.
I upgraded to 2.4.2, and this issue started to occur. When I try to create an internal certificate with the CA for openVPN it creates this error.
The following input errors were detected:
•openssl library returns: error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name
•openssl library returns: error:22097069:X509 V3 routines:DO_EXT_NCONF:invalid extension string
•openssl library returns: error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extensionAny ideas?
Thanks,
Colton -
What are the exact inputs you used for each field?
-
Method: Internal Certificate
Descriptive Name : Test Certificate
CA: MyOpenVPNCa
Keylength: 2048
Digest Algorithm:Sha256
Lifetime: 3650
CountryCode:US
State:State Abbreviation
City:MyCity
Organization:MyOrgName
OU: Left blank
Email: User Email
Common Name:Test Certificate
Certificate Type: User Certificate
Alternative Name: Email Address: User Email -
"Common Name:Test Certificate"
Yeah that is not going to work.. Get the same error when you do that… Use something like actual username of the user for the vpn connection... Say secretlycool for example..
Username as CN with spaces not going to be valid since a CN "space" is not a valid character..
-common-name <fqdn or="" custom="" common="" name="">- FQDN or Custom Common Name
This specifies the desired certificate name as a fully qualified domain name (FQDN) or custom common name or the name of a person. The supported characters, which are a subset of the ASCII character set, are as follows:
o Letters a through z, A through Z
o Numbers 0 through 9
o Asterisk (*), period (.), underscore (_) and hyphen (-)The common name must not start or end with a "-" or a ".". The maximum length is 253 characters.</fqdn>
-
On the old build you I have CNs with spaces. But this worked without issue!
Thanks,
Colton -
sorry but a CN with spaces would never be valid.. Its not a valid FQDN…
edit: Hmmmm You sure you were not adding that as fqdn as SAN... I just tested this and created cn of test cert without any problem..
When I first tested this I got the same exact error.. But now I can not seem to duplicate it.. I was doing some more research and while your fqdn like in a san has to meet those requirements, etc. common name seems to be able to have a space.. Hmm... Normally CN is a fqdn of the webserver.. But your using this as user cert etc.. So yeah I can see like name John Doe might be appropriate on the cert..
But been trying all kinds of possible combos and can not duplicate this now... Strange... Wish I would of taken screenshot when got the error..
-
Ah ok found it - when you try and add a san of email address it creates those errors..
even the email address format is correct name@domain.com
I had jumped on the CN because normally a CN would have to be a DNS valid name, etc. But this seems to be where the problem is.. I jumped on that because I am never fan of using spaces in such thing, be it file name or directory name.. Habit from when you never used spaces ;) Been doing this many many years. But from what I have seen as to a CN in a user cert sure spaces are valid.. And from above you can see can create them without any issue. But seems might be a bug.. hate to say that in in the parsing of the email address section for the SAN..
"Alternative Name: Email Address: User Email "
But I can duplicate your problem.. So prob need to file a bug report using this thread as reference.. I can fire up previous versions and see if its a regression, etc. If your saying you use to create certs with email addresses as SAN before without issue.
-
Only when there is a space in the common though? Seems odd to me. Could be a bug? No Space allowed this to work without issue.
Once again thanks for the help!
-
Oh so your saying it works with email SAN as long as no space in the CN… Odd...... hmmmmm
-
It's actually not the e-mail address that is the trigger but any SAN in addition to a CN with a space. It tries to copy the CN to the SAN list, but a CN with a space can't make a valid SAN entry, so it ended up with a bunk empty entry due to the way I coded that feature originally.
https://redmine.pfsense.org/issues/8252
I just pushed a fix, should show up in a few minutes.
