SSL Certificate Cannot be Trusted, Certificate Signed Using Weak Hashing Algorithm, Certificate with Wrong Hostname
Hi Guys,
We ran a Nessus scan on our DC and Exchange server,
It is picking up; SSL Certificate Cannot be Trusted, Certificate Signed Using Weak Hashing Algorithm, Self-Signed Certificate, etc from the Exchange server.
5 x entries of each.
The Exchange server does have a valid public certificate, and SSL labs gives this certificate an A rating.
I gathered that the findings reported is most likely linked to the Exchange self-signed certificates installed by default.
When I check in MMC, certificates, I am only able to identify 3 x self-signed certificates under the Personal\Certificates container
There is nothing listed under the "Untrusted Certificates" folder
My Questions,
Where does Nessus find the other two "self-signed" certificates?
Why does it complain about valid self-signed certificates, if a SHA256RSA public certificate has been installed?
We ran a Nessus scan on our DC and Exchange server,
It is picking up; SSL Certificate Cannot be Trusted, Certificate Signed Using Weak Hashing Algorithm, Self-Signed Certificate, etc from the Exchange server.
5 x entries of each.
The Exchange server does have a valid public certificate, and SSL labs gives this certificate an A rating.
I gathered that the findings reported is most likely linked to the Exchange self-signed certificates installed by default.
When I check in MMC, certificates, I am only able to identify 3 x self-signed certificates under the Personal\Certificates container
There is nothing listed under the "Untrusted Certificates" folder
My Questions,
Where does Nessus find the other two "self-signed" certificates?
Why does it complain about valid self-signed certificates, if a SHA256RSA public certificate has been installed?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Yeah regularly are the ones that are installed by default.
What you can do in this stage is to remove the ones that are "expired" but those that are used internally I think it can be ignored.
From 6
1. WMSvc certificate (installed by default) (Marked)
2. ServerName certificate (installed by default) (marked)
3. PublicName certificate (signed sha256 or not?) if not (marked) if yes not marked)
4. Another PublicName certificate (expired) (marked)
5. PublicName certificate (signed sha256 or not?) if not (marked) if yes not marked)
6. Microsoft Exchange Server Auth Cert (marked)
This is my guess...
What you can do in this stage is to remove the ones that are "expired" but those that are used internally I think it can be ignored.
From 6
1. WMSvc certificate (installed by default) (Marked)
2. ServerName certificate (installed by default) (marked)
3. PublicName certificate (signed sha256 or not?) if not (marked) if yes not marked)
4. Another PublicName certificate (expired) (marked)
5. PublicName certificate (signed sha256 or not?) if not (marked) if yes not marked)
6. Microsoft Exchange Server Auth Cert (marked)
This is my guess...
ASKER
Strangely enough, Nessus did not say anything about the expired certificate.
This certificate is still linked to IIS and SMTP.
I am wary to remove this certificate, as I've had an instance of ECP breaking sometime ago, after removing the certificate linked to IIS.
Although it shows linked to IIS ... ECP currently works without problems over the "valid" certificate.
It seems the only concern Nessus reports is the ServerName certificate - installed by default as it was signed with SHA1.
As mentioned above, this certificate is only accessible internally, thus can be safely ignored?
This certificate is still linked to IIS and SMTP.
I am wary to remove this certificate, as I've had an instance of ECP breaking sometime ago, after removing the certificate linked to IIS.
Although it shows linked to IIS ... ECP currently works without problems over the "valid" certificate.
It seems the only concern Nessus reports is the ServerName certificate - installed by default as it was signed with SHA1.
As mentioned above, this certificate is only accessible internally, thus can be safely ignored?
Interesting.
If the cert is enabled on any exchange service do not remove it yet.
On exchange once you assign services you wont be able to remove it.
The thing is to know over the bindings on iis which one is actually in use
If the cert is enabled on any exchange service do not remove it yet.
On exchange once you assign services you wont be able to remove it.
The thing is to know over the bindings on iis which one is actually in use
ASKER
It is Exchange Server 2016.
I checked the certificates in EMS, and found the following:
1. WMSvc certificate (installed by default)
2. ServerName certificate (installed by default)
3. PublicName certificate
4. Another PublicName certificate (expired)
5. PublicName certificate
6. Microsoft Exchange Server Auth Cert
All certificates are SHA256RSA, accept ServerName certificate which is SHA1RSA
This certificate is only used internally,
Nessus reports this certificate on ports 25, 465, 2525, 717, 587
All ports are only opened internally.
Should Exchange Services for this certificate be re-assigned? On ports 25, 465, 2525, 717, 587?