locked
SQL Connection Failed for SCCM 2012 R2 (Unable to load user-specified certificate) RRS feed

  • General discussion

  • We've recently completed an upgrade from SCCM 2012 SP1 to 2012 R2 and have been running in the new environment for about a week. As of this morning, The consoles failed to connect to the CAS' and one of the Primary Site's database. The issue was resolved easily enough by addressing a certificate issue in SQL, but I'm left wondering if there's a correlation between the SP1-to-R2 upgrade that would cause the cert to fail. Anyone have experience with this?

    2014-01-21 22:10:11.81 Server      The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d. Check certificates to make sure they are valid.

    2014-01-21 22:10:11.81 Server      Error: 26014, Severity: 16, State: 1.

    2014-01-21 22:10:11.81 Server      Unable to load user-specified certificate [Cert Hash(sha1) "haaaaassssshhhh"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.

    2014-01-21 22:10:11.81 Server      Error: 17182, Severity: 16, State: 1.

    2014-01-21 22:10:11.81 Server      TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.

    2014-01-21 22:10:11.81 Server      Error: 17182, Severity: 16, State: 1.

    2014-01-21 22:10:11.81 Server      TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Cannot find object or property.

    2014-01-21 22:10:11.81 Server      Error: 17826, Severity: 18, State: 3.

    2014-01-21 22:10:11.81 Server      Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.

    2014-01-21 22:10:11.81 Server      Error: 17120, Severity: 16, State: 1.

    2014-01-21 22:10:11.81 Server      SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.


    • Changed type Joyce L Thursday, January 23, 2014 9:11 AM
    Wednesday, January 22, 2014 3:12 PM

All replies

  • I've never seen that happening after upgrading to R2.

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, January 22, 2014 3:25 PM
  • We got the same certificate related error events after a fresh install of SCCM 2012 R2 on a new server. It happened during the first reboot after SCCM was installed. In the Certificates mmc, I right-clicked on the certificate used by SQL and chose Manage Private Keys. Giving the service account that runs the MSSQLSERVER service read rights to the private key allowed SQL to start. However, after a day or so we rebooted the server again, and SQL wouldn't start. Something had removed the service account's read permission. Since the SCCM configuration wasn't that far along, we uninstalled SCCM. After giving the service account read rights again, and rebooting several times over a few days, and SQL started every time. We then installed SCCM 2012 R2 again, and checked the certificate's permissions before rebooting. The service account still had read permissions when the install completed, but as soon as the server was rebooted, it lost the permissions again.

    The Certificates mmc was then used to request a second computer certificate and then SQL was configured to use that new certificate via SQL Server Configuration Manager. After several days and a number of reboots the SQL services have started normally every time so the second certificate seems to have fixed the issue. I have kept the original certificate for fear that removing it will cause whatever part of SCCM 2012 R2 that modifies the original certificate to start removing permissions from the new certificate as well.

    • Edited by Loc_750 Tuesday, February 4, 2014 3:00 PM
    Wednesday, January 29, 2014 3:52 PM