Windows Certificate Authority Delivers Certificates that Cannot be Read by PAN-OS

Printer Friendly Page


When using Windows Certificate Authority 2008R2 or later the following may be encountered:

  • SSL client certificate authentication fails on Captive Portal or Global Protect
  • LDAP over SSL connection are failing without a reason
  • Server certificates signed by Windows CA for the use Management or Captive are failing to commit with error message saying there is a use of unsupported algorithms.
  • Decryption Certificate CA signed by Windows CA fails to commit with error message saying there is a use of unsupported algorithms.

At the time of committing to a firewall, you will usually see the following error message which is not exclusive to this problem:

Error: Certificate failed to load: parse tbs certificate not supported algorithm.


By default Windows CA 2008R2 and later will use RSASSA-PSS algorithm to sign its certificates. This algorithm has poor support from many SSL stack vendors and with earlier version of Windows (pre Server2008 and WindowsVista), and is not currently supported by PAN-OS.


Apply one of the following workarounds :

  • [Preferred Solution] Use another Certificate Authority that doesn't make use of RSASSA-PSS algorithm
  • Edit Windows CA server Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\IssuingCA\CSP\AlternateSignatureAlgorithm and set its value to 0. Then delete/re-issue failing certificate with this CA.
    Warning: This operation is not officially supported by Microsoft and should be operated by a competent Windows administrator.

owner: cpainchaud


Using the RSASSA-PSS signature algorithm will also in 7.0 (7.0.2 and 7.0.3 at least) cause error messages such as



Error: Error loading vsys cfg
failed to handle CONFIG_UPDATE_START
(Module: device)
Commit failed


Error: Error preparing global objects
failed to handle CONFIG_UPDATE_START
(Module: device)
Commit failed


Note that the certificates can be imported successfully into the store, and the commit will succeed, but as soon as you try to use one (such as in a certificate profile, or add it to the trusted root CAs of a GP portal configuration), you will get these commit errors.  No mention that the problem is with a certificate at all.


I needed to do a certutil -setreg ca\csp\alternatesignaturealgorithm 0 on both Offline root and Issuing CA, and reissue both certificates.  New certificates issued from the issuing CA then has the (in my case) SHA256RSA signature algorithm.




In 6.0.x release we only used to load the
cert marked as Forward Trust/Forward Untrust or Trusted Root CA in DP.

But in 6.1.x + releases we now load the entire chain if chain is present for
Forward Trust/Forward Untrust certificates. 

Please also check if the parent certs (root ca and Sub ca) are not signed using algorithm RSASSA-PSS


In order for these changes to take affect, I had to restart the CertSvc service on the CA.  Otherwise it will continue to use the RSASSA-PSS signature algorithm.