WorkgroupShare Fails to Synchronize When Using SSL

  1. Home
  2. Knowledge Base
  3. Softalk
  4. Workgroupshare
  5. WorkgroupShare Fails to Synchronize When Using SSL


Clients are unable to synchronize with WorkgroupShare using the Secure Sockets Layer protocol (SSL) and Diagnostics may report the following error message:

Unable to create secure socket to test connection to the WorkgroupShare server on localhost.


This error occurs because the SSL certificates installed on the server cannot be accessed by the WorkgroupShare application, or the certificate files have been corrupted.


To resolve this problem, the certificates need to be deleted from the Windows Certificate Store, and then re-created by running the WorkgroupShare Server Setup once again. WorkgroupShare needs to be installed while logged in as a local administrator and it must be installed to run as a service under that same account.

More Info

The Local System Account does not have access to the Microsoft Windows Certificate Store. Therefore, for WorkgroupShare to be able to run and use SSL it must be running as a Windows service under the context of a local administrator.

Moreover, if you run the WorkgroupShare setup while logged in as Bob who has local administrative access, and elect to run the WorkgroupShare service as user Bill who also has local administrative access, SSL would fail.

Why? When the certificates are installed, they are done so as the currently logged in user, and encrypted by the WPAPI.DLL using the key of that user. In this instance, the certificate would be encrypted using Bob’s key, which is private. When WorkgroupShare tries to access the certificate store using the credentials of the account upon which it is running – Bill in this example – the service cannot do so, as Bill does not know Bob’s private key, and therefore cannot access the certificate. As a consequence SSL will not function.


Create a local user account and give it local administrator access permissions. This account will be used to install and run the WorkgroupShare server program. Log into the WorkgroupShare server computer using this account and remove the existing WorkgroupShare certificates.

Run Certificates.MSC. If it fails to run, please open a command window, and enter the following command:

regsvr32 %systemroot%system32certmmc.dll

Underneath Console Root are three certificate stores (Certificates – Current User, Certificates (Local Computer), and Certificates – Service(WorkgroupShare)). Right click on each one in turn, and select Find Certificates from the context menu.

Accept the default search parameters, and in the Contains: field type:


The results of the search will be populated in a list below. From this list, delete each certificate by right-clicking on it, and selecting Delete from the context menu.

As mentioned before, repeat this for each of the three certificate stores.

Once this has been completed, the WorkgroupShare Server component needs to be re-installed. Before doing so, however, please make a backup of your WorkgroupShare database. For SQL Server installations, please backup your database according to your database documentation. If you are using Microsoft JET, you can verify the location of your database file by following the steps given below:

  • Click Start >> Run and type: odbccp32.cpl
  • Click OK
  • Select the System DSN tab and double-click the SoftalkCollaborationSuite data source entry. The details window of the data source will show you where the WorkgroupShare database (SCS.mdb) is located.

When the database has been backed up, run the WorkgroupShare setup program. If necessary, download the latest version.

When re-installing the application you are asked if you wish to run WorkgroupShare as an Executable or as a Windows Service. Select Windows Service. Next, you will be asked under which credentials the service should run as. The default option is to run the service as the Local System Account, but this needs to be changed if you wish to use SSL. Select to run the service under the user account created earlier.

Note that this user account needs to be specified using the notation of domain or local machine nameusername

Continue to install WorkgroupShare. When installation is complete, open the WorkgroupShare Administrator, and do the following:

  • Go to Settings >> and then to the Server tab
  • Ensure that

Was this article helpful?

Related Articles