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

  1. i feel very happy after reading this post. i hope i will collect more information in future.
    click here for know
    more

    ReplyDelete

Post a Comment

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.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Remove Azure DevOps Enterprise application record from Azure AD

If you want to delete an Azure AD tenant which contains an Azure DevOps Enterprise application record you will first have to remove this Enterprise application record. Removing the Azure DevOps Enterprise record will not succeed from the user interface because the delete button is greyed out. To remove the record follow these steps: Create a new Global Admin account in the directory you are trying to delete. Make sure you copy the temporary password. Start Windows PowerShell commandline and run: Install-Module -Name AzureAD . Once done run Connect-AzureAD . You will be prompted to login, login with the user you created and you will be asked to change your password. Run Remove-AzureADServicePrincipal -ObjectId [Object ID] to remove the Enterprise application record. Remove the Global Admin account you created. After the Azure DevOps Enterprise record is removed you can delete the Azure AD tenant.