DevTest SSL Certificate with Port 2010 Indicates Wrong Hostname and Weak Hashing Algorithm

Article Id: 77725
Status: Published
Updated On: 13-04-2018 12:33
Products:
CA Application Test , Service Virtualization , CA Continuous Application Insight (PathFinder)
Issue/Introduction:

AFS Security Team has sited the following vulnerabilities for DevTest servers:

Wrong Hostname, Protocol: TCP    Port: 2010
The SSL certificate for this service is for a different host.    The 'commonName' (CN) attribute of the SSL certificate presented for this service is for a different machine.

The Common Name in the certificate is :  Lisa"

---

SSL Certificate Signed Using Weak Hashing Algorithm, Protocol: TCP, Port: 2010

|-Subject             : [email protected]/C=US/ST=Texas/L=Dallas/O=Lisa/OU=Lisa/CN=Lisa
|-Signature Algorithm : SHA-1 With RSA Encryption

An SSL certificate in the certificate chain has been signed using a weak hash algorithm.    "The remote service uses an SSL certificate chain that has been signed using a cryptographically weak hashing algorithm (e.g. MD2, MD4, MD5, or SHA1). These signature algorithms are known to be vulnerable to collision attacks. An attacker can exploit this to generate another certificate with the same digital signature, allowing an attacker to masquerade as the affected service.

Note that this plugin reports all SSL certificate chains signed with SHA-1 that expire after January 1, 2017 as vulnerable. This is in accordance with Google's gradual sunsetting of the SHA-1 cryptographic hash algorithm.

Note that certificates in the chain that are contained in the Nessus CA database (known_CA.inc) have been ignored."    Contact the Certificate Authority to have the certificate reissued.    "http://tools.ietf.org/html/rfc3279
http://www.nessus.org/u?e120eea1
http://technet.microsoft.com/en-us/security/advisory/961509"

Cause:

In DevTest we use self-signed certificates for SSL connections.

And due to these self-signed certificates the vulnerability scanning tool is not trusting it.

Environment:

All Supported DevTest releases.

Resolution:

There are 2 ways to solve it:

1. In the scanning tool, we can add the DevTest certificates under the trusted certs. And continue to use the self-signed certs with DevTest.

OR

2. To use a certificate issued by a trusted or private Certificate Authority and add it to the the keystore files in DevTest and this cert will be used by DevTest during SSL connections.