locked
SSL Certificate with Wrong Hostname - 1433/tcp RRS feed

  • Question

  • Hi 

    This it my question Pls answer it to Step by step

    I Just Scan the Vulnerabilities through the Nessus Scaning Tool . I found this  Medium Risk Security Vulnerabilities form the server, The Server Running on Windows server 2008r2  I want to Correct this Medium Risk Security Vulnerability ASAP

    Details of Medium Risk Security Vulnerabilities
     Vulnerability : SSL Certificate with Wrong Hostname - 1433/tcp
    Medium Risk Security Vulnerability
    • Synopsis :
    The SSL certificate for this service is for a different host.
    • Description :
    The commonName (CN) of the SSL certificate presented on this service is for a
    different machine.
    • Solution :
    Purchase or generate a proper certificate for this service.
    • Plugin Output :
    The identity known by Standard Tool is :
    10.x.x.x
    The Common Name in the certificate is :
    SSL_Self_Signed_Fallback
    • Affected Port :
    1433/tcp - mssql

    Wednesday, March 19, 2014 7:27 AM

All replies

  • I am looking for the same! Any ideas please
    Thursday, May 29, 2014 1:32 AM
  • anyone find a solution to this?
    Wednesday, February 4, 2015 2:19 PM
  • Same issue here, any impact to our system? thank you.
    Thursday, February 5, 2015 7:59 AM
  • So, I imagine this is on your SQL server. When the SQL service starts, it searches the certificate store for a qualifying certificate. It must match 5 requirements.

    http://blogs.msdn.com/b/sql_protocols/archive/2005/12/30/508311.aspx
    https://msdn.microsoft.com/en-us/library/ms189067.aspx
    https://technet.microsoft.com/en-us/library/ms191192.aspx

    Open your certificate store then open the certificate properties.
    1. Make sure the certificate is in either the Personal store of the local computer or the personal store of the service account used to start SQL.
    2. In the certificate properties, choose the “Valid from” and “Valid to” Fields.  The certificate must still be valid.
    3. Choose the “Enhanced Key Usage” field.  Ensure the value contains “Server Authentication (1.3.6.1.5.5.7.3.1)”.
    4. Choose the “Key Usage” field.  Ensure the value contains “Key Encipherment”.
    5. Choose the “Subject field”.  Ensure the value contains “CN = “ <FQDN of the server>.  This must contain the FQDN of the server not just the NetBIOS name.

    If any of these are missing or incorrect, you must request a new cert with this information.

    Once these requirements are met, SQL should be able to see the certificate.  Open SQL server Configuration Manager.  Choose SQL Server Services.  Restart the SQL Server service.  After restarting the service Choose Protocols for <Instance>, right click and open properties.  Click the certificate tab.  The certificate should appear in the drop down.  You might also have to Click the flags tab and change Force Encryption to Yes.  After setting the certificate and forcing encryption, restart the SQL server service.

    http://thesqldude.com/2011/08/03/sql-server-service-does-not-start-after-enabling-ssl-encryption/

    After accomplishing the tasks above, the SQL service may not restart.  This is because the service account does not have permission to the certificate.  Go back to the certificate store, right click the certificate and choose All Tasks > Manage Private Keys.  Add the SQL server user security group (SQLServerMSSQLUser$[Computer_Name]$[Instance_Name]).  After giving the group permission to the certificate, the SQL service should start.  If not, then SQL service accounts weren’t set up properly, and you will have to give permission directly to the service account.  Read the article above to resolve the issue with the SQL service accounts.

    Wednesday, May 13, 2015 1:28 PM