Hi Julian,
Would you be able to submit a support case so we can look at this individually?
We do not discuss security-related questions in the forum to protect the community and your own security stance.
https://knowledge.broadcom.com/external/article/209191We can review these via the support channels and will be happy to assist you.
Thanks!
------------------------------
Global Support Lead, Encryption
BRCM
------------------------------
Original Message:
Sent: Aug 22, 2022 02:07 AM
From: Julian Rendon
Subject: symantec encryption management server port 444 Self-Signed Certificate
Hello team
A vulnerability analysis was recently carried out on the symantec encryption management server and it was found that the certificate used on ports 444, 9000, 636, 443, is Self-Signed Certificate, its posible change it by CA-Signed certificate?
thanks
192.X.X.X.X |
PGP |
Medium |
(en blanco) |
444, 9000,636, 443 |
|
SSL Certificate Cannot Be Trusted |
The SSL certificate for this service cannot be trusted. |
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below :
- First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.
If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server. This could make it easier to carry out man-in-the-middle attacks against the remote host. |
Purchase or generate a proper SSL certificate for this service. |