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.

Make steps conditional in multi-stage YAML pipelines

To make the switch from the graphical release pipelines in Azure DevOps I am missing two features. The first one is to be able to defer a deploy and the second one is to exclude certain deployment steps without the need for editing the YAML file.  The defer option is something Microsoft has to solve in their Azure DevOps proposition. It's a feature which you have in the graphical release pipeline but what they have not implemented yet in their YAML pipeline replacement. Approvals and certain gate conditions are implemented on the environment but the defer option is still missing .  Pipeline The conditional deployment option can be implemented with the help of runtime parameters and expressions . In the parameter section you define boolean parameters which will control the deploy behavior. With the expressions you can control which stage/job/task should be executed when the pipeline runs. In the below YAML sample I experimented with conditions in the azure-pipelines.yml  file

Switch from Azure DevOps release pipeline to YAML based CI/CD pipeline

It has been years ago I started applying continuous integration (CI) and continuous deployment (CD) principles at work. Around 2005, it was the time of Visual Studio 2005 Team System, we started using a build server in our daily development process. From then on it was no longer more: "it works on my machine". With every check-in of code changes a CI build was started which compiled your code and run unit tests which verified the quality of your code.  Deployment was in the beginning still a process of manually copying build artifacts and script files to servers and doing the installation process based on the instructions from the deployment manual (if available). Gradually it migrated to scripts (mix of batch/PowerShell/VBScript files) that our release automatically ran from the build server. In 2016 we migrated from our on-premise TFS 2008 based environment to the cloud solution nowadays known as Azure DevOps . We upgraded our MSBuild driven CI/CD pipelines to the new vis