Issue with SSL/HTTPS - 503 Error Service Unavailable

I just setup a new Octopus Server as our lab virtualization team wanted to decommission my initial POC Octopus server. I had never implemented a https binding on the old server. I wanted to implement SSL for the new server but I’ve run into an issue.

I have set up port and iplisten entries as well as the urcacl for the ssl binding via netsh and I think that is all working correctly. I am not getting any errors about the SSL binding on startup (once I set up everything correctly via netsh).

If I connect to the admin portal via SSL, it simply gives me a HTTP Error 503. The Service is Unavailable. I’ve reviewed the Octopus log and the event logs and the only error I’m seeing is from when it is going out and checking for updates on the Octopus site.

My platform is Windows Server 2012 Standard with SQL Server 2014 Standard. I had to modify the config by hand to not force SSL in order to be able to browse the admin portal. Otherwise the force to SSL just takes me to the 503 error page. I also turned off the update check as that was throwing a certificate validation error while trying to connect to the Octopus update server.

I have attached a fresh Octopus log from when I start the service. As you can see, there are no errors in the log. I find it curious that my config file shows entries for localhost:80, :80 and :443 but the log shows 2 entries for browsing to http://localhost:80/ and one to browse to http://localhost:443 but there is no mention of the DNS/SSL Cert Common name that I bound it to while setting up the configuration and that is stated in the config file as well.

Any thoughts on what I should do to resolve this issue?


OctopusServer.txt (1 KB)

Hi Jerwin,

Thanks for getting in touch!

When setting up SSL, did you follow our docs page on how to expose the web portal over HTTPS?

Thank you and warm regards,
Hope that helps!



I did not actually set up the https binding for “localhost” since that does not match the name on the certificate or the host’s DNS entry that matches the certificate. Once I changed it explicitly to localhost (as per the instructions) it appears to be working fine.

I have to say I am a little confused by this though. This is the first time I have ever used a product that had me configure a SSL binding for a host name where the host name in configuration did not match the common name of the SSL cert. Is there a particular reason for this design choice?

thanks for helping me solve the problem.


Hi Jim,

When you first setup the bindings for HTTPS for Octopus, did you use the Octopus Server manager to create them? Our demo server binds its HTTPS to the hosts DNS name, not localhost and it is working as expected. Or could it be that there is something intercepting the request to dnshostname and redirecting to localhost on that server?

Thank you and kind regards,


Yes, I used Octopus Server Manager to create the bindings. Your documentation (which I had to follow exactly to get this to work) does not mention using the Dns Host Name to set up the SSL binding. It shows locahost as the host to reference. Once I did that, everything worked (which still don’t quite get). There is nothing that I can see on box that is redirecting the DnsHostName of the SSL cert to localhost on the box.



I just had huge issues installing an Octopus server.

As I do actually not want the server to listen to “localhost”, I always removed this binding and added only “octopus” for http and https. Somehow this didn’t work, I always got the “Service unavailable” error message when browsing the “http://octopus”.
After I added a binding for localhost for both, HTTP and HTTPS I got it working again.

I also executed the following command as I was desperate, but I’m not sure whether it’s needed:

netsh http add iplisten ipaddress=


This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.