Digital signatures are used to ensure that program files have not been changed after publication and that the software came from the publisher. They are based on digital certificates, which are issued by an authorized and trusted authority to a person or company, identified by the authority. If an executable file is digitally signed, then a user can decide whether or not to run the file by checking the signature.
For the validation of the digital signature, two parts must be checked:
  1. Digital signature: This is an encrypted hash value, produced by a hash function for a file and encrypted with the private key of the underlying certificate. To verify a signature, the encrypted hash value will be decrypted by using the public key and the output must match the re-calculated hash value by using the same hash function.
  2. Certificate: A software comes from the publisher, if it was signed with the certificate of the publisher. Thus, it must be checked, whether the correct certificate was used and whether the certificate is valid. In particular, the issuer of the certificate, the owner, the certification path, the serial number and the thumbprint must be validated.
Logo  This article was last updated on 2020-DEC-20, to reflect changes regarding the used certificate starting with TurboSFV v8.62. If you like this article, then please set a link to it.
Digital signatures and TurboSFV
All program files of TurboSFV, which contain executable code, are digitally signed, including the setup. The used certificate was issued for code signing (enhanced key usage:
The following values are needed for the validation of the underlying certificate, which is used for digitally sign TurboSFV v8.62 and newer:
Issuer:Sectigo RSA Code Signing CA
Owner:Jörg Krahe
Certification path: Sectigo (AAA)
  + USERTrust RSA Certification Authority
    + Sectigo RSA Code Signing CA
      + Jörg Krahe
Serial number:00 ef 6d 34 6d 9b 9d 55 c5 29 34 8a 38 e5 59 7d 3d
Thumbprint (SHA-1, insecure):ca 2a b9 4b 2f 2f 89 01 94 26 17 25 7e d4 27 bb aa 49 2a f5
Alternative, secure thumbprints (checksums) of the certificate - not displayed by Windows:
Read below for further instructions how to calculate and use them.
Used hash functions
The hash function SHA-1 is used for calculating the digital signature for a file and the thumbprint for the underlying certificate. Since 2005, successful attacks on SHA-1 are known, so that SHA-1 checksums can not guarantee security, when it comes to digital signatures and certificates. SHA-1 should only be seen as a data integrity check. The secure alternative is a hash function from the SHA-2 family, such as SHA-224, SHA-256, SHA-384 or SHA-512 or even better, one from the SHA-3 family (SHA3-224, SHA3-256, SHA3-384, SHA3-512).
SHA-1 is still used for providing backward compatibility to older Windows versions, which are not capable to check the digital signature based on a SHA-2 or SHA-3 hash function. However, the executables from TurboSFV are signed with two digital signatures, one based on SHA-1 and another based on the secure SHA-512. Windows always displays the primary signature, which is based on SHA-1. The additional signature based on SHA-512 is only displayed, if the used Windows version supports this hash function together with multiple signatures (such as Windows 8 or a fully updated Windows 7).
The thumbprint for the certificate, which is displayed by Windows, is still based on the insecure SHA-1. Thus, it can't be used alone to validate a certificate. Alternatively, a secure hash function (i.e. SHA3-256) could be used to identify a certificate (validation steps explained below).
Validation of the digital signature
Check existence of the digital signature
The necessary information is located on the tab sheet Digital Signatures: Locate the file in the explorer, right-click on the file which opens the context menu and then select Properties.
If you don't see this tab sheet, then the file isn't digitally signed or the signature was removed - the validation failed.
In newer Windows versions, you should see one entry, where the hash function SHA-1 was used for the digital signature and another based on SHA-512. The value for Name must appear as displayed, the timestamp indicates, when the file was signed (the value above should be treated as an example and will change for new versions of TurboSFV).
In older Windows versions, which are only capable to compute SHA-1 checksums, you should only see one entry in the signature list:
If you have the option, select SHA-512. In older Windows versions, the one you can select is based on SHA-1. Click on Details.
Digital Signature Details
A new window pops up, which displays general information about the signature. The most important information on this page is the statement, that the digital signature is OK.
The signature is OK, if
  1. the file has not been altered after signing: The calculated hash value, based on the selected hash function, matches the decrypted hash value in the signature,
  2. the certification chain is complete, and
  3. the underlying certificate (which can be a fake) is OK.
Otherwise an error message is displayed, marked with an error sign, for example:
In this case, the signature is invalid. If you see any error message, then the validation failed.
The field Name indicates, who signed the file and should exactly look as displayed. The field is taken from the underlying certificate, which now needs to be examined to ensure, that the correct certificate was used and that the certificate is valid (an attacker can sign a file with any certificate containing fake values). Take also a note of the signing time, because the underlying certificate is only valid for a certain period and must be valid on this date.
Click on View Certificate for the validation of the used certificate.
Validation of the certificate
A new window opens, which has three tab sheets containing details about the certificate, which was used to sign the file. A certificate can be seen as a digital identity card, issued by an authorized and trusted authority to a person or company, identified by the authority.
Issuer and owner
On the General tab, you see some basic information about the certificate.
The purpose field should be filled as displayed and indicates, that the certificate was issued for code signing (technically taken from the field enhanced key usage in the certificate: Any error message or warning like
indicates a problem with the certificate and the validation failed.
Now review the two fields Issued to and Issued by, which must have the following values, else the validation failed.
Issued to:Jörg Krahe
Issued by:Sectigo RSA Code Signing CA
The time period indicates start and end date, in which the certificate is valid. A file must be signed within this period, the signing time is displayed in the Digital Signature Details.
Serial number and thumprint
Checking the serial number ensures, that the correct certificate was used, and not another issued by the same authority (assuming that the serial number is unique within the authority). A different thumbprint indicates a wrong or damaged certificate.
Open the Details tab, ensure you have selected Show All:
The serial number for the certificate is managed by the authority and should be unique. The certificate, which is used to sign TurboSFV v8.62 and newer, has the following serial number:
Serial number:00 ef 6d 34 6d 9b 9d 55 c5 29 34 8a 38 e5 59 7d 3d
uppercase:00 EF 6D 34 6D 9B 9D 55 C5 29 34 8A 38 E5 59 7D 3D
This is a hexadecimal number and can appear in uppercase letters in some versions of Windows.
Now scroll down the list and select the field Thumbprint:
The thumbprint is a SHA-1 checksum for the certificate: It's not a part of the certificate, but calculated, used and displayed by Windows. The certificate, which is used to sign TurboSFV v8.62 and newer, has the following thumbprint:
Thumbprint:ca 2a b9 4b 2f 2f 89 01 94 26 17 25 7e d4 27 bb aa 49 2a f5
uppercase:CA 2A B9 4B 2F 2F 89 01 94 26 17 25 7E D4 27 BB AA 49 2A F5
Also the thumbprint is hexadecimal notated.
As explained, the thumbprint is a checksum for the certificate, hence a checksum for all fields in the certificate. Because of the security issues with SHA-1 (see Used hash functions), the SHA-1 thumbprint alone can't guarantee correctness. However, a wrong thumbprint surely indicates an error.
If the Serial number or the Thumbprint doesn't match, then the validation failed.
Now let's take a second and think about the thumbprint:
If we could get a checksum for the certificate from a secure hash function (such as from the SHA-3 family), then it would be enough to validate that checksum, because it covers all fields in the certificate. Unfortunately, Windows displays only the insecure SHA-1 thumbprint - but nothing keeps us away from calculating a secure thumbprint by ourselves, so here we go.
Alternative, secure and fast method for validating the details of a certificate
We calculate a SHA3-256 checksum of the underlying certificate and compare the result with a given one, provided by the software author. If both are the same, then we don't have to check special fields in the certificate, because we can trust SHA3-256. In particular, the following three steps need to be processed:
  1. Extract the certificate from the executable.
  2. Calculate a SHA3-256 checksum for the extracted certificate.
  3. Compare the calculated checksum with the one provided by the software author.
In the picture above, which shows the details of the certificate, you may have noticed a little button:
If you click on it, a certificate export wizard opens, which allows to extract the certificate from the executable. Click on next to select the export file format.
In the dialog, select DER encoded binary X.509 (.CER) as the file format. In principle we could use any file format, but we must agree on one, otherwise we can't compare the checksums. Furthermore, Windows uses the same file format for calculating the SHA-1 thumbprint, so we are here in line with Windows. Click on next to specify file location and name, again on next to review your settings and click on finish to save the file.
For calculating the SHA3-256 checksum, you must have a checksum utility installed. Of course we use TurboSFV, in particular the Shell extension of TurboSFV, which helps us with the calculation of the SHA3-256 checksum: Right-click on the exported file, select properties and navigate to the property page Hash.
Select SHA3-256 as the hash algorithm. If you want to compare with the Windows SHA-1 thumbprint, then tag also SHA-1. The SHA-256 checksum is also mentioned here: The hash function is widely spread, but the underlying algorithm is less secure comparing to SHA3-256. Click on start, then copy and paste the results into a text document and compare the SHA3-256 checksum with the following:
If the checksum matches, then the correct certificate was used, else the validation failed.
As you can see, this method is quick, easy and secure. As a precondition, the software author must provide the original SHA3-256 checksum of the certificate. Now we still have to have a look on the certification path.
Certification path
The certification path needs to be reviewed, to ensure that the correct authorities are involved and that the certification chain is complete.
In newer Windows versions, the path should be built as follows:
Certification path: Serial number of the certificate:
Sectigo (AAA)
  + USERTrust RSA Certification Authority
    + Sectigo RSA Code Signing CA
      + Jörg Krahe
39 72 44 3a f9 22 b7 51 d7 d3 6c 10 dd 31 35 95
1d a2 48 30 6f 9b 26 18 d0 82 e0 96 7d 33 d3 6a
- validated in previous step -
The top entry indicates the root authority in this chain. In Windows, a list of trusted root authorities is stored in the certificate store. Microsoft keeps this list updated via the Windows Update feature, but the list can also be managed manually by users (or programs) with appropriate privileges. The bottom entry indicates the certificate holder, all other entries are intermediate certificates. The certificates are trusted by their parent certificate, except the root certificate.
For the certification authorities, Windows may display so called "friendly names", which can be different - thus the serial numbers of the underlying certificates are mentioned here as well for further examination. The certification path, which is displayed, is the result of an operation, where Windows tries to resolve the path from the certificate holder up to the root authority - depending on which certificates are available in the certificate store.
The certification path is also called certification chain or chain of trust, and must not be broken. A broken chain, where the broken part of the chain is marked with a red error sign, can - for example - look like this:
A broken chain means, that you can't trust a particular certificate and thus, you can't trust all child certificates in the chain, because they are issued by their parent. The validation failed.
Now we also know why a certification chain must be complete: If not all certificates are displayed, we can't check whether or not a particular certificate was - for example - revoked meanwhile, and thus we can't trust all displayed certificates. An incomplete chain may look like this:
Here, the root certificate isn't available in the Windows certificate store, thus the path can't be resolved. In this case, Windows might then display a warning in the certificate details on the general tab ...
... and thus an error in the signature details, because the signature is based on that certificate:
Interpreting results
Success  If you have successfully finished all steps, then you can assume, that you have the original file.
Error  If at any point the validation failed, then most likely you don't have the original file and you shouldn't run it. If the validation failed for the setup program of TurboSFV. then download it from this website. If you have problems with validating the underlying certificate, then you should consult your administrator. You can also contact us as indicated under support.
Privacy PolicyCopyright © 2007-2021 Jörg Krahe. All Rights reserved!