Install VS Code (Visual Studio Code) on Fedora 45 / 44 / 43

On Fedora 45, VS Code installs cleanly from Microsoft’s repo and then refuses to install a single extension. The editor opens, the marketplace loads, and every Install click ends in “Signature verification failed with ‘UnknownError’ error.” The cause is one missing compatibility library, and the fix is one dnf command. It is covered below, right after the install.

Original content from computingforgeeks.com - post 17545

To install VS Code on Fedora 45, 44 or 43, this guide uses the official Microsoft RPM repository (the vscode dnf repo). It fixes the Fedora 45 extension signature error and covers extension management from the command line, Remote SSH, updates through dnf, the Flathub build and a clean uninstall. The steps were run on Fedora 45 and on Fedora 44 with VS Code 1.139.1. Fedora 43 was not run.

What changed on Fedora 45

Fedora 45 moved the system crypto library to the OpenSSL 4 line under the OpenSSL40 change. The old libssl.so.3 now lives in a separate compat package, openssl3-libs, which a default install does not pull in. We checked a fresh install from the Fedora 45 Workstation ISO and a cloud image: neither had it.

VS Code verifies every marketplace extension with a bundled helper called vsce-sign. That helper is a .NET binary, and .NET looks for libssl.so.3 (or older) at runtime. It never looks for libssl.so.4. With no OpenSSL 3 library on the box, vsce-sign aborts, VS Code reports the failure as UnknownError, and the extension is not installed. The editor itself is fine because Electron ships its own TLS stack. Only extension installs break.

Fedora 44 and Fedora 43 still use OpenSSL 3 as the system library, so libssl.so.3 comes with openssl-libs and extensions verify normally. On the Fedora 44 test VM the same extension installed on the first try. There is no openssl3-libs package on those releases at all, which matters if you script the fix (see below). The rest of the guide is identical on all three releases.

Prerequisites

• Fedora 45, 44 or 43 (Workstation, a desktop Spin, or Server if you only need the CLI and Remote SSH)
• A user with sudo rights
• Outbound HTTPS to packages.microsoft.com, marketplace.visualstudio.com and *.gallerycdn.vsassets.io (extension downloads)
• About 1 GiB of free disk: the code package alone is 961 MiB installed

Import the Microsoft signing key

Every package in the repo is signed with Microsoft’s release key. Import it first:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

It prints nothing on success. List the keys RPM now trusts:

rpmkeys --list

The Microsoft key now sits next to the Fedora release key:

4f50a6114cd5c6976a7f1179655a4b02f577861e Fedora (45) <[email protected]> public key
bc528686b50d79e339d3721ceb3e94adbe1229cf Microsoft (Release signing) <[email protected]> public key

Skipping this step also works. DNF5 imports the key from the gpgkey= URL in the repo file on the first install, and with -y it accepts the key without asking. It prints the fingerprint as it does, which is worth checking against the line above: BC528686B50D79E339D3721CEB3E94ADBE1229CF. Importing the key yourself just keeps that decision out of an unattended -y run.

Add the VS Code repository

Third-party repo files still go in /etc/yum.repos.d/, even on Fedora 45 where that directory ships empty and Fedora’s own repos moved to /usr/share/dnf5/repos.d/. Create the repo file:

sudo vim /etc/yum.repos.d/vscode.repo

Add this definition, which matches the one Microsoft publishes:

[code]
name=Visual Studio Code
baseurl=https://packages.microsoft.com/yumrepos/vscode
enabled=1
autorefresh=1
type=rpm-md
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc

Confirm DNF sees it:

dnf repo list

The code repo shows up with the Fedora repos. Our Fedora 45 machine also had updates-testing enabled; sudo dnf config-manager setopt updates-testing.enabled=0 switches it off if you only want stable updates:

repo id               repo name
code                  Visual Studio Code
fedora                Fedora 45 - x86_64
fedora-cisco-openh264 Fedora 45 openh264 (From Cisco) - x86_64
updates               Fedora 45 - x86_64 - Updates
updates-testing       Fedora 45 - x86_64 - Test Updates

The same repo also carries code-insiders (the nightly channel) and code-exploration. The package names differ, so they install side by side with the stable build if you want to try a preview.

Install VS Code on Fedora

One command:

sudo dnf install -y code

The dependency count depends on what is already installed. On a Fedora 45 Workstation install the transaction is two packages (code plus socat) and a 325 MiB download, because GTK, ALSA and the X11 libraries are already there. The minimal cloud images we also tested needed 226 packages on Fedora 45 and 247 on Fedora 44, since they had no desktop libraries at all. Check the result:

rpm -q code
code --version

The package release carries an el8 tag because Microsoft builds one generic RPM for every RPM distro. That is expected, and it runs fine on Fedora:

code-1.139.1-1790309585.el8.x86_64
1.139.1
04c0d99f4fb0d8afe6ce4f0c58e31e183ac3e4b1
x64

The same check on the Fedora 45 test box, with the key and repo in place:

If you would rather install the downloaded RPM than use the repo, Microsoft’s download link redirects to the same signed file, and the two releases treat it differently when the key is missing. On Fedora 45, plain rpm refuses it with “does not verify: Header OpenPGP V4 RSA/SHA256 signature, key ID eb3e94adbe1229cf: NOKEY”. On Fedora 44 the same command prints only a NOKEY warning and carries on. sudo dnf install ./code-*.rpm installs it on both, but it ends with “Warning: skipped OpenPGP checks for 1 package from repository: @commandline”, which means DNF did not check the signature at all. Import the key and check the file with rpm -K before a local install. You also lose automatic updates without the repo, which is why the repo route is the one to use.

Fix “Signature verification failed” on Fedora 45

On a stock Fedora 45 box, the first extension install fails. From the command line:

code --install-extension redhat.vscode-yaml

No extension is installed, and the error names signature verification, not networking:

Installing extension 'redhat.vscode-yaml'...
Error while installing extension redhat.vscode-yaml: Signature verification failed with 'UnknownError' error.
Failed Installing Extensions: redhat.vscode-yaml

The GUI hits the same wall. Clicking Install in the Extensions view opens a modal offering “Install Anyway (Don’t Verify Signature)”, with openssl3-libs confirmed missing in the integrated terminal below it:

Do not click Install Anyway. It turns off the one check that stops a tampered VSIX from being installed, and you would face the same prompt for every extension. The real failure shows up when you run the verifier by hand against a downloaded extension and its signature archive. Both files come from the marketplace: the extensionquery API at marketplace.visualstudio.com/_apis/public/gallery/extensionquery returns, for each extension version, a Microsoft.VisualStudio.Services.VSIXPackage URL and a Microsoft.VisualStudio.Services.VsixSignature URL on *.gallerycdn.vsassets.io. We saved those two assets with curl as y.vsix and y.sigzip, then ran:

/usr/share/code/resources/app/node_modules.asar.unpacked/@vscode/vsce-sign/bin/vsce-sign verify --package y.vsix --signaturearchive y.sigzip -v

It reads the files, then aborts with exit code 134:

Package file size:  1056571
Signature archive file size:  11127
Manifest file size:  5668
Signature file size:  12150
No usable version of libssl was found

The same command on Fedora 44 runs through its signature policies and exits 0. An strace of the Fedora 45 run shows the probe order: libssl.so.3, .so.1.1, .so.1.0.2, .so.1.0.0 and .so.10, each under /lib64 and /usr/lib64, all missing, while the system library is libssl.so.4. On Fedora 45 the OpenSSL 3 library is a compat package called openssl3-libs in the main fedora repo. Install it by the library it provides rather than by package name:

sudo dnf install -y 'libssl.so.3()(64bit)'

That provides string resolves to openssl3-libs, about 9 MiB (libssl.so.3 and libcrypto.so.3). It replaces nothing, so the system stays on OpenSSL 4. No restart of VS Code is needed. Retry the install:

code --install-extension redhat.vscode-yaml

Verification passes and the extension lands:

Installing extension 'redhat.vscode-yaml'...
Extension 'redhat.vscode-yaml' v1.24.0 was successfully installed.

Here is the whole sequence in one terminal, from failure to fix:

Clicking Install on the same extension in the GUI now completes, and the extension’s sidebar view appears immediately:

The provides form is the one to put in a playbook that targets several releases. On Fedora 44 the same command answers Package "openssl-libs-1:3.5.8-1.fc44.x86_64" is already installed. Nothing to do. and exits 0. sudo dnf install openssl3-libs by name works on Fedora 45 only. On Fedora 44 it fails with “No match for argument: openssl3-libs” and exit code 1, because that package does not exist there. Nothing in the Microsoft RPM requires the library, so install it in the same provisioning step as code.

Launch VS Code

On Workstation, open it from Activities by searching for “Visual Studio Code”. The launcher is /usr/share/applications/com.microsoft.VSCode.desktop (plus com.microsoft.VSCode.UrlHandler.desktop for vscode:// links). The package ships no code.desktop, so edit the com.microsoft.VSCode file if you need to add launch flags. From a terminal, open the current directory as a workspace:

code .

The first launch shows a sign-in screen for GitHub Copilot. “Continue without Signing In” skips it, and the editor works fully without an account. The editor below has a Compose file open, the YAML and Container Tools extensions active (the schema line and the “Run Service” code lens come from them), and the integrated terminal confirming the release and packages:

Do not start the editor with sudo. VS Code refuses to run as root without extra flags, and editing system files is better done by opening them as your user and saving through the password prompt VS Code offers.

Manage extensions from the command line

The CLI is the reproducible way to set up a new machine. Extensions are addressed by their publisher.name ID from the marketplace, and dependencies resolve on their own. Installing the Python extension pulls in three more:

code --install-extension ms-python.python

Debugpy, Pylance and the Python environments extension come along with it. The tail of the output:

Extension 'ms-python.debugpy' v2026.6.0 was successfully installed.
Extension 'ms-python.vscode-pylance' v2026.4.1 was successfully installed.

List what is installed, with versions:

code --list-extensions --show-versions

The test box, after the Python, YAML and Docker installs:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

The Docker extension is now a thin wrapper. Installing ms-azuretools.vscode-docker also installs ms-azuretools.vscode-containers (Container Tools), which does the actual work. Removing the Docker one leaves Container Tools in place:

code --uninstall-extension ms-azuretools.vscode-docker

To copy a setup to another machine, export the IDs to a file and feed them back in. On the test box we deleted the extension folders, fed the list back in, and all 11 were present afterwards:

code --list-extensions > ~/vscode-extensions.txt
xargs -L1 code --install-extension < ~/vscode-extensions.txt

Extensions live in ~/.vscode/extensions/ and settings in ~/.config/Code/User/. Both belong in your dotfiles if you manage them by hand. The built-in Settings Sync, switched on from the Accounts menu, does the same through a GitHub or Microsoft account if you would rather not.

Remote SSH and tunnels

Remote SSH runs the language servers, terminal and debugger on the remote host while the UI stays local. It installs like any other extension and brings two helpers with it:

code --install-extension ms-vscode-remote.remote-ssh

Three extensions come down, including the SSH config editor:

Extension 'ms-vscode-remote.remote-ssh-edit' v0.87.0 was successfully installed.
Extension 'ms-vscode-remote.remote-ssh' v0.128.0 was successfully installed.
Extension 'ms-vscode.remote-explorer' v0.5.0 was successfully installed.

Remote SSH reads your existing ~/.ssh/config, so hosts and jump boxes you already defined show up in Remote Explorer. The package also ships a code-tunnel binary for machines you cannot reach over SSH. code tunnel registers the machine with Microsoft’s relay after a GitHub or Microsoft sign-in, and you connect from another VS Code or from vscode.dev. It needs no inbound port, which also means it goes around your firewall, so check that it is allowed before you run it on a work server. Its subcommands:

code tunnel --help

An excerpt of the command list, which covers stopping, checking and removing a tunnel, including unregister for when the machine is retired:

Commands:
  prune       Delete all servers which are currently not running
  kill        Stops any running tunnel on the system
  restart     Restarts any running tunnel on the system
  status      Gets whether there is a tunnel running on the current machine
  rename      Rename the name of this machine associated with port forwarding service
  unregister  Remove this machine's association with the port forwarding service
  user

For per-project toolchains that do not touch the host, pair Remote Containers with Distrobox or Toolbox, or run Dev Containers on top of Docker on Fedora. The Python, Node.js, Go and Rust setup covers the language runtimes those extensions expect to find.

Update VS Code with dnf

The repo keeps older builds next to the current one, and updates arrive with normal system upgrades. To update only VS Code:

sudo dnf upgrade -y code

To test the update path we downgraded to the previous build with sudo dnf downgrade code-1.139.0 and ran the upgrade. DNF replaced it with the current build:

Upgrading:
 code             x86_64 0:1.139.1-1790309585.el8 code       961.2 MiB
   replacing code x86_64 0:1.139.0-1790100890.el8 code       961.2 MiB

Downgrading is also the escape hatch when a release breaks something you depend on. List the builds the repo still has:

dnf list --showduplicates code

Pick one of the listed versions for dnf downgrade. A version that is not in that list fails with “No match for argument” and the hint to use --skip-unavailable, which is not the fix. Choose a build that is listed. The DNF5 cheat sheet covers versionlock if you need to hold VS Code at a version across system upgrades.

VS Code from Flathub

The Flathub package com.visualstudio.code is a community wrapper around Microsoft’s official build, not a Microsoft package. With Flathub enabled, install it per user:

flatpak install --user -y flathub com.visualstudio.code

Check which version it installed:

flatpak list --user --app --columns=application,version,origin

It was one release behind the RPM on the same day:

com.visualstudio.code	1.138.0	flathub

The Flatpak does not have the Fedora 45 signature problem. Its runtime (the freedesktop SDK) carries its own libssl.so.3, so with rpm -q openssl3-libs reporting “package openssl3-libs is not installed” on the host, flatpak run com.visualstudio.code --install-extension redhat.vscode-yaml still verified and installed. The cost is the sandbox. The integrated terminal opens inside the Flatpak, so your host compilers, podman and docker are not on its PATH until you go through flatpak-spawn --host. On a fresh box the user Flatpak directory reached 3.4 GiB on disk after the first install. For development work on your own machine, the RPM is the better fit.

If you want an open-source build without Microsoft’s telemetry and branding, VSCodium (com.vscodium.codium on Flathub) is the usual choice. It uses the Open VSX registry instead of the Microsoft marketplace, so Pylance, Remote SSH and a few other Microsoft extensions are not available there.

Uninstall VS Code

Remove the package. DNF also removes the dependencies it pulled in for it (66 packages in total, including code, on the cloud test box):

sudo dnf remove -y code

User data survives the package removal. Delete the repo file, and your settings and extensions if you are not coming back:

sudo rm -f /etc/yum.repos.d/vscode.repo
rm -rf ~/.config/Code ~/.vscode

The Microsoft key stays in the RPM keyring. Remove it by fingerprint with sudo rpmkeys --delete bc528686b50d79e339d3721ceb3e94adbe1229cf. On Fedora 45 the openssl3-libs package can go too, unless something else needs the library. Check with rpm -q --whatrequires 'libssl.so.3()(64bit)', which answered “no package requires libssl.so.3()(64bit)” on the test box. Do not remove it on Fedora 44, where the library belongs to openssl-libs and sudo, libcurl and git-core depend on it.

Errors hit on the test machines

Signature verification failed with ‘UnknownError’ error

This is the Fedora 45 OpenSSL 4 issue described above. sudo dnf install 'libssl.so.3()(64bit)' fixes it. If you see it on Fedora 44 or 43, the library is present, so run the verifier by hand: /usr/share/code/resources/app/node_modules.asar.unpacked/@vscode/vsce-sign/bin/vsce-sign verify --package x.vsix --signaturearchive x.sigzip -v prints the real reason, where VS Code only reports UnknownError.

error: https://microsoft.com: key 1 not an armored public key.

RPM downloaded an HTML page instead of a key, because the URL points at a website rather than the .asc file. We reproduced it with sudo rpm --import https://microsoft.com (exit code 1). Use the exact key URL, https://packages.microsoft.com/keys/microsoft.asc, in both the import command and the gpgkey= line of the repo file.

Error while installing extensions: AggregateError [ETIMEDOUT]

This is a network failure, not a signing one. It showed up a few times on the lab network against marketplace.visualstudio.com with both the RPM and the Flatpak, and the same command succeeded on a retry. If it never succeeds, check that a proxy or firewall allows the marketplace and *.gallerycdn.vsassets.io, where the VSIX files and signatures are downloaded from.

You are trying to start Visual Studio Code as a super user which isn’t recommended

You ran sudo code. Run it as your normal user. VS Code offers to save root-owned files through a password prompt, and that keeps root from owning files under your home directory. The --no-sandbox --user-data-dir workaround in the message disables Chromium’s sandbox, so do not make it a habit.

For the rest of the Fedora 45 changes that affect third-party software like this (the empty /etc/yum.repos.d/, stricter rpm -i, the move to OpenSSL 4), see what is new in Fedora 45. If the machine is not on Fedora 45 yet, the Fedora 45 install guide covers both editions.