the certificate must be signed by a CA authority. No certificate that is issued to a ".local" domain can be trusted. The certificate verification is done against a public CA authority by the browser, so any certificate that you self-signed locally is only valid locally (the browser can't verify it is trusted with the public CA authority)
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
Actually web browsers does validate certs against their CA store. MSIE, Edge, Chrome on Windows does use system Cert Storage (certlm). Or shorter, through chrome://settings/security
FireFox does use it's own internal cert storage.
Both are looking to who signed cert you are trying to use, or which is presented to browser as server cert. And so browser validates if server cert itself is valid, or if it is signed by "Trusted Root Certificate Authority" (in short "CA")as if it is, then trust is inherently applied also to certs signed by that CA.
And so you can have your own certs, issued/signed by your own CA, but then you have to add cert of that Root CA into Trusted Root CA in every browser you'll use. MSFT do have a shortcut for domain members as it could be pushed to workstations via GPO (but that's a bit out of scope in here).
Allow me to repeat my suggestions/questions from my first reply:
1, Does this certificate contain the fortigate.xxx.local FQDN in its SAN field? This is required by modern browsers, and no screenshot so far suggests that it is present. (screenshots only show the CN, which alone is insufficient)
2, When connected to the HTTPS GUI in Chrome, open the developer tools panel (F12), then go to the Security tab, and there you should see the reason why the certificate is not trusted.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.