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 extension

    Any ideas?

    Thanks,
    Colton


  • Rebel Alliance Developer Netgate

    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


  • LAYER 8 Global Moderator

    "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


  • LAYER 8 Global Moderator

    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..



  • LAYER 8 Global Moderator

    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!


  • LAYER 8 Global Moderator

    Oh so your saying it works with email SAN as long as no space in the CN…  Odd...... hmmmmm


  • Rebel Alliance Developer Netgate

    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.


Log in to reply