Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Remote Access VPN - IPSEC with Certificate - connection export .scx file invalid - SFOS 19.5

Remote Access VPN IPSEC with Authentication type certificate does still lead to invalid connection .scx file on SFOS 19.5.0 GA-Build197, SFOS 19.5.1 MR-1-Build278 and SFOS 19.5.2 MR-2-Build624 if the "Organization name" in the Certificate does contain Whitespaces.

There are some Bug Reports like NC-85383 and NC-95633 whitch are listed as "resoled issues" at the release notes: https://docs.sophos.com/releasenotes/index.html?productGroupID=nsg&productID=xg&versionID=19.5

Looks like the same Problem is reported for older Firmware Versions:  IPSEC Remote Access .scx file invalid 


CA Settings

No "German" Umlaute / "Special" Characters but Whitespaces in Company Name Organization Name.

Certificate Settings


Content of xxx.scx:

cannot open file /tmp/root_cert.txt at /scripts/vpn/ipsec/generateJSONVPNClientConf.pl line 331.

Distinguished name:

/C=DE/ST=NRW/L=City/O=The Example GmbH/OU=IT/emailAddress=info@example.com


Update

It does still happen on 19.5-MR2.



This thread was automatically locked due to age.
Parents
  • If I remove the Whitespaces in "Organization Name" for the Certificate, the .scx file is generated correctly.

    Please fix the BUG!



    Update
    [bearbeitet von: philbert um 9:01 AM (GMT -7) am 9 Jun 2023]
  • We tried to reproduce the issue on the SFOS 19.5.1 MR-1-Build278, we are not hitting the issue.

  • Thanks for your Feedback.

    Whitespaces are at the Organization Name not Company Name, I`ve edited my post.

    Certificate details looks like this:

    Country name: Germany
    State: XYZ
    Locality name: Somewhere
    Organization Name: The Example Company GmbH
    Organization unit name: IT
    Common Name: xyz.example.com
    Email address: somebody@example.com

    DNS names: xyz.example.com

    If I change Organization Name to "TheExampleCompanyGmbH", it works.

    Did you test with a "new" Config on SFOS 19.5? Maybe it only happens with config upgraded from older Version? I believe we startet with the Firewall around SFOS 17 and updated at least to every Major MR Release.

  • Just to be sure: Do you have special characters somewhere? Because in Germany, you can easily do something like "Köln" or "München" as a City or street. 

    __________________________________________________________________________________________________________________

  • Hi Philbert,

    This is the update after some more testing on this issue by our QE.

    >>>

    I configured IPSec RA in 19.0 MR1 (Akamaru) build 367, with spaces in Organization Name (also in common name and organizational unit), where the issue is present. Then I upgraded to 19.5 MR1 (Hatutu) build 278, where the fix is present. Before upgrade, I could see the scx file throwing the error and after the upgrade I could see the scx file getting generated successfully and I was able to connect from Windows too.

    We suspect that there could be some other issue in the certificate in the customer’s case. Would it be possible to get access to the customer device to check what else may be missing?

    >>>

  • No, we do not use special characters in or around the Certifikate AFAIK.

Reply Children
  • Did some more testing with 19.5-MR2 (still the same issue).

    Without Whitespace in Org Name: "TheExampleCompany" - OK: 

    SG230_WP02_SFOS 19.5.2 MR-2-Build624 HA-Primary# cat /tmp/vpnclientconfdetailsjson.txt
    ra_ipsec"#"tunnel"#"rw"#"cert"#"111.222.333.444"#"111.222.333.444/255.255.255.255,10.48.20.0/255.255.0.0,192.168.2.0/255.255.255.0"#"/C=NA/ST=NA/L=NA/O=NA/OU=NA/CN=Appliance_Certificate_xxx/emailAddress=na@example.com"#"x509"#"*"#"/C=DE/ST=XXX/L=Example/O=TheExampleCompany/OU=IT/CN=vpn.example.com/Email=info@example.com"#"x509"#"1"#"4"#"3600"#"y"#"0 "#"60 "#"120"#"m"#"aes256"#"sha2_512"#""#""#""#""#"15|21|31|"#"y"#"aes256gcm16"#"sha2_512"#""#""#""#""#"15"#"5400"#"y"#"a"#"2"#"y"#"2"#"0"#"y"#"y"#"y"#"y"#"n"#"1"#"y"#""#"foo.example.com"#"RemoteAccessIpsecVpnNoWhitespace"#"root_cert"#"
    
    SG230_WP02_SFOS 19.5.2 MR-2-Build624 HA-Primary# perl /scripts/vpn/ipsec/generateJSONVPNClientConf.pl /tmp/vpnclientconfdetailsjson.txt
    {
       "dpd_delay" : "60 ",
       "local_auth" : {
          "otp" : true,
          "pubkey" : {
             "cert" : "-----BEGIN CERTIFICATE-----\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n-----END CERTIFICATE-----\n",
             "id" : "/C=DE/ST=XXX/L=Example/O=TheExampleCompany/OU=IT/CN=vpn.example.com/Email=info@example.com",
             "key" : "-----BEGIN RSA PRIVATE KEY-----\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n-----END RSA PRIVATE KEY-----\n"
          },
          "xauth" : {
             "can_save" : true
          }
       },
    ....

    With Whitespace in Org Name: "The Example Company" - ERROR:

    SG230_WP02_SFOS 19.5.2 MR-2-Build624 HA-Primary# cat /tmp/vpnclientconfdetailsjson.txt
    ra_ipsec"#"tunnel"#"rw"#"cert"#"111.222.333.444"#"111.222.333.444/255.255.255.255,10.48.20.0/255.255.0.0,192.168.2.0/255.255.255.0"#"/C=NA/ST=NA/L=NA/O=NA/OU=NA/CN=Appliance_Certificate_xxx/emailAddress=na@example.com"#"x509"#"*"#"/C=DE/ST=XXX/L=Example/O=The Example Company/OU=IT/CN=vpn.example.com/Email=info@example.com"#"x509"#"1"#"4"#"3600"#"y"#"0 "#"60 "#"120"#"m"#"aes256"#"sha2_512"#""#""#""#""#"15|21|31|"#"y"#"aes256gcm16"#"sha2_512"#""#""#""#""#"15"#"5400"#"y"#"a"#"2"#"y"#"2"#"0"#"y"#"y"#"y"#"y"#"n"#"1"#"y"#""#"foo.example.com"#"RemoteAccessIpsecVpn"#"root_cert"#"
    
    SG230_WP02_SFOS 19.5.2 MR-2-Build624 HA-Primary# perl /scripts/vpn/ipsec/generateJSONVPNClientConf.pl /tmp/vpnclientconfdetailsjson.txt
    cannot open file /tmp/root_cert.txt at /scripts/vpn/ipsec/generateJSONVPNClientConf.pl line 345.

    Remote Access would be possible.

  • There is 1 known issue that when the subject fields of the issuer cert exactly matches with the subject fields of the issued cert we see this issue. Ideally default ca's fields should be unique. Could you please check if you have the unique default CA, if we hit this issue ? 

  •   

    I am not sure if I understand you correctly, sorry.

    This is what the Remote Access Config looks like:

    This is what the Remote Certificate / Remote ID looks like:

    Subject and Issuer are the same.

    For Local ID, we use the Appliance Certificate with a different Subject.

    So I believe we hit the issue?

  • Update from the team on this - 

    The issuer and subject field is same for the client certificate. Only Root CA will have the issuer and subject fields same. Whenever certs are generated using Default.pem as the root CA we should ensure that the subject fields are not same. This is the reason they are seeing this issue and when they remove the space it goes away. For now they can change this. But to handle this kind of issues in future, we should block the user from creating these certs with the same fields that matches issuer’s in the UI.

  • Thanks for the Update.

    Change the CA Subject to be slightly different from the Remote Access Certificate, and now the Config export is ok.

    I agree, this Issue should be prevented.

    Will there be a Issue ID?

  • Thanks. WE will create one for the future release.