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

Products

• CA Application Test
• CA Continuous Application Insight (PathFinder)
• Service Virtualization

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.

Environment

All Supported DevTest releases.

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.

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. 

 

These are the keystores/truststores we deliver with DevTest:

rmi-keystore.jks    <== this has expired and can be deleted

rmi-truststore.jks  <== this has expired and can be deleted

 

These are used in DevTest as default keystores, but if you are using your own, they can be deleted:

vse.ks

webreckeys.ks

webserver.ks

Additional Information

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