Certificates on Palo Alto Panorama

Everything Monopam can do with a Panorama or a PAN-OS firewall: read the certificate stores it keeps, import a certificate and its key, repoint an SSL/TLS service profile, commit, push the change on to a device group, and undo any of it. All over the XML API. No agent, no SSH, nothing installed on the appliance.

Before you start

You need a PAN-OS administrator whose role allows the XML API, or a pre-generated API key. Monopam reaches the management address directly over HTTPS on port 443.

An import lands in the candidate configuration. Leave Commit after change on unless your change process commits separately, because an uncommitted PAN-OS edit changes nothing in practice.

The one thing that trips people up: scope

PAN-OS resolves a certificate reference inside a scope, and it will not look outside it. A profile in a template's vsys cannot see a certificate imported into Panorama's own store, and the repoint silently fails to take even though both objects clearly exist in the interface.

So the rule is short: put the certificate where the profile lives.

A resource scan is the quickest way to find out which scope a profile is really in, because it labels every finding with the scope it came from.

1. Get the certificate into Monopam

A certificate can only be deployed if Monopam holds its private key. Go to Certificates → Inventory → Import and upload a PFX, or a PEM certificate together with its key file, entering the file's password in the same dialog. Monopam reads the file there and then, and refuses it immediately if it cannot, rather than failing later on the appliance.

A certificate that was only discovered by a scan has no key and cannot be deployed: its row shows Tracking only instead of Private key .

Monopam sends the pair as two PEM imports rather than one PKCS#12 bundle, because PAN-OS cannot open a modern p12. This is internal, but it explains why the appliance's own log shows two import calls for one deployment.

2. Add Panorama as a deployment target

Open the certificate, go to its Deployment tab and choose Add Target. Set Server Type to Palo Alto Panorama / PAN-OS and the rest of the form changes to the fields below.

The Panorama target. Values shown are examples.

3. Deploy it

Press Deploy on the target's row. Monopam confirms first, because this changes what the appliance is serving right now. A PAN-OS commit takes a while, so the run stays in the background for a minute or two before the result lands.

Every deployment is confirmed before it runs.

What a finished deployment looks like.

To confirm independently, look at the running configuration for the certificate entry: it should carry both a public key and a private key, and the profile should name it.

4. When a policy asks for approval

If a Certificate Approval Policy covers this operation, the deployment does not run on the click. Monopam raises a request, tells you so, and carries the deployment out itself the moment somebody approves it. You do not come back and press the button again.

The approver sees which certificate is going where, on the request itself:

The request names the certificate, how long it has left, whether its private key came with it, and the appliance it is bound for.

If the policy is set to refuse rather than to ask, the deployment stops immediately with the policy's own wording, and no request is raised. Either outcome is written to Audits against the certificate.

5. Undoing a deployment

Every deployment records which certificate the profile served and whether the certificate entry already existed. In Certificates → Deployments → History, tick a run and the undo actions appear above the list. Every rollback commits, for the same reason the deployment does.

Both are usually available on a Panorama run, because the profile's previous binding was captured.

A button that cannot work on the runs you selected is disabled and says why when you hover it, rather than failing after the fact.

Undo is confirmed too, and states that it runs against the live appliance.

The run's own row records exactly what the rollback did.

A rollback does not reach firewalls the deployment pushed to. If Push (commit-all) to device group was on, push again after the rollback so the devices pick up the restored configuration.

6. Renewals

With Automatically deploy when the certificate renews left on, a renewed certificate is imported under the same certificate name, the profile follows it, and the change is committed. The appliance keeps one entry per service rather than collecting one per renewal.

A deployment that fails is retried on a widening schedule; the row shows the attempt count and when the next one is due. A target that is switched off is skipped entirely, and says so.

Read what is already on the appliance

Deployment answers "put this certificate there". A resource scan answers the opposite question: what is on that box already, including the certificates no profile uses and nobody remembers importing.

Register the appliance as a resource first, then go to Certificates → Resource Scan → Scan a resource and set Device Type to Palo Alto Panorama / PAN-OS.

A scan is read-only. It changes nothing on the appliance, and it commits nothing.

A PAN-OS scan reads four stores, and the Used by column labels each finding with the scope it came from:

This is the single most useful thing a Panorama scan does, and it is worth running one before you build a deployment target: the scope label on a finding tells you exactly what to put in the target's vsys and Template fields so the repoint will actually take.

Both PAN-OS certificates on one appliance. The second row names the SSL/TLS service profile that uses it, and the scope that profile is in.

• Managed means Monopam holds this certificate and can renew and redeploy it. Unmanaged means the appliance has it and Monopam does not: that is the backlog a first scan exists to find.

• Used by resolves the SSL/TLS service profile that names each certificate, with its scope. A certificate that says nothing bound is imported but no profile uses it.

• Matched means the certificate on the appliance is byte for byte the one in the inventory. That is the state the next section watches for changes.

Unlike a NetScaler, PAN-OS keeps the certificate itself in its configuration, so every finding here can be imported into the inventory as a tracked row. Leave Import everything new straight into the inventory off the first time anyway: a device store also holds CA bundles and the appliance's own certificate, and you rarely want those as managed rows. With the switch off, every finding waits for you to import or ignore it.

A scan remembers your decisions: re-scanning never re-raises something you imported or ignored, unless the object's certificate changed.

One certificate across several appliances

A deployment target is one appliance. When a service is only correct if the firewall management plane, the load balancer and the inspection appliance all carry the same certificate, you want those changes to succeed or fail together. That is a building template: an ordered plan that runs as one transaction.

Go to Certificates → Building Templates → New Template, add a step, and set Device to Palo Alto Panorama / PAN-OS. The step is then configured by exactly the fields the deployment target uses, scope fields included.

A Panorama step. Deploy to target is the only operation this device offers; the clone primitive in the F5 guide is specific to a BIG-IP.

A template is a plan, not a property of a certificate: you choose the certificate when you run it.

Running a template against a certificate.

The run's own history. Committed means every step succeeded.

When somebody changes it outside Monopam

A certificate Monopam manages can still be replaced on the appliance by someone with a console and a reason. The next scan notices: the object now holds a different certificate from the one Monopam put there, so the finding is marked as changed, the displaced certificate is named, an alert goes out on the certificate alert channels and an audit entry is written. It is raised once per replacement, because it is a security event and not a line in a report.

The displaced certificate's own page says so too, with a banner naming what is on the device now and two ways out:

The banner sits above the tabs, so the owner does not have to go looking. This example was captured on a sibling appliance; the PAN-OS banner is the same, with the certificate's PAN-OS object name in place of the ADOM path.

• Put this certificate back deploys it again, through the existing target, which means the approval policy applies to it like any other deployment, and the commit happens as part of it.

• Accept the new certificate takes what is there into the inventory and closes the question, changing nothing on the appliance.

Putting it back is a deployment, and is confirmed like one. Again captured on a sibling appliance; the dialog names whatever object and appliance the finding came from.

Either answer clears the mark. Monopam also stops claiming the device for the displaced certificate: its sighting for that object is removed, so the certificate's page no longer names a box it is not on.

Pushing to every target at once

A certificate with several targets has a Deploy to all targets button on its Deployment tab. It is all-or-nothing: targets are done in order, and the first failure puts back every target already done, in reverse. Use it when a service is only correct if all of its devices carry the same certificate; use the per-target button when getting three of four devices done is better than none.

It is offered only when the certificate has more than one enabled target, and refused outright when deployment history is turned off, because the captured state is what an undo restores from.

Note that this is a different thing from PAN-OS's own Push (commit-all) to device group, which is a per-target switch and pushes Panorama's committed configuration down to its firewalls.

When something goes wrong

What this target type does not do

• It does not create SSL/TLS service profiles. It repoints one that already exists, in the scope the certificate was imported into.

• It does not manage decryption policy. Repointing a profile changes which certificate is presented, not which traffic is decrypted.

• It does not push unless you ask. Without Push (commit-all) to device group, the change is committed on Panorama and installed on firewalls by your own push.

• It does not move a certificate between scopes. A certificate in the wrong scope is imported again into the right one, under the same name.

• It does not read private keys during a scan. An imported finding is a tracking-only row until you supply the key.

Monopam Certificate Manager. Addresses, names and certificates in the screenshots are examples.

Device guides: F5 BIG-IP · FortiManager · NetScaler · Panorama