Existing Bindings not updated with new certificates

[kd8ssq]

In v. 3.0.11.30336, when you create a new certificate against a site that has existing bindings (with an old, non-Lets Encrypt cert), the bindings don't get updated with the new Certify cert. They have to bound manually (the "Re-apply Certificate to Bindings" doesn't work either). I've had this happen to 3 different certificate registrations across 2 servers.

The log file shows the certificates were bound as they should be, but they aren't.

2018-05-11 16:21:25.411 -04:00 [INF] Completed Certificate Request.
2018-05-11 16:21:25.429 -04:00 [INF] Performing Automated Certificate Binding
2018-05-11 16:21:26.779 -04:00 [INF] Completed certificate request and automated bindings update (IIS)
2018-05-11 16:21:27.819 -04:00 [INF] Certificate installed and SSL bindings updated for abc.com
2018-05-11 16:22:49.447 -04:00 [INF] Performing Automated Certificate Binding
2018-05-11 16:22:50.801 -04:00 [INF] Completed certificate request and automated bindings update (IIS)
2018-05-11 16:22:51.350 -04:00 [INF] Certificate installed and SSL bindings updated for abc.com

[webprofusion-chrisc]

@kd8ssq thanks for raising this, that's very unusual.

What version of Windows/IIS are you using?

I assume the IIS bindings are on port 443 and has a hostname set that exactly matches the hostnames included in the certificate. Versions before v4 won't match bindings with no hostname specified.

[kd8ssq]

I’m using Server 2012 R2, IIS 8.5. The ports are 443 and the host names match exactly in the Certify cert. Also, SNI is enabled and the IP address on the binding is undefined (matches any IP).

…

On Fri, May 11, 2018 at 21:22 Christopher Cook ***@***.***> wrote: @kd8ssq <https://github.com/kd8ssq> thanks for raising this, that's very unusual. What version of Windows/IIS are you using? I assume the IIS bindings are on port 443 and has a hostname set that exactly matches the hostnames included in the certificate. Versions before v4 won't match bindings with no hostname specified. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#308 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGx26DiRMv7YGwv7Lp2d0d3pXVFH-EQks5txjlcgaJpZM4T8BJj> .

[webprofusion-chrisc]

@kd8ssq thanks, looks like a bug then. Our code to match an existing https binding is pretty simple, so I don't understand where it could go wrong, unless it's not matching the correct IIS site: https://github.com/webprofusion/certify/blob/release3.x/src/Certify.Core/Management/IISManager.cs#L582

[kd8ssq]

I’ll run some more tests on Monday and see if I can narrow down what the problem may be.

…

On Fri, May 11, 2018 at 22:21 Christopher Cook ***@***.***> wrote: @kd8ssq <https://github.com/kd8ssq> thanks, looks like a bug then. Our code to match an existing https binding is pretty simple, so I don't understand where it could go wrong, unless it's not matching the correct IIS site: https://github.com/webprofusion/certify/blob/release3.x/src/Certify.Core/Management/IISManager.cs#L582 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#308 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGx28RHXClTMlIFdJqeiSeCOesQzKRwks5txkcPgaJpZM4T8BJj> .

[kd8ssq]

I pulled out the code used to update the bindings if they already exist and added them to a brand new project so I could do more generic testing without having to generate new certificates.

What I've found is that when the CertificateHash and CertificateStoreName get set, it does take in the existingBinding (

certify/src/Certify.Core/Management/IISManager.cs

Line 587 in 3b31573

existingBinding.CertificateHash = certificateHash;

). But when the commit happens, it nulls out the CertificateHash and blanks out the CertificateStoreName (

certify/src/Certify.Core/Management/IISManager.cs

Line 644 in 3b31573

iisManager.CommitChanges();

).

I've seen a few references to people having the same problem where the SSL cert is not set, but no resolution.

[kd8ssq]

Looks like we're not the only ones having this issue: win-acme/win-acme#371.

Based on that information the following should work:

public bool InstallCertificateforBinding(Site site, X509Certificate2 certificate, string host, int sslPort = 443, bool useSNI = true, string ipAddress = null, bool alwaysRecreateBindings = false)
        {
            var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
            store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadWrite);

            using (var iisManager = GetDefaultServerManager())
            {
                if (GetIisVersion().Major < 8)
                {
                    // IIS ver < 8 doesn't support SNI - default to host/SNI-less bindings
                    useSNI = false;
                    host = "";
                }

                var siteToUpdate = iisManager.Sites.FirstOrDefault(s => s.Id == site.Id);

                if (siteToUpdate != null)
                {
                    string internationalHost = host == "" ? "" : ToUnicodeString(host);
                    var existingBinding = (from b in siteToUpdate.Bindings where b.Host == internationalHost && b.Protocol == "https" select b).FirstOrDefault();
                    string bindingSpec = "";

                    if (existingBinding != null)
                    {
                        // save off old binding information
                        bindingSpec = existingBinding.BindingInformation;
                        var bindingAttributes = existingBinding.Attributes;

                        // remove old binding
                        siteToUpdate.Bindings.Remove(existingBinding);
                    }
                    else
                    {
                        //add new https binding at default port "<ip>:port:hostDnsName";
                        bindingSpec = (!String.IsNullOrEmpty(ipAddress) ? ipAddress : "*") +
                            ":" + sslPort + ":" + internationalHost;
                    }

                    var iisBinding = siteToUpdate.Bindings.Add(bindingSpec, certificate.GetCertHash(), store.Name);
                    iisBinding.Protocol = "https";

                    if (useSNI)
                    {
                        try
                        {
                            iisBinding["sslFlags"] = 1; //enable sni
                        }
                        catch (Exception)
                        {
                            // failed to enable SNI
                            store.Close();
                            return false;
                        }
                    }
                }
                else
                {
                    //could not match site to bind to
                    return false;
                }

                iisManager.CommitChanges();
                store.Close();

                return true;
            }
        }

certify/src/Certify.Core/Management/IISManager.cs

Line 566 in 3b31573

public bool InstallCertificateforBinding(string certStoreName, byte[] certificateHash, Site site, string host, int sslPort = 443, bool useSNI = true, string ipAddress = null, bool alwaysRecreateBindings = false)

I can create a pull request if you would like. I just need to know which repository to use.

[webprofusion-chrisc]

Thanks for doing this research. Can you confirm if the original certificate was in the MY certificate store, or was it in the Web Hosting store? Can you also confirm if you have any web hosting control panel/cpanel type software installed that could have it's own version of the web administration dll in the GAC?

[kd8ssq]

Chris, The original very was in the Personal (MY) store on all 4 servers tested. I also have no custom panel software installed that would have its own web admin dll. Really the only things running on the servers are IIS, ISAPI and Coldfusion.

…

On Mon, May 14, 2018 at 21:38 Christopher Cook ***@***.***> wrote: Thanks for doing this research. Can you confirm if the original certificate was in the MY certificate store, or was it in the Web Hosting store? Can you also confirm if you have any web hosting control panel/cpanel type software installed that could have it's own version of the web administration dll in the GAC? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#308 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGx2w-1jJVWLR2-DB7zCHzZ_q5fYEAFks5tyjGYgaJpZM4T8BJj> .

[kd8ssq]

I actually tested on my local computer as well with the same results. Definitely seems odd that it doesn't want to update the binding when the cert is different. Deleting and re-creating the binding seems like a very easy way to get around the issue.

We have thousands of sites each with existing certificates that we're slowly fazing out and switching over to Let's Encrypt. Right now there's an extra step of having to manually select the new cert each time we create a Let's Encrypt cert.

[TheOfficeMaven]

I can confirm this one as well. I'm using V4Alpha6 and unless I completely delete the existing binding, it will fail to get updated without an error being thrown about the certificate not being valid (under Windows Server 2016).

BTW, I'm testing this using the "RE-APPLY CERTIFICATE TO BINDINGS" button that's located on the "Show Advanced Options" -> "Other Options" tab (so that I don't have to request a new certificate each time I want to re-apply the bindings for the latest certificate).

[webprofusion-chrisc]

@TheOfficeMaven so can you confirm that the preview tab in v4 says it will update that binding (not create a new one)? And that the certificate your replacing was just a manually applied certificate.