HTTPS Requests to Remote Servers Failing in ColdFusion

Yesterday, we noticed that our HTTPS GET requests to a remote secure server had stopped working after a year in service.  A CFDUMP of CFHTTP showed the following:

Charset: [empty string]
ErrorDetail: I/O Exception: peer not authenticated
Filecontent: Connection Failure
Header: [empty string]
Mimetype: Unable to determine MIME type of file.
Responseheader:  [struct]
Statuscode: Connection Failure.  Status code unavailable.
Text: YES


After some Googling, it seemed that the remote server’s SSL certificate was not recognized by our server.  Why all of a sudden and why now? We first thought there was a change in our server, OS, or firewall that was causing it.  The remote server's certificate looked good.  It was issued by Thawte, not a self-signed.  So I asked the remote server admins.  Apparently, Thawte, had changed the way they issued certificates and the new certs were not shipped with ColdFusion or the underlying Java.  After digging around a bit on Thawte,  I ran into this knowledge base article: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=AR1406.  For Coldfusion or Java, read “Installation to a Java Keystore”.   Then follow these steps:

1. Copy the certificates in Step 1 of the knowledge base article and save them (e.g. in c:\ssl)
2. Optional: Back up the folder/coldfusion9/jre/lib/security
3. Open /coldfusion9/jre/lib/security from command prompt
4. Issue the following command to install the first certificate (intca.cer).  Note that keytool.exe is in another folder.

\coldfusion9\runtime\jre\bin\keytool -import -trustcacerts -alias intca -file c:\ssl\intca.cer -keystore cacerts

• It’ll prompt you to “Enter keystore password.”  Enter “changeit” without quotes.  “changeit” is the default password for cacerts
• You may prompted “Trust this certificate?”  Enter “yes”
• You’re done when it says “Certificate was added to keystore”
• Check your keystore file size.  It should have gone up by 1-2 KB (ours went from 67KB to 69KB).

-          Repeat the same process for the other Thawte certificate (crossca.cer):

\coldfusion9\runtime\jre\bin\keytool -import -trustcacerts -alias crossca -file c:\ssl\crossca.cer -keystore cacerts

• Check your keystore file size again.  Ours went up to 70KB.

Finally, restart ColdFusion server: Go to Windows Services and restart “ColdFusion 9 Application Server”

ERwin errors when connecting to Database - Fixed

Just installed my old ERwin program (4.x) on a newer Windows 7 64bit.  When trying to connect to the database, it gave this error message:

"Unable to locate client connectivity software ntwdblib.dll Check with your miscrosoft SQL Server database administrator to install the appropriate client software."

After googling around, I found the fix at http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=97161 (the last post).  Here's how to fix the issue, just in case:

Find c:\windows\systems32\ntwdblib.DLL, possibly in your older 32bit Windows folder.  Copy that to  "c:\program files\CA\AllFusion ERwin Data Modeler" folder.

That's it.  Try to connect again.

iPhone died after taking a picture

My iPhone turned off and wouldn't come back on after I took a couple of pictures.  The battery was around 30%.  Pushed all the buttons and held each one for a few seconds with no luck.  Tried to recharge it and nothing. 

Googled the problem.  The solution was to push and hold both power and home buttons for a few seconds.  And that did the job.

Godaddy SSL certificate and PKIX path problem

This issue got me twice and I should've blogged it the first time for reference.

I installed a Godaddy certificate and everything looked fine on Firefox and IE. But when we tried to make a server-server connection via SSL, the requesting server rejected our SSL cert. Here's a part of the error message on the requesting server:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)

This is what went wrong:

While following the instructions at http://help.godaddy.com/topic/742/article/4875 to install the Godaddy Cert, I originally picked the wrong file.

In section 10 of the first part, it says "Click Browse to locate the certificate file." The Browse button defaults to "*.cer, *.crt", so I chose the .crt file that Godaddy sent us. That was the wrong file, even though the certificate installed and most browsers seemed happy with it.

The correct file:

What the instructions should've said in Step 10 was to select the .p7b or gd_iis_intermediates.p7b file which is the actual intermediate certificate. So I went back and imported the .p7b file and the server-server connection was fine again.

p.s. I also deleted the incorrect record from the previous step. It's was created under Certificates/Intermediate Certificates/Certificates.

Malware on Windows 2003

One of our development server was infected by a few nasty trojan spyware a couple of weeks ago. The malware went totally unnoticed by ESET NOD32. After installing several spyware protection tools that couldn't fully remove the malware, we gave up on that server and rebuilt it. The trojans were actually detected by these programs (see the list below) and removed, but came right back. Since it was on a Windows Server 2003, most PC software couldn't be installed. The following are the ones that were successfully installed and did detect the malware:

- SpyBot Search & Destroy. This one did detect the malware and removed the infections, but couldn't remove the root cause, so the malware was right back.

- MalwareBytes. Same as Spybot, except it doesn't have a resident protection. So you can only run it.

- Spyware sweeper. This one was installed towards the end of the life of that server.

After fighting the trojans for days, the damage was too great to keep the server running. So now we're trying to figure out how to backup the data without getting the trojans backed up.

Ancient City with a Backdrop of the Heavens

Here's a beautiful picture of ancient ruins in Iran with a backdrop of the heavens. Found a smaller version of this beautiful picture at Wikipedia.org with a link to yazd.com where you can find a hi-res picture.

Credits: http://www.yazd.com/images/SaryazdStandingFacadeHR.jpg

VSS to SVN Migration

One of my friends convinced me to migrate to SVN. My biggest doubt was file level permission control, but soon discovered that I could mimic that by implementing permission on branches. So the next step was to convert my VSS databased to SVN. After days of trying different solutions, the one that (almost) worked is described here. Thanks to guys at poweradmin.com and others who enhanced their tool. I had to make a change to get one of tools to work with US date/time values. Checkout the bottom for a list of references.

The following have been tested on Windows XP SP2 with VSS 6. The migrated repository was then moved to Windows 2003 server.

So, here are the steps:
I would do this process on a PC (and not a server) first. Then copy the repository to the destination server.

Install SVN Server:
- If you don't have an SVN server, try VisualSVN.

Create a migration directory structure:
Create a folder structure like this:
C:\TestMigration
C:\TestMigration\Temp
C:\TestMigration\Proj1\VSS_DB
C:\TestMigration\Proj1\Tool

Copy VSS database:
- Before copying, try to check in all files to VSS or as many as you can.
- Making a copy is easy, just copy the VSS directory structure (at the OS level, using Windows Explorer). Copy it to C:\TestMigration\Proj1\VSS_DB.

Clean up the database:
In this step, you want to purge all deleted files from VSS. That may not be necessary, but it helped my migration to go a little faster. You can do one of the following:
- From VSS client, go to each folder, right click and go to properties, select "deleted items" tab, and press purge deleted. This may be time consuming if you're database has a lot of folders.
- You can download an install AxTools VssRecursivePurge (http://www.softpedia.com/get/Programming/Other-Programming-Files/AxTools-VssRecursivePurge.shtml).
- When running AxTools VssRecursivePurge, end the path with \SRCSAFE.INI or it will crash with an confusing message: "The SourceSafe database path {your user name} does not exist. Please select another database."

Analyze and fix VSS database:
Go to command prompt and run this:
C:\Program Files\Microsoft Visual Studio\VSS\win32\ANALYZE.EXE -f -c -d -v1 C:\TestMigration\Proj1\VSS_DB

Upgrade your VSS 6 to the latest version:
- Your PC must have VSS installed.
- Check Help/About of VSS client. It should be version 6.0d
- Or read this: http://support.microsoft.com/kb/153925/EN-US/ which states "to determine if your Visual SourceSafe 6.0 database has been upgraded to the new database format check your Visual SourceSafe data directory for a file named Crcs.dat and a subdirectory named Labels. "

Download the Migration Tool:
- If you are in US and you and 11-01-08 means 'Nov 01 2008' to you, download my revision here. If 11-01-08 means '08 January 2011' to you, Karl's version may work better for you.

Extract the migration tool to C:\TestMigration\Proj1\Tool

Create an SVN user and an SVN repository:
- Create a repository (i.e. TestMigration) . In VisualSVN, right click on "Repositories" and select "Create new repository". Check "Create default structure" and press OK.

- Create an SVN user (e.g. VssMigrate, password abcdefg). In VisualSVN, right click on "Users", select "Create User" and enter user name and password.

Setup the configuration file:
Change the config.ini that comes with the VssMigrate download. Here's the content that matches our folder structure:

[Settings]VSSWIN32=C:\Program Files\Microsoft Visual Studio\VSS\win32 # VSS\Win32 directory which contains ss.exe

VSSDIR=C:\Vss2SVN_Migration\Testing\VSS_DB\ #VSS repository directory (contains srcsafe.ini) . Use environment variable SSDIR to set the current repository (see run.bat below).

VSSPROJ=$/SourceCode #VSS project to start at (ie $/SourceCode). Do NOT use root ($/), but migrate one top folder at a time

VSSUSER="UserName" #This is a VSS user name with full control.
VSSPASSWORD="xxxx" #Use the password for the VSSUSER above

SVNWIN32=C:\Program Files\VisualSVN Server\bin # SVN\bin directory which contains svn.exe

SVNUSER="VssMigrate" #This is an SVN user. All files will be migrated under this user name. Make sure this user is already created in SVN

SVNPASSWORD="xxxxxx" #password of the SVNUSER

SVNURL=http://yourservername:8080/svn/TestMigration/trunk #URL to use for the root of the check in


SVNPROJ=$/SourceCode #Target folder under SVN. This will be created under the SVN URL. It may be best to name it similar to the VSS PROJ

WORKDIR=C:\Vss2SVN_Migration\Temp #Directory under which files and directories will be created as work progresses

DEBUG=1 #turn on debug output, blank is

OKAUTORETRY=0 #if a command fails to run, it will be run automatically 1 time before failing

Create a batch file to run the program:
Create a file in C:\TestMigration\Proj1\Tool and name it run.bat. If you followed the directory structure above, the content of this batch file will be:

set ssdir=C:\TestMigration\Proj1\VSS_DB
VSSMigrate.exe C:\TestMigration\Proj1\Tool \config.ini

Run it!
Go to command prompt and type run.bat to run the program. Depending on your database size, it may take a few hours.

What if it breaks:
If you have to re-run the program, make sure to delete and recreate the SVN repository. Reset your computer time.

Rest the computer date/time:
The migration tool, sets the computer time to the time of each revision. At the end, your computer may end up in a date/time in the past which can cause problems with your virus scan and firewall among others. Reset your computer date/time.