October 31, 2018
Installing an SSL Certificate into ColdFusion’s Trust Store
Comments
(7)
October 31, 2018
Installing an SSL Certificate into ColdFusion’s Trust Store
Newbie 49 posts
Followers: 42 people
(7)

Let me preface this post by saying that in no way am I an expert when it comes to Java key stores or certificates.  I’m lucky if I can get Certbot to automatically install a Let’s Encrypt certificate on an Apache website under Ubuntu.  So understand that this post is about my experience as I learned without a lot of assistance.  I’m hoping it may help someone else who ends up struggling with a similar situation.

Background:  I am working on property management software that integrates with the credit company TransUnion to be able to pull credit reports and criminal background checks on prospective tenants.  In order to communicate with TransUnion (TU) they require that I use either system to create, download and install an SSL Certificate on to my web server.  The web server stack is:

  • Ubuntu 16.04
  • SQL Server 2017 (on Ubuntu)
  • ColdFusion 2016, Update 7
  • Apache

TU provided me a .p12 file as the certificate and told me to install it in my web application server to be able to communicate with them securely.  It’s go time.

Author’s note:  Here’s where my ignorance and lack of experience with this sort of thing kicks in.  If I sound very newbie-ish on some of this, bear with me.  We all start learning somewhere, and I warned you this article detailed my learning experience.

So I google: “what is a .p12 file” and learn that the PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key into a single encrypt-able file.  Ok, cool.  That makes sense.  I’ve got a single file with everything I need to install.  Got it.

Next step.  How do I get this certificate installed into my ColdFusion Server?  I found this article on the Adobe Help docs, but it’s painfully out of date for what I need.  It’s referring to JRun, and ColdFusion 8, (despite saying it was last update in January 2017) but I figured there’s sure to be some gems in this article somewhere.  First let’s make some corrections:

  • Since ColdFusion has used Apache Tomcat since ColdFusion 10, anything related to JRun in this article is moot.
  • In a server configuration, the Java Keytool utility is located at cf_root/jre/bin/keytool instead of cf_root/runtime/bin/keytool.

There is some important information in this article though.  Primarily the line that reads, “The certificate must be an X.509 certificate in Distinguished Encoding Rules (DER) format.”  This was important to learn as the .p12 file I had was not in this format.

Researching further, I learned that there are some linux command line tools that would help me convert the certificate into something ColdFusion liked.  First, I used openssl to convert the .p12 file into a .pem file using the following unix command:

openssl pkcs12 -in [filename].p12 -out [filename].pem -nodes

Then I used openssl again to convert the .pem file to a .der format file.

openssl x509 -outform der -in [filename].pem -out [filename].der

Finally, I used the JRE key tool utility to import the certificate into ColdFusion’s Java Keystore.  In the {cf_root}/jre/bin/ folder, I executed the following command:

./keytool -importcert -trustcacerts -alias "myAlias" -file [filename].der -cacerts

The keystone password, by default is “changeit.”  You should, probably, well… change it.  To do this, use the following command:

keytool -keypasswd -alias server -keypass changeit -new newpassword -keystore server.keystore -storepass newpassword

Beautifully, I saw a message reading “Certificate was added to keystore” and I was able to move forward.

7 Comments
2019-10-01 13:11:03
2019-10-01 13:11:03

I’m working in an environment where I do not have root control of the CF Server as it is administered by an IT team in another city.    I’ve discovered connection failure’s throughout the CF administrator logs due to some scheduled processes failing.   I think it’s related to the CFHTTP tag pulling on ssl pages.   I’ve seen this many times at other organizations that I’ve worked for and have updated the cacerts on those servers not always with the desired outcome.   It’s one thing to just install a new cert but how do we test the cert or the jvm to simply find out what we have currently installed so that we can compare it to the current version in use out there?   Any direct instructions or ideas?

Like
(1)
(2)
>
dotcomdguy
's comment
2019-10-14 16:55:48
2019-10-14 16:55:48
>
dotcomdguy
's comment

That’s a great question, and I don’t have an immediate answer to it.  For me there wasn’t any “testing” required since… well… it wasn’t connecting before I installed the cert and it was connecting afterwards.  Sorry I couldn’t be more help.

Like
>
dotcomdguy
's comment
2019-10-14 20:59:33
2019-10-14 20:59:33
>
dotcomdguy
's comment

Guys, see my comment below from July for a different perspective on/alternative to cacert updates.

Like
2019-07-05 13:33:35
2019-07-05 13:33:35

David (and to commenter jBrodeur), be aware of a couple of things.

First, let me offer an important clarification on David’s showing WHERE to put the cert. (I realize he admits to being new to this topic, so I’m just expanding in his post and protecting the unsuspecting.)

As for where to do the import, note that you need to put the cert in the /lib/security/cacerts of wherever cf is naming its jvm to be. It may not be the one cf installed (the cf_root referenced above) , as so many resources show (including from Adobe). If someone has changed cf to use a new jvm, then your cf admin jvm page will show it pointing elsewhere, and you need to import the cert in the /lib/security/cacerts there instead. (And when you may change jvm’s in the future, don’t forget to bring the certs along, if still needed.) That leads to the second point.

Note as well that sometimes a cert import is NOT needed, to fix cfhttp and related problems. You may simply need to update the jvm that cf is using. For more, see my post:

https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/

I realize that in David’s listed situation he seems confident he DID need to import a cert, for a particularly secured site. I’m just noting that for some folks who get errors on https calls out of cf (including perhaps jBrodeur), a cert import is not really what’s needed. Indeed, some folks have been importing certs as they DID move to new jvm’s (see above) when in fact the cert was no longer really needed. 

Hope that’s helpful. Thanks as always, David, for what you do share.

Like
(1)
(1)
>
Charlie Arehart
's comment
2019-07-08 03:11:37
2019-07-08 03:11:37
>
Charlie Arehart
's comment

Excellent additional content Charlie.  Thanks for the input!

 

Like
(1)
2019-07-04 18:54:25
2019-07-04 18:54:25

Thanks for posting David!

I’m encouraged to see you using Ubuntu in your stack for both SQL and Coldfusion.

More to the point, we use cfdocument extensively and we are running into issues with connectivity with graphics across our secure servers and chttp suffers the same connectivity issue in our instance.

So, your post has tweaked my attention.

I suspect we need to import some certificates into the trust to complete our connections successfully.

Like
(1)
>
jBrodeur
's comment
2019-07-04 22:43:23
2019-07-04 22:43:23
>
jBrodeur
's comment

I’m happy it helped!  (Even if it wasn’t directly!)

Like
Add Comment