Resolving SSL certificate selection problems in Sophos VPN

I hit this twice on different Sophos firewalls. I imported a signed SSL certificate, went to assign it to SSL VPN, and the dropdown still only showed ApplianceCertificate. The firewall kept presenting the old certificate. These are the checks that mattered.

What you see

The SSL Certificate Selection menu in the VPN settings will not list the certificate you just uploaded. You expect to see it in the Select server certificate box. Instead you get lines like these:

  • “Only ApplianceCertificate available in dropdown”
  • “SSL VPN – Certificate Verification Failed” (log title)

You can upload the certificate and still see it under Certificates > Certificates, but VPN > Show VPN settings > SSL server certificate only shows ApplianceCertificate. The uploaded certificate should appear there so it can be selected for the VPN.

Client-side errors can follow. The VPN client may say the server certificate does not match, or the browser and user portal may keep showing the old certificate. That points to the firewall presenting the wrong certificate during the TLS handshake.

Where it happens

Check these GUI locations in this order:

  • Certificates > Certificates. This lists imported certificates and keys. Confirm the certificate is there and check the fields shown.
  • VPN > Show VPN settings. Open the SSL VPN settings and expand the server certificate selector. This is where the SSL certificate must be chosen.
  • Certificate management sections used by Admin Console or WAF. Sometimes the certificate is visible to one feature and not another.

Sophos documents how SSL VPN uses the server certificate and how to upload certificates, so the official guidance is worth checking:

If the certificate appears under Certificates > Certificates but not in the VPN selector, the usual causes are the wrong certificate type, a missing private key, or a naming conflict with ApplianceCertificate.

Find the cause

Work through the checks below.

1) Verify the private key is present

  • Expected: the GUI entry shows a private key attached, or the file is a PKCS#12 import.
  • Quick test off the appliance: export the certificate file and run this locally:
openssl x509 -in cert.pem -noout -text
openssl pkcs12 -info -in cert.p12
  • If OpenSSL reports the certificate but no private key, the import was incomplete. The firewall may list the certificate but not make it available for server use.

2) Check the subject name and SAN against the VPN FQDN

  • Expected: the CN or SAN contains the public FQDN clients use.
  • If it does not match, clients will reject the certificate even if it is selected.

3) Check certificate type and conflicts

  • If the only selectable certificate is ApplianceCertificate, the problem is often a duplicate FQDN or an existing appliance certificate with the same name. Sophos will refuse to replace or show a conflicting certificate.
  • Another cause is importing the certificate for webserver use only, not for appliance or server use. If the usage is wrong, SSL VPN will not list it.

4) Check character set or format problems

  • Some Sophos versions are strict about characters in certificate fields. Non-Latin characters in CN or SAN may block selection.

5) Check the logs

  • Look in Logs & Reports > View local log files and inspect the system and VPN logs.
  • Look for entries like Certificate Verification Failed or errors mentioning private key missing or cannot load certificate.
  • When the certificate is valid, those load errors should not appear.

Fix

Work through these in order. Only apply what fits the problem.

1) Re-import the certificate correctly

  • Use a PKCS#12 (.p12/.pfx) file that contains the certificate and private key where possible. Check it first with openssl pkcs12 -info -in file.p12.
  • In Certificates > Certificates, choose Add and import the PKCS#12. Give it a clear name.
  • If you only have PEM files, import the certificate and key together and verify with openssl x509 -in cert.pem -noout -text.

2) Deal with appliance name conflicts

  • If an existing ApplianceCertificate uses the same FQDN, delete or rename the old entry first. On some SFOS versions the old appliance certificate blocks replacement with the same FQDN. Only remove it once you have checked it is safe to do so in a maintenance window.

3) Make the certificate available to services

  • After import, open VPN > Show VPN settings and expand the SSL server certificate selector. The new certificate should appear. Select it and click Apply.
  • If it still does not show, disable SSL VPN, apply the change, then re-enable it. Some config changes only take effect when the service restarts.

4) Check the firewall rules

  • Confirm the WAN->Firewall rule allows TCP 8443, the default SSL VPN port, to reach the firewall. If NAT or port changes hide the service, the VPN handshake may not reach the code path that presents the chosen certificate.
  • If you changed the VPN port, test connections on the new port.

5) Restart or reapply services

  • Instead of a full reboot, toggle SSL VPN off and on in VPN > Global and click Save. If the appliance still behaves oddly, plan a maintenance reboot.

The most common cause I have seen is a missing private key on import, or a name conflict with the existing ApplianceCertificate. Re-importing as PKCS#12 and checking the firewall treats it as a server or appliance certificate fixes it most of the time.

Check it is fixed

Use these checks and note expected versus actual.

1) Verify certificate selection in the GUI

  • Expected: VPN > Show VPN settings > SSL server certificate shows the new certificate name.
  • Actual: the dropdown lists the new certificate and it stays selected after Apply.

2) Test the TLS handshake live

  • From a client or laptop:
openssl s_client -connect firewall.example.com:8443 -servername firewall.example.com
  • Expected: the server presents the new certificate chain. Check the CN/SAN and validity dates returned by OpenSSL match the certificate you uploaded.
  • A mismatch means the appliance is still serving the old certificate.

3) Test VPN connectivity

  • Authenticate and bring up an SSL VPN session. Check that the client does not show certificate warnings and the tunnel comes up.
  • Expected: the connection establishes with no certificate name mismatch.

4) Watch the logs

  • Search the system and VPN logs for Certificate Verification Failed or private key missing.
  • Expected: no certificate load or verification errors during client connections.

Takeaways

  • If the certificate is visible in Certificates but not selectable for the VPN, check the private key and certificate purpose first.
  • Import as PKCS#12 where you can.
  • Check for FQDN conflicts with ApplianceCertificate before replacing anything.
  • Use openssl s_client locally to confirm the firewall is actually presenting the certificate you expect.

Related posts

Weekly Tech Digest | 06 Jul 2026

Stay updated with the latest in tech! This digest covers AI ethics, auto industry shifts, and the impact of politics on technology, exploring today's pressing issues.

wolfCOSE zero-allocation parsing in embedded C

wolfCOSE looks sensible only if you care about what your firmware actually has to carry. I like that, because on small targets the wrong crypto feature can cost more than the message itself, and there...

restic | v0.19.1

restic v0 19 1: safer FUSE mounts and mountpoint checks, robust backup source and exclude handling, clearer CLI JSON output, Windows SFTP deletion fixes