01-22-2023 01:08 PM
Greetings,
We are researching Certificate management and all the certificate management the Firewall can do. It came across as a question - is there a way to have the PA function as a secondary / sub-ca? Our team members our discussing instead of standing of a new CA since everyone should have the root FW cert. My question is at what scale and other problems could arise? I see some docs that state to monitor cpu and it does have a resource cost but I think this would be more than 10 certs which seems to be a basic suggestion: To be clear this is for applications on the FW like SSL Forward Proxy, Captive Portal, Global Protect. This would be about generating self signed certs or public CA for other webservices in the environment.
PA 3220
OS 10.2
Has anyone had experience with this and how did it go? Lessons learned or advice welcome?
01-24-2023 08:41 AM
Yes you can import certificates from different sources into the firewall and use different certificates for different purposes.
If you want Palo to sign certificates itself then it needs to either have root CA cert or intermediate signed by your enterprise root CA.
Public CA's won't sign you trusted intermediate cert.
01-22-2023 09:06 PM - edited 01-22-2023 09:12 PM
For GlobalProtect I would buy cert from pubic CA to avoid users seeing cert warning when they access site first time as it teaches them that it is ok to bypass cert warnings.
For SSL Forward Proxy you need to sign certificates with CA that users already trust.
If you have internal CA then you can generate intermediate CA CSR on Palo and sign it with enterprise CA.
If you don't have internal CA just create CA on Palo and export PUBLIC key of it into workstations (using Group Policy for example).
You will not import private key of CA cert into workstations.
What is goal of sub-ca idea? Security in case CA private key leaks out from firewall?
In this case you would need to generate root CA on Palo.
Generate intermediate CA on Palo and sign with CA cert.
Most likely export both of them and then delete both of them (as you can't delete root ca if cert signed by it exists on Palo).
Then import root CA public key only and then import intermediate CA with private key.
And when intermediate expires then go through the process again by importing CA with private key to sign intermediate etc?
Not worth the work if you don't have enterprise CA then just export root CA public key into workstations I think.
01-24-2023 07:02 AM
Greetings and thank you for the discussion. Let me correct a few items. I made a typing mistake and this should state NOT:
To be clear this is for applications on the FW like SSL Forward Proxy, Captive Portal, Global Protect.
To be clear this is NOT for applications on the FW like SSL Forward Proxy, Captive Portal, Global Protect.
For testing purposes we have a CA in a secure environment but this FW is in-between. Can we provide the Firewall with other secure certs from other 3rd party applications? Thinking that the FW can be a CA instead of standing a new separate CA up. The same clients that access the secure portal will have access to the secure certificates on the FW. This situation for testing is because Captive Portal in redirect mode. PA 3220 PANOS 10.2 -TEST
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJYCA0
01-24-2023 08:41 AM
Yes you can import certificates from different sources into the firewall and use different certificates for different purposes.
If you want Palo to sign certificates itself then it needs to either have root CA cert or intermediate signed by your enterprise root CA.
Public CA's won't sign you trusted intermediate cert.
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!
