In my last post I talked about the various plugins of KDE Connect and their current status in KDE Connect for Windows. 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.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.

Well, I don’t know about you, but I counted that three :p

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=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 @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={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 “2.5.29.37={text}1.3.6.1.5.5.7.3.3”, 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 “2.5.29.19={text}”, which indicates that the certificate is an end entity (not a CA).

source: 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 <File Path to Save Cert>.pfx

Prerequisites

– 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. 🙂

– SignTool.exe

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! After this couple of commands your app package is ready to hit the streets! ✊

cd "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\"
SignTool sign /fd SHA256 /a /f <ABSOLUTE_PATH_TO_CERTIFICATE>.pfx /p <PASSWORD_FOR_CERTIFICATE>  

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.

Again, remember that you have to this installation of the certificate in every computer that you wish to test the .Appx package on, otherwise it won’t install.

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