How to Generate a Palo Alto Certificate Signed by Microsoft AD CS

When a Palo Alto Networks firewall needs a certificate signed by an internal Microsoft Certificate Authority, the workflow is slightly different from simply generating a certificate directly on the CA. The firewall generates the private key and Certificate Signing Request (CSR), Microsoft Active Directory Certificate Services (AD CS) signs that request, and the resulting certificate is imported back into the firewall.

This guide walks through a practical deployment using pa-fw01.networkfix.in as the certificate name and a dedicated Microsoft AD CS template named PaloAlto-Server. The approach keeps the private key on the Palo Alto firewall throughout the process.

What You Need

• A Palo Alto Networks firewall with administrative access.
• Microsoft AD CS with permission to create and issue certificate templates.
• A DNS name for the firewall certificate, such as pa-fw01.networkfix.in.
• RSA 2048 and SHA-256 for the example configuration.

1. Generate the CSR on Palo Alto

In the Palo Alto web interface, create a new certificate/CSR from the certificate management area. Use a certificate name appropriate for the firewall and configure the subject information required by your PKI.

For this example:

• Common Name (CN): pa-fw01.networkfix.in
• Key type: RSA
• Key size: 2048 bits
• Signature/hash: SHA-256
• SAN / Host Name: pa-fw01.networkfix.in

The important point is that Palo Alto generates and retains the private key. The CSR contains the public-key portion and requested subject information; the private key does not need to be exported to Microsoft AD CS.

2. Why AD CS May Reject the CSR

If you submit the Palo Alto CSR without specifying a certificate template, AD CS can return:

CERTSRV_E_NO_CERT_TYPE
The request contains no certificate template information.

This happens because AD CS needs to know which certificate template should govern the request. A practical solution is to submit the request with the template name explicitly, but first the template must be suitable for the Palo Alto CSR.

3. Create a Dedicated Palo Alto Certificate Template

Instead of changing a built-in Microsoft template, duplicate an existing server-oriented template and create a dedicated template for Palo Alto. In this example, the starting template is RAS and IAS Server.

Open the Certification Authority console, locate Certificate Templates, and use the option to manage the certificate templates. Duplicate RAS and IAS Server and name the new template:

PaloAlto-Server

4. Configure the PaloAlto-Server Template

Subject Name

Set the template’s Subject Name option to:

Supply in the request

This is important because the Palo Alto CSR already contains the requested certificate identity and SAN. Requiring AD CS to construct the DNS name from Active Directory can cause errors such as:

CERTSRV_E_SUBJECT_DNS_REQUIRED
The DNS name is unavailable and cannot be added to the Subject Alternative Name.

Application Policy

Configure the template for Server Authentication:

1.3.6.1.5.5.7.3.1

Key Usage

For the example template, enable:

• Digital Signature
• Key Encipherment

Keep the key-usage extension critical if that is how the template is configured for your environment.

Security Permissions

Give the account that will submit the CSR the required Read and Enroll permissions on the template. Use the least privilege necessary for your environment.

5. Publish the Template on the CA

Creating a template does not automatically make it available for issuance. In the Certification Authority console, right-click Certificate Templates, choose New → Certificate Template to Issue, and select:

PaloAlto-Server

The template is now available for certificate requests submitted to that CA.

6. Submit and Sign the Palo Alto CSR

Copy the CSR generated by Palo Alto to the Windows system used to submit the request. Then use certreq and explicitly specify the certificate template:

certreq -submit -attrib "CertificateTemplate:PaloAlto-Server" pa-fw01.csr pa-fw01.cer

The CA should issue the certificate according to the PaloAlto-Server template. If the CA asks you to select a certification authority, select the appropriate issuing CA.

7. Import the Signed Certificate Back into Palo Alto

After AD CS issues the certificate, import the resulting .cer certificate into the corresponding Palo Alto certificate entry created when the CSR was generated.

You do not need to import a private key or enter a private-key password for this workflow. Palo Alto generated the private key when the CSR was created and retained it on the firewall. The certificate returned by AD CS is the signed public certificate that completes the existing key pair.

8. Verify the Certificate Before Using It

After import, verify the certificate details rather than relying only on the fact that the import succeeded. Check:

• Subject/CN: pa-fw01.networkfix.in
• SAN: pa-fw01.networkfix.in
• Issuer: your Microsoft AD CS issuing CA
• Key algorithm: RSA 2048
• Signature: SHA-256
• EKU: Server Authentication
• Validity: correct start and expiration dates

Also make sure the client devices that will connect to the firewall trust the issuing CA and any required intermediate CA certificates.

9. Assign the Certificate to a Palo Alto Service Profile

Importing the certificate does not automatically make every firewall service use it. If the certificate is intended for the management interface, GlobalProtect, an SSL/TLS service profile, or another service, select the appropriate certificate in that service’s configuration and commit the configuration.

Troubleshooting Common AD CS Errors

Why a Dedicated Template Is Better

A dedicated PaloAlto-Server template makes the intent of the certificate request clear and avoids modifying a Microsoft built-in template for one appliance. It also gives PKI administrators a controlled place to define subject handling, EKU, key usage and enrollment permissions specifically for Palo Alto certificates.

Quick End-to-End Checklist

1. Generate the CSR on Palo Alto.
2. Keep the Palo Alto-generated private key on the firewall.
3. Create the PaloAlto-Server AD CS template.
4. Set Subject Name to Supply in the request.
5. Enable Server Authentication EKU.
6. Configure the required key usage.
7. Grant the submitting account Read and Enroll.
8. Publish the template on the issuing CA.
9. Submit the CSR with CertificateTemplate:PaloAlto-Server.
10. Import the signed certificate back into the Palo Alto certificate entry.
11. Verify CN, SAN, issuer, EKU, key and validity.
12. Assign the certificate to the required firewall service and commit.

Conclusion

The key to integrating a Palo Alto CSR with Microsoft AD CS is understanding which system owns each part of the certificate. Palo Alto generates and retains the private key, while AD CS applies the approved certificate template and signs the CSR. Using a dedicated template with Supply in the request avoids the common DNS-subject error and provides a repeatable PKI workflow for Palo Alto appliances.

Related Palo Alto Guides

• Palo Alto GlobalProtect configuration
• Palo Alto IPsec VPN troubleshooting
• Palo Alto log forwarding to Syslog or SIEM
• Palo Alto security profiles configuration

References

• Palo Alto Networks: Obtain a Certificate from an External CA
• Microsoft Learn: certreq command
• Microsoft Learn: Certificate Template Concepts
• Microsoft Learn: Submit PKCS Certificate Requests