| Description | This article describes an issue where a certificate does not populate in all VDOMs when uploading a new local certificate in the Global VDOM via CLI. This issue only affects v7.2.9 and v7.2.10. |
| Scope | FortiGate v7.2.9 and v7.2.10. |
| Solution |
Uploading the certificate via CLI may cause issues in two scenarios: one with a standalone FortiGate and the other with an HA FortiGate.
Standalone FortiGate: After uploading a new local certificate to the Global VDOM via the CLI, the certificate will only be populated in the first non-Global VDOM shown in the VDOM dropdown list; no other VDOM will have this new local certificate.
In this example, the root VDOM will have the certificate, but vdom1 and vdom2 will not have the certificate.
HA FortiGate: On the primary FortiGate, the new certificate will only be available in the first non-Global VDOM in the VDOM dropdown list. On the secondary FortiGate, the new certificate will be populated in all VDOMs. This will cause the HA cluster to become and subsequently stay out-of-sync.
This issue is documented as part of known issue 830538, which has been resolved in v7.2.11 and v7.4.0.
Workaround: To work around this issue for both standalone and HA FortiGates, avoid uploading certificates to the FortiGate via the CLI and instead upload the certificate to the Global VDOM using the GUI (Global VDOM -> System -> Certificates). This will ensure that the certificate is populated and available on all VDOMs.
If uploading the certificate via the CLI is the only available option (i.e., no HTTPS GUI access is available), then the following procedure can be used after performing the initial upload:
config global config certificate local edit [NAME] set comments [STRING] next end end
config global config certificate local edit [NAME] unset comments next end end
The certificate cache can be cleared as well to update the status:
diagnose ips share clear cert_verify_cache |
