SonicWall NetExtender 10.3.0 Linux client (equivalent --always-trust like 10.2.850 version?)

Answers

• Robertus Newbie ✭

  December 11 edited December 11

  There was another option in version 10.2.850 or below - to add to~/.netextender in section [trustedcerts] a server and cert's fingerprint like that:

  [trustedcerts]
  
  X.X.X.X:4433=SHA1[1F:1C:1D:1E:12:18:11:14:1B:18:16:1E:18:1B:14:12:1C:13:17:18]
  

  but it doesn't work either.

  Is there any solution to trust some cert and save that in settings for NetExtender 10.3.0?

  1
• byroniac Newbie ✭

  December 11

  https://community.sonicwall.com/technology-and-support/discussion/comment/22776#Comment_22776

  I didn't know that. Thanks. I believe that there has to be some way to do either of these things in the new client, but perhaps they are undocumented?

  0
• Robertus Newbie ✭

  December 13 edited December 13

  @byroniac

  I've found that there is a workaround for our problem - adding a profile for the connection to the profiles list. When adding a new connection, you are asked whether to trust the certificate. This answer is remembered and you won't be asked for the certificate again until it changes.
  
  Example:

  nxcli connection add MyConnection --server X.X.X.X:4433 --username=my_name --domain=localdomain --protocol Auto
  
  # then to connect:
  
  nxcli connect MyConnection
  

  For more look at nxcli connection --help.
  
  The main problem - all profile details are saved into file /etc/SonicWall/NetExtender/Config/profile.jsonwhich - by default - is available for reading for all system users.

  0
• byroniac Newbie ✭

  December 16

  Robertus, thank you, but I've already tried that. It works great in Windows, but not Linux. In Windows, it will prompt me to trust the server certificate (my work VPN has a weird invalid self-signed certificate). In Linux, the debug log just shows a failure to retrieve the server certificate with an EOF message, and I will usually get the message, "Failed to get Logon ID". I think our VPN appliance is configured differently than normal and I am just an end-user for our work VPN so I don't administer it. It has the most recent firmware updates according to my boss. On Linux, I'm stuck using the old 10.2.850 client version with the undocumented —always-trust flag.

  0
• Robertus Newbie ✭

  December 17 edited December 17

  Are you able to retrieve cert and established a connection with your VPN server in other way (by a connection I mean a TCP connection, not fully working VPN connection)?

  Try using openssl:

  openssl s_client -showcerts -connect server_address:port -servername server_address </dev/null 2>/dev/null
  

  If you will see a correct handshake there is a chance to get the cert's fingerprint and try manually set the profile with that fingerprint as trustedCert. Maybe that way new NetExtender will allow for selfsigned cert?
  
  The new profile configuration has entry:

  "trustCert": "8f4c3d8e22988194fb68866e48eb04328c138798"
  

  This is the cert's SHA-1 fingerprint. You can use openssl to count it by yourself:

  openssl s_client -showcerts -connect server_address:4433 -servername server_address </dev/null 2>/dev/null | openssl x509 -fingerprint -sha1 -noout
  

  If that will not work then probably only adding that selfsigned cert to CA store could work. But the main problem is to get know what CA store new netExtender is using.

  2
• byroniac Newbie ✭

  December 17 edited December 17

  Rats! That is very interesting, but it didn't work for me. I added the "trustCert" and the hash I got from the openssl command you gave for my VPN server in the format you showed "trustCert" above to the /etc/SonicWall/NetExtender/Config/profile.json file but I still get the error message, "Failed to get logon id." Not sure why the Linux client is failing/restricted when the Windows client just pops up the (invalid) self-signed certificate and gives me an option to always trust it (so never bothers me again). The Linux client doesn't even get that far. I must have something misconfigured on my end, but I know very little about certificates and openssl. Also, I don't understand why the older 10.2.850 Linux client works (it will even prompt to accept the invalid self-signed certificate like the Windows client does if I don't use the —always-trust parameter). And, I have the self-signed certificate in Windows, but I can't add it on the Linux side because I don't know the password to it. I am going to ask my boss and see if I can get that information or figure something out, and try your suggestion of adding the certificate itself to my Linux connection, and if so, that may work!

  0
• Robertus Newbie ✭

  December 18

  but I can't add it on the Linux side because I don't know the password to it

  You don't need the password - certificates don't have them. Only private key is sometimes protected by password.
  
  The part which should be added to CA store is a public part - the certificate - and is always sent to client in unencrypted channel at the first part of establishing a SSL/TLS connection.
  
  You cant save that cert into file using openssl :

  openssl s_client -showcerts -connect server_address:443 -servername server_address </dev/null 2>/dev/null|openssl x509 -outform PEM > server_cert.pem
  

  You can then check downloaded certificate details with openssl too:

  openssl x509 -in server_cert.pem -noout -text
  

  In that way you can download certificate sent by any server during SSL/TLS handshake.

  2
• byroniac Newbie ✭

  December 19

  I think I understand your command, but I was only able to actually get certificate data back once, and I had disabled the input and output redirects for that instance, and now I seem to only get an error message of the connection being refused or nothing at all. Tested again with 10.2.850 and it works fine on Linux. I have no idea what is going on with it, but I appreciate all the help. I might just have to give up and use the Windows version or wait for a Linux patched version (next year?).

  0