How to Implement Certificates Issued from Microsoft Certificate Services

Printer Friendly Page


Users who have implemented a Microsoft Certification Authority are able to seamlessly deploy (assuming Root Certificates have been pushed to all clients) various features such as SSL-Decrypt (forward-proxy) and GlobalProtect. Using Microsoft Certificate Authority can also eliminate errors when accessing the web UI for Management Access.

Use the Microsoft Certification Authority with Server 2008 Enterprise to backup/export the Root Certificate hosted on the CA or generate/export a Subordinate CA. This allows the Root CA to remain secured with the subordinate being capable of revocation at any time, which is completely transparent to the clients. Subordinates can be created if the CA includes the ‘Subordinate Certificate Authority’ template through the ‘Advanced Certificate Request’ of the Microsoft Certificate Service web UI.


If the certificate services web page does not work, try to generate the certificate from the domain controller command line with the following command:

C:\> certreq.exe -submit -attrib "CertificateTemplate:SubCA" <CSR file>

If unable to generate a subordinate through the Microsoft Certificate Service, you can export the Root CA (w/ the private key) and import into the Palo Alto Networks firewall to allow signing of ‘on-the-fly’ certificates generated for SSL-Decrypt.

Important! This workaround should be exercised with caution. It is highly advisable/recommended to delete the Root CA from the Palo Alto Networks Firewall immediately following the issuing of the subordinate CA.


To backup/export the Root Certificate from the CA, launch the Certification Authority snap-in and follow the export wizard as follows:

  1. Launch the Certification Authority snap-in and right-click on the CA. In the menu selections that appear, select "All Tasks" and then "Back up CA…" as shown below:
  2. Select Next to continue the Backup Wizard.
  3. Select the checkbox for "Private key and CA certificate". Without the private key, it will not be possible to sign certificates as a CA, which is a requirement for SSL-Decrypt/Forward-Proxy.
  4. Enter a Password and save to a secure location, this will be required during import.
  5. Click Finish to complete the backup/export process, which will save the cert/key as a '.p12 format'.


To generate a Subordinate CA with the Root Cert issued by the Microsoft Certificate Authority, temporarily import the Root Cert from the CA into the Palo Alto Networks. Then, generate/sign a new CA off of the Root CA. In this example, the Microsoft Root CA 'InternalCA' is signing the Subordinate CA 'SubordinateCA', which has been generated as a Certificate Authority.
Important! Once the certificate is successfully issued, delete the recently imported Root CA.


This allows the distribution of the Subordinate CA to various Palo Alto Networks firewalls throughout an organization without compromising the Root CA, which should be deleted from the Palo Alto Networks firewall upon generation of the Subordinate. As long as the Root Cert are installed into the client systems (typically deployed with AD/GPO’s, scripts, etc.), the Subordinate cert would be trusted by default as it was signed directly from the Root. The following example shows a full/valid chain utilized with SSL-Decrypt, with the certificate generated on-the-fly by the subordinate and validated by the Root.

With either the Root Certificate imported as a CA or the Subordinate imported/generated as a CA, in addition to benefits associated with seamless SSL-Decrypt deployments (assuming previously deployed to the user community), it will now be possible to sign Server certs for GlobalProtect, Secure WebUI for Admin Access, Client Certs, etc.

owner: bryan


Thank you for this article bryan.

We created a "firewall issuing CA" on our Windows PKI and imported the subCA to the PA firewall. We can use it for SSL decryption but we can't use it for the Web UI. It looks like the browser is unable to construct the whole certificate chain. It just displays the WebUI cert with no parents.

The correct chain would be:

- Root CA

- - Issusing CA 1

- - - Firewall Issuing CA (installed on PAN)

- - - - Web UI certificate (created on PAN)

Any idea why?

Thank you.


Hello Oliver,

In cases such as this (where the cert is being hosted/utilized as a Server cert on the appliance), we will need to combine the server cert with the intermediate to complete the chain. Please reference the following KB which steps you through the process:

Should you have any issues or require assistance with the process, please open a case & we shall be happy to assist.

Thanks very much,


Hello Bryan,

Are you sure this works for the Web UI certificate on a box with 4.1.9 installed? I tried that already and also now it seems not work. It seems even though the imported cert contains all the intermediate certs but when the firewall presents the cert to the browser the intermediate certs are not coming along...

Thanks a lot,


Hello Oliver,

I performed a test in the lab on a PanOS v4.0.x & a v4.1.9 box & confirmed that combining the intermediate beneath the root (based on the previous KB article provided) & importing with the private key correctly displays the chain, i.e.:

This was done strictly with the Root CA installed onto the workstation as well as the imported Root on the appliance generating the subordinate, then the Subordinate issuing the WebUI cert using the appliance IP for the CN, i.e.:


Additionally, can you select the certificate with the bundled chain utilized for 'Certificate for Secure Web GUI', select Export, then Right-click & open with Notepad to verify that the chain has in fact been retained, i.e.:


If cert following the export looks OK & the correct bundled cert was specified for 'Certificate for Secure Web GUI' with issues persisting, please feel free to open a case & we shall be happy to assist.

Thanks very much,


Hello Bryan

Thank you for all the effort you put in this. I really appreciate that.

I didn't thought it's necessary to import the public key of the Root CA on the firewall and mark it as trusted CA. With that done it worked. I was under the mistaken impression that it's only the browser's task to verify the whole chain.

Unfortunately it won't work for me in version 5 anymore. In our Panorama (which is already on version 5.01) we get an error message telling us that the "Validity period can not be more than 30 years" when we try to import our Root CA certificate :-).



Hello Oliver,

Thank you very much for your updates. I wanted to update as well that there is a potential fix in the works (on v5.0.x) to address the validity period limitation. Please keep an eye out for upcoming maintenance releases (which should reference the changes within the release notes). If you open a case, we can keep you posted pro-actively on status of fix, targeted release as well as ETA.

Thanks again & have a great weekend!



Oh, good to know that a fix is on the way. I'm reading the release notes anyhow so it's not necessary to open a ticket.

You have a great weekend too.



Hi all,

looks like this is an old document, has anyone done this with v7.0.2, I'm creating certs off our internal CA, I can only get the sub-ca created with the keys off my internal root ca that was imported(I get the options to enable fwd trust and untrust), but I can't get it to create the web-ui cert, how was the bottom of the chain created and how to get the option for web-ui to come up on the imported cert.