To fix this create a proper Server certificate that doesn't have the "CA" field.
You can generate a CSR and send to the PKI team for signing, or have the PKI team create the csr and certificate for you.
Creating a Certificate Signing Request (CSR)
https://knowledge.broadcom.com/external/article/165633/creating-a-certificate-signing-request-c.html
Import Certificates onto the ProxySG Appliance
https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/edge-swg/7-3/about-ssl-proxy/ssl-proxy-troubleshooting-intro/provide-cert-policy/add-certificates/import-certs.html
The below links also discuss the issue of having the "CA" ability with this certificate:
Secure the HTTPS Management Console
https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/proxysg/7-3/securityBP/Securing-the-HTTPS-Management-Console.html
Create a certificate signed by a trusted CA.
"Do not rely on the self-signed certificate provided by default. Before deploying your appliance, create a new SSL interception keyring and replace the built-in self-signed certificate with one signed by a CA conforming to your PKI and your security policy. Follow instructions in “Create a CA-Signed Certificate” in the First Steps Deployment Guide to generate a CSR and issue the appropriate certificate."
SSL Proxy Best Practices
https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/proxysg/7-3/securityBP/SSL-Proxy-Best-Practices.html
It also appears that some browsers started introducing this check against the Basic Constraints extension for the Key Usage and if "CA=True" is present on a server certificate that this can cause an issue.
In either case, the resolution here should be to issue an server certificate to the Proxy for accessing the MGMNT console, and not to use a certificate that has the Basic Constraints CA=True field.