Advantages with code-signing EV certificates other than the Smartscreen ones?

Question

I have to buy a code-signing certificate, for signing Win32 applications, and I was considering whether to pick an EV one.

The advantages of EV certificates I was able to find are:

1. Immediate Smartscreen reputation establisment (instead of waiting for 3k downloads? [source] )

2. Maintainance of Smartscreen reputation across certificate renewals [source] (probably a moot point if point 1 applies anyway)

3. Option for delivery on a hardware token, often not available for normal certificates

I wonder if they bring other advantages, for example if applications signed with them are more trusted than applications signed with non-EV certificates by antivirus, firewalls and other security applications (they get less blocked, provoke more favourable warnings, etc.).

I restate the case I'm most interested in: are you aware of differences in treatment by some specific antivirus/firewall/security application of applications signed with EV certificates, vs. applications signed with standard certificates?

Answer 1

Disclosure: I work for an AV vendor.

I wonder if they bring other advantages, for example if applications signed with them are more trusted than applications signed with non-EV certificates by antivirus, firewalls and other security applications

This depends on the vendor making the security application, or their current(*) policy. Both security vendors I have worked for ignored the presence of the certificate when scanning for malware. There are several reasons for this:

• Just because the code is signed doesn't mean it is not malicious. It only means it has not been modified after it has been signed. For example, a relatively large number of adware applications is signed.

• Malware writes have used stolen certificates in past, and thus we cannot be truly sure it was used by the original author. This is why I mentioned "current policy" above, as this could change overnight.

• Verifying a certificate is a complex and relatively slow process which requires reading the whole file from disk - an expensive operation for a non-SSD storage. It also requires performing some public key cryptography operations which are CPU-intensive. Thus for some large executable files checking the certificate might take longer than scanning the file for malware.

And since we generally don't look at certificate at all, it doesn't matter whether it is standard or EV.

Answer 2

I have a different experience than @George Y. Our Code Signing EV-Certificate from Sectigo did help to avoid false positives in Norton 360. I don't know about other Antivirus software - to be tested.

^{Note:
My different experience from @George Y. doesn't imply that he is wrong. The difference can be due to many factors, such as Antivirus Software Company policies, ...
Also, my experience is based on positive results I get today from the code signing. More tests in the future (and experiences from our users) will prove if these positive results were temporary or permanent.}

1. Before code signing

Before the code signature, our users got warnings like this:

Even worse, Norton 360 would simply remove a lot of executables and .pyd files automatically - thereby breaking our software completely:

It was a complete disaster.

2. After code signing

Today, I signed our application for the first time with our new EV-Certificate. I signed not only the .exe files, but also the .dll, .so and .pyd files. When signing these files, I first check if they already have a signature, to avoid double signing .dll files from third party opensource binaries that we include in our build. Here is my Python script that automates this procedure:

import os, subprocess

# 'exefiles' is a Python list of filepaths
# to .exe, .dll, .so and .pyd files. Each
# filepath in this list is an absolute path
# with forward slashes.
quote = '"'
for f in exefiles:
    cmd = f"signtool verify /pa {quote}{f}{quote}"
    result = subprocess.run(
        cmd,
        stdin    = subprocess.DEVNULL,
        stdout   = subprocess.PIPE,
        stderr   = subprocess.PIPE,
        cwd      = os.getcwd(),
        encoding = 'utf-8',
    )
    if result.returncode:
        # Verification failed, so the file is not yet signed
        cmd = f"signtool sign /tr http://timestamp.sectigo.com /td sha256 /fd sha256 /a {quote}{f}{quote}"
        result = subprocess.run(
            cmd,
            stdin    = subprocess.DEVNULL,
            stdout   = subprocess.PIPE,
            stderr   = subprocess.PIPE,
            cwd      = os.getcwd(),
            encoding = 'utf-8',
        )
        if result.returncode:
            # Code signing failed!
            print(f"Sign: '{f.split('/')[-1]}' failed")
        else:
            # Code signing succeeded
            print(f"Sign: '{f.split('/')[-1]}'")
    else:
        # Verification succeeded, so the file was already signed
        print(f"Already signed: '{f.split('/')[-1]}'")

The results are promising so far. Windows SmartScreen no longer generates warnings. Norton 360 neither. I've tried on both my laptop and a desktop with a clean Norton 360 install - both of them trust the application (unlike before the code signature).

Fingers crossed it will stay this way. Let's also hope other Antivirus software will trust our application.

Note:
As of writing this post, our signed application is only available for testers on https://new.embeetle.com
It will be available soon on our public website https://embeetle.com as well - but not yet today.