HOWTO try out KDE Connect for Windows with latest code inside?

In my last post I talked about the various plugins of KDE Connect and their current status in KDE Connect for Windows port. As promised, here is a follow up quickie on how to try out the two types of the build -> 1) as a Windows Store app (.Appx package), 2) as a desktop app (.exe installer).

.EXE Installer

This one is fairly simple. You get the installer out of doing craft --package kdeconnect-kde and then just share it with your friends and fam. 😉

.Appx Installer

NOTE: requires Administrator Privileges.

Now, this is the reason why this post exists. The .Appx packages have a little something special about them.

Challenge: The .Appx packages must be signed by a trusted developer if you want to install them on a computer.

To do this right, we need to 3 things in series:-

  1. creating a self – signed certificate key for yourself
    1. exporting the key into a tangible file
  2. signing a build with that certificate key
  3. installing the key as a trusted key into a system

Simple enough? Let’s dive into it! 💦

Creating a Self-Signed Certificate Key for yourself

  1. Open a powershell window
  2. Type this.
New-SelfSignedCertificate -Type Custom -Subject "CN=CN=K Desktop Environment e.V., O=K Desktop Environment e.V., L=Berlin, C=DE" -KeyUsage DigitalSignature -FriendlyName "KDE Connect" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("{text}", "{text}") 

Note the following details about some of the parameters:
KeyUsage: This parameter defines what the certificate may be used for. For a self-signing certificate, this parameter should be set to DigitalSignature.
TextExtension: This parameter includes settings for the following extensions:
– Extended Key Usage (EKU): This extension indicates additional purposes for which the certified public key may be used. For a self-signing certificate, this parameter should include the extension string “{text}”, which indicates that the certificate is to be used for code signing.
– Basic Constraints: This extension indicates whether or not the certificate is a Certificate Authority (CA). For a self-signing certificate, this parameter should include the extension string “{text}”, which indicates that the certificate is an end entity (not a CA).

Windows docs

After running this command, the certificate will be added to the local certificate store, as specified in the “-CertStoreLocation” parameter. The result of the command will also produce the certificate’s thumbprint.

You can view your certificate in a PowerShell window by using the following commands. NOTE: Yes, these are 2 separate commands.

Set-Location Cert:\CurrentUser\My
Get-ChildItem | Format-Table Subject, FriendlyName, Thumbprint

This will display all of the certificates in your local store.

Exporting the Certificate Key

To export a certificate out of the local store, you will need to secure it. That’s a necessity for Windows App signing certificates, and Windows needs to make sure every application packaged as a .Appx is secure by default. Hence, protecting your certificate key will help you so that no one else can sign app packages without you knowing about it. (well, unless that other person knows your password; then, you’re screwed).

You also have an option to specify what all users can exclusively make use of the key, but that is a special case and not being covered in this post. You can read about it from the docs as well, so we won’t digress and go on with the guide.

Use these commands to export the certificate key.
NOTE: Don’t forget to remove the angle brackets when you replace the 3 things in these commands.

$pwd = ConvertTo-SecureString -String <Your Password> -Force -AsPlainText 
Export-PfxCertificate -cert "Cert:\CurrentUser\My\<Certificate Thumbprint>" -FilePath <FilePath>.pfx -Password $pwd

FilePath: where you want to save the certificate. For example: C:\MyCerti.pfx will make a certificate within C:\ with the name MyCerti.pfx.

Signing a Build with the (shiny new) Certificate Key

A packaged app
You got this when you did that craft --package kdeconnect-kde thing.
A valid signing certificate
For more information about creating or importing a valid signing certificate, see Create or import a certificate for package signing. We just covered this. 🙂
Based on your installation path of the SDK, this is where SignTool is on your Windows 10 PC:
x86: C:\Program Files (x86)\Windows Kits\10\bin\x86\SignTool.exe
x64: C:\Program Files (x86)\Windows Kits\10\bin\x64\SignTool.exe

the most useful bits from Windows docs

SignTool can be used to sign files, verify signatures or timestamps, remove signatures, and more.

Next up, you should read this tiny but very important bit before moving ahead.

Done? Great! This is just a couple commands then your app package is ready to hit the streets!

cd "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\"

If you happen to face any problems, check out the Windows docs or contact us over mail or Telegram!

Installing the Key as a trusted key in a Windows System

NOTE: This is the part that requires Administrator Privileges.

After you’re done signing the application with a certificate key, let’s get the certificate key installed in a system so you can test out the package on the computer.

Right click on the build > Got to Properties
Go to Digital Signatures tab
Select the signature > Click Details
Click View Certificate
Click Install Certificate…
IMPORTANT! Select Local Machine and then click Next
Make sure to select Trusted People store after clicking on Browse
Click Finish
yay! 🎉

That’s all for now! You should be able to install all subsequent packages after this on the machine! 😁

Happy KDEing! 😁

3 thoughts on “HOWTO try out KDE Connect for Windows with latest code inside?

  1. kmi

    Ask the Krita guys to upload the appx version to the Windows Store.

    Liked by 1 person

  2. J Janz

    Hello, there

    Thank you for doing this for us!

    One question: are Nightly Builds’ .exe ( ) getting these new stuff already? And, if so, maybe you can add it to the article’s EXE section to make it a breeze for bypassers, how about that? 😉


    1. The nightly builds do not have “all” of these features, because it still uses the release version of KDE Frameworks, and not the latest source code (for dependencies). Hence, features like “Notifications Sync” do not work as well for the builds yet.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website at
Get started
%d bloggers like this: