PCI Compliance seeing wrong certificate in persnal store
Please be patient here as I am not overly familiar with SSL certificates
I have a client failing PCI Compliance testing
The two errors below relate to TCP on port 636 LDAPS (used by the external spam service to manage AD users automatically)
Description: SSL Certificate Cannot Be Trusted
Synopsis: The SSL certificate for this service cannot be trusted.
Impact: The server's X.509 certificate does not have a signature from a known public certificate authority. This situation can occur in three different ways, each of which results in a break in the chain below which certificates cannot be trusted.
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 SecurityMetrics 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.
Data Received: The following certificate was at the top of the certificate chain sent by the remote host, but is signed by an unknown certificate authority : |-Subject : CN= sbsserver.domain.local |-Issuer : CN=domain-sbs2008-SERVER-C
Resolution: Purchase or generate a proper certificate for this service.
Risk Factor: Medium/ CVSS2 Base Score: 6.4
AV:N/AC:L/Au:N/C:P/I:P/A:N
Description: SSL Certificate with Wrong Hostname
Synopsis: The SSL certificate for this service is for a different host.
Impact: The commonName (CN) of the SSL certificate presented on this service is for a different machine.
Data Received: The identities known by SecurityMetrics are : remote.domain.com mail.domain.com
(Entries sanitised but are valid external sans)
The Common Name in the certificate is :
sbs2008server.domain.local
(Entry sanitised but is valid servername.domain.local)
The Subject Alternate Name in the certificate is :
sbs2008SERVER.domain.local
Resolution: Purchase or generate a proper certificate for this service.
Further information
The server has a valid 3rd party certificate installed
The personal certificate store for the local computer account (SBS2008)
Has a third party (geotrust) certificate chain installed
With the san - > mail.domain.com The certificate is valid til 04/12/2015
There is also an internal certificate
With the san sbs2008server.domain.local
It seems "by design ?" that the PCI scan is seeing the internal certificate with the longest expiry ?
How do I change this for the LDAPS service only
In all other respects the server works fine on the third party external certificate
( Installed and renewed last year running the sbs wizards)
I do not want to remove the internal certificate as I have no idea what impact that has on other services
I have a client failing PCI Compliance testing
The two errors below relate to TCP on port 636 LDAPS (used by the external spam service to manage AD users automatically)
Description: SSL Certificate Cannot Be Trusted
Synopsis: The SSL certificate for this service cannot be trusted.
Impact: The server's X.509 certificate does not have a signature from a known public certificate authority. This situation can occur in three different ways, each of which results in a break in the chain below which certificates cannot be trusted.
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 SecurityMetrics 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.
Data Received: The following certificate was at the top of the certificate chain sent by the remote host, but is signed by an unknown certificate authority : |-Subject : CN= sbsserver.domain.local |-Issuer : CN=domain-sbs2008-SERVER-C
Resolution: Purchase or generate a proper certificate for this service.
Risk Factor: Medium/ CVSS2 Base Score: 6.4
AV:N/AC:L/Au:N/C:P/I:P/A:N
Description: SSL Certificate with Wrong Hostname
Synopsis: The SSL certificate for this service is for a different host.
Impact: The commonName (CN) of the SSL certificate presented on this service is for a different machine.
Data Received: The identities known by SecurityMetrics are : remote.domain.com mail.domain.com
(Entries sanitised but are valid external sans)
The Common Name in the certificate is :
sbs2008server.domain.local
(Entry sanitised but is valid servername.domain.local)
The Subject Alternate Name in the certificate is :
sbs2008SERVER.domain.local
Resolution: Purchase or generate a proper certificate for this service.
Further information
The server has a valid 3rd party certificate installed
The personal certificate store for the local computer account (SBS2008)
Has a third party (geotrust) certificate chain installed
With the san - > mail.domain.com The certificate is valid til 04/12/2015
There is also an internal certificate
With the san sbs2008server.domain.local
It seems "by design ?" that the PCI scan is seeing the internal certificate with the longest expiry ?
How do I change this for the LDAPS service only
In all other respects the server works fine on the third party external certificate
( Installed and renewed last year running the sbs wizards)
I do not want to remove the internal certificate as I have no idea what impact that has on other services
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I think if IP firewalling were done, many of the breaches that have occurred would not have gotten so far.
ASKER
yes have seen this article ( not that it makes a lot of sense to me :-)
I have imported the certificate and am doing some connection/pci testing to see if this is resolved
Takes 24 hrs.
I like the idea of securing the service on the firewall -would seem to be good practise anyway.
Will post tomorrow