Lets Encrypt Portal Certificate Binding


Firstly, great to see the new features coming through. Really excited for the LE functionality, one less thing to maintain :slight_smile: Great work

I have raised this before (49147-multi-instance-server-certificate) but we could work around the issue based on the support instructions.

We have a server running two Octopus instances.
When we configure the SSL binding, Octopus always attempts to bind certificates on - so if i configure the SSL cert (using the octopus manager) for {instance 1} it sets the cert. After if I set the SSL cert for {instance 2} it will bind that cert on and overwrite the cert binding for {instance 1}.
The two instances have different IP addresses so I need these certs to bind on the specific IP for the instance.

netsh http show sslcert
IP:port : {instance 1 IP}:443
Cert hash : {instance 1 cert hash}

IP:port :{instance 2 IP}:443
Cert hash : {instance 2 cert hash}

Now that I am using the LE functionality, it will automatically renew and set the binding on my instance 21 days before this certificate expires. Setting it incorrectly on instead of {instance IP}:443
So every time Octopus renews the portal cert it is going to break one of my instances certificate binding.


This also effects sites in IIS that have Https enabled.

Have a *.example.com cert bound in IIS and in Octopus. Turn on the LE integration and the sites bound in IIS will no longer work. as they are now mapped to the cert for Octopus.

This is just a limitation of port binding in windows but might want to be noted on the screen.

Only when you bind on
If you bind on a specific IP and port this is no longer the case. So if I could pass the IP to Octopus when binding the SSL cert it could instead run the command

“netsh.exe” http add sslcert ipport={Instance IP}:443 appid={instance ID} certhash={cert hash} certstorename=My

currently the command it generates and then runs is
"netsh.exe" http add sslcert ipport= appid={instance ID} certhash={cert hash} certstorename=My

Hi Morgan and Dustin,

Thanks for getting in touch and for the feedback on our new Let’s Encrypt support.

Thanks for identifying an issue with our current implementation. I have created an issue that we can use to keep track of this.

Again, thanks for letting us know, it’s feedback like this that helps us build a better product!


Thank you all for contributing.