Preview not showing all applicable IIS sites

Single IIS server (server 2016) with CTW v 5.2.1. Two IIS sites:

  • Site 1 is “default web site” with SNI https 443 binding for www_site1_net, no other https bindings.
  • Site 2 has SNI https 443 binding for www_site2_net and a second SNI http3 443 binding for www_site2_co_uk no other https bindings
  • All IP addresses are set to [*] - no IP address is “specified”.

certifytheweb set on AUTO deployment. Preview screen correctly shows the DNS authorisation from our DNS manager for www_site1_net (primary) , www_site2_net (SAN) and www_site2_co_uk (SAN)

List of IIS sites at the bottom shows only www_site2_net and www_site2_co_uk

If I change from AUTO to SINGLE SITE then the preview shows www_site1_net to be updated.

If I change from AUTO to ALL SITES then the preview shows only www_site2_net and www_site2_co_uk

the resulting certificate correctly shows the three domains with the primary being www_site1_net The cert does work if I manually change site1 in IIS.

Website property in IIS for “default web site” (site1) shows the correct binding as https:*.443:www_site1_net as the very first entry

how can I get both sites to update? It should be noted that I updated from an older ver4 to ver5.2.1 this morning and was testing. Ver4 worked just fine for both sites. I am happy to script a post-request script to make it work.

“cheesy fix” so far is to run this as a “post script”. yes it can be tidied to a few less lines but i left my testing portions in there near enough…

Import-Module -Name WebAdministration

$DefaultCertThumb = “-1”
$TestedCertThumb = “-1”
$DefaultCertName = “-1”
$TestedCertName = “-1”

Get-ChildItem -Path IIS:SSLBindings | ForEach-Object -Process `
{
if ($.Sites)
{
$certificate = Get-ChildItem -Path CERT:LocalMachine/My | Where-Object -Property Thumbprint -EQ -Value $
.Thumbprint
if ( $.Sites.Value -eq “Default Web Site”)
{
$DefaultCertName = $certificate.FriendlyName
$DefaultCertThumb = $certificate.Thumbprint
}
if ( $
.Sites.Value -eq “site2”)
{
$TestedCertName = $certificate.FriendlyName
$TestedCertThumb = $certificate.Thumbprint
}
}
}
if ($DefaultCertThumb -ne $TestedCertThumb -And $TestedCertThumb -ne “-1”)
{
$webbinding = get-webbinding -name “Default Web Site” | Where-Object { $_.bindingInformation -eq “*:443:www_site1_net” }
if ($webbinding)
{
$webbinding.AddSslCertificate($TestedCertThumb, “my”)
}
}

Hi, with Auto deployment you need to have an existing http or https binding with the same hostname specified as appears on the certificate, it won’t just apply your cert to every website on the server.

The preview bindings are what the app sees need to be updated so if another binding isn’t being targetted you need to consider why that is.

You can optionally customise the deployment mode and choose from a range of settings but if it gets complicated you can of course define 2 or more managed certificates and deploy them differently.

it does, the “default web site” has a https SNI binding for www_site1_net no other https bindings exist for this site. The bindings, websites have not changed since I first started using CTW, the only thing I did was upgrade the CTW version from version 4.1.6 to 5.2.1

Before 5.2.1 it worked. Since 5.2.1 only site2 is picked up by “auto” or “all”.

IIS -> Binding screen
ctw2

text under RED boxes is identical on all my screenshots.

sorry for multiple posts it will only allow me 1 picture per post. It wont let me put www.site1.net too many times either, hence me needing to put www_site1_net

confirmation of IIS binding:

My script cheesy fix was overly complex. It seems you can push the certificate details into the powershell:

param($result)
if ($result.IsSuccess)
{
Import-Module -Name WebAdministration
$webbinding = get-webbinding -name “Default Web Site” | Where-Object { $_.bindingInformation -eq “*:443:www.site1.net” }
if ($webbinding)
{
$webbinding.AddSslCertificate($result.ManagedItem.CertificateThumbprintHash, “my”)
}
}

The irony is that this script wouldnt work if there wasnt already a binding for the site I am after, I have tested this and it works live:

get-webbinding -name “Default Web Site” | Where-Object { $_.bindingInformation -eq “*:443:www.site1.net”

1 Like

Thanks, there’s about 18 months of updates since 4.1.6 so the behavior of some of the app has changed in a few places but this is a pretty interesting issue, I’ve not seen anyone else report.

I presume all of your sites are running (not stopped) and everything is working normally otherwise.

It’s possible that there is an old setting that’s causing an issue, could you try adding a new managed certificate with the same settings (same domains, set to auto deployment) to see if the preview still shows the same planned binding updates?

interestingly, I created a new cert and looked in the “select site (optional)” and the “default web site” does not exist in the drop down.

I ran Get-IISSite which listed “Default Web Site” as having ID 1 and was “started” (plus my other websites underneath). No duplicated IDs and the correct working directory (My phoneline would melt if this website was not working, it has our primary intranet running from it).

what method is that “select site (optional)” list populated? Perhaps I can replicate that method and work backwards as to why the site isnt appearing in the list.

Fixed it. I downloaded the github source for the certify.coreservice. Found the GetPrimarySites function and found a section on FTP. My “Default Web Site” does have an FTP binding but the FTP facility is currently stopped. The function is an else and does not consider that there might be multiple bindings. I could edit and recompile the service but instead I simply deleted the binding for the FTP.

Personally I would say the GetPrimarySites needs to flag if ANY of the bindings are active and treat that site as being IsEnabled true, afterall there could be multiple bindings for FTP or HTTP under a single site, if either are started then surely the site should be considered?

I suspect 4.1.6 didnt check for FTP bindings hence why that worked!

Awesome, yes that sounds exactly right, thanks for finding the problem! I’ll get that fixed for the next update.