I just tested this and it works for me so it is some issue in environment.
This error means there is some communications issue between scServer and OnCommand.
Did you try "telnet dfmServer 8488"? Does that go through.
Additionally if this is a linux scServer there could be some issues with your ssl libs, SC will link to SSL libs on OS so if they aren't named correctly that can cause issue. It is simple problem to fix you just create symlinks.
Here is info from BURT 499567:
HTTPS may not work on linux out-of-the-box. This appears to mainly be issue with SuSe but really could apply to any Unix. Snap Creator does not include ssl libraries we are dependent on, therefore customer must install openssl and ensure symlinks are created correctly (see below). The reason is simply we dynamically link so customers can update SSL versions of openssl for important security fixes without being dependent on SC versions.
The requirements for HTTPS for Linux/Unix are as follows:
1) openssl package
2) SSL symlinks
Make sure the following symlinks are located under /usr/lib oder /usr/lib64 (depending on if OS is 64bit or not)
If the symlinks dont exist please cd to /usr/lib or /usr/lib64 and run following command to link them. Make sure what we are linking to is installed, again pre-requisite is openssl so it should be installed first.
ln -sf libssl.so.0.9.8 libssl.so.6
ln -sf libcrypto.so.0.9.8 libcrypto.so.6
If this doesn't work run strace and send to engineering:
The only thing I can think of is some issue between scServer and dfm server, maybe hostname resolution, maybe ACL but if you can telnet to port and get connection then most likely that stuff is working.
Another idea is maybe you dont have TRANSPORT=HTTPS set in config? Although if that was case I would expect a different error. This error usually indicated hostname resolution.
You could try installing SC on DFM server see if that works, that would tell you if problem is between host and DFM server at least.
SC will use either HTTP or HTTPS to communicate with both storage systems and DFM.
If TRANSPORT is set to HTTP it means you must also use HTTP to communicate with DFM.
This is the reason it isn't working. If you switched to TRANSPORT=HTTPS and PORT used for filer to 443 it would work. Problem is a vfiler can only talk over HTTP, so option is live with HTTP or communicate with physical filer then you can do HTTPS.