Best Practice for Root CA Self Signed Cert on NGFW

[pomologist]

I have a question regarding best practices for creating Root CA self-signed cert(s) on a NGFW.

Should one single self-signed CA root cert be used as the root cert for ALL certificate chains for firewall services such as SSL Decryption, GlobalProtect portal, Gateway Certificates, etc, etc?  So I guess there are two specific questions:

1) Is there any issue having all these services' cert chains share the same root cert, or should each of these services have a separate, self-signed CA root cert? What is considered most secure, best practice, etc?

2) And what risks/attacks are we being exposed to if we use a self-signed cert for public facing portals?

Thanks so much!

[rmfalconer]

If you use the PA as a CA, then you'll have to export the root certificate from the PA and import on any client that will need to trust certificates it issues. 

For example, if you use a self-signed cert for decryption and the endpoints don't have the root certificate in their trust store, you'll get a warning in the browser. 

Same problem if you use it on a public facing service, browsers won't trust the authority that issued the certificate and they'll get a warning message.

Common practice is to keep the root authority offline or powered-down to avoid compromise. An intermediate authority is created that actually issues and revokes the certificates.

Do you have an internal private authority that your clients already trust, like a Microsoft CA?

For external services that the general public needs to access, you can get a free cert with a short expiration or pay a couple of hundred dollars for 1-year. If it's only for something that your endpoints access, you can use the self-signed but you still need to have the correct trust in place. 

[pomologist]

Thanks!   A few questions:

1) Thus far, I have imported self signed certs into the browsers one the endpoints, and marked them as trusted.  That has thus far prevented clients from receiving untrusted errors. 

2) I do not use Microsoft CA - all the computers in our business are Macs and we don't use any Microsoft services.  I understand that running an internal PKI is fraught with security risks and should be avoided unless there's an experienced team to manage it.  Should I reconsider this?

3) If I continue using self signed certs, then I'm back to my original question:  Should I use  a bunch of root-cert/end-cert chains for each service on the firewall (thus meaning I may have 4 or 5 chains, with 4-5 individual root certs, for various firewall services) , or should I use one root cert, and have a bunch of end certs signed by that one single root cert, for all firewall services?  I.e, Can all firewall services share the same self signed root cert and just have it's own end cert, signed by that root CA?  Or do I need a separate root Cert CA for every end cert I need?

Thanks!

[rmfalconer]

If you don't have the need for internal certificates then you don't really need your own PKI. We use internal certificates for a lot of stuff including wireless, VPN and internal secure services. If you run internal PKI, you should definitely understand how it works and the best practices. 

I'm not sure if the PA can even have multiple roots, I don't have access to my test device today to check. I would just issue each device cert from a single CA.

[pomologist]

Thanks! 

The PA can indeed have multiple CA roots.  That's the way I have done it in the past, with a root CA on the firewall for EVERY service listed above, assuming that if one root was compromised, it could be helpful not to have to change certs for all other services on the NGFW.  I just wasn't sure if that was problematic on any front, other than being a pain to manage. 

[rmfalconer · Accepted solution]

It feels like minimal benefit for more complexity. If the PA is compromised, all the roots are in the same place. You don't have the option of keeping the root offline.