You would need to use certificates signed by the same CA, on components that communicate with each other.
The BYO means you will generate certificates using a company CA.
So if you use those on Agents, you also need to use them on CTM/Server. (but not necessarily on EM if EM to Server is not over SSL)
If you have SSL enabled for all communication paths so you need certificates signed by the same CA for all components.
EM Client --ssl--> EM Server --ssl--> CTM/Server or CTM for zOS --ssl--> CTM/Agents
If all of these SSL communication paths are enabled so you would need certificates signed by the same CA on all components.
BTW, what do you mean by "control-m native SSL certs"?
Are you using the certificates that come out of the box with Control-M? or something else?
I think you did our original install of Control-M back in 2016. Hope that you are doing well!
When I refer to the control-M native certs, I mean the out of the box ones that are generated by Control-M when you add a new agent or remote host for connection. CCM -> Security -> SSH Keys
In our environment, we have Main Components of Control-M EM: ControlM, Control-M Server: Distributed and Control-M Server: Mainframe. We would like to use the SSL BYO for only the Control-M Server: Distributed and leave the other components as they are. Is that possible?
Or is there an issue since we would have: Server <-> Distributed Agents as well as Server <-> Control-M: Mainframe ?
Thanks for any assistance that you can give.
1 of 1 people found this helpful
I'm doing well. Hope you are too!
I think it may have been my colleague David Kingsley that did the original install, although I may have been involved too. (I'm getting old and 2016 seems like decades ago :-)
The "CCM -> Security -> SSH Keys" is only for Remote Hosts and manages the SSH connection between Control-M/Agent and the Remote Host. It's different to SSL.
The communication paths options are:
Control-M/EM Client --[SSL or TCP]--> Control-M/EM Server --[SSL or TCP]--> Control-M/Server for DS --[SSL or TCP]--> Control-M/Agent --[SSH or WMI]--> Remote Host
And for Mainframe:
Control-M/EM Client --[SSL or TCP]--> Control-M/EM Server --[SSL or TCP]--> Control-M/Server for MF
For your immediate problem of connection from Agent to Remote host over SSH and using SHA1, which doesn't work when the Remote Host has been upgraded to Linux Ubuntu v20.04 that doesn't support SHA1 anymore, the only solution I could find from BMC Knowledge Base is to convert the Remote Hosts to Agents and then you don't rely on SSH anymore to communicate with them.
See KA 000345717 on BMC Support site: https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=kA33n000000YD66CAG&type=Solution
It describes CAR00118299 which details the fact that SHA2* isn't supported by Control-M/Agents SSH to Remote Hosts.
You may want to contact BMC Support to ask if CAR00118299 has been addressed in v19 or v20. (as far as I can tell, at least for v19, it has not been, v20 isn't released yet so not sure about CAR00118299 and v20)
In regards to SSL, if you want to enable that for all or some of the possible communication paths that support SSL, the method to do this depends on the exact version you're on. (v9.0.00.xxx, v9.0.18.xxx or v9.0.19.xxx)
I think it would better to discuss SSL separately in a new thread.
Hope this information is helpful.
You are correct, David did the install and you and I worked through the groundwork before his arrival. I know what you mean about getting old... 2016 seems like decades ago!
I have updated my ticket with BMC to check on CAR00118299. We are currently on 184.108.40.206 and I haven't found anything that indicates the SHA-1 issue has been addressed.
We currently proxy through a Centos 7 agent to the Ubuntu boxes. I didn't think that Control-M had a native Ubuntu agent. Is that still correct?
If I convert the Centos 7 agent to a remote host, will that break my connectivity to the Ubuntu boxes? Or am I misunderstanding the way the agents and remote hosts work together?
Thanks again for your assistance?
2 of 2 people found this helpful
I checked the BMC Compatibility tool (BMC Product Availability and Compatibility ) and found that the following agents support the following Ubuntu versions:
Control-M/Agent v220.127.116.11: supports Ubuntu 16.04 LTS and 14.04.5 LTS
Control-M/Agent v18.104.22.168: supports Ubuntu 18.04 LTS and 16.04 LTS
Ubuntu v20.04 isn't officially supported yet. (maybe Agent v9.0.20 will support it?)
You need at least one Agent in order to have Remote Hosts, so converting the CentOS Agent to a Remote Host isn't advisable or necessary. (this is because all comms to a Remote Host happen via a Control-M/Agent)
If the Ubuntu boxes are v16 or v14, you can install Control-M/Agent 22.214.171.124 on them, then convert the Remote Host definition to an Agent definition (via CCM you delete the Remote Host and re-add the host as a regular Agent, but do this while no jobs are running on the agent), then upgrade the OS to v20. It's not officially supported so you should do a test of this and make sure the agent still work, which it should. (if you try to do a new agent install on Ubuntu v20 it might not allow you to start the install because of the compatibility issue)
Doing this will mean you're running Control-M/Agent on an unsupported OS so has that risk to it. I suggest you ask BMC Support for their advise and maybe they can at least commit to best-effort support because the incompatibility really stems from CAR00118299.
Another option, ask Ubuntu team if there is a way to allow it's SSH Server to work with SHA1 certificates. Maybe they can configure that as an exception on the Ubuntu hosts that you need to run jobs on and then no changes are required from Control-M side and you're not running any unsupported applications. (this configuration on Ubuntu side would be temporary until CAR00118299 is fixed or there is a Control-M/Agent that supports Ubuntu 20.04)
Hope this information helps.
Have a nice weekend with no Control-M thoughts and a happy and healthy 4th of July :-)
That is extremely helpful!!
I am pursuing with support to see if 9.0.20.x will support Ubuntu 20.04 and also checking to see if they are willing to make "best effort" support since CAR00118299 is involved. If 9.0.20.x does support Ubuntu 20.04, we will accelerate our upgrade process. I hate to go to a "dot zero" version, but if it accomplishes what we are striving for without breaking anything else, so be it.
We are also looking at allowing SHA-1 certificates but only for specific hosts. This is our most likely avenue since it would still have 100 percent support if there is an issue.
Thank you again for all of your assistance!!
1 of 1 people found this helpful
Just read in the v20 release notes that Agent v20 supports SHA2 for connecting to Remote Hosts:
The WBL-108327 & WSI-1003 items say: "Remote hosts now support the latest ciphers (SHA-2) via SSH communication".
(it seems CAR00118299 has been re-branded as these two items)
Also, Control-M/Agent v20 is compatible with Control-M/Server and Control-M/EM v9.0.18:
So it looks like to resolve your immediate problem with Remote Hosts on Ubuntu 20.04 you can upgrade the gateway agent that is used to connect to Remote Hosts to v20 and that will solve all these compatibility issues.
Lastly, it seems, based on enhancement CTM-3148, that Ubuntu 20.04 is not yet supported by Control-M/Agent so converting your Remote Hosts to Agents on this OS version is still not a (supported) option.
Armed with your information, I updated both support and sales.
Our plan is to try upgrading our Centos proxy to 126.96.36.199 and attempt the connection. Which should work.
Once 188.8.131.52 comes out, we have been assured that it will support Ubuntu 20.04. At that point, we will remove the proxy and install the agent directly on the 20.04 box.
So our metamorphosis will be as follows:
ControlM (184.108.40.206) => CentOS Proxy (220.127.116.11) => Ubuntu box
ControlM (18.104.22.168) => CentOS Proxy (22.214.171.124) => Ubuntu 20.04
ControlM (126.96.36.199) => Ubuntu 20.04 (agent 188.8.131.52)
I will update this thread as we move through the phases to hopefully help someone else going through the same growing pains.
Thank you again for your invaluable assistance!!