Blog of Dave

• Setting up OpenSSL
  First we need to get OpenSSL setup on our system, which is not included with the Apache Windows binaries.  In fact the OpenSSL project doesn't even provide the binaries themselves, but you can find them at Shining Light Productions.  For this example, I will be choosing the Win32 OpenSSL v0.9.8k Light version.  If you see a message like the one below, you will need to install the Microsoft Visual C++ 2008 Redistributable Package and then attempt the OpenSSL installation again.
  
   
  
  Once you have it installed, you can do a quick test to make sure that it is set up properly:
  
  
  
  
• Creating Certificates
  Next, we will use the OpenSSL terminal interface to create our self-signed certificates.  To explain a bit about what is going on below, I have a site already existing on my system that can be reached at http://scribble.  What we are doing is creating a secure subdomain of https://secure.scribble.   Typically when I create certificates, I name the files with the host/domain obvious so that they can be easily identified later.  Obviously you will want to replace the domain name to match your setup, but type the following in the terminal in the OpenSSL/bin directory:
  
  

  openssl req -new -out secure.scribble.csr -keyout secure.scribble.pem

  
  
  That will generate what you see below.
  
  
  
  You may notice that I left a lot of the prompts blank.  Considering this is a dummy certificate in a development environment, that approach makes sense.  You may choose to be more explicit based on your needs.
  
  
  If we were to use this key as it is, we would be prompted for the password every time that Apache starts.  Since that is less than ideal, we will now generate a non-protected key from the one we created in the previous step by typing the following:
  
  

  openssl rsa -in secure.scribble.pem -out secure.scribble.key

  
  
  
  
  
  You can see that I was prompted for a pass phrase.  This is the same password that you created when we generated the certificate above.
  
  Now we need to need to build the certificate that we will actually import into Apache.  You can do so by typing:
  
  

  openssl x509 -in secure.scribble.csr -out secure.scribble.cert -req -signkey secure.scribble.key -days 1000

  
  
  This will result in the following output:
  
  
  
  You can see that we now have a .cert, .csr, .key, and .pem file for our domain.  We will use a combination of the .key and the .cert
  
  
• Configuring Apache
  Now we need to make sure that your Apache server is ready to serve SSL requests. 
  
  First, let's put the .key and .cert files that we created above into a directory under Apache.  In your "conf" directory, create a subdirectory named "ssl" and move secure.scribble.key and secure.scribble.cert into that new directory.
  
  Next we need to make sure that the mod_ssl module is enabled.  Open up the httpd.conf file for your Apache webserver.  Search for "mod_ssl" and you should find a line that looks like this:
  
  
  
  Yours will likely be commented out with a '#' sign in front of the line.  You will want to delete that '#' so that it looks like the highlighted line above.
  
  Next you will need to make sure that you have uncommented the line that includes the httpd-ssl.conf file like you see below:
  
  
  
  The last thing we need to do is configure our site.  Open up the conf/extra/httpd-ssl.conf file in an editor.  You will see that there is an amazingly huge and complex site definition in there already that starts with and ends about 150 lines later with .  We need to disable this site.  If you are feeling bold, you can simply delete it.  However, I take the approach of commenting it out entirely so that I still have it as a reference, which is my recommendation as well.   Starting with the line , put a '#' at the start of every line that doesn't already have one and continue until you comment out the line.
  
  Now it is finally time for us to create the site definition for our https://secure.scribble site.  We will use some of the concepts in the example, but eliminate most of them.  Here is what mine looks like after paring down all the excess:
  

  <VirtualHost *:443>
  DocumentRoot "C:/www/scribble"
  ServerName secure.scribble:443
  SSLEngine on
  SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
  SSLCertificateFile conf/ssl/secure.scribble.cert
  SSLCertificateKeyFile conf/ssl/secure.scribble.key
  </VirtualHost>    

  
  
  In that code you can see where we are pointing to the .key and .cert files that we created above. 
  
  Now, restart your Apache server and you are now serving up securely!
  
  

• Running in the cloud - Our production environment will have any number of CF instances, not clustered, but rather running as isolated applications with a load balancer directing the requests using sticky sessions.  Our system will be bringing new instances on/off line as traffic traffic dictates.  I have yet to solve the issue of how to set up my JMS Event Gateway in this environment.  I definitely don't want 20 different listeners out there all doing the same work.  I have considered the idea of having some sort of a support database where a listener can insert a row with a specific JMS message ID and when any other server picks up a message with that ID it will see that it is already being acted upon and it can safely ignore it. There are a couple of negatives that I can see right off the bat.  First is that every single subscribed instance will have to pull in the same message and test to see whether or not it should be acted upon.  It just seems like a little bit of redundancy that shouldn't be there.  Secondly, there is a chance that two servers could pick up the same request within milliseconds of each other and both could end up doing the work.  Duplicate processing could not only be wasteful, but could also create some data integrity issues.
  
  
• Different environments have different settings (dynamic config) - Right now in our development phase, we have a single config file with setting specific to our development JMS server (credentials, domain, URL, Initial Context Factory, etc).  However, soon I will need to have this process support a number of different environments: multiple dev environments, multiple integration environments, multiple QA environments, and eventually production.  Ideally it would be wonderful if I could find some way to load a specific config into the event gateway at server init time, but as of today I have _NO_ idea how to solve this one.  First, there is no real intrinsic indicator at the server level that lets it know what environment is currently running (yet anyway...) and secondly, ColdFusion event gateway architecture isn't conducive in any way to dynamically loading a specific config. 
  

I was playing around with the Quicksilver framework last night, and for some reason it was unable to find and instantiate my CFCs properly.  After digging into the framework a bit and determining where it was breaking, I discovered something strange about the way that ColdFusion interprets ExpandPath() when it exists in a directory that is defined as a symbolic link.  I am not sure if the same behavior exists on Macs, but I would imagine it does.  If someone could confirm that to be the case, I would be interested.

For starters, I usually have a 'www' directory in my user home directory. This way when I pass my user profile around from distro to distro, my development work is included in my home directory.  For ease of configuration I typically have a symbolic link in my OS that points /www/ ---> /home/dshuck/www/.  Then when I am creating a new web project called 'davescode', I would put it in /home/dshuck/www/davescode, but my Apache config would usually point to /www/davescode.  For the past several years, this approach has worked will for me.  That is until last night when experimenting with Quicksilver. 

When Quicksilver loads, it creates a list of service CFCs in the the application in such a way that if I had Foo.cfc in a directory 'com' in the root of my davescode site, it would look like /home/dshuck/www/davescode/com/Foo.cfc.  When I initted the application, I was getting an error that  it couldn't find the CFC home/dshuckcom/Foo.cfc.  Essentially what was happening is that it was getting the full path of the CFC and replacing the path to the root of the site with "".  In a perfect world the value of the path after the string replace would have looked like com/Foo.cfc.  Unfortunately that was not so.  Here's why!

I put a test file called path.cfm in the root of my davescode site that considted of the following:

<cfoutput>#ExpandPath("./")#</cfoutput>
<br/>
<cfoutput>#ExpandPath("/")#</cfoutput>

/home/dshuck/www/davescode/
/www/davescode/