Everything Monopam can do with a FortiManager: read the certificates already held in its global store, its ADOMs and the FortiGates it manages, import a certificate into an ADOM, repoint an SSL-inspection profile at it, install the change down to a device, and undo any of it. All over the JSON-RPC API. No agent, no SSH, nothing installed on the appliance.
|
How it connects |
JSON-RPC over HTTPS, to |
|---|---|
|
What it writes |
A local certificate object in an ADOM's store, or in a managed device's own store |
|
What it repoints |
One |
|
Undo |
Points the profile back and deletes the certificate the deployment created |
Before you start
You need a FortiManager administrator that can use the JSON-RPC API and write in the ADOM you are targeting. Monopam reaches the management address directly over HTTPS on port 443.
The decision that matters most here is not an address, it is which field of the inspection profile you are filling, because the two take different kinds of certificate:
|
Profile field |
Inspection mode |
Certificate it takes |
|---|---|---|
|
|
Certificate inspection, where the FortiGate presents a certificate on behalf of a server |
An ordinary server certificate with its private key |
|
|
Deep inspection, where the FortiGate re-signs traffic |
A CA certificate. A server leaf is rejected outright |
Most certificate lifecycle work is the first row. Pick caname only when you are rotating the re-signing CA itself.
ADOM names are checked, not guessed. FortiManager answers every request in a non-existent ADOM with the same "invalid url" error it uses for a wrong path, so a typo used to look exactly like an empty store. Monopam verifies the ADOM before it does anything and fails with ADOM '<name>' was not found on the appliance. if it is wrong.
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 .
2. Add FortiManager as a deployment target
Open the certificate, go to its Deployment tab and choose Add Target. Set Server Type to Fortinet FortiManager and the rest of the form changes to the fields below.
The FortiManager target. Values shown are examples.
|
Field |
What it means |
Required |
|---|---|---|
|
Name |
What this target is called in Monopam. Use the appliance's role rather than its address, so the name survives a change of IP. |
|
|
Appliance Resource |
A registered appliance keeps its management address in one place, so every certificate deployed to it follows the same record when the address changes. It is also what lets a scan finding and a deployment target recognise each other as the same box, which is what makes the drift remedy below available. |
Recommended |
|
Management Host / Port |
The JSON-RPC endpoint, reached from Monopam directly and not through a gateway. |
Required unless an appliance is selected |
|
Username / Password |
The management credential. A literal value, or a Monopam Vault reference such as |
Required |
|
ADOM |
The administrative domain whose certificate store the certificate is written to. |
Required |
|
Certificate Name |
Local certificate object name in FortiManager. The same name is reused on every later deployment, so a renewal replaces the object instead of adding one. |
Required |
|
SSL-Inspection Profile |
The |
Optional |
|
Profile Cert Field |
Which field of that profile to fill: |
Required when a profile is set |
|
Install to FortiGate |
Device name to push the change down to. Blank means the change stays in the FortiManager configuration and is installed on the device by your own install run. |
Optional |
|
ADOM runs in workspace mode |
Turn on when the ADOM requires an explicit lock and commit. Monopam then takes the lock, makes its change, commits and releases it. |
|
|
Automatically deploy when the certificate renews |
On by default. A renewed certificate is pushed to this target without anyone clicking. |
|
|
Target is enabled |
Turn off to keep the configuration but stop all deployments and retries, for example while the appliance is out of service. |
3. Deploy it
Press Deploy on the target's row. Monopam confirms first, because this changes what the appliance is serving right now.
Every deployment is confirmed before it runs.
The run happens in the background and the result lands on the target's row and in Certificates → Deployments → History.
What a finished deployment looks like.
Repointed 'example-inspection' at 'portal-example-com' on FortiManager.
The certificate is in the ADOM store and the named inspection profile now uses it.
"Succeeded" here means the appliance was read back. When a profile is in re-signing mode, FortiManager accepts a write to server-cert with an OK and then discards it. Monopam therefore sets the matching mode in the same write and reads the profile back afterwards to confirm it really names the certificate. A deployment that reports success has been verified on the appliance, not merely acknowledged by 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 the profile's binding and whether the certificate object already existed. In Certificates → Deployments → History, tick a run and the undo actions appear above the list.
Two ways back. Which ones are offered depends on what the run captured.
Unlike a BIG-IP, FortiManager hands back the object it was holding, so Restore previous certificate is genuinely available here when the profile named something before. 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.
profile 'example-inspection' repointed; certificate 'portal-example-com' removed.
The profile serves what it served before, and the certificate this deployment created is gone.
certificate 'portal-example-com' existed before this deployment and was left in place
The certificate object was already on the appliance before this run, so this run is not what created it. Only the profile binding was put back.
Undoing does not reach a FortiGate the deployment installed to. If you used Install to FortiGate, run your own install after the rollback so the device picks 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 object 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 Fortinet FortiManager.
A scan is read-only. It changes nothing on the appliance.
A FortiManager scan reads three places, and the Where column tells you which one each finding came from:
|
Scope |
What it holds |
|---|---|
|
|
The appliance's own store, including the Fortinet and public CA certificates the box ships with, for example |
|
|
An ADOM's policy objects: the certificates your own work put there, for example |
|
|
The local certificate store of a FortiGate that ADOM manages, read through FortiManager rather than from the device directly. |
Leave ADOM empty and every ADOM that manages FortiGates is read. The dialog says how many other ADOMs it found and skipped: a FortiManager that also has FortiAnalyzer or FortiWeb ADOMs cannot hold a FortiGate certificate in them, so reading them would only produce noise. Name ADOMs explicitly when you want a narrower scan.
The global store is mostly the roots the appliance shipped with. This is why findings wait for a decision by default.
Leave Import everything new straight into the inventory off the first time, exactly because of the screenshot above: 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.
The findings that repay attention are the ones in an ADOM with something in Used by:
One certificate, three appliances, one list. The FortiManager row names the inspection profile that uses it and the ADOM it lives 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-inspection profile that names each certificate, with the scope it lives in. 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.
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 FortiManager, the load balancer and the firewall management plane all carry the same certificate, you want the three 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 Fortinet FortiManager. The step is then configured by exactly the fields the deployment target uses.
A FortiManager 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.
All or nothing. Steps run in order, and the first failure undoes every step that already succeeded, in reverse, from what that step captured off its own device. A run ends as Committed or RolledBack; there is no half-applied state to clean up by hand. The flip side: a template that has already committed cannot be rolled back, neither from here nor from the deployment history, where its steps appear as step of template … with no restore offered. Undo a committed change by running the template again with the earlier certificate. Every run stays on record under Building template runs, on the certificate's Deployment tab and below Deployments → History.
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.
Replaced portal.example.com on Today at 2:20 AM. Monopam did not make this change.
How the changed finding reads on the Resource Scan page. The Changed filter above the list collects them.
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.
-
Put this certificate back deploys it again, through the existing target, which means the approval policy applies to it like any other deployment.
-
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.
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.
Link the target to the appliance resource. Put this certificate back is offered only when a deployment target for that resource exists. A target whose address was typed by hand is not recognised as the scanned appliance even when the address matches, and the banner then reads There is no deployment target for this device, so Monopam cannot put the certificate back by itself. Choosing the appliance in Appliance Resource is what makes the difference.
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.
When something goes wrong
|
What you see |
What it means |
|---|---|
|
|
The target fills |
|
|
The ADOM name is wrong. FortiManager reports a missing ADOM and a wrong path identically, so Monopam checks the name first rather than reporting an empty store. |
|
|
Reported by builds before 2026-09-13, which wrote the ADOM case to a path this firmware does not implement. Update; there is nothing to change on the appliance. |
|
Succeeded, but the profile still serves the old certificate |
Also a pre-2026-09-13 build: |
|
|
The management credential was refused. If the password is a Vault reference, check that it resolves and holds the appliance password rather than a personal one. |
|
Operation timed out |
The management address is not reachable from the Monopam server, or JSON-RPC is not enabled for that administrator. |
|
A scan returns only |
The account can read the appliance's own store but not the ADOM's policy objects. Scan again with an administrator that has ADOM access. |
|
Certificate has no private key to deploy. |
The row is a discovered, public-only certificate. Import the PFX, or issue the certificate through an issuer, and try again. |
|
This certificate is archived. Unarchive it before deploying. |
A retired certificate is deliberately kept away from live endpoints. Unarchive it from the inventory first. |
|
Deployment is running in the background, and it stays that way |
The Monopam service was restarted mid-run. The run is closed as failed within twenty minutes and the button becomes available again. |
|
A template step fails and the whole run says RolledBack |
Working as intended: the steps that already succeeded were undone from what they captured, so no device is left half-changed. Fix the failing step and run it again. |
What this target type does not do
-
It does not create inspection profiles. It repoints one that already exists.
-
It does not touch the appliance's trust store. The Fortinet and public roots that ship with the box are not an inventory of what your organisation issued, which is why a scan lists them but imports nothing by default.
-
It does not install to every managed device. One target names at most one FortiGate; add a target per device if several need the change pushed.
-
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