New Member

Question

FortiManager 7.4.11 rejects FortiGate-VM evaluation cluster

Forum|Forum|8 days ago
June 3, 2026
2 replies
94 views

Servus Community,

I'm trying to add a FortiGate-VM HA cluster (A-P) running FortiOS 7.4.11 to a FortiManager VM running 7.4.11. Both FortiGate VMs and the FortiManager VM are running in evaluation/trial mode.

The cluster itself is healthy and synchronized. Network connectivity is fine and TCP/541 is reachable. I have also enabled:

config system global
 set fgfm-allow-vm enable
end

When I try to add the FortiGate to FortiManager, the device discovery fails with "Probe failed".

After enabling FGFM debugging, I noticed that the TLS handshake actually completes successfully. The FortiGate then sends its authentication information including the serial number:

serialno=FGVMEVO4T9J2-XXX

At that point FortiManager rejects the session and logs:

serial number (FGVMEVO4T9J2-XXX) in 'get' message doesn't match the subject CN (FortiGate) in peer's certificate.

I then checked the certificates on both HA members.

Both nodes have the same Fortinet_Factory certificate:

Subject:
CN = FortiGate

The certificate fingerprint is identical on both nodes.

However, the Fortinet_SSL certificate on the primary node contains the correct serial number:

Subject:
CN = FGVMEVO4T9J2-XXX

This made me suspect that the issue is related to the well-known evaluation VM certificate problem discussed in several community posts.

I also tried:

execute vm-license FGVMEVO4T9J2-XXX

but the result was:

Failed to download VM license.

So unfortunately that workaround did not change anything.

Has anyone successfully registered a FortiGate-VM evaluation cluster running 7.4.11 with FortiManager 7.4.11 recently?

Is the generic "CN=FortiGate" factory certificate still a limitation of evaluation VMs, or is there another workaround available?

Thanks in advance!

CD

msanjaypadma

Staff

Hi @Cyberduck ,

This is my findings !

I also attempted to use the EVAL license; however, it did not function as expected. This is because the FortiGate-presented certificate lacks the CN field containing the FortiGate-serial-number. Additionally, the EVAL license does not support FortiGuard/FortiCare, which results in the update function failing and generating a "file download error." To the best of my understanding, the certificate remains unchanged for EVAL licenses.

Furthermore, the referenced article indicates that the EVAL license employs lower encryption levels expect for GUI and FortiManager communication, but it is still restricted by the serial number in fortimanager.

Reference:
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/441460

As per article “The command 'fgfm-peercert-withoutsn' has been removed from FortiManager v7.2.10/v7.4.6/v7.6.2. As a result, it is now a hard requirement for the FortiGate to present the local serial number inside the CN= field of the certificate it is presenting to the FortiManager.”

Checked with regular license version, as it appears to be functioning correctly for me.

Refer this thread for different solution :

Create Certificate
or
Downgrade to FortiManager v7.4.5
config sys global
set fgfm-peercert-withoutsn enable ( Starting in v7.6.2/v7.4.6/v7.2.10 command is no longer supported )

If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.

Thanks,
Mayur Padma

CyberduckAuthor

New Member

Servus Mayur

thanks for the links. After going through them, they seem to confirm what we have already observed in our lab rather than providing a new explanation.

At this point, our working theory is still that FortiManager rejects the FGFM session because the FortiGate evaluation VM presents a certificate with:

CN = FortiGate

while the device identifies itself with:

FGVMEVO4T9J2-XXX

This matches the error we consistently see in the FortiManager debug output:

serial number (FGVMEVO4T9J2-XE3) in 'get' message doesn't match the subject CN (FortiGate) in peer's certificate.

We have verified that both HA members use a Fortinet_Factory certificate with CN=FortiGate, while the Fortinet_SSL certificate contains the correct serial number.

One thing that caught my attention in the linked discussions is the reference to the "set fgfm-peercert-withoutsn enable" workaround.

However, there seems to be conflicting information regarding its availability. Some posts suggest that it was removed starting with FortiManager 7.6.1, which would imply that it should still exist in 7.4.11. On the other hand, several other reports indicate that it had already been removed or was unavailable in earlier releases.

We will investigate that option further and see whether there is still a supported way to disable the serial-number-to-certificate-CN validation in our version.

If that does not lead anywhere, the next workaround we plan to test is the custom certificate / custom CA approach that has been mentioned in several community discussions. So far, we have not yet tested that method ourselves.

I will report back with the results once we have tried it.

Thanks again for the pointers and suggestions.

CD

christian_89_

New Member

This is the classic FGFM cert-pinning wall, and the thread is circling it without quite landing the conclusion. Here is the clean version.

It's not a bug, it's expected on eval VMs. Your diagnosis is right: the eval Fortinet_Factory cert carries the generic CN=FortiGate, not the serial. A licensed FortiGate-VM gets a factory cert regenerated with the serial in the CN after FortiCare validation; eval/trial instances never do. Since the FGFM hardening, FortiManager requires the serial to be present in the peer cert CN, full stop. So with an eval cert the probe will always fail with exactly that "serial number ... doesn't match subject CN (FortiGate)" error. Nothing on the FortiGate side fixes this while it's on an eval license.

Stop chasing fgfm-peercert-withoutsn on 7.4.11. Cyberduck's "maybe it was removed at 7.6.1" theory is wrong and will waste his time. The Fortinet staff answer is the accurate one: it was removed at 7.2.10 / 7.4.6 / 7.6.2. 7.4.11 is well past 7.4.6, so the command is simply not there. There is no knob to disable the CN check in that build.

execute vm-license failing is also expected. Eval VMs have no real entitlement to pull, and FortiCare/FortiGuard is gated on eval, so that returns a download error by design. That path is dead too.

That leaves two real options and one I'd skip:

Put a proper VM license on it. This is the actual fix, and for Alphahub it's the obvious one since you have partner access. A FortiFlex or NFR license validates against FortiCare, the factory cert regenerates with the serial in the CN, and FGFM then works with zero tricks. Building an FMG-managed lab on eval certs is the wrong foundation precisely because of this. Use real licenses in the lab.
Downgrade FortiManager to 7.4.5 and set fgfm-peercert-withoutsn enable. Works, but you're pinning FMG to a pre-7.4.6 build and forgoing every fix since. Acceptable for a throwaway lab, a bad habit for anything you keep around.
Custom cert / custom CA approach. I would not bother. Replacing the cert the FortiGate actually presents in the FGFM session (Fortinet_Factory) with a self-made CN=serial cert is fiddly and not cleanly supported for the FGFM client side. The community posts that mention it tend to trail off without a reproducible result, which matches the fact that nobody in this thread has actually completed it. It's effort spent fighting the platform instead of just licensing the VM.

Bottom line: this isn't solvable on the FortiGate while it's eval-licensed. License the VMs properly (FortiFlex/NFR) and the problem disappears. Only fall back to the 7.4.5 downgrade if the lab is genuinely disposable and you can't spare a license.

CyberduckAuthor

New Member

Bottom line: this isn't solvable on the FortiGate while it's eval-licensed. License the VMs properly (FortiFlex/NFR) and the problem disappears. Only fall back to the 7.4.5 downgrade if the lab is genuinely disposable and you can't spare a license.

I agree that a properly licensed VM is the recommended solution. For a small lab environment, however, a full FortiFlex or production VM license is difficult to justify from a cost perspective.

For completeness: I was able to get the setup working with the evaluation VMs and custom certificates. The FortiGate is now successfully registered in FortiManager, the HA cluster is managed correctly, and failover testing was successful as well.

That said, you were right regarding the limitations of the evaluation license. During testing we already ran into several restrictions, including the inability to perform normal firmware upgrade workflows and the very limited number of supported interfaces, VLANs, routes and firewall policies. Those limitations make it clear that an evaluation VM is not a suitable long-term foundation for a realistic lab environment.

We may actually be able to obtain fully functional demo licenses through our Fortinet contacts, as we are currently in the middle of a fairly large Fortinet deployment project. My concern is that this would introduce a limited time window for the lab. For now, I will continue documenting and testing with the existing setup and keep the demo-license option in reserve for a later stage if needed.

Thanks for your attention and taking the time to provide the background information.

CD

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded