Synergy-core: ERROR: failed to verify server certificate fingerprint

Created on 7 May 2015  路  53Comments  路  Source: symless/synergy-core

I think this might happen because I went from 1.7.1 then downgraded them to 1.6.2 then upgraded to 1.7.2. and maybe the client still remember the old certificate but the server already got a new one.

Both are on 1.7.2
OS X 10.10.3 (14D136)

bug

Most helpful comment

For some reason, setting the error level to DEBUG2 trigger the fingerprint dialog. And fixed this issue.

All 53 comments

For some reason, setting the error level to DEBUG2 trigger the fingerprint dialog. And fixed this issue.

Nice investigation. Quite bizzare, but this helped me upgrading from 1.6.2 to 1.7.2 (Mac 10.10 - Client, Windows 7 - Server). After setting it to DEBUG2 and restarting, the Mac popped a box asking to confirm the new fingerprints of the Server. Restarted again and now we are all good.

Confirmed I have tested this too and is now working correctly.

Setting DEBUG2 fixed the dialog for me too

Setting DEBUG2 fixed the dialog and prompted by client machine (Windows) to accept the fingerprint of the server. Thanks!

I confirm the behavior. 1.7.2, Linux (both server and client) got the dialog only after changing the debug level.

Happened to me between 2 Yosemite Macbook Pros, both using 1.7.3.

2009 Mac originally auto configured as a server, started it up.
2015 Mac started up app for the first time, auto configured as server.
Switched 2009 Mac to client, would not prompt for fingerprint verification after connecting to the 2015 Mac.
Rebooted both machines, reopened Synergy, still would not prompt for fingerprint verification.

Both machines had the logs set to Warnings only. Switched the client Mac to Debug2 and got the popup immediately. After confirming, switched it back to Warning because geez was that laggy. :unamused:

still there at 1.7.3 (Ubuntu + OSX). Thanks for sharing your knowledge, helped me to upgrade to 1.7.3

Running 1.7.3 under Arch Linux, can't get the dialog to appear at all, no matter the debug level. Any way to add a fingerprint manually?

Running 1.7.4 Server Mac 10.10, client Windows 7 same issue. DEBUG2 triggered the certificate message. Not as bad as the Windows 7 install dll bug :)

For me it is working on 1.7.4rc but I聽had to restart Windows (synergy server) first. I聽have ERROR聽on client and fingerprint showed after windows was restarted (service restart didnt help). There was no need to restart linux client (same version)

Seems to be working now with the latest git rev, with the default debug level.

@kepi RC7?

I tried that with rc5. Is new test with rc8 needed?

same issue with 1.7.4 stable ( OSX + linux mint 17.2)

Confirmed v1.7.4 stable (OSX + Ubuntu 12.04). Fixed by switched to DEBUG2, approving the certificate, then switching back to a higher logging level.

Confirmed, v1.7.4 Linux mint 17.2. No way to confirm fingerprint after upgrade from v1.6 to v1.7.4

+1

Confirmed v1.7.4 Linux Mint 17.2 on command line. Switching to DEBUG2 did not work for me, but using the gui works.
Manual fixing might be possible by creating ~/.synergy/SSL/Fingerprints/TrustedServers.txt containing the fingerprint.

Confirmed, v1.7.4 on Windows 10/Windows 7 x64. Switching to DEBUG2 was a successful workaround for me.

Bug confirmed in v1.7.6 RC1, client: Windows 10 Home 64-bit, server: Ubuntu 15.10 32-bit.

The DEBUG2 workaround on client-side to accept fingerprint (and then back to lower logging level) worked for me too.

Still present in 1.8.0-beta-4ff3cdd - Tested on Ubuntu (both client and server).

Confirmed on latest Windows public beta 1.80..using "Debug2" work-around. Looking forward to a real fix.

You don't have to go all the way to debug2, just setting the client to NOTE worked for me.

Bug confirmed on OSX - "1.7.6 - Mar 15, 2016". Thanks for posting the workaround!

Synergy 1.7.6 / Server: Mac OS X 10.11.5 Beta / Client: Windows 7

Switching to DEBUG2 on client, accepting certificate, and then switching back to ERROR, worked for me. Thank you for the workaround.

Synergy 1.7.6 / Server: Ubuntu 15.10 / Client Max OS X 10.11.4

Thanks for posting the work-around.

Synergy 1.7.6 / Server: OS X 10.11.5 / Client: Windows 10

Same thing here. Didn't get the certificate validation until I turned logging to Debug2 on the Client and received the prompt. Seems like that should happen regardless of log level.

Just upgraded to 1.8.2 and had to use the same workaround (drop logging to DEBUG2 to get prompted for SSL certificate)

Same problem on 1.8.3. Fortunatelly same workaround helped.

This issue is still present in 1.8.5 version (tested on Windows 7 both server and client).

The above mentioned workaround (DEBUG2) also works.

still present in 1.8.5-stable-a18eba7
Can't use workaround (DEBUG2) - prompt about SLL sertificate doesn't help to confirm it...

1.8.6 still present

Confirmed still in 1.8.6-stable-2ab21aa

1.8.7 still present. Thanks for the work around using DEBUG2 though.

1.8.8 still present, especially when connecting command-line from Ubuntu client to Windows server.

This can happen if the SSL directory and certificate files haven't been created by the GUI yet.
Some files that should exist:
mac OS: ~/Library/Synergy/SSL/Fingerprints/TrustedServers.txt
Linux: ~/.synergy/SSL/Fingerprints/TrustedServers.txt
Windows: %APPDATA%\Synergy\SSL\Fingerprints\TrustedServers.txt

along with a line in the TrustedServers.txt file that has the server's fingerprint (the same thing visible in the server's GUI)

It may give a few more errors if a client doesn't have a generated certificate file (.pem) but I can't remember. Just make sure you've had the GUI generate all the SSL stuff.

Note for windows: I think the file needs to be using Unix newlines (\n) not Windows newlins (\r\n).

I did have the GUI generate all the SSL stuff - the problem is that I am trying to force lightdm to run it at startup and there is a hiccup with the the fact it is being run by the root upon startup.

@chiffa Yeah that is a bit of a problem. You'll probably have to run some script that su <user> then forks off into the synergyc executable.

So, for me the following pipeline worked:

  • Configure the server and the client with the GUI application
  • Make sure SSL server certificate fingerprint was stored in the ~/.synergy/SSL/Fingerprints/TrustedServers.txt
  • run sudo -su myself /usr/bin/synergyc -f --enable-crypto my.server.ip.address
  • after that check everything was working with sudo /usr/bin/synergyc -d DEBUG2 -f --enable-crypto my.server.ip.address
  • and finally add the greeter-setup-script=sudo /usr/bin/synergyc --enable-crypto my.server.ip.address line into the lightdm.conf file under the [SeatDefaults] section.

Just downloaded latest binary for Ubuntu x64, can confirm issue persists

Mac Osx Version: 1.8.8-stable-25a8cb2

When I set my linux box as client and the Mac as server I got the "trust" dialogue, and the app worked as expected. When the linux machine was server and mac the client, I got the verify error generated by the mac client.

17-12-31T23:53:17] ERROR: failed to verify server certificate fingerprint
2017-12-31 23:53:17.419 synergyc[560:507] starting cocoa loop
[2017-12-31T23:53:34] ERROR: failed to ve

The set logging to "DEBUG2" solved the problem, and I was able to return the logging back to WARN level.

[2017-12-31T23:56:18] DEBUG2: connecting secure socket
[2017-12-31T23:56:18] NOTE: server fingerprint: 65XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[2017-12-31T23:56:18] INFO: connected to secure socket
[2017-12-31T23:56:18] INFO: server ssl certificate info: /CN=Synergy
[2017-12-31T23:56:18] DEBUG2: connected secure socket

I can not believe this but setting to DEBUG2 actually triggered the prompt which asked me to accept the Fingerprint of the server and worked afterwards. I hope it does not fill in the logs too much. thanks for the help people. i have struggled to fix this for many months. even paid money to download synergy2 which also has the same issue btw.

finally its working with version 1.8

Per the comment https://github.com/symless/synergy-core/issues/4626#issuecomment-283988601 I was able to work out how to enable the trust via the command line instead of requiring the GUI which actually works out way better for my use cases anyways.

I updated the Arch Wiki with it here but basically just need to run:

mkdir -p ~/.synergy/SSL/Fingerprints
echo -n | openssl s_client -connect $YOUR_SYNERGY_SERVER:24800 2>/dev/null | openssl x509  -noout -fingerprint | cut -f2 -d'=' | tee ~/.synergy/SSL/Fingerprints/TrustedServers.txt
synergyc --enable-crypto $YOUR_SYNERGY_SERVER

I just copied from my GUI user's homedir .synergy/SSL/Fingerprints/TrustedServers.txt to my root's homedir.

Wow, this is 5 years old now and it's still a problem.

FWIW I'm on Arch Linux and I came across this on the ArchWiki: Client is returning "failed to verify server certificate fingerprint"

I noticed I did not have the directory tree as mentioned. After scratching my head a bit I figured I needed more information on where the fingerprints where being stored locally so I switch the log level to debug on both client and server and then reloaded both, to my suprise this promted a new window that asked if I wanted to trust the server and after agreeing it just started working.

I hope this helps someone.

Also make sure to set the screen name of the client in the server's layout configurator.

If you still can reproduce this issue, could you please check with the latest release candidate?
We have made a good number of improvements in this area: https://symless.com/synergy/releases/synergy-1-13-release-candidate-2

I can reproduce the error on Windows with 1.13-rc.

I am not sure if it is the same error reason/situation as the other reports but the result is the same error message.

I got a new company laptop and I used an azure active directory account when setting it up. My name contains an Umlaut (眉) and an accented e (茅) and this also ended up in my Windows username.

I did not see a %localappdata%\Synergy directory and even as I created one it didn't seem to generate a certificate to that location and later on also didn't seem to write TrustedServers.txt.

I suspect that the weird username is doing it. Funny enough, synergy has no problems writing the temporary config file in %temp%.

@RobertMueller2 , thanks for your valuable feedback on this issue.
We'll check this additional case.

Does manually creating a new certificate works as a workaround?

I have tried that, but no.

Thank you, appreciate it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Celant picture Celant  路  4Comments

legonigel picture legonigel  路  4Comments

jasonfisherjlf picture jasonfisherjlf  路  4Comments

spacepluk picture spacepluk  路  5Comments

nbeazy picture nbeazy  路  4Comments