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

[LuisMateosCaro]

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! 

[JohnWade]

Thanks for replying, I really appreciate it.   As to the workaround, maybe I am dense, but I dumped out the xml and reviewed the <certificate> block.     Each existing certificate is present and I can see how to change the the <ca></ca> flag, but since I can't import the certificate I need, it is not in this section.   I thought I could just manually add the needed certificate to this section since I have the PEM encoded public key for the certificate, and I can pull most of the fields from the cert, but I was stumped by the subject and issuer hash tags, since I am not aware of what hashing algorithm they are using. (See below for an example CA entry.)

I admit, I must be missing something obvious, can you guide me in the error of my ways?

Thanks,

John

<entry name="DigiCertCA">
<subject-hash>58754cf2</subject-hash>
<issuer-hash>81b9768f</issuer-hash>
<not-valid-before>Oct 22 12:00:00 2013 GMT</not-valid-before>
<issuer>/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA</issuer>
<not-valid-after>Oct 22 12:00:00 2028 GMT</not-valid-after>
<common-name>DigiCert SHA2 High Assurance Server CA</common-name>
<algorithm>RSA</algorithm>
<expiry-epoch>1855828800</expiry-epoch>
<ca>yes</ca>
<subject>/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA</subject>

<public-key>-----BEGIN CERTIFICATE-----
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowcDEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEvMC0GA1UEAxMmRGlnaUNlcnQgU0hBMiBIaWdoIEFzc3Vy
YW5jZSBTZXJ2ZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2
4C/CJAbIbQRf1+8KZAayfSImZRauQkCbztyfn3YHPsMwVYcZuU+UDlqUH1VWtMIC
Kq/QmO4LQNfE0DtyyBSe75CxEamu0si4QzrZCwvV1ZX1QK/IHe1NnF9Xt4ZQaJn1
itrSxwUfqJfJ3KSxgoQtxq2lnMcZgqaFD15EWCo3j/018QsIJzJa9buLnqS9UdAn
4t07QjOjBSjEuyjMmqwrIw14xnvmXnG3Sj4I+4G3FhahnSMSTeXXkgisdaScus0X
sh5ENWV/UyU50RwKmmMbGZJ0aAo3wsJSSMs5WqK24V3B3aAguCGikyZvFEohQcft
bZvySC/zA/WiaJJTL17jAgMBAAGjggFJMIIBRTASBgNVHRMBAf8ECDAGAQH/AgEA
MA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDA9BgNVHSAENjA0MDIG
BFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQ
UzAdBgNVHQ4EFgQUUWj/kK8CB3U8zNllZGKiErhZcjswHwYDVR0jBBgwFoAUsT7D
aQP4v0cB1JgmGggC72NkK8MwDQYJKoZIhvcNAQELBQADggEBABiKlYkD5m3fXPwd
aOpKj4PWUS+Na0QWnqxj9dJubISZi6qBcYRb7TROsLd5kinMLYBq8I4g4Xmk/gNH
E+r1hspZcX30BJZr01lYPf7TMSVcGDiEo+afgv2MW5gxTs14nhr9hctJqvIni5ly
/D6q1UEL2tU2ob8cbkdJf17ZSHwD2f2LSaCYJkJA69aSEaRkCldUxPUd1gJea6zu
xICaEnL6VpPX/78whQYwvwt/Tv9XBZ0k7YXDK/umdaisLRbvfXknsuvCnQsH6qqF
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae
cPUeybQ=
-----END CERTIFICATE-----
</public-key>
</entry>

[Nehmaan]

Is that the actual certificate ?

It's a root CA so it's going to have the CA flag already set.

Export candidate-config:

[JohnWade]

No, sorry if this was not clear.   As I noted, this is just an example certificate from an existing CA taken from the XML config export.   Since I can't import the certificate I need to add through the GUI, it is not in the export to tweak.   

I included the example section to illustrate the fields you would need to have to manually create a certificate entry and import the config.   I think I could put correct values in for most of them but am stumped by what hashing algorithm PaloAlto is using to generate the 

<subject-hash>58754cf2</subject-hash>
<issuer-hash>81b9768f</issuer-hash>

Thanks!

But maybe I don't need to go down this path.    Do you know of another way?

[Nehmaan]

Nothing to do with Palo, Here you go mate.

[JohnWade]

Easy enough, will give it a try.  Should have Googled it or gone to openssl rather than relying on Window's lame SSL cert tools.  Thanks a million

[Nehmaan]

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

[JohnWade]

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.

John   

[Nehmaan]

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 ?

[JohnWade]

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
----------------------------------------------------------
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = <state>
L = <City>
O = <org Name>
OU = <Department>
CN = <FQDN of IdPserver>
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @@alt_name
[alt_names]
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

[JohnWade]

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.

[jagosto]

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.

https://docs.paloaltonetworks.com/globalprotect/8-1/globalprotect-admin/authentication/set-up-extern...

• 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

  Device

  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

  GP-User-Auth

  .
• Browse

  for the metadata file.
• (

  Recommended

  ) 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

  Commit

  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

  OK

  to save the server profile.

[chyates]

@Nehmaan - I am having this issue as well.  in 1) you're exporting from where?  If you couldn't import the certificate, how did you get PANOS .xml?

I'm specifically trying to do this on Panorama into a device group which is a little more challenging.

[aleksandar.astardzhiev]

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

[mcrowley]

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:

[jeffrowan]

1. I know this is an old post, but is there a Palo Alto approved way to avoid this error or is the XML method the only way?