If I remove the Whitespaces in "Organization Name" for the Certificate, the .scx file is generated correctly.

Please fix the BUG!

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.

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

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 ? 

 Giridhar Katti 

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.