This message appears when uploading an external CA certificate to the sistem. "Only self signed CA certificates can have identical subject and issuer fields". It's a Microsoft-adfs autosigned CA certificate used to sign SAML messages and we can't not change that, you know if there's any way to upload this certificate to the system in order we can use it? thanks!
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:
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 \
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
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.
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.
Hi @chyates ,
We need to renew the certificate for our SAML and today when I was preparing for this change I experiance the same message so with quick tests on lab VM we came up with the following steps
1. Import the IdP metadata as XML file. In our case with ADFS we use the link https://<your-adfs.local>/FederationMetadata/2007-06/FederationMetadata.xml
2. Go to Device -> Server Profiles -> SAML -> Import (at the bottom) and import the metadata. This will automatically create:
a. New certificate - the self signed used by the IdP
b. New SAML profile already using the new certificate
3. We edit the old SAML profile (which is used for GP auth) and configure it to use the new certificate
4. Remove the new SAML profile (as it is not needed)
5. Commit. At this point a warning for duplicated certificate will show, but if everything is working with the new cert, just delete the old one and commit again.
I sure that the same approach is applicable for Panorama deployment as well, or if it is completely new SAML setup (skip the part with removeing the saml server profile).
As I mentioned I have tested this once on lab VM, but looking at the successfull commit without warning and errors I don't see any reason to bother with the CA flag. Even without CA flag and self signed FW was still showing the certificate in the dropdown menu under the SAML server profile
Did anyone get a satisfactory answer on this?
Like some of those above, I am attempting to renew the SAML Signing Certificate for Azure AD. Once you click "new", "save" in the Azure portal, you can download a new XML file and this XML file imports without error in PanOS - however PanOS is importing the PREVIOUS signing certificate, despite the XML referencing the new certificate.
i.e., the XML starts with:
<RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706"> <KeyDescriptor use="signing"> <KeyInfo> <X509Data> <X509Certificate>
...and references the NEW certificate, however the PanOS UI simply shows the OLD certificate twice in the certificate list.
Is there a bug in PanOS that doesn't understand how to parse certificates from the XML when another SAML profile with the same IDP is present? I certainly don't want to have to destroy the complete SAML configuration on a production system.
None of this was a problem until Palo Alto shot themselves in the foot by disallowing the import of self-signed certificates. Having to re-import a whole SAML server profile to renew a certificate is stupid.
Do I have to backup the entire running config, edit it in notepad with this new cert and import it back?
As you can see in the below, while the new profile references the new cert, the old certificate shows up instead:
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!