Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 518
  • Last Modified:

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-CA

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 The certificate is valid til 27/12/2015

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
0
cpmcomputers
Asked:
cpmcomputers
  • 2
1 Solution
 
Greg HejlCommented:
Your LDAPS is using the domain certificate for LDAPS.

You can follow this to change the certificate the service is using.
http://support.microsoft.com/kb/321051

You can also work with security metrics to accept the self-signed certificate if you determine your service is not public.

You can also secure this service using the firewall to only accept the ip ranges that are used by the spam service.  this will hide the service from general internet users and security metrics scanners.

remember to document the changes made to firewall.
0
 
cpmcomputersAuthor Commented:
Thanks for the suggestion

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
0
 
Greg HejlCommented:
I think if IP firewalling were done, many of the breaches that have occurred would not have gotten so far.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now