Endpoint Protection

 View Only
Expand all | Collapse all

SEPM nonfunctioning after updating expiring wildcard SSL Certificate with 14.3 RU4 and default SQL Express

  • 1.  SEPM nonfunctioning after updating expiring wildcard SSL Certificate with 14.3 RU4 and default SQL Express

    Posted Jun 24, 2022 02:51 PM

    Unable to access SEPM after replacing our wildcard SSL certificate (SEPM > Admin > Servers > SEPM_Server > Manage Server Certificate > Update the server certificate) and a reboot. The SEPM runs Windows Server 2016 (with Microsoft's June Cumulative update) and SEPM 14.3 RU4. Earlier this year, when I updated SEPM, the upgrade process migrated the existing embedded database to SQL Express, and everything has been running well for months.

    Our existing wildcard SSL certificate is expiring next month, and yesterday I updated this certificate on the SEPM server. After updating the certificate with SEPM, everything appeared to be functioning, including exporting new client packages. However, after a reboot, the SQL Express service didn't start. Looking through the SQL logs (Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG - per Viewing the SQL Server Error Log - SQL Server | Microsoft Docs), I discovered that SQL Express couldn't find the certificate it was configured, which corresponded to the old wildcard certificate. I followed a Microsoft article, SQL Server fails to start with error 17182 - SQL Server | Microsoft Docs, in an attempt to get SQL Express to use the new wildcard certificate. Still, the SQL Express instance would not start; therefore, I reimported the old wildcard certificate to the Windows Server Certificate store (Computer > Personnel). This allowed SQL Express to start, but attempting to log into the management interface for SEPM gave an error.

    I then reviewed a Broadcom article posted/updated yesterday called "Configuring encrypted communication between Symantec Endpoint Protection Manager and Microsoft SQL Server" (https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/endpoint-protection/all/upgrading-to-a-new-release-v14510472-d27e6/Configuring-encryption-communication-between-SEPM-and-SQL-Server.html).

    I followed Step 3 of "Import the SQL Server certificate into Windows on the Symantec Endpoint Protection Manager computer" with both wildcard certificates.

    I followed Step 4 of "Configure permissions for the jre11 folder." However, we are not using a Domain Admin or other domain user with SQL Express. Instead, it uses the default local account created when upgrading to 14.3 RU4, which is NT Service\MSSQL$SQLEXPRESSSYMC.

    I could not follow Step 5 of "Open the Management Server Configuration Wizard and complete the Server Configuration with Windows Authentication option" because I don't know the password associated with NT Service\MSSQL$SQLEXPRESSSYMC. This account and the password were auto-generated with the 14.3 RU4 upgrade.

    I followed Step 6 of "Check if the communication is encrypted and using the SQL Server certificate." Substeps 1 and 2 were already configured correctly. After installing SQL Management Studio, I ran the requested query, showing only two connections. Both shared memory and encrypted.

    I suspect that SEPM expects the SSL certificate used within SEPM and SQL Express to be the same, therefore failing. I don't know enough about SQL Server or Express to troubleshoot this problem further (other than knowing that the SQL Server Configuration Manager cannot be used to select a wildcard certificate to use with SQL encryption).

    I submitted a case along with the SyDiag information but wanted to reach out while waiting on support to see if anyone has any suggestions.



  • 2.  RE: SEPM nonfunctioning after updating expiring wildcard SSL Certificate with 14.3 RU4 and default SQL Express

    Posted Jun 24, 2022 08:54 PM
    Support resolved this by turning off using encryption on SQL Express, modifying ROOT.xml, and running upgrade.bat. SEPM is now using the new wildcard certificate, but the local SQL Express is not using encryption for communication with SEPM. Not ideal, but at least it is now functioning again.