So let's say XYZ Soft creates an application, XYZCalc. They build the product, create an MSI and an EXE installer, and put it on the internet. The commercial (not self-signed) cert they use to sign the app is valid for two years.
XYZ Soft goes under and closes it's doors. However that EXE and MSI is still floating around out there. Four years go by. The cert they used to sign the app has expired.
QUESTION: Can I still install the application, after four years?
Yes, if the signature contains a cryptographic time stamp. The Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) defined in RFC 3161 and RFC 5816 define the standard. You can use your own time stamp authority on-premises or an externally hosted to provide you a time stamp. Here is a Gist with free to use Time Stamp Server URLs: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710
If you use signtool.exe to create the signature you can use its time stamping options to do so.
# This is how to timestamp a previously signed file
& signtool.exe timestamp `
-t "https://url-of-a-time-stamp-server.com" `
".\MyApp.exe"
# This is how to sign and timestamp a file in one
& signTool.exe sign `
/n "Subject-Name-Of-Certificate-In-Store-User-My" `
/t "https://url-of-a-time-stamp-server.com" `
".\MyApp.exe"
Related
To the people that close vote this post: it doesn't help if you don't comment why. We're all trying to learn here.
I want to have wildcard certificates for 2 domains of mine using Let's Encrypt. Here's what I did:
In Chrome it all works. In Firefox I get the error below:
So I tested here: https://www.ssllabs.com/ssltest/analyze.html?d=gamegorilla.net
I also checked this other post.
There's talk on making sure that "the server supplies a certificate chain to the client, only the domain certificate". I found validating the certificate chain here.
I then took these steps found here:
Open the Certificates Microsoft Management Console (MMC) snap-in.
On the File menu, click Add/Remove Snap-in.
In the Add or Remove Snap-ins dialog box, click the Certificates snap-in in the Available snap-ins list, click Add, and
then click OK.
In the Certificates snap-in dialog box, click Computer account, and then click Next.
In the Select computer dialog box, click Finish.
I already see "Let's Encrypt Authority X3" in the Intermediate Certification Authorities. So that should already be handling things correctly I'd presume.
How can I ensure the Let's Encrypt certificate chain is supplied to the client so it works in Firefox too?
UPDATE 1
Based on #rfkortekaas' suggestion I used "all binding identifiers" instead of supplying the search pattern. When Win-acme asked Please pick the main host, which will be presented as the subject of the certificate, I selected gamegorilla.net. After this gamegorilla.net now works in Firefox, however, on www.karo-elektrogroothandel.nl I now get an insecure certificate.
UPDATE 2
Alright, that seems to fix it. I do see that bindings for smtp/mail (e.g. smtp.gamegorilla.net) are now also added to IIS automatically:
Should I leave those or delete those mail+smtp records here?
Also, the certificate is now [Manual], does that mean I need to renew manually (which woud be weird since nowhere during the certificate creation steps did I see an option for auto-renewal):
The issue is that you only generate the certificate for www.gamegorilla.net and not gamegorilla.net if you select all binding identifiers instead of supplying the search pattern I think it should work.
To also get certificates for other names that are not hosted by IIS you cannot use the import from IIS function. You need to supply them all, starting with the common name.
After starting wacs select M for a new request and select option 2 for manual input. After that enter the comma separated list with the common name first: gamegorilla.net,www.gamegorilla.net,smtp.gamegorilla.net,karo-elektrogroothandel.nl,www.karo-elektrogroothandel.nl,smtpkaro-elektrogroothandel.nl (without any spaces). Or when you want to generate a wildcard certificate you can use: gamegorilla.net,*.gamegorilla.net,karo-elektrogroothandel.nl,*.karo-elektrogroothandel.nl.
Please be aware that for generating wildcard certificates you need to be able to use the DNS-01 challenge. The HTTP-01 challange doesn't support wildcard certificates.
For the certificate renewal you should run wacs --renew from time to time (for example via a schedules task).
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:
Immediate Smartscreen reputation establisment (instead of waiting for 3k downloads? [source] )
Maintainance of Smartscreen reputation across certificate renewals [source] (probably a moot point if point 1 applies anyway)
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?
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.
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.
I need the certificate from my smart card to be in the Windows service local sotre. I opened the store with mmc -> snap-in -> certificates.
I used different little tools to see informations(ATR etc.) about my smartcard and they all worked out.
I can see a lot of certificates there, but the one from my smartcard is missing in the store. The folder 'Smartcard trusted Roots' is empty. Windows gets the .cer/.pfx-data from smart cards automatically, right?
Or is there no chance, i can do it without using low-level programming(APDU-commands etc.)
First read this:
http://technet.microsoft.com/en-us/library/ff404288(v=WS.10).aspx
As it's written
A logged-on user inserts a smart card.
CertPropSvc is notified that a smart card was inserted.
CertPropSvc reads all certificates from all inserted smart cards. The certificates are written to the user's personal certificate store
So yes, gnerally certificates should pop up in User Personal Certificate Store automatically.
First thing to check is that you have CertPropSvc service runnig.
Another thing that I saw that some smart cards drivers doesn't work with Windows API. One example I know was old RSA tokens. We have changed them to Gemalto .NET cards and USB readers because of this
Note: In the artcle I linked it's written that this is valid for Windows 7 and 2008 but it worked for me on XP and Vista.
We have purchased Thawte code signing certificate and am able to sign scripts with that. In all signed execution policy mode, powershell still asks for confirmation on servers before running the code. I need to run this code as scheduled job on many servers and was wondering if their is any workaround this.
In my search it seems like that the certificate needs to be in trusted publisher before execution of scripts. I could not find any scripts that can place certificate in TrustedPublisher on a remote server.
Thank you for all the help you can provide.
PowerShell Help about execution policies easily found by PS C:\>help about_Execution_Policies shows that in AllSigned mode it will Prompt you before running scripts from Publishers that you have not yet classified as trusted or untrusted. You can try RemoteSigned or try this wonderfully explainedby Scott Hanselman http://www.hanselman.com/blog/SigningPowerShellScripts.aspx
Signed scripts can be transported by exporting (from original
computer) and importing (to the new computer) the Powershell
certificates found in the Trusted Root Certification Authorities
container. Optionally, the Trusted Publishers can also be moved to
prevent the first-time prompt.
Final note on the blog
Note that Powershell will prompt you the first time it’s run unless
you also import the Trusted Publishers certificate.
Does any one how to tell what folders are trusted when the ExecutionPolicy is set to RemotedSigned? I want to run a number of Powershell script of our network share (which is not mapped, hence using the full unc), but i do not want to have to digitally signed them all.
Any help would be great.
Thanks.
We have done this in the past by adding a registry key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains that names the server where the share resides. Under the EscDomains key, add a key that is the server name. Under that key, add a DWORD value with the name "file" and the value 2.
You need to do this on each machine that will run scripts from the server, but you can do that via group policy. There are security implications to this beyond running PowerShell scripts. I don't know if this will work if your computers are not in a domain. If there are better solutions, I look forward to learning about them.
For more information, see this KB article.
So, what happens when you run a script from UNC Path?
With RemoteSigned, you should be able to run all scripts written & run locally without a digital signature.
RemoteSigned
- Scripts can run.
- Requires a digital signature from a trusted
publisher on scripts and configuration files that
are downloaded from the Internet (including
e-mail and instant messaging programs).
- Does not require digital signatures on scripts that you have run
and that you have written on the local computer (not
downloaded from the Internet).
- Risks running unsigned scripts from sources other
than the Internet and signed, but malicious, scripts.
Unrestricted
- Unsigned scripts can run. (This risks running malicious
scripts.)
- Warns the user before running srcipts and configuration
files that are downloaded from the Internet.