Skip navigation

Cloud Lifecycle Mgmt

2 Posts authored by: Manish Bhandekar
Share This:

Logjam: How Diffie-Hellman Fails in Practice describes the vulnerability in the Transport Layer Security (TLS) protocol. This blog provides guidelines to mitigate the risk of this vulnerability in the BMC Cloud Lifecycle Management (CLM) solution.


Who is impacted by this issue?

  1. BMC Cloud Lifecycle Management version 4.5 deployments
    1. Running the web-based GUI over Tomcat or Jetty web server and using HTTPS-based access
    2. Using Tomcat or Jetty, which entertains TLS DHE_EXPORT ciphers
    3. Using 1024 bit Diffie-Hellman groups
  2. BMC Cloud Lifecycle Management version 4.1 or earlier deployments
    1. Running mid-tier using HTTPS.
    2. Refer to Instructions specified in the knowledge article for BMC Remedy AR system and ITSM at


What are the steps required to fix this vulnerability in CLM v4.5?


Step 1. Applicable if the new End User Portal is deployed on Apache Tomcat,

If the customer is using CLM 4.5 and new end user portal is deployed on Tomcat, change the server.xml file to include the ciphers specified in the following code block.Ensure that you specify the allowed ciphers explicitly as shown in the following code snippet and arrange it in a single line:


Step 2. Applicable if the new End User Portal is accessible from a Jetty web-based server embedded in the CLM Platform Manager,

If the customer is using CLM 4.5 and new end user portal is deployed on Jetty, change secure_jetty.xml in cloudjetty-*.jar file by performing the following steps:

  1. Logon to the VM / server where the CLM Platform Manager is installed. Navigate to 'Platform_Manager/lib' folder.
  2. Retain a copy of cloudjetty-*.jar in a different folder for backup.
  3. Extract cloudjetty-*.jar at a temporary location preferably by using the 'jar' tool.
  4. Open the 'etc/secured_jetty.xml' file and locate the 'addConnector' entry with the 'org.eclipse.jetty.server.ssl.SslSelectChannelConnector' class.
  5. Modify the entry to include ciphers mentioned in step 1. Refer to the detailed steps at Jetty/Howto/CipherSuites - Eclipsepedia for information on how to include specific ciphers.
  6. Repackage cloudjetty-*.jar with the latest contents, preferably using 'jar' tool.
  7. Overwrite cloudjetty-*.jar in the 'lib' folder.


Step 3. Generate and configure a 2048-bit server certificate

If the customer has CLM 4.5 and HTTPS is configured for Tomcat or Jetty with a certificate key size less than 2048 bits.

  1. Locate the existing certificate file in Tomcat or Jetty depending on what is configured.
  2. Backup the existing certificate file.
  3. Use the following command to generate a new certificate key,
  4. keytool -importkeystore -srckeystore jetty.pkcs12 \  -srcstoretype PKCS12 -destkeystore keystore -keysize 2048
  5. Replace the existing certificate with the newly generated certificate keeping the file name exactly the same.

Refer to keytool-Key and Certificate Management Tool for more details.

Step 4. Restart the CLM Platform Manager

Ensure that all provisioning or day 2 operations to extend the service are complete before performing following steps:

  1. Stop CLM Platform Manager service.
  2. Delete the 'configuration/org.*' folders in the 'Platform_Manager' folder.
  3. Restart the CLM Platform Manager service.


Step 5. Verify that the vulnerability is fixed

Open command prompt on a server where openssl 1.0.2 or above is installed and issue following commands to ensure vulnerability is fixed.


> openssl s_client -connect host:port -cipher "EDH"
Server public key is 2048 bit

> openssl s_client -connect host:port -cipher "ECDHE"
-- connection should be successful --

> openssl s_client -connect host:port -cipher "EXP"
-- connection should fail --


Update the configurations in other point products shipped with CLM

In addition to these changes, make changes in other point products that integrate with BMC CLM. Refer to The Logjam Attack -- CVE-2015-4000 - BMC for more details.

Share This:

In my previous post Stop services or servers in bulk using Cloud SDK, I shared my experience of using Python SDK.


With CLM v4.5, BMC Cloud Lifecycle Management AWS Client Software Development Kit is also released! Simply put, one can use this SDK as if they were interacting with Amazon Web Service (AWS) infrastructure but in reality it can talk to AWS and non-AWS infrastructure as well.


What's the catch?

The catch is ... using same SDK one can start interacting with non-AWS infrastructure as well. And to add to that, one can leverage other facilities delivered in BMC CLM like trusted cloud, compliance etc.


Case Study

As a case study, let's take AWS Toolkit for Eclipse and see how it can be changed with minimal efforts to manage all servers hosted through BMC CLM.


In a moment I will explain what we did. But before that one disclaimer is - you have to know basics of Amazon AWS SDK. If you don't know, read these articles before - Tutorial: Starting an EC2 Instance - AWS SDK for Java and Run an Amazon EC2 Instance - AWS SDK for Java to know how Amazon AWS SDK works.


So let's get back to what we did,

  1. Downloaded source code from GIT @ aws/aws-toolkit-eclipse · GitHub
  2. Introduced a dummy region, BMC CLM, that would use CLM AWS SDK instead of Amazon AWS SDK. For this we had to modify regions.xml to include following XML block -

        <displayname>BMC CLM</displayname>
          <service name="S3">...</service>
          <service name="CloudFront">...</service>
          <service name="IAM">...</service>
          <service name="SNS">...</service>
          <service name="SQS">...</service>
          <service name="SimpleDB">...</service>
          <service name="EC2">...</service>
          <service name="RDS">...</service>
          <service name="CloudFormation">...</service>
          <service name="ElasticBeanstalk">...</service>
          <service name="GitPush">...</service>
          <service name="ELB">...</service>
          <service name="AutoScaling">...</service>
          <service name="CloudWatch">...</service>
          <service name="DynamoDB">...</service>

  3. Extracted CLM AWS SDK ZIP in lib/clm folder under com.amazonaws.eclipse.core module.
  4. Modified Eclipse project build paths to include all the libraries under 'lib/clm' folder and it's sub-folders.
  5. Modified AWSClientFactory class as shown below -

    public AmazonEC2 getEC2ClientByEndpoint(String endpoint) {
        final String BMCCLM = "bmc-clm";
        if(endpoint == null || endpoint.contains(BMCCLM)) {
                Properties configProps = new Properties();
                configProps.put("PLATFORM_MANAGER_URL", "clmhost:port");
                configProps.put("CLM_USER_ID", "<<clmusername>>");
                configProps.put("CLM_USER_PASSWORD", "<<clmpassword>>");
            return new CLMEC2Client(configProps);
        } else {
            return getOrCreateClient(endpoint, AmazonEC2Client.class);

  6. Build the latest code base.


Well, that's it! We have AWS Toolkit that communicates with BMC CLM if 'BMC CLM' region is selected!


So let's step back a bit and understand what is done.


Let's say user invoked 'Launch' action to launch an EC2 instance. What happens beneath the scene is,


  1. The call hits flow in LaunchWizard class in com.amazonaws.eclipse.ec2 module.
  2. That intern calls launch(...) method in Ec2InstanceLauncher class in same module. That's where all communication logic gets triggered.
  3. All the actual communication happens through com.amazonaws.eclipse.core.
  4. All the other modules refer to regions.xml to show supported regions. That's where BMC CLM region comes in picture.
  5. The call reaches AWSClientFactory.getEC2ClientByEndpoint(...) and URLs are picked up from selected region. That's where we have patched code to route the call to CLMEC2Client instead of AmazonEC2Client. Since CLMEC2Client implements same interface AmazonEC2, no other changes are needed.
  6. Ec2InstanceLauncher later makes call to ec2.runInstances(request) which is nothing but CLMEC2Client.runInstances(...).
  7. CLMEC2Client.runInstances(...) implementation will all necessary steps mentioned @ runInstances - BMC Cloud Lifecycle Management 4.5 - BMC Documentation.


Similarly, if user invokes server list, start server, stop server actions, all the calls will route through BMC CLM.



  1. CLM AWS SDK is much simpler to use. In fact, if you have consumed Amazon AWS SDK for java, there is no/minimal learning curve at all.
  2. CLM AWS SDK implements same interfaces and method signatures, so no practically no code changes are required if you already have a custom portal or application talking to Amazon EC2 infrastructure.
  3. CLM AWS SDK takes care of translating a method call to what all it takes to perform equivalent operation through BMC CLM.
  4. CLM AWS SDK will work for all servers may it be on-premise, AWS, Microsoft Azure, OpenStack etc.
  5. And BTW, did you realize that if you had configured change approval in BMC CLM, all of a sudden the actions done by user will wait for approval before touching the infrastructure? Isn't that awesome? There are many more such features of BMC CLM... not just this one.


How easy can it get?!

Filter Blog

By date:
By tag: