Integrating tools in a proof of concept environment can sometimes be tricky.  Many tools won't accept a self-signed SSL certificate from an external end point ...

During a proof of concept, it is sometimes necessary to have a properly signed certificate rather then the self-signed certificate UCD (now DevOps Deploy) installs itself.  Because it's a PoC many clients don't want to go to the trouble of getting a proper certificate or they can't do so in the time frame of the PoC.  So what do you do in this situation?  Fake it!!

The difference between a self-signed certificate and one that is signed is just another signed certificate.  So to get over this issue we just need to create a certificate that will act as a root Certificate authority and then use that to sign our UCD certificate.

You should not use the techniques outlined in this article outside of a PoC environment as it could leave the environment exposed. Never import a certificate into a trust store that you are not completely sure is legitimate.  Your client will need to give you their certificate bundle so that the JVM that UCD uses can trust the clients certificates.

In most PoC environments this is never a problem beyond the warning in your browser when connecting to the UCD web UI.  But sometimes when integrating with other systems you will come across a problem where the other end wont trust you.

The specific instance for which this was developed was in using UCD HTTP select properties to point at a UCD endpoint.  By this I mean using a UCD REST API to act as the external data source for an HTTP select property.  UCD will not accept an insecure SSL connection as a valid data source; including itself.

Outline of Procedure

• Backup the tomcat.keystore
• Create your own Root Certificate Authority Certificate
• Generate a signing request for the UCD servers certificate
• Sign the request
• Import the signed certificate back into the tomcat.keystore

The example we will work though in this tutorial will show examples for a Linux system but the same principals can be applied to a windows system as well.  The mechanics may however vary.

We will make use of the JVM keytool and openssl tools.  During the examples whenever a password is required I will use 'changeit'  This is also the default password for java key stores.

Step 1 - Make a work area 

Step 2 - Create our Root Certificate Authority

Step 3 - Generate a Signing Request for our UCD Server

Step 4 - Sign the UCD server certificate

Step 5 - Import the signed Certificate

Step 6 - Install keystore and Test

You can import the caroot.cer file into other key stores or trusted certificate stores.  Like importing it into your browser or the keystore of other tools so they also trust your UCD server.  Just remember that this is not a good thing to do outside of a PoC environment. 

A Final Word of Caution:

Once you have your caroot certificate inside a trust or other key store whatever uses those stores will trust anything you sign with that certificate.  Similarly,  don't go downloading root certificates off the internet because the owner of that can then trust anything they like with it and therefore so will you.  Don't forget to delete your fake root CA certificate when you're done.  If you only changed the tomcat.keystore, just replace it with the backup you made.

Alan Murphy
Cloud, DevOps, IT Specialist, Cloud Integration Expert Labs
IBM Cloud and Cognitive Software

 Alan Murphy is a services consultant who has worked with clients to help them adopt new tools and processes for the last 20 years. 
UrbanCode Deploy and DevOps has been his focus for the last 6+ years. 
He also develops tools to assist clients in tool adoption and blogs on an occasional basis.

#UrbanCodeDeploy
#10minutetip