[FIXED; update to v3.9.10] Cannot get Insync to auth Google on Fedora 44

1

Insync Authorization Failure on Fedora 44 — Support Summary

Environment

  • OS: Fedora 44 (recently upgraded from Fedora 43)
  • Hardware: Minisforum UM890 Pro (Ryzen 9 8945HS, x86_64)
  • Desktop: GNOME on Wayland
  • Insync version: 3.9.8.60034 (Fedora repo build, package insync-3.9.8.60034-fc44.x86_64)
  • Insync Nautilus extension: 3.9.5.60024 (insync-nautilus-3.9.5.60024-1.noarch, downloaded from insynchq.com — the F44 yum repo does not advertise this package)
  • System CA infrastructure: ca-certificates package installed; consolidated bundle at /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
  • Account type: Personal Google account, previously authorized to Insync for several years without incident on Fedora 43

Problem

Authorization fails immediately when attempting to add the Google account to Insync. Both the standard browser-redirect OAuth flow and the manual copy/paste authorization code method produce the same error inside the Insync GUI:

Unexpected error CurlError: (60, 'SSL certificate problem: unable to get local issuer certificate')

curl error 60 indicates libcurl could not verify the peer’s TLS certificate against any known certificate authority. This points to Insync’s bundled libcurl being unable to locate or load the system CA trust store.

Background — How This Started

Insync was working normally on Fedora 43 until a sync job got stuck on a phantom delete of a directory inside Google Drive:Projects/oscope/ that no longer existed on either side. After Fedora 43 → 44 upgrade the stuck state persisted. Decision was made to fully uninstall Insync (packages and all state directories under ~/.config/Insync/, ~/.local/share/Insync/, ~/.cache/Insync/), reboot, and reinstall.

After the clean reinstall on Fedora 44, the OAuth/authorization step fails with the curl error 60 above. The pre-uninstall Insync 3.9.8 install on Fedora 43 did not exhibit this error — authorization worked.

Diagnostics Performed

1. System trust store is functional

$ curl -sI https://accounts.google.com/ -o /dev/null -w "%{http_code}\n"
302

System-wide TLS validation works against Google’s OAuth endpoint. The system curl binary (which uses the system libcurl) successfully validates Google’s certificate. Trust failure is isolated to Insync’s bundled libcurl.

2. Fedora 44 CA layout

$ ls -la /etc/pki/tls/certs/ca-bundle.crt
ls: cannot access '/etc/pki/tls/certs/ca-bundle.crt': No such file or directory

$ ls -la /etc/ssl/certs/ca-certificates.crt
lrwxrwxrwx. 1 root root 49 Mar 31 19:00 /etc/ssl/certs/ca-certificates.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

$ ls /etc/ssl/certs/
ca-bundle.crt
ca-bundle.trust.crt
ca-certificates.crt

The historical Fedora canonical bundle path /etc/pki/tls/certs/ca-bundle.crt does not exist on Fedora 44. The consolidated bundle now lives at /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. The directory /etc/ssl/certs/ contains only three bundle-format files — no individual hash-named certificate symlinks of the kind libcurl expects when configured with CURLOPT_CAPATH against a directory.

3. What Insync’s bundled libcurl looks for

$ find /usr/lib/insync -name 'libcurl*' -exec strings {} \; | grep -iE '(ca-bundle|/etc/(pki|ssl))'
/etc/ssl/certs/

Insync’s bundled libcurl has only one CA-related path string compiled in: /etc/ssl/certs/. It is calling CURLOPT_CAPATH against this directory and walking it looking for hash-named individual cert files (the OpenSSL c_rehash convention used by Debian/Ubuntu). On Fedora the directory is essentially empty, so libcurl finds no CA certs and rejects the TLS handshake with curl error 60.

The Insync top-level binary (/usr/lib/insync/insync) contains no CA path strings of its own. No bundled CA .pem file ships with Insync.

4. Symptom is reproducible across reboots

A clean reboot was performed. Authorization was retried immediately — same error.

Fixes Attempted

Attempt 1 — Create the historical Fedora bundle path as a symlink

sudo ln -s /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/pki/tls/certs/ca-bundle.crt

Result: No effect. Subsequent authorization attempt produced the same error.

This was based on the assumption that Insync’s libcurl might fall back to the Fedora canonical path if its primary lookup failed. The strings analysis (above, performed afterward) confirmed Insync’s libcurl does not look at this path at all — it only uses /etc/ssl/certs/.

Attempt 2 — Force-regenerate the system trust store

sudo update-ca-trust extract

(Note: sudo update-ca-trust force-enable was attempted first but returned Error: unknown command: 'force-enable' — that subcommand has been removed in Fedora 44’s update-ca-trust.)

Result: Trust store extracted. /etc/ssl/certs/ still contains only three bundle files, no individual hash-named cert symlinks. Subsequent authorization attempt produced the same error.

This appears to be Fedora 44’s default behavior: update-ca-trust extract produces consolidated bundle files only, not the rehashed individual-cert directory layout that Debian/Ubuntu produces and that Insync’s libcurl expects.

Attempt 3 — Override CA bundle path via libcurl environment variable

insync quit
CURL_CA_BUNDLE=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem insync start &

Result: Same error. Insync’s bundled libcurl ignores CURL_CA_BUNDLE.

Attempt 4 — Override CA via OpenSSL environment variables

insync quit
SSL_CERT_FILE=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
SSL_CERT_DIR=/etc/ssl/certs \
insync start &

Result: Same error. Neither SSL_CERT_FILE nor SSL_CERT_DIR is honored by Insync’s bundled libcurl.

Current State

  • Insync 3.9.8 is installed but not authorized.
  • All previously-discussed fixes have failed.
  • The next step under consideration was to manually split /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem into individual .pem files, place them in /etc/ssl/certs/, and run openssl rehash to create the hash-named symlinks Insync’s libcurl requires. This is invasive (adds ~130 files to a system-managed directory), unsupported (would conflict with future update-ca-trust runs), and amounts to a workaround for what appears to be an Insync bug or packaging gap on Fedora 44.

Questions for Insync Support

  1. Is there a known incompatibility between Insync 3.9.8 and Fedora 44’s CA trust layout?
  2. Does Insync’s bundled libcurl honor any CA-related environment variable, or is the lookup hardcoded entirely?
  3. Should the Fedora-targeted Insync RPM ship with a CA bundle of its own, or with a Requires: on a Fedora package that produces the rehashed /etc/ssl/certs/ layout (e.g., ca-certificates with a update-ca-trust post-install hook)?
  4. What is the supported fix on Fedora 44 systems where /etc/ssl/certs/ is bundle-only?

Reference — Files and Versions

Item Value
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists, valid
/etc/pki/tls/certs/ca-bundle.crt does not exist (created as symlink during attempt 1)
/etc/ssl/certs/ca-bundle.crt exists, bundle file
/etc/ssl/certs/ca-certificates.crt symlink → /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/etc/ssl/certs/ hash-named symlinks none
Insync libcurl CA path strings /etc/ssl/certs/ only
Fedora ca-certificates package installed
update-ca-trust force-enable not available on Fedora 44
System curl against Google succeeds (HTTP 302)
2 Likes
2

Hi @ArrowJ, a fix is on the way for this issue. I’ll update as soon as it’s ready!

2 Likes
3

following this, I also just installed fedora 44 and have been pulling my hair out!

4

I also recently installed Fedora 44 and insync and am unable to get past activation with google drive.

5

Is there any ETA for the fix?

(It took two years to fix the problem with emblems in Dolphin)

6

I also have the same problem here with the Fedora 44 version. I fixed using the Fedora 43 Insync version on my new Fedora 44 installation.

2 Likes
7

The thing about that solution is that it makes perfect sense and therefore I did not try it. Files are syncing again. Thanks!

For the support team, a quick fix would still be appreciated.

8

I uninstalled the 44 version and re-installed the 43 version and have presently versionlocked it. It appears to be working fine now. Thanks for the tips.

Support should 100% fix this or just remove 44 and label 43 and 44 the same packages.

9

ELI5, or rather, in terms clear enough for a layman to understand: What needs to be done?

Like, tomorrow’s a holiday, luckily. Afterwards, I need my cloud to work again. Then, either Fedora goes, or Insync goes. Help me out, please. Like, really, could need some support here.

10

i fixed the problem by making a backup of etc/ssl and etc/pki folders on fedora 43 then upgrade to 44 and merging these folders from 43 to fedora 44 but not overwriting any new file already on theses folders only missing ones and insync worked on fedora 44 without any issues.

11

I was able to install the Fedora 43 version and block to this version, but did you have an ETA for the fix ?

1 Like
12

Bob Saget voice: “There was no fix available soon.”

14

same issue here, waiting for a fix

15

Following up on @ArrowJ’s root cause analysis, here’s a more surgical fix that doesn’t require downgrading or having a Fedora 43 backup.

The problem is exactly as ArrowJ described: Insync’s bundled libcurl.so.4 has /etc/ssl/certs/ hardcoded as its CA path and expects OpenSSL-style hash files there (e.g. a1b2c3d4.0). Fedora 44 removed those hash files, the directory now only contains symlinks to bundle files, which libcurl can’t use in this mode.

The good news: /etc/pki/tls/certs/ already has all the hash files you need. The only problem is the path is 18 characters, while the hardcoded string in libcurl is exactly 15. So: create a 15-char symlink and patch that one string in the binary:

sudo ln -s /etc/pki/tls/certs /etc/pki/tls/ca

sudo python3 -c "
data = open('/usr/lib/insync/libcurl.so.4','rb').read()
old = b'/etc/ssl/certs/'
new = b'/etc/pki/tls/ca'
print(f'{data.count(old)} occurrence(s) patched')
open('/usr/lib/insync/libcurl.so.4','wb').write(data.replace(old, new))
print('Done.')
"

Restart Insync normally afterwards. The fix survives reboots, and when the official update lands it will simply overwrite the patched libcurl.so.4 .

16

Hello everyone! The SSL certificate issue has been fixed on v3.9.10. You may download it here or install via the YUM repository.

Thank you! :slight_smile:

1 Like
17

Works for me, thanks

1 Like