We Keep Coding

Validating a Code Signing Certificate on a Windows Application

I am trying to programmatically validate a code signing certificate as described in this question from 2014. After following the suggestions, I am still not able to find a consistent working solution to determine when my .exe has been tampered with (i.e. the hash no longer matches)
The WinVerifyTrust method from wintrust.dll is the most accurate however I seem to getting a false positive after my executable has been obfuscated/VM'd. In this scenario, I am getting a result of (int)2148204800 even though the .exe is validly signed and un-tampered with. I am also averse to using Windows API calls as I want the code to be as portable as possible.
The other methods such as X509Certificate.CreateFromSignedFile().Verify() and the Powershell method of course do not validate the exe's hash so return true.
Is there any new way that's come about in the last 4 years to validate the hash of the .exe, preferably in pure .NET? I am happy with a solution that simply validates that the hash and not the entire certificate (if that's possible).

If you pull from Mono.Security as a Nuget Package they have a nice AuthenticodeDeformatter class that will verify code signing certificates:
var authenticode = new AuthenticodeDeformatter(Filename);
authenticode.IsTrusted(); //Should return False if tampered with.

You can use the WinVerifyTrust API.
A largish working class with PInvoke calls too long to post here, is available at PInvoke.net: WinVerifyTrust. You can copy that code verbatim and call WinTrust.VerifyEmbeddedSignature() to verify the signature and file hash.
Additionally, it's also a good idea to check the certificate (first) to make sure it's the correct certificate. Somebody could change the file, then sign with a new certificate.
To put it together:
Check the certificate
Use the WinTrust helper
var theSigner = X509Certificate.CreateFromSignedFile(filePath);
var theCertificate = new X509Certificate2(theSigner);
// ensure it's my application's cerfificate
var subject = theCertificate.Subject;
if (!subject.Contains("ACME Inc.")
return false;
// verify the authenticode signature and file hash
if (WinTrust.VerifyEmbeddedSignature(filePath))
return true;
return false;

Creating asymmetric keys in SQL Server 2014 for unsafe assemblies

I have 2 DLLs signed in Visual Studio (VS) 2015. A former employee created an asymmetric key and login and I ran one of the assemblies in UNSAFE mode correctly.
I get the following error with the second one:
Msg 10327, Level 14, State 1, Line 27
CREATE ASSEMBLY for assembly 'TableFile' failed because assembly 'TableFile' is not authorized for PERMISSION_SET = UNSAFE. The assembly is authorized when either of the following is true: the database owner (DBO) has UNSAFE ASSEMBLY permission and the database has the TRUSTWORTHY database property on; or the assembly is signed with a certificate or an asymmetric key that has a corresponding login with UNSAFE ASSEMBLY permission.
I can't ask the former employee so how do I find out how to get this to run? I tried this too:
USE master;
GO
CREATE ASYMMETRIC KEY AProjectKey FROM EXECUTABLE FILE = 'E:\sqldlls\TableFile.dll'
CREATE LOGIN AProjectLogin FROM ASYMMETRIC KEY AProjectKey ;
GRANT UNSAFE ASSEMBLY TO AProjectLogin ;
GO
This gives the following errors:
Msg 15396, Level 16, State 1, Line 9
An asymmetric key with name 'AProjectKey' already exists or this asymmetric key already has been added to the database.
Msg 15151, Level 16, State 1, Line 10
Cannot find the asymmetric key 'AProjectKey', because it does not exist or you do not have permission.
Msg 15151, Level 16, State 1, Line 11
Cannot find the login 'AProjectLogin', because it does not exist or you do not have permission.
How do I get both these assemblies running in unsafe mode? Thanks in advance.

Regarding those 3 error messages:
The first could be due to the Asymmetric Key already existing, but under a different name. Keys and Certificates need to be unique in terms of their public key, not just the name (though that obviously needs to be unique as well). Each Key and Certificate has a hash of the public key which is referred to as the "thumbprint". The thumbprints of existing Keys / Certificates are checked when creating a new one and will prevent the creation, even of a differently named Key / Certificate, if the thumbprint already exists. That is what the error message means by "or this asymmetric key already has been added to the database".
OR:
It could mean that a different Asymmetric Key (i.e. different "thumbprint") exists in master, but with the name AProjectKey
Because you couldn't create the same key under a different name, no Asymmetric Key exists with that new name, hence you can't create a Login from it (since, again, the CREATE ASYMMETRIC KEY statement failed).
Because you couldn't create the Login, it doesn't exist to be granted any permissions.
Error # 2 helps narrow down the issue. If Error # 1 was caused by an existing Asymmetric Key having the same name but different "thumbprint", then you either would have been able to create the Login (if it did not already exist), or you would have gotten an error stating that the Login (i.e. "server principal") already exists. But the error is that an Asymmetric Key by that name cannot be found. This should mean that the Asymmetric Key itself does already exist, but under a different name. You can see what Asymmetric Keys have been created by executing the following:
SELECT * FROM sys.asymmetric_keys;
But that doesn't tell you which one came from that Assembly (or an Assembly signed with the same Strong Name Key used to sign this one). For that you need to know the "thumbprint", and for that you need to open a Command Prompt (preferably a "Developer Command Prompt" which Visual Studio sets up when installed, as it has the correct path set up upon opening it). Then, run the following:
CD /D E:\sqldlls\
sn -T TableFile.dll
You should see:
Public key token is XXXXXXXXXXXXXXXX
Copy and paste that XXXXX "token" (i.e. thumbprint) into the following query:
SELECT ak.[name], ak.[sid]
FROM sys.asymmetric_keys ak
WHERE ak.[thumbprint] = 0x{XXXXXXXXXXXXXXXX}; -- remove the { and }
Assuming that you get a row returned, we need to see if the Login exists. Simply trying to create a Login from the Asymmetric Key won't get us the Login's name if it does exist since you can only have 1 Login created per Key / Certificate, and the error message only reports back the name you are trying to create as the one that already exists, even though it can be a different name for the same Key. So, take the SID from the returned row and paste it in the following query:
SELECT sp.*
FROM sys.server_principals sp
WHERE sp.[sid] = 0x{SID_from_sys_asymmetric_keys}; -- remove the { and }
If no row is returned then you should create a Login from that Asymmetric Key.
At this point a Login should exist, so grant it the UNSAFE ASSEMBLY permission.
Now try creating the Assembly again.

Password required to access private key in code?

I have a certificate with private key installed in my certificate store. It required the password in order to install it, which I provided. My question is whether or not I need to provide it again when referencing it in code. I need to "sign" a SAML2 request using the private key. Do I need to use an overload of X509Certificate2() that takes in the password in order for the code to allow me to access the private key for signing? It was questionable to me since I already had to provide it upon installation of the certificate.

My sources tell me no. =)
Once you have installed it in the windows keystore, the private key is usable to all the applications running as the user.
There is an option which you can use called "Enable strong private key protection". Password would then be prompted at every use.
The overloaded version X509Certificate2() constructor is used to read a raw p12 file, in the case you don't use the keystore. http://msdn.microsoft.com/en-us/library/ms148417.aspx

Auto Update Downloading Latest .exe file - how to verify it's not been tampered with?

We have a small console application (under 200kb) that will be distributed to clients and we want to ensure they run the latest version (verified by a WCF service). Currently it downloads the new .exe file over HTTPS and replaces the current .exe file with it.
Assuming our server isn't compromised, this would be ok. However we also sign our .exe file with a Code Signing certificate. Is there a way to verify this and delete the file if it doesn't match? We would need to be able to verify and delete the file without it ever being executed in case it is a virus.
How can we verify our signed .exe file? For example, Windows will show if it is invalid:
Edit: would this code do the job?
X509Certificate basicSigner = X509Certificate.CreateFromSignedFile(file);
X509Certificate2 cert = new X509Certificate2(basicSigner);
if (cert.Subject.Contains("CN=MY COMPANY NAME IN CERTIFICATE"))
valid = true;
Edit: if we also check StrongNameSignatureVerificationEx, it comes back failed if one bit is changed in the file. Perhaps this is enough?
[DllImport("mscoree.dll", CharSet = CharSet.Unicode)]
static extern bool StrongNameSignatureVerificationEx(string wszFilePath, bool fForceVerification, ref bool pfWasVerified);
Edit: I've implemented this code too which calls WinVerifyTrust in WinTrust.dll to actually verify the Authenticode signature: http://www.pinvoke.net/default.aspx/wintrust.winverifytrust
Now, it checks if the digital signature contains the correct subject, is from a valid trusted root, the signature is valid and if the code is strong named with it's digital signature. This must be safe enough now?

This is a nice walkthrough including source code on the options available to achieve what you want...
Basically you need to pinvoke StrongNameSignatureVerificationEx since there is no managed API to do what you need.
Another option might be to call SignTool.

This is a pretty fundamentally wrong way to go about it. The only thing that a code signing certificate proves is the identity of the person or company that signed the EXE. The certificate authority merely proves that identity is valid. What you haven't proved at all is that it is your certificate, you only proved that it is somebody's certificate. An attacker could trivially replace your EXE with another one that was signed by him.
You'll probably object with "but can't I just verify it is mine!". And the answer is no, if the attacker can replace the EXE then he'll have no trouble replacing your checking code either. There is zero security in having the verification performed on the same machine.
Code certificates serve only one purpose, they prove the identity of the signer to the user. Making them do anything else is a security hole. The really bad kind, the kind that make you feel that your system is secure. And make you stop thinking about implementing real security.

Import certificate with private key programmatically

I'm trying to use the HttpListener class in a C# application to have a mini webserver serve content over SSL. In order to do this I need to use the httpcfg tool. I have a .pfx file with my public and private key pair. If I import this key pair manually using mmc into the local machine store, everything works fine. However, if I import this key pair programmatically using the X509Store class, I am not able to connect to my mini webserver. Note that in both methods the cert is getting imported to the MY store in LocalMachine. Oddly, I am able to view the certificate in mmc once I programmatically import it and when I view it, the UI indicates that a private key is also available for this certificate.
Digging a little deeper, I notice that when I manually import the key pair, I can see a new file appear in C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, but one does not appear when I import programmatically. On a related note, when I delete a manually imported certificate, it does not remove the corresponding private key file from the previously mentioned directory.
Ultimately, my question is this: When I programmatically add the certificate to the store, where is the private key being stored and why isn't it accessible to the HttpListener class (HttpApi)?
Note that this question is slightly related but I don't think permissioning is the problem since this is all being done as the same Windows user:
How to set read permission on the private key file of X.509 certificate from .NET

Ok, I figured it out. It had to do with the key storage parameters for the certificate object. For anyone else that runs into this problem, make sure you construct your X509Certificate2 objects that you are adding to the store using the X509KeyStorageFlags.PersistKeySet and X509KeyStorageFlags.MachineKeySet flags. This will force the private key to persist in the machine key set location which is required by HttpApi (HttpListener wraps this).

Is this a 2 way SSL? If it is then did you send over a SSL Certificate Request file generated on your machine? This Certificate Request file will be used to create the SSL and they together form a public private key pair.
Also did you try assigning the cert permission for the user account that is being used to run the web app? You can do this by using the Microsoft WSE 3.0 tool.

Not exactly the answer to your question, but here for reference of others going down this path:
Here is a link to a MS chat that gives sample C# code to do what httpcfg does, thus eliminating the need for the tool on deployment.