Skip to main content

DocuShare Fails to Start After Microsoft SQL Server Patching

Updated

TLS/SSL Connection Error: Server selected protocol version TLS10 not accepted

Note: Applies to DocuShare 7.5, 7.6, and 7.7.

Issue Summary

After applying Microsoft monthly security patches, DocuShare may fail to start and enter a continuous retry loop. The root cause is a TLS version conflict: Amazon Corretto JDK 21, which DocuShare 7.x uses as its Java runtime, requires a minimum of TLS 1.2 for all SSL connections. Certain older SQL Server versions only offer TLS 1.0 during the JDBC connection handshake. When these patches change SQL Server's SSL negotiation behavior, the handshake fails and DocuShare cannot connect to the database.

This article describes how to identify the issue, apply an immediate workaround, and implement a permanent fix.

Symptoms

After applying Microsoft security patches and restarting the server, you observe one or more of the following:

  • DocuShare does not start and remains in a retry loop.

  • The DocuShare log files contain the following error:

 

com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a

secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.

Error: The server selected protocol version TLS10 is not accepted by client

preferences [TLS13, TLS12]

 

Caused by: javax.net.ssl.SSLHandshakeException: The server selected protocol

version TLS10 is not accepted by client preferences [TLS13, TLS12]

 

  • The DocuShare service eventually stops after exhausting connection retries.

  • No DocuShare pages are accessible; the site returns a service unavailable error.

Note:  DocuShare log files are located in the logs subdirectory of the DocuShare installation. The default installation path is C:\Xerox\DocuShare\logs.

Applies To

DocuShare versions

  • DocuShare 7.5 with Amazon Corretto JDK 21

  • DocuShare 7.6 with Amazon Corretto JDK 21

  • DocuShare 7.7 with Amazon Corretto JDK 21

SQL Server versions that may be affected

  • SQL Server 2014 RTM through SP2 (build 12.0.2000 up to 12.0.5999) -- these builds do not support TLS 1.2 at the SQL Server application level

  • SQL Server 2017 on the GDR (security-only) update track with builds earlier than 14.0.3257 -- verify your specific build

  • Any SQL Server version where TLS 1.2 has not been explicitly enabled and configured

Known triggering patches

  • KB 5077465 -- SQL Server Security Update (March 2026)

  • KB 5078740 -- Windows Monthly Cumulative Update (March 2026)

Note:  Other Microsoft monthly security patches that modify SQL Server SSL/TLS negotiation behavior may also trigger this issue in future update cycles.

Root Cause

DocuShare 7.5 / 7.6 / 7.7 uses Amazon Corretto JDK 21 as its Java runtime. JDK 21 enforces a minimum of TLS 1.2 for all SSL/TLS connections. TLS 1.0 and TLS 1.1 are disabled in JDK 21 by default and cannot be negotiated.

Older SQL Server versions only support TLS 1.0 at the SQL Server application layer. When Microsoft monthly patches update SQL Server's SSL behavior, SQL Server explicitly proposes TLS 1.0 during the JDBC SSL handshake. JDK 21 rejects this, the handshake fails, and DocuShare cannot establish a database connection.

The failure chain is as follows:

  • Microsoft monthly patch modifies SQL Server SSL negotiation behavior.

  • DocuShare's JDBC driver (using JDK 21) initiates an SSL handshake with SQL Server.

  • SQL Server proposes TLS 1.0 as the connection protocol.

  • JDK 21 rejects TLS 1.0. Only TLS 1.2 and TLS 1.3 are accepted.

  • The JDBC connection cannot be established.

  • DocuShare enters a startup retry loop, exhausts retries, and fails to start.

Warning:  Enabling TLS 1.2 in the Windows SCHANNEL registry alone is not sufficient for SQL Server 2014 RTM (build 12.0.2000.x). That specific build does not support TLS 1.2 at the SQL Server application level and will ignore the registry settings. SQL Server 2014 SP1 and later support TLS 1.2 when combined with the registry configuration. See the resolution steps below for details.

How to Determine Your SQL Server Version

Before applying any of the resolution options below, confirm your SQL Server version and build number.

  1. Connect to SQL Server using SQL Server Management Studio (SSMS).

  2. Open a new query window and run the following command:

    SELECT @@VERSION

  3. Review the output. The build number appears in the version string, for example:

    Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64)

Use the table below to determine TLS 1.2 support for your version:

  • SQL Server 2014 build 12.0.2000 through 12.0.5999 (RTM, SP1, SP2) -- TLS 1.2 NOT supported. Must upgrade SQL Server first.

  • SQL Server 2014 SP1 (build 12.0.4416.0 or later) -- TLS 1.2 supported when combined with the Windows registry configuration.

  • SQL Server 2016 (any build) -- TLS 1.2 supported.

  • SQL Server 2017 GDR track, build 14.0.2095 -- TLS 1.2 support may be incomplete. Upgrade to the latest CU track.

  • SQL Server 2017 CU track (build 14.0.3257 or later) -- TLS 1.2 supported.

  • SQL Server 2019 and 2022 (all builds) -- TLS 1.2 supported by default.

Resolution

Three resolution paths are provided. Option A is the confirmed working solution (verified by Xerox Engineering) and should be applied in all cases except SQL Server 2014 RTM. Option B is an emergency-only workaround for SQL Server 2014 RTM environments that cannot yet support TLS 1.2. Option C describes the SQL Server upgrade path.

Option A: Enable TLS 1.2 via Windows Registry (Confirmed Solution)

This is the confirmed solution. Enabling TLS 1.2 in the Windows SCHANNEL registry and .NET Framework, followed by a full server reboot, resolves the issue while keeping the database connection encrypted. This applies to all supported SQL Server versions (2012 SP4+, 2014 SP1+, 2016, 2017, 2019, 2022).

Note:  If you are running SQL Server 2014 RTM (build 12.0.2000.x) -- the original release with no service packs applied -- that version does not support TLS 1.2 at the application level and this option will not work. Apply Option B as a temporary workaround, then upgrade SQL Server.

  1. On the SQL Server machine, open Registry Editor as Administrator. Press Windows+R, type regedit, and click OK.

  2. Enable TLS 1.2 for the SQL Server side. Navigate to or create the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

    Within that key, create or set the following DWORD (32-bit) values:

  • Enabled = 1

  • DisabledByDefault = 0

    Note:  If the TLS 1.2\Server or TLS 1.2\Client subkeys do not already exist, you must create them manually in Registry Editor.

  1. Enable TLS 1.2 for the client (outbound) side. Navigate to or create the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

    Within that key, create or set the following DWORD (32-bit) values:

  • Enabled = 1
  • DisabledByDefault = 0

  1. Enable strong cryptography in .NET Framework (64-bit). Navigate to:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

    Create or set:

  • SchUseStrongCrypto = 1

  1. Repeat the .NET Framework setting for the 32-bit path. Navigate to:

    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319

    Create or set:

  • SchUseStrongCrypto = 1

  1. Restart the SQL Server service:

    net stop MSSQLSERVER

    net start MSSQLSERVER

  2.  Perform a full server reboot. This is required -- not optional -- to ensure SCHANNEL registry changes take effect system-wide:

    shutdown /r /t 0

  3. After the server restarts, start DocuShare and verify that it starts normally.

Option B: Emergency Workaround -- Disable JDBC Encryption (SQL Server 2014 RTM Only)

Use this option ONLY if your SQL Server version is SQL Server 2014 RTM (build 12.0.2000.x) and cannot be immediately upgraded. This bypasses the TLS handshake entirely by disabling SSL encryption on the JDBC connection, allowing DocuShare to start. It is a temporary workaround only -- plan to upgrade SQL Server as soon as possible.

  1. On the DocuShare server, stop the DocuShare service if it is running.

  2. Open the following file in a text editor (Notepad, for example):\

    <DocuShare Home>\config\JDBCPropertyBean.properties

    Note:  The default DocuShare Home is C:\Xerox\DocuShare. Replace <DocuShare Home> with your actual installation path.

  3. Locate the line beginning with url= in the file. It will look similar to this:

    url=jdbc:sqlserver://SQLSERVER01;databaseName=DocuShare;

  4. Append the following parameters to the end of the url= value:

    encrypt=false;trustServerCertificate=true;

    The updated line should look similar to this:

    url=jdbc:sqlserver://SQLSERVER01;databaseName=DocuShare;encrypt=false;trustServerCertificate=true;

  5. Save the file and close the text editor.
  6. Start the DocuShare service. DocuShare should start normally.

Warning:  This workaround disables SSL encryption on the database connection. Use only as a temporary measure for SQL Server 2014 RTM environments while planning a SQL Server upgrade. Once SQL Server is upgraded to SP1 or later, remove encrypt=false;trustServerCertificate=true; from JDBCPropertyBean.properties and apply Option A to restore encrypted connections.

Option C: Upgrade SQL Server

Note: Please review the system requirements for the version of DocuShare you are currently running to confirm that it is supported. If you have an active support contract, we recommend upgrading to the latest version of DocuShare. For more information about upgrading your current version, please contact DocuShare Support.

Upgrading SQL Server resolves the root cause for SQL Server 2014 RTM environments that cannot use the registry fix (Option A) and is strongly recommended for all SQL Server 2014 deployments since that version reached end of extended support in October 2024.

SQL Server 2014

  • Minimum fix: Upgrade to SP1 (build 12.0.4416.0 or later). SQL Server 2014 SP1 and later support TLS 1.2 when combined with the registry fix in Option A.
  • Recommended: Upgrade to SQL Server 2019 or SQL Server 2022.

SQL Server 2014 reached end of extended support in October 2024. Microsoft no longer publishes security updates for this version.

SQL Server 2017

  • Switch from the GDR track to the Cumulative Update track and upgrade to build 14.0.3257 or later for full TLS 1.2 support.
  • SQL Server 2017 extended support ends October 2027. Plan migration to SQL Server 2019 or 2022.

SQL Server 2019 and 2022

  • TLS 1.2 is supported by default on all builds. No additional SQL Server configuration is required.

Note:  After upgrading SQL Server from RTM to SP1 or later, remove the encrypt=false;trustServerCertificate=true; parameters from JDBCPropertyBean.properties, then follow Option A to enable TLS 1.2 via the registry and restore encrypted connections.

Frequently Asked Questions

Will this happen again after the next patching cycle?

No. Once the registry changes from Option A are in place and the server has been fully rebooted, they will persist across future patching cycles. However, for SQL Server 2014 RTM environments using the Option B workaround (encrypt=false), the underlying incompatibility remains and the workaround will need to stay in place. Those environments should plan a SQL Server upgrade.

My server was restored to a snapshot after this incident. Do I need to act now?

If the snapshot was taken before the Microsoft patches were applied, the patches will be re-applied during your next update cycle and the issue will recur. Apply the workaround or permanent fix proactively before the next patching window.

Does this affect DocuShare installations using PostgreSQL?

No. This issue is specific to Microsoft SQL Server. DocuShare installations using PostgreSQL are not affected.

Does this affect DocuShare 8.x?

This specific issue has been identified for DocuShare 7.5 / 7.6 / 7.7 with Corretto JDK 21. DocuShare 8.x uses a different database configuration and Java packaging. If you are running DocuShare 8.x and observing a similar TLS error, contact Xerox DocuShare Support.

Is encrypt=false safe to use permanently?

From a DocuShare functionality standpoint, yes. However, it disables encryption on the database connection and should only be used for SQL Server 2014 RTM environments as a temporary measure. For environments where DocuShare and SQL Server are co-located on the same machine or same trusted network segment, the practical risk is low. Apply Option A (registry fix) once SQL Server is upgraded to SP1 or later to restore encrypted connections.