[GH-ISSUE #4023] Signed Windows Installer #8330

Closed
opened 2026-08-05 01:17:27 -04:00 by saavagebueno · 7 comments
Owner

Originally created by @scheibling on GitHub (Jun 21, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4023

Is your feature request related to a problem? Please describe.
Currently, the MSI and EXE installers for Windows don't seem to be signed in the same way that the actual executables are. Everything mostly still works, but it does cause a higher rate of issues with computers that have an EDR or company policies applied.

Describe the solution you'd like
Apply a signature to the installers in the same way as with the win executables

Describe alternatives you've considered
Currently, we sign it ourselves

Additional context
This is very much nice-to-have more than need-to-have, but since you seem to have the EV certificate in place adding the signature before publishing the Windows clients shouldn't be overly complicated.

Also want to add: Great product, you've done amazing work with this so far. Thank you!

Originally created by @scheibling on GitHub (Jun 21, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4023 **Is your feature request related to a problem? Please describe.** Currently, the MSI and EXE installers for Windows don't seem to be signed in the same way that the actual executables are. Everything mostly still works, but it does cause a higher rate of issues with computers that have an EDR or company policies applied. **Describe the solution you'd like** Apply a signature to the installers in the same way as with the win executables **Describe alternatives you've considered** Currently, we sign it ourselves **Additional context** This is very much nice-to-have more than need-to-have, but since you seem to have the EV certificate in place adding the signature before publishing the Windows clients shouldn't be overly complicated. Also want to add: Great product, you've done amazing work with this so far. Thank you!
saavagebueno added the feature-request label 2026-08-05 01:17:27 -04:00
Author
Owner

@ephb commented on GitHub (Feb 27, 2026):

I want to second this request.
This is really cumbersome as we also now need to sign the installer ourselves, as unsigned code can not be run in our company.

While the installer is signed the signature is not based on a certificate authority that is trusted on Windows by default, showing Windows defender warning.

One solution would be to sign with Azure app signing.

Image
<!-- gh-comment-id:3971694791 --> @ephb commented on GitHub (Feb 27, 2026): I want to second this request. This is really cumbersome as we also now need to sign the installer ourselves, as unsigned code can not be run in our company. While the installer is signed the signature is not based on a certificate authority that is trusted on Windows by default, showing Windows defender warning. One solution would be to sign with Azure app signing. <img width="404" height="484" alt="Image" src="https://github.com/user-attachments/assets/0d434e5b-11da-4028-98ee-8e5a3e6d8e9a" />
Author
Owner

@mlsmaycon commented on GitHub (Mar 1, 2026):

That's interesting because the command is the same on both signatures.

<!-- gh-comment-id:3980786602 --> @mlsmaycon commented on GitHub (Mar 1, 2026): That's interesting because the command is the same on both signatures.
Author
Owner

@ephb commented on GitHub (Mar 6, 2026):

Upon further investigation I noticed the application is signed the same, but windows does not bring it up again, when the installer was signed. Overall the current Root CA is insufficient for strict environments.

Image
<!-- gh-comment-id:4011497353 --> @ephb commented on GitHub (Mar 6, 2026): Upon further investigation I noticed the application is signed the same, but windows does not bring it up again, when the installer was signed. Overall the current Root CA is insufficient for strict environments. <img width="406" height="511" alt="Image" src="https://github.com/user-attachments/assets/79a224e8-5240-4e48-aacc-d06bdb56acb2" />
Author
Owner

@scheibling commented on GitHub (Mar 6, 2026):

@ephb That one is strange though, the issuing CA for SSL.com EV Code Signing Intermediate CA RSA R3 is SSL.com EV Root Certification Authority RSA R2, which is included in the Microsoft Trusted Root Program.

Can you have a look at the certification path to see what it resolves to, or if it just fails to resolve the chain?

With that said, I haven't run into the issue lately on my end, so it might already be resolved. The ones I tested just now all worked in the enterprise environment I have access to.

<!-- gh-comment-id:4014487095 --> @scheibling commented on GitHub (Mar 6, 2026): @ephb That one is strange though, the issuing CA for ```SSL.com EV Code Signing Intermediate CA RSA R3``` is ```SSL.com EV Root Certification Authority RSA R2```, which is included in the Microsoft Trusted Root Program. Can you have a look at the certification path to see what it resolves to, or if it just fails to resolve the chain? With that said, I haven't run into the issue lately on my end, so it might already be resolved. The ones I tested just now all worked in the enterprise environment I have access to.
Author
Owner

@ephb commented on GitHub (Mar 12, 2026):

@scheibling you are right. It is trusted in my personal PC but somehow our domain does not trust it.
I will investigate the origin of that issue and then report back to not confuse others with what I said earlier.

<!-- gh-comment-id:4044644411 --> @ephb commented on GitHub (Mar 12, 2026): @scheibling you are right. It is trusted in my personal PC but somehow our domain does not trust it. I will investigate the origin of that issue and then report back to not confuse others with what I said earlier.
Author
Owner

@scheibling commented on GitHub (Mar 17, 2026):

Right, after having looked into this a little more it looks like some of my domain-joined PCs are experiencing the same issue (both Intune and On-prem-managed devices).

The problem arises from a registry value:

HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate

This key is normally used when you have your own internal CA distribution method and don't want to accept auto-updates for trusted root certificates from Windows Update, but in most cases this should not be enabled. For some reason, it was enabled on some machines by default. Why I haven't quite figured out.

Normally, on first sighting of a CA from the trusted roots list it will be imported into the Windows Trusted Root Certification Authorities store. When the key is enabled, this does not happen automatically.

Some background: https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/setup-migrate-backup-recovery/connectivity-issues-digicert-global-root-g2-not-installed

Since the files are actually signed from Netbird, and this issue is a user/organization-level configuration issue, I'll close the ticket for now.

<!-- gh-comment-id:4077548483 --> @scheibling commented on GitHub (Mar 17, 2026): Right, after having looked into this a little more it looks like some of my domain-joined PCs are experiencing the same issue (both Intune and On-prem-managed devices). The problem arises from a registry value: ```HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate``` This key is normally used when you have your own internal CA distribution method and don't want to accept auto-updates for trusted root certificates from Windows Update, but in most cases this should not be enabled. For some reason, it was enabled on some machines by default. Why I haven't quite figured out. Normally, on first sighting of a CA from the trusted roots list it will be imported into the Windows Trusted Root Certification Authorities store. When the key is enabled, this does not happen automatically. Some background: https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/setup-migrate-backup-recovery/connectivity-issues-digicert-global-root-g2-not-installed Since the files are actually signed from Netbird, and this issue is a user/organization-level configuration issue, I'll close the ticket for now.
Author
Owner

@ephb commented on GitHub (Mar 17, 2026):

Thanks for digging.
I will change this in our domain.

<!-- gh-comment-id:4077606945 --> @ephb commented on GitHub (Mar 17, 2026): Thanks for digging. I will change this in our domain.
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#8330