Hi Jose,
Thanks for getting in touch! I understand you have some concerns about how we’ve implemented some aspects of Octopus, but I’ll get started with helping you resolve your Tentacle connection problems.
Resolving Tentacle connection problems
When it comes to exposing a non-standard port over a reverse-proxy, that depends on your proxy server and your specific requirements. Normally we would recommend simply port-forwarding requests for TCP Port 10943 from the public interface to your Octopus Server, and in the case of ISA Server, that’s what I would do.
If you really need to traverse through a reverse-proxy, that should be fine too, but I can’t help with the proxy configuration, but I can help with Octopus.
Which version of Octopus Deploy are you using? We just shipped Octopus 3.4 which adds support for Tentacles to connect to the Octopus Server via HTTP Proxy: http://docs.octopusdeploy.com/display/OD/Proxy+Support
We have written a comprehensive troubleshooting guide for Polling Tentacles and I’d appreciate it if you could go through that and get back in touch if you need further help: http://docs.octopusdeploy.com/display/OD/Troubleshoot+Polling+Tentacles
Tentacle communication concerns
I appreciate you taking the time to share your concerns with us. We haven’t made any of these decisions lightly, and I’ll go to some effort to provide some background.
This article should give you some more insight into the design of the Tentacle - Octopus Server communication: http://docs.octopusdeploy.com/display/OD/Octopus+-+Tentacle+communication
Self-signed certificates
This blog post should explain why we chose self-signed certificates in the first place: https://octopus.com/blog/why-self-signed-certificates
Out of the box we use self-signed certificates as a convenience for customers who don’t have their own PKI, or don’t have the experience to work with PKI, or simply don’t care to manage it themselves. As long as the trust relationship between the Octopus Server and Tentacles are maintained, self-signed or not, that’s OK - all of the benefits of TLS still apply.
If you want to, you can use custom certificates on both sides of the relationship: http://docs.octopusdeploy.com/display/OD/How+to+use+custom+certificates+with+Octopus+Server+and+Tentacle
Client certificate authentication
In the case of Octopus Server - Tentacle authentication - we are just using TLS Client Authentication provided out of the box by .NET which leverages Schannel in Windows servers: https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx
Whilst I can see plenty of usability problems with Client Certificate Authentication schemes, it makes a lot of sense for Client-Server relationships, especially because Octopus owns both sides of the relationship, and can wrangle the certificates on your behalf if you want it to.
Custom TCP Port
We didn’t originally have Polling Tentacles, only Listening Tentacles which listen on TCP Port 10933 by default. The reason for the custom TCP Port is because Tentacle is usually running on a Web Server which is already trying to listen on Port 80 and 443 to host web sites - and it wouldn’t be nice if Tentacle caused web sites to fail due to a binding conflict. This way customers can have control over which TCP Ports they open and bind to and for which reasons.
When Polling Tentacles were introduced, we followed suit and made them listen on a custom TCP Port 10943 by default. Again, people often host their Octopus Server on the same machine as other services, and we wanted to give control to our customers, hence why you can configure the Octopus Web bindings, and the Tentacle port.
Granted it would be convenient if Polling Tentacles could just poll against the same HTTP interface as the standard web traffic for the Web Portal, but this isn’t easily achieved since Tentacle uses TLS but doesn’t implement HTTP - it uses a custom transport called Halibut: https://github.com/OctopusDeploy/Halibut Perhaps in a future version of Octopus Deploy we’ll be able to simplify this further.
Hope that helps!
Mike