Certificate Detection/Installation with WiX Installer - wix

Using WiX, is there a way to detect if a Certificate is installed on a machine? Is the only option you have to run a custom action with C# to detect if the certificate is installed, or is there a built in way with WiX to do it. I know how to install a certificate with WiX, but there needs to be some custom logic to detect if it already exists.
For example...
Our installer is a Per-User install, which means we don't have write access to the local-machine certificate store (although we do have read access). I have the following component in my .wxs file that adds the certificate to the User Certificates store:
<Component Id="C__IntermediateCert" Guid="{GUID_HERE}" Permanent="no" >
<iis:Certificate Id="_IntermediateCert" BinaryKey="B__IntermediateCert" StoreName="ca" Overwrite="no"
StoreLocation="currentUser" Name="Intermediate Cert Name" Request="no" />
</Component>
The problem is that this line will fail if there is already a certificate with this name in the local machine certificate store, even though we specified overwrite=no. There is an installer error raised and the user cannot continue the installation.
So the workaround I want to implement is to first look to see if the certificate is installed on the machine (either in local machine or user) and skip the component if it is already installed. However, it doesn't appear there is anyway to just search for the certificate (like there is for files/directories).
Any suggestions or help with how to either search for the certificate, or point out what I am doing wrong in the certificate creation (to properly ignore if it is already installed) would be greatly appreciated!
EDIT: (with correct solution)
Adding some information about a workaround I tried, and is now working. I ended up creating a C# custom action that should check if the certificate exists
See here:
public static ActionResult CheckForExistingCertificate(Session session)
{
session.Log("Starting CheckForExistingCertificate");
try
{
session.Log("***** Beginning LocalMachine Certificate Store Search...");
X509Store lmStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.LocalMachine);
lmStore.Open(OpenFlags.ReadOnly);
session.Log("***** lmStore.Certificates.Count = " + lmStore.Certificates.Count);
foreach(X509Certificate2 cert in lmStore.Certificates)
{
session.Log("lmCertificate Listing : " + cert.FriendlyName);
if (cert.FriendlyName == "Intermediate Cert Name")
{
session["INTERMEDIATECERTIFICATEALREADYINSTALLED"] = "TRUE";
}
}
session.Log("***** Beginning CurrentUser Certificate Store Search...");
X509Store cuStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.CurrentUser);
cuStore.Open(OpenFlags.ReadOnly);
session.Log("***** cuStore.Certificates.Count = " + cuStore.Certificates.Count);
foreach (X509Certificate2 cert in cuStore.Certificates)
{
session.Log("cuCertificate Listing : " + cert.FriendlyName);
if (cert.FriendlyName == "Intermediate Cert Name")
{
session["INTERMEDIATECERTIFICATEALREADYINSTALLED"] = "TRUE";
}
}
}
catch
{
session.Log("CheckForExistingCertificate - in catch");
}
session.Log("Ending CheckForExistingCertificate - end of function");
return ActionResult.Success;
}

Interesting, I hit the exact same bug last week. I was really up against a deadline so I just wrote a custom action to delete the certificate if it exists and the component is being reinstalled. But yes, I believe this is a WiX 3.8 bug as If overwrite=no it shouldn't cause a problem.
In my case we were distributing a cert via group policy and via an MSI to ensure we had as close to 100% coverage as possible. The MSI worked and the GPO worked but then the MSI failed after the GPO was applied. I delete the GPO loaded cert, load mine and then when you do a GPUPDATE -FORCE you end up with two copies of the cert but with no obvious negative side effects.

Related

WebSocketpp handshake issue with TLS

I have been learning with WebSocket++ and built some of the server examples (Windows 10 Visual Studio 2019). The non-TLS examples work without issues, however, the TLS-enabled examples (echo_server_both.cpp and echo_server_tls.cpp) can't do the handshake. I am very new to web development in general so I know I must be doing something wrong with regards to the certificate and keys.
I am testing the servers with WebSocket King client, an extension of Google Chrome that connects correctly to other websocket servers like wss://echo.websocket.org and to my own localhost when I don't use TLS.
The echo_server_both example comes with a server.pem file, and the echo_server_tls example comes with server.pem and dh.pem. I have used the same files that come with the samples, and I have also tried generating and registering my own .pem files using openSSL. In both cases I get this when the client tries to connect:
[2021-06-29 20:51:21] [error] handle_transport_init received error: sslv3 alert certificate unknown
[2021-06-29 20:51:21] [fail] WebSocket Connection [::1]:63346 - "" - 0 asio.ssl:336151574 sslv3 alert certificate unknown
[2021-06-29 20:51:21] [info] asio async_shutdown error: asio.ssl:336462231 (shutdown while in init)
I discovered these errors after I edited handle_init() in tls.hpp, following a suggestion in another site, to look like this:
void handle_init(init_handler callback,lib::asio::error_code const & ec) {
if (ec) {
//m_ec = socket::make_error_code(socket::error::tls_handshake_failed);
m_ec = ec;
} else {
m_ec = lib::error_code();
}
callback(m_ec);
}
This change let the actual openSSL error to show in the console, otherwise it would show a generic "handshake failed" error.
I know I'm not doing what I should with the certificates, but I have no idea where else to look or what to do next. Can anyone here help please? Should I use the .pem files that come with the examples, or should I generate my own? in case I should generate my own, what would be the openSSL command to do that correctly and how do I tell my PC to recognize these as valid so that the server works?
Found the problem: WebSocket++ will not accept a self-signed certificate (the ones you can create directly in your own PC using OpenSSL or the Windows utilities). There is no way around it. You must have a valid, authority-validated and endorsed certificate. You can get such a certificate for free (valid only for 90 days) from https://zerossl.com/. The site has detailed instructions on how to request, obtain and install a certificate. After getting a valid certificate and installing it on my server, everything worked as it should.

ServiceFabric standalone: Failed to get private key file

I have a standalone ServiceFabric cluster (3 nodes). I created SSL certificate for server and client authorization. Then I assign certificate thumbprint to a cluster config. Everything work okey( cluster health is Ok and my applications works as well. But there are a lot of errors in Microsoft-ServiceFabric/Admin log. Following warning and errors are writing to log every minute:
CryptAcquireCertificatePrivateKey failed. Error:0x80090014
Can't get private key filename for certificate. Error: 0x80090014
All tries to get private key filename failed.
Failed to get the Certificate's private key. Thumbprint: {Cert
Thumbprint}. Error: E_FAIL
Failed to get private key file. x509FindValue: {Cert Thumbprint},
x509StoreName: My, findType: FindByThumbprint, Error E_FAIL
SetCertificateAcls failed. ErrorCode: E_FAIL Can't ACL
FabricNode/ServerAuthX509FindValue, ErrorCode E_FAIL
I assinged write permitions to private keys storage for NETWORK SERVICE and SYSTEM. As well I assigned gMSA account for PK storage. But errors still apears in log.
From the other hand everything looks fine, cluster up and running...
Here is my cluster config (security part):
"security":{
"ServerCredentialType":"X509",
"ClusterCredentialType":"Windows",
"WindowsIdentities":{
"ClustergMSAIdentity":"gMSAccountName#domain.com",
"ClusterSPN":"http/servicefabric"
},
"CertificateInformation":{
"ServerCertificate": {
"Thumbprint": "{Cert Thumbprint}",
"X509StoreName": "My"
},
"ClientCertificateThumbprints":[
{
"CertificateThumbprint":"{Cert Thumbprint}",
"IsAdmin":true
}
],
"X509StoreName": "My"
}
},
For x509 certificated creation I used OpenSSL 1.0.2k-fips 26 Jan 2017. I follow the steps from this article: https://gist.github.com/harishanchu/e82d759c0235379d1778f799992b5774
Could anyone clarify this issue?
It seems like you don't have a private key file in the MachineKeys folder.
To verify if you have a physical file in the folder run this powershell command:
$certThumb = "1D6523F622E33DF46382D081BCA9AE9A2D8D78CC"
Try
{
$WorkingCert = Get-ChildItem CERT:\LocalMachine\My |where {$_.Thumbprint -match $certThumb} | sort $_.NotAfter -Descending | select -first 1 -erroraction STOP
$TPrint = $WorkingCert.Thumbprint
$rsaFile = $WorkingCert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
}
Catch
{
"Error: unable to locate certificate for $($CertCN)"
Exit
}
if ($WorkingCert.PrivateKey) {
$WorkingCert.PrivateKey
}
else
{
"No private key found"
}
If you get No private key found message it means there is no private key in the MachineKeys folder. Even though certificate properties can claim otherwise (there is a key icon and message You have a private key that corresponds to this certificate). Although I don't know why but for some certificates above situation happens.
As a workaround, follow these steps:
Go to the local machine cert store and delete your certificate.
Import your certificate to the local user store first.
Then import your certificate to the local machine store.
Set access rights for Network Service user.
If you follow steps above, private key will be added to MachineKeys folder and error will disappear.
Obviously you have to repeat these steps for every cluster node.

Client certificate has different thumprint via ARR and AuthorizationContext

I am currently working on a prototype for a WCF service that will make use of client-certificate authentication. We would like to be able to directly publish our application to IIS, but also allow SSL offloading using IIS ARR (Application Request Routing).
After digging through the documentation, I have been able to test both configurations successfully. I am able to retrieve the client certificate used to authenticate from:
X-Arr-ClientCert - the header that contains the certificate when using ARR.
X509CertificateClaimSet - when published directly to IIS, this is how to retrieve the Client Certificate
To verify that the request is allowed, I match the thumbprint of the certificate to the expected thumbprint that is configured somewhere. To my surprise, when getting the certificate through different methods, the same certificate has different thumbprints.
To verify what is going on, I have converted the "RawData" property on both certificates to Base64 and found that it's the same, except that in the case of the X509CertificateClaimSet, there are spaces in the certificate data, while in the case of ARR, there are not. Otherwise, both strings are the same:
My question:
Has anyone else run into this, and can I actually rely on thumbprints? If not, my backup plan is to implement a check on Subject and Issuer, but I am open to other suggestions.
I have included some (simplified) sample code below:
string expectedThumbprint = "...";
if (OperationContext.Current.ServiceSecurityContext == null ||
OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets == null ||
OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets.Count <= 0)
{
// Claimsets not found, assume that we are reverse proxied by ARR (Application Request Routing). If this is the case, we expect the certificate to be in the X-ARR-CLIENTCERT header
IncomingWebRequestContext request = WebOperationContext.Current.IncomingRequest;
string certBase64 = request.Headers["X-Arr-ClientCert"];
if (certBase64 == null) return false;
byte[] bytes = Convert.FromBase64String(certBase64);
var cert = new System.Security.Cryptography.X509Certificates.X509Certificate2(bytes);
return cert.Thumbprint == expectedThumbprint;
}
// In this case, we are directly published to IIS with Certificate authentication.
else
{
bool correctCertificateFound = false;
foreach (var claimSet in OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets)
{
if (!(claimSet is X509CertificateClaimSet)) continue;
var cert = ((X509CertificateClaimSet)claimSet).X509Certificate;
// Match certificate thumbprint to expected value
if (cert.Thumbprint == expectedThumbprint)
{
correctCertificateFound = true;
break;
}
}
return correctCertificateFound;
}
Not sure what your exact scenario is, but I've always liked the Octopus Deploy approach to secure server <-> tentacle (client) communication. It is described in their Octopus Tentacle communication article. They essentially use the SslStream class, self-signed X.509 certificates and trusted thumbprints configured on both server and tentacle.
-Marco-
When setting up the test again for a peer review by colleagues, it appears that my issue has gone away. I'm not sure if I made a mistake (probably) or if rebooting my machine helped, but in any case, the Thumbprint now is reliable over both methods of authentication.

WebRequest client certificate null on WebAPI side

I have a WebApi controller action that I decorated with my [x509Authorize] attribute. I'm debugging this endpoint locally - and at the same time running a console application that tries to call this endpoint.
Client side
Here's the client code - slightly simplified:
X509Certificate Cert = X509Certificate.CreateFromCertFile("C:\\Temp\\ht-android-client.pfx");
HttpWebRequest Request = (HttpWebRequest)WebRequest.Create("https://localhost:44300/api/mobile/predict");
Request.ClientCertificates.Add(Cert);
HttpWebResponse Response = (HttpWebResponse)Request.GetResponse();
....
I've asserted that the Cert is the correct certificate. I've installed the .pfx in my CurrentUser\Personal store and in the LocalMachine\Personal store - and modified to take the Cert from that store, as suggested here but that doesn't seem to make a difference:
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var Cert = store.Certificates.Find(X509FindType.FindBySubjectName, "Android", true)[0];
Server side
And I'm listening on the WebAPI endpoint like with the following code:
public class x509AuthorizeAttribute : AuthorizeAttribute
{
public override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
{
var cert = actionContext.Request.GetClientCertificate();
// value of 'cert' is null
I hit a breakpoint in the console app first - see that the correct certificate is selected. Then I hit the breakpoint on the server and see that the value of .GetClientCertificate() is null. What am I doing wrong? The other SO questions 1 and 2 didn't help me any further.
Additional information on the certificates
I've created a self-signed CA certificate which is installed on the LocalMachine\Trusted root CA store. I've created the android client cert - and signed it with my self-signed CA certificate. Then I converted that into a pkcs12 file. This is the certificate that the client is using - which is also installed in my personal stores ( both machine and currentUser ) and is valid ( you can see the chain go back to the ROOT CA cert ).
Also - the certificate's purpose is set to clientAuth:
So the problem is indeed that the server needs to have the following set in the web.config in order to force IIS to start the SSL cert negotiation:
<security>
<access sslFlags="SslNegotiateCert" />
</security>
If this is not present - the certificate will be ignored and you will get null on the GetClientCertificate() call.
This implies however that all clients for my WebAPI are now forced to present a valid certificate - so my original idea of having just one controller method requiring a certificate does not seem possible.
Then there's the challenge of setting this config paramter in web.config, because of the restrictions for Azure Cloud Services. However - this answer provides a solution for that.
EDIT
On a side note this is not supported yet in ASP.NET vNext ( v rc-01-final )

WiX: Problem installing password protected PFX certificate

I'm having some trouble getting a password protected PFX certificate to install through WiX.
I'm using WiX 3.5.2519.0.
I include a PFX file as follows:
<Binary Id="My.Binary"
SourceFile="$(var.ProjectDir)MyProject$(var.ConfigSuffix).pfx" />
The value of $(var.ConfigSuffix) varies based on solution configuration (e.g. " (Debug)", " (Stage)"). For "Release", it is set to an empty string.
I have various solution configurations, all but one use a non-password protected PFX certificate, "Release" uses a password protected PFX. I deal with this by conditionally defining $(var.PfxPassword) in "Release" configuration only, and then installing the certificate as follows:
<?ifdef $(var.PfxPassword) ?>
<iis:Certificate
Id="My.Certificate"
StoreName="root"
Overwrite="yes"
Name="My Web Site$(var.ConfigSuffix)"
Request="no"
BinaryKey="MyCertificate.Binary"
StoreLocation="localMachine"
PFXPassword="$(var.PfxPassword)" />
<?else?>
<iis:Certificate
Id="My.Certificate"
StoreName="root"
Overwrite="yes"
Name="My Web Site$(var.ConfigSuffix)"
Request="no"
BinaryKey="MyCertificate.Binary"
StoreLocation="localMachine" />
<?endif?>
I have also tried replacing "$(var.PfxPassword)" with "[PFXPASSWORD]" (having defined this elsewhere), and the actual password in plain text. In every case, installation fails with the following log snippet:
Action start 12:29:02: InstallCertificates.
InstallCertificates: Error 0x80070056: Failed to open PFX file.
InstallCertificates: Error 0x80070056: Failed to get SHA1 hash of certificate.
InstallCertificates: Error 0x80070056: Failed to resolve certificate: LinnRecords.Certificate
CustomAction InstallCertificates returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:29:02: InstallCertificates. Return value 3.
I believe error 0x80070056 indicates an incorrect password, however I have used the Get-PfxCertificate in PowerShell to verify that the password I am using is correct.
For all configurations where the PFX file does not use a password, the installation works without issue.
Looking at a similar problem elsewhere on the internet, it looks like return code 3 is a "File not found" problem. Are you sure the correct pfx file is being included?