Failed to Enumerate SSL bindings?

My deployment keeps failing with the error below. The SSL thumbprint seems to be entered all-right( as it can find the certificate).
I’m running the latest version Any ideas?


Finding SSL certificate with thumbprint 945703656f973eb3dcafe0e002eac0391da22678
Info    17:11:34
Found certificate: CN=*, O=Fonden DIS - Danish Institute For Study Abroad, L=Copenhagen K, C=DK
Error    17:11:34
ForEach-Object : Cannot retrieve the dynamic parameters for the cmdlet. Failed 
Error    17:11:34
to enumerate SSL bindings, error code 234.
Error    17:11:34
At C:\Program Files\Octopus Deploy\Tentacle\Scripts\Octopus.Features.IISWebSite
Error    17:11:34
_BeforePostDeploy.ps1:41 char:72
Error    17:11:34
+ $wsbindings | where-object { $_.protocol -eq "https" } | foreach-object <<<< 
Error    17:11:34
Error    17:11:34
    + CategoryInfo          : InvalidArgument: (:) [ForEach-Object], Parameter 
Error    17:11:34
Error    17:11:34
    + FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.PowerShe 
Error    17:11:34
Fatal    17:11:34
Script 'C:\Program Files\Octopus Deploy\Tentacle\Scripts\Octopus.Features.IISWebSite_BeforePostDeploy.ps1' returned non-zero exit code: 1. Deployment terminated.

Hi Christoffer - we’ve hit this one before, in the original case InstallShield had something to do with the cause, but I’m not sure of the details. There is some information at: - can you please refer to the ticket and see if it rings any bells?


Found the answer here:

I am also running into this problem. It seems to be very inconsistent as to when it occurs. One thing that I did to remove the problem was to disable the “Default Web Site” and also remove all the bindings besides *:80. (I would completely delete Default Web Site but I believe you then can’t add a site via PowerShell) This seemed to fix the problem but after some time I got the same error, we did not use Install Shield so this isnt the culprit. After it failed I manually removed the site and just hit try again on the deploy and it worked. This is our first time using the SSL with OD, and it hasn’t been as smooth as it usually has been with deploys so any information can help

This has just proved too problematic and inconsistent to rely on, shame.

I’ve gone back to having a separate constant “live” installation directory for each environment.

Is anyone looking into this? This makes us not be able to configure SSL sites on the fly because of the inconsistencies. It means we have to rely on manual steps instead of our deployment process handling them for us. Currently for ssl sites we just use the update IIS path instead of the setup iis site.

Hi Brent and James,

If you look at this previous thread:
Could you both see if Alonso’s script would work for you here?
If in the case of it is a success we will consider adding it to the Step Template library.

We are extremely hesitant to do anything to the registry, but if we place nice big warnings that using this step template does that would remove some of our discomfort.

Please let me know how this goes.

We are also running in to this issue on every deploy.

Currently our work-around is to run the powershell script from ( step template ) before every site.

This is very annoying and I don’t think that step templates are practical but should be handled by website steps themselves. Otherwise we’d have to have a step before every website which we have had to do now and it’s very ugly.

Please let us know what the plan is for this?


Hi Dejan,

As it stands now, ‘as a step template’ is our immediate plan for this. As the step updates the registry and makes changes for sites outside of the current deployment we feel it would be risky to make it part of the current step processes. We want those kind of updates and changes to the deployment machines to be conscious and chosen by the users. Sorry if it’s crappy news.



I have also been running into this issue constantly and we needed some manual steps to resolve (I was just simply deleting the site in question before deploy). This was proving to be quite frustrating.

I have since used the script posted via the link above and appears to be working now. Although the issue appeared to happen sporadically so I will be more confident it has worked after numerous deployments. I will report back then.

Hi Gavin,

Thanks for the update, please do update this thread with your findings of the template and it’s consistency.


The issue should be related with registry HKLM\System\Currentcontrolset\services\http\parameters\sslbindinginfo, SSLCertStoreName key. If there are multy items, make sure that the start item have this key. Add the SSLCertStoreName key, or remove the key from all items.
Please use Trace-Command command, such as:
Trace-Command -Name ParameterBinding -Option All -Expression { Get-Item!4466 } -PSHost
Hope this helps.

I encountered a problem with the above script and had to modify it to check if the $_.PSPath was not null first. I haven’t had any issues since. Here is the modified script now:

Function Test-RegistryValue {
[Parameter(Position = 0, Mandatory = $true, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true)]
[Parameter(Position = 1, Mandatory = $true)]

process {
    if (Test-Path $Path) {
        $Key = Get-Item -LiteralPath $Path
        if ($Key.GetValue($Name, $null) -ne $null) {
            if ($PassThru) {
                Get-ItemProperty $Path $Name
            } else {
        } else {
    } else {


Find those entries which are missing the ‘SslCertStoreName’ property:

$brokenBindings = dir HKLM:\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo |
where { !(Test-RegistryValue $_.PSPath SslCertStoreName) }

Output the certificate thumbprint for the broken ones and fix them:

$brokenBindings | % {
if ($.PSPath)
$hashBytes = (Get-ItemProperty -Path $
.PSPath -Name SslCertHash).SslCertHash
$hashString = [BitConverter]::ToString($hashBytes).Replace(’-’, ‘’)
Write-Output ("{0} – {1}" -f $.Name, $hashString)
Set-ItemProperty -Path $
.PSPath -Name SslCertStoreName -Value ‘MY’