Support,
It is hard to believe that this is the response to your non-self-signed certificate issue:
http://help.octopusdeploy.com/discussions/questions/4244-internal-ca
For such a feature-rich, perfect platform, this is a huge issue. Companies like the one I work for, Rushcard/ UniRush, have to pass high-level PCI scans on our network. Having a self-signed certificate on the machine is a failing grade with the level that we have to pass. After reading all of the responses to this issue, it doesn’t seem like any effort is willing to be put into this problem. I understand “why” you say self-signed certificates are “ok” in most environments but this isn’t even an edge case, in my opinion. A lot of companies will disagree with you and simply not purchase Octopus because of issues like ours.
Is there a deeper reason that you do not plan on supporting custom certificates? Especially with all of the problems that I just went trough trying to procure this platform, it seems like a terrible waste if these type of blocking issues will “never” be resolved, especially out of spite or lack of need from your view, not ours.
With all of that said, I love Octopus and would love to continue using it when I go from company to company, but you will have to listen to the needs of the customers. I look forward to hearing your response.
Thank you,
Ryan Helms
Ryan,
Just out of curiosity, why would this be an issue for you?
Each Tentacle only trusts the Octopus Server you tell it to trust. Vice versa, the Octopus Server will only trust Tentacles that you tell it to trust.
The Tentacles and Servers do have “web services” running on them, but they communicate in the binary format as internally defined by the Octopus development team. Those web endpoints aren’t ones that a customer could access and exchange information with in some meaningful way, not without at least reverse engineering the communication protocol.
Sure, the certificate was generated and signed by the same machine but for you to gain access to the private key to that machine to be able to impersonate it, you’d need to gain some kind of access to the machine. That could be through the file system, physically taking the machine, reading memory via some exploit (like Heartbleed) or otherwise some exploit that allows arbitrary code execution.
At that point, I’d very much argue that you have much bigger problems if someone physically comprised the machine or gained remote access.
As Paul alluded to in his post on Why Octopus uses self-signed certificates, they could check to see if the certificate was actually issued by a valid CA. But, at the end of the day you still want to have each Octopus Server and Tentacle only allowing communication from specific machines.
Help me out here. I truly don’t understand the absolute requirement for having CA issued certificates. I was under the impression that it would only be necessary for customer facing / payment systems.
Hey Mike,
I think the end of your email is the important part, as we are a payment facility (http://www.rushcard.com). I agree with all of the things that you say and agree with why you default to use self-signed certificates. However, when we run our weekly security audits, the octopus self-signed certificate is always the culprit of the failure. What’s worse is, if we fail X consecutive scans, there are possible financial consequences.
This entire issue was brought to my attention by our IT Security / Auditing team, so this is why it ended up a big deal. I was able to help them re-architect the network topology to accommodate the issue, for the time being. It will just have to stay away out of the production environment. We were able to install the tentacle and open the specific port to transfer files and get it to still pass a PCI scan. The endgame would be to be able to keep the server running on production hardware with production monitoring on it.
Does that help?
Thanks!
Ryan,
Just so I don’t get anyone confused, I just want to let you know I am in no way affiliated with Octopus Deploy 
I’m simply an enthusiast and full time user of their software.
I see how having the self signed certs raises red flags in terms of PCI compliance. I was curious as the company I am currently employed at also has to deal with PCI compliance, but the systems that we have the tentacles installed are completely firewalled off from the rest of the systems that actually handle sensitive payment information.
WIth that said, does the polling vs listening tentacle make a difference in your situation? I’m interested the security implications here and how you’re handling it for the time being as it could have an impact over at the company I work for.
On our end, the extent to which we’ve been using it (we’re still running on a 1.6.x release – staging for upgrade to the newer and much better 2.x release!) has been somewhat similar to how you are doing things. One of our more security critical servers has a single port opened up for the Tentacle and it’s firewalled in such a way that only the Octopus Server can initiate and perform communications. Anything coming in from the environment is blocked unless otherwise initiated by the server.
To switch gears a bit: I re-read your post a few times and combed over it to understand it better and am I correct in assuming that the compliance issues you’re running into are caused by tentacles with self signed certificates?
Because if that’s the case, you can actually solve it on the tentacle side by using the certificate import command on the tentacle.
I’ll have to test this out on my lab VM, but it almost certainly sounds like this would solve at least your tentacle side issues. The Octopus Server certificate would still be self signed, but you can do some network engineering to protect that from the rest of your systems.
To jumpstart you, here’s the command for the 2.x tentacle: Tentacle.exe import-certificate --from-file=C:\Path\To\Your\Certificate.cer
Thanks for the healthy discussion on this issue!
Hi Ryan,
Thanks for the kind words about Octopus as well as for the honest feedback. I’m actually open to having our minds changed on this, and Mike’s right - you can import a CA-signed certifiate into Octopus if you need to, and we can provide more details on how to do this. We could make it easier to do, and make it possible to do on the Octopus server too.
As Mark mentioned we do have plenty of customers who operate in PCI compliant environments, including one of the major card providers themselves. Usually once their auditors have been presented with the information on how Octopus/Tentacle works, they’ve be able to pass it (the automated tools are very general in nature). There’s no actual security gain to be had by using a CA for Octopus/Tentacle specifically (Remote Desktop and SSH both use certificates, nearly always self-signed, and neither of those usually impact PCI audits), but I understand that for organization/commercial reasons using a CA might be required anyway.
Paul
Guys,
Thanks for all of the help. Would anyone be able to take 30 minutes to get on a call with myself and our security team for 2 things:
- To explain why the certificates are done the way they are
- To direct us how we can leave the hardware in the production environment but still allow it to pass scans
There will be smart people on both sides of the phone, so it should be fairly quick, concise conversation and Unirush / Rushcard will be very happy with the outcome.
We are available any day except This Thursday and Friday afternoon EST.
I look forward to hearing back, we may be able to come up wit a solution after all!
Thank you,
Ryan
Hi Ryan,
Sorry for the delay - yes, I’d be happy to be on a call. To make scheduling it easy, is there a time here that works for you? https://octopusdeploy.acuityscheduling.com/schedule.php
Paul