"Only self signed CA cert can have identical sub and issuer fields" when uploading a certificate


ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

L2 Linker

No problem. Shout if you get stuck or need more help.

L2 Linker

Ah well, spoke to soon, the certificate shows up in the interface under certificates and is marked as valid, but does not appear when configuring the SAML Identity Provider under the "Identity Provider Certificates" pull down.  (all the other certs show up)


Still missing something.



L2 Linker

The only case I've seen that is when the certificate is not valid for SAML purposes. 


Which provider are you using ?


Do you not have an XML file which you can import, Modify CA flag and commit the change ?

L2 Linker

Well, the certificate is in use by the IdP, and 40 plus other service providers are happy with it, but Palo Alto is special I guess.  I created the certificate with:


cat Identity.cnf
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
C = US
ST = <state>
L = <City>
O = <org Name>
OU = <Department>
CN = <FQDN of IdPserver>
keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @@alt_name
DNS.1 = <FQDN of IdPserver>

openssl req -config ./Identity.cnf -new -x509 -nodes -sha256 \
-days 36524 -newkey rsa:2048 -keyout Identity.key \
-out Identity.crt


I am confused by your statement, "Do you not have an XML file which you can import, Modify CA flag and commit the change ?".  I have a metadata xml file for the IdP, but import fails due to the certificate being self signed with issue and subject the same.    I obviously created the named config export XML file and grafted in the certificate with a CA flag set to Yes and reimported, which got me the certificate in Palo Alto but not the ability to use it in this context.  Is there another XML file you are referring to?


Thanks for the help


L2 Linker

Ah well, I switch the CA flag back to "No" and reimported the config, still wasn't choosable.


I then created a SAML Idp configuration, selecting an existing certificate used for something else, exported the config, manually switched it to the correct  certificate name in the xml, and reimported the config.   This imported fine but failed (claiming an invalid certificate) when trying to commit.      It appears that the certificate I hacked in is really not functional for Palo Alto


Support is still struggling to offer any kind of work around.   At this point, my best bet may be to build a second IdP, since I don't have time to do another certificate rollover and need to get this Global protect MFA config running ASAP.   


Thanks for all the help,  still wondering how your workaround is supposed to work.


Have never struggled this much with 40+ other SAML/CAS integrations.

L0 Member

I was struggling with this too, but I went over the instructions again and I just found out that at the very first screen when you click the "SAML identity provider" at the bottom, you can click import. And that is where you upload the XLM file from the azure website and it will automatically create the profile and import you certificate as well. I followed the instructions from the support page. If you click too add the profile your self you went to far and the XML file will not work there as it will be giving the CA warning, I hope this helps.




  • Export the SAML metadata file from the IdP to an endpoint that the firewall can access.
    Refer to your IdP documentation for instructions on how to export the file.
  • Select
    Server Profiles
    SAML Identity Provider
    . ---> Go the Botom and click import  <---
  • Import
    the metadata file onto the firewall.
  • Enter a
    Profile Name
    to identify the server profile, such as
  • Browse
    for the metadata file.
  • (
    ) Select
    Validate Identity Provider Certificate
    (default) so that the firewall validates the IdP certificate.
    Validation occurs only after you assign the server profile to an authentication profile and
    the changes. The firewall uses the certificate profile within the authentication profile to validate the certificate.
  • Enter the
    Maximum Clock Skew
    , which is the allowed system time difference (in seconds) between the IdP and the firewall when the firewall validates IdP messages. The default value is 60 seconds, and the range is 1 to 900 seconds. If the difference exceeds this value, authentication fails.
  • Click
    to save the server profile.



Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!