Installing an Intermediate CA

[CafNetMatt]

I'm getting the following error when I perform a commit on a PA-3020.  PAN-OS 5.0.1.  I know I'm doing something wrong.  I'm new to installing certs so feel free to point and laugh.

I had a certificate signed by GoDaddy for use by Global Protect.  It came signed by an Intermediate CA.

I've created a chained certificate to make sure the Intermediate cert goes to the client so no errors occur.  The chained cert is installed, shows its signed by the GoDaddy root and when I use GP I do not get any certificate errors.  So that part is good.

The chained certificate has the Public Key issued by GoDaddy at the top, the Intermediate cert "Issued To" cert and I imported the private key generated when the CSR was made (CSR created using a Winders server & IIS).  I didn't know what to do with the "Issued By" portion of the Intermediate cert & the chaining document I found in the PAN forums didn't mention it so it didn't get used in the chained cert.  If this is wrong let me know.

The problem is I get an error on the PAN every time I commit:  "vsys1:  Warning:  can't find complete cert chain for <imported_cert_name>".  I think the problem is that I did not import the Intermediate certificate before importing the chained certificate.

Here's my ignorant question:  How do I import the Intermediate cert?  The intermediate cert has two certs in it:  The "Issued To" cert and the "Issued By" cert.  When I import the PEM, is the "Issued By" considered the private key (checking 'Import Private Key')?  Or, do I just leave both "Issued To" & "Issued By" certs together in the PEM file & import it without checking 'Import Private Key'?

I've gone through pretty much all the PAN docs I can find and I get the impression that this bit of knowledge is considered "a given" that the user knows how to do it.

Again, feel free to laugh; it's how I learn.  Appreciate the help in filling this knowledge gap.

[rmonvon]

Hi...Maybe this post will help .

[zarina]

This document walks you through the process of chaining the certificates:

[CafNetMatt]

Read that post and I just did it.  This was a slightly different instruction from the document on chaining or at least the suggestion was clearer.  I took everything in the bundle from GoDaddy and pasted it to the bottom of the server cert.  It imports fine, shows the issuer being Go Daddy Secure Certification Authority but once I link it to the GP Gateway and GP Portal and commit, I get the same error.

[CafNetMatt]

That's the document I originally went off of.

If I understand this correctly, if you chain the certificates then you do not need to import the Intermediate CA to the PA separately.  Correct?

[CafNetMatt]

From my workstation, I issued 'openssl s_client -showcerts -connect client.url.com:443

The interesting thing is I don't get a certificate error on my machine when I connect and never had (meaning I didn't tell GP to install an invalid certificate).

This is the output:

CONNECTED(00000003)

depth=0 /O=client.url.com/OU=Domain Control Validated/CN=client.url.com

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 /O=client.url.com/OU=Domain Control Validated/CN=client.url.com

verify error:num=27:certificate not trusted

verify return:1

depth=0 /O=client.url.com/OU=Domain Control Validated/CN=client.url.com

verify error:num=21:unable to verify the first certificate

verify return:1

---

Certificate chain

0 s:/O=client.url.com/OU=Domain Control Validated/CN=client.url.com

   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certifi7

-----BEGIN CERTIFICATE-----

<blah, blah, blah>

-----END CERTIFICATE-----

---

Server certificate

subject=/O=client.url.com/OU=Domain Control Validated/CN=client.url.com

issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certi7

---

No client certificate CA names sent

---

SSL handshake has read 1541 bytes and written 456 bytes

---

New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 2048 bit

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : AES256-SHA

    Session-ID: 79F6EAE72AE214E143C7BF7D4A84D64334154BD419F6E73701547B6E6B079240

    Session-ID-ctx:

    Master-Key: 06FCC6E59888670B44C2451B831246D9D2FFEFA0AAB3541C7DAC4A45F9AFE4727F9E57647AD0624671FC076C07DE6194

    Key-Arg   : None

    Start Time: 1358315077

    Timeout   : 300 (sec)

    Verify return code: 21 (unable to verify the first certificate)

---

read:errno=0

Finally, I checked the keychain on my Mac and the server certificate is showing valid.  So, I'm kinda stumped.  I've seen another post where someone was having an issue with a GoDaddy certificate and not with a cert from another issuer.  I've used namecheap without an issue.

Thanks everyone for the help.

[CafNetMatt]

I've gone to the GoDaddy cert repository and downloaded the Intermediate and Root certs and verified them against the certs I was given.  They all match so I don't see why I'm receiving this commit error.  The server

Following the instructions from the link in rmonvon's posting, the chained cert includes the server cert, the intermediate cert and the root cert.  I've also tried:

1) chaining the intermediate cert:  same error on commit

2) just using the server cert by itself

3) importing the intermediate cert then the server cert separately:  This shows the server cert being authorized by the intermediate cert.

The only thing I haven't done is export the GoDaddy root CA from the PAN.  It won't let me so i can't compare that certificate to the one in the gd_bundle.crt.

[jochristian · Accepted solution]

Hello,

I have noticed an similar/same issue on 5.0. I think there is a bug in 5.0. Seems like the GUI filters out everything after the server certificate when doing an import.

I have already created a case with support #00112405

The workaround for me to "fix" the problem is to manually edit the configuration file. Export -> Edit in textpad/xml editor or similar and then paste the server certificate with Intermediate certificate.

After importing the changed configuration file and then commit the problem is solved and if you look at the configuration file the certificate with all intermediates are included:

Jo Christian

[CafNetMatt]

That did it!

Just one thing for clarification for anyone else finding this thread.  When you chain the certs, they all go into <public-key>.  The don't get their own XML headers.  Not sure who'd do that (*uhm...*) but just in case.

[CafNetMatt]

Just checked the release notes for 5.0.2.  Looks like this didn't make it in.  This problem was probably just too new.  Next release hopefully.

[jochristian]

Hello,

Yes that is correct. This is a case that is still ongoing, I opened it last week.

But what you could do is to open a case yourself or contact your SE and refer to the problem that you had and my case #00112405.

Jo Christian