Skip to main content

Assign an existing certificate to your IIS website with WiX

Recently I had to change the bindings of existing IIS hosted websites and APIs from HTTP to HTTPS. They are installed with a MSI file created with the WiX Toolset.

Because I have to use an already on the server installed certificate I cannot use the Certificate element from the IIS Extension because this element only supports installing and uninstalling certificates based on PFX files. After doing some research I found the blog article Assign Certificate (Set HTTPS Binding certificate) to IIS website from Wix Installer which described the usage of Custom Actions for this purpose. I adopted this approach and rewrote the code for my scenario.

With WiX I still create the website.
<iis:WebSite Id="WebSite"
             ConfigureIfExists="yes"
             AutoStart="yes"
             Description="MyWebsite"
             Directory="IISROOT"
             StartOnInstall="yes">
  <iis:WebAddress Id="WebSite"
                  Header="my.dns.org"
                  Port="443"
                  Secure="yes" />
  <iis:WebDirProperties Id="WebSiteProperties"
                        AnonymousAccess="yes"
                        WindowsAuthentication="yes" />
</iis:WebSite>
After that we use a custom action to configure the certificate on the IIS binding which was created with the WebSite element. The code uses the Microsoft Web Administration classes to find the website and it's binding and to apply the certificate.

The certificate is found based on the common name. I wrote the code in such a way that only valid certificates can be used for the binding. If there are multiple certificates found with the same common name we will use the certificate with the expiration date furthest in the future.

I used the instructions documented in the blog article How to pass custom actions to a WiX installer using command line arguments to add this code to my Visual Studio solution.
namespace Wix.IisCustomActions
{
    using System;
    using System.Linq;
    using System.Security.Cryptography.X509Certificates;
    using System.Security.Principal;

    using Microsoft.Deployment.WindowsInstaller;
    using Microsoft.Web.Administration;

    public class CustomActions
    {
        [CustomAction]
        public static ActionResult AddExistingCertificateToBinding(Session session)
        {
            var result = ActionResult.Failure;

            session.Log("Start: AddExistingCertificateToBinding.");

            if (CheckRunAsAdministrator())
            {
                var siteName = session.CustomActionData["SiteName"];
                var ip = session.CustomActionData["IP"];
                var port = session.CustomActionData["Port"];
                var hostName = session.CustomActionData["HostName"];
                var certificateCommonName = session.CustomActionData["CertificateCommonName"];

                bool outcome = AddExistingCertificateToBinding(siteName, ip, port, hostName, certificateCommonName);

                if (outcome)
                {
                    result = ActionResult.Success;
                }

                session.Log("End: AddExistingCertificateToBinding.");
            }
            else
            {
                session.Log("Not running with elevated permissions.STOP");
                session.DoAction("NotElevated");
            }

            return result;
        }

        private static bool AddExistingCertificateToBinding(string siteName, string ip, string port, string hostName, string certificateCommonName)
        {
            bool result = false;

            using (var serverManager = new ServerManager(Environment.SystemDirectory + "\\inetsrv\\config\\applicationhost.config"))
            {
                var site = serverManager.Sites.SingleOrDefault(x => x.Name == siteName);

                if (site == null)
                {
                    return false;
                }

                var bindingInformation = $"{ip}:{port}:{hostName}";
                var binding = site.Bindings.SingleOrDefault(x => x.BindingInformation == bindingInformation);

                if (binding == null)
                {
                    return false;
                }

                using (var store = new X509Store(StoreName.My, StoreLocation.LocalMachine))
                {
                    store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadWrite);

                    var subjectName = $"CN={certificateCommonName}";
                    var certificates = store.Certificates.OfType().Where(x => x.Subject.Contains(subjectName));

                    var now = DateTime.Now;
                    var notAfter = now;
                    X509Certificate2 validCertificate = null;

                    foreach (var certificate in certificates)
                    {
                        if (certificate.NotBefore <= now && certificate.NotAfter >= notAfter)
                        {
                            validCertificate = certificate;
                        }
                    }

                     if (validCertificate != null)
                     {
                        binding.CertificateHash = validCertificate.GetCertHash();
                        binding.CertificateStoreName = store.Name;
                        binding.BindingInformation = bindingInformation;
                        serverManager.CommitChanges();
                        result = true;
                    }
                }
            }

            return result;
        }

        private static bool CheckRunAsAdministrator()
        {
            var identity = WindowsIdentity.GetCurrent();
            var principal = new WindowsPrincipal(identity);

            return principal.IsInRole(WindowsBuiltInRole.Administrator);
        }
    }
}
The WiX markup for using this deferred custom action is below. The custom action named AddCertificateActionParameters sets the parameters which the AddCertificateAction will use to perform the action.
... insert within product element ....
<CustomAction Id="AddCertificateActionParameters"
              Property="AddCertificateAction"
              Value="SiteName=MyWebsite;IP=;Port=443;HostName=my.dns.org;CertificateCommonName=my.dns.org"
              Return="check" />

<CustomAction Id="AddCertificateAction"
              BinaryKey="CustomActionBinary"
              DllEntry="AddExistingCertificateToBinding"
              Execute="deferred"
              Return="check" />

<Binary Id="CustomActionBinary" SourceFile="..\Wix.IisCustomActions\bin\$(var.Configuration)\Wix.IisCustomActions.CA.dll" />

<InstallExecuteSequence>
  <Custom Action="AddCertificateActionParameters" Before="AddCertificateAction">NOT Installed</Custom>
  <Custom Action="AddCertificateAction" Before="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
It's possible to configure multiple HTTPS bindings to the same website with this deferred custom action approach because you can ingest unique parameter values to the custom action by configuration. Something what is not possible with the normal property approach.

Comments

Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message:
Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers.
// Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.*&qu…

Deploy with ARM templates an Azure DevTest Lab environment

Within the company I work for we use Azure DevTest Labs already for a year to host our personal development computer and the BizTalk CI machines we need. We are planning to host also our development and test environments in Lab environments. At the moment we configure the lab environments manually.

I invested some time to write ARM templates to deploy Azure DevTest Labs within 5 minutes based on Azure DevOps CI/CD pipelines. In the process of writing these scripts I learned a lot. For example that the Azure documentation is not always up to date and that includes also tooling like Azure Resource Explorer. Based on querying the REST API with Postman I found the missing pieces for deploying a DevTest Lab environment based on nested ARM templates.

In this post I will document the nested ARM template I created the last few days. Lab With the first template you can create the lab environment itself and configure the following parts of the environment
Lab settings; like the storage which th…