NOV 20 2007

Specifying the trustStore and keyStore properties

Related Categories: Breeze, CPS, Security ColdFusion, JRun,

I've written a topic on enabling SSL and another topic which talks about debugging SSL, but what if you don't want to use the default cacerts or keystore (trustStore) files? Or, what if you have to install a new jvm for DST compliance, but don't want to share certificate stores among Java apps? What if you have a centralized file you want all of your Java apps to use to enable SSL. In these cases you can use the Java system properties to configure these files at runtime.

[More]

Comments (2) | Print | Send | del.icio.us | Digg It! | Linking Blogs
OCT 12 2006

Troubleshooting SQL Server connection

Related Categories: Breeze, ColdFusion, JRun

Here's a checklist for checking connectivity to SQL Server. Replace 1433 in the following steps with the TCP port bound by your SQL Server:

  1. Verify SQL Server configuration:
    • Ensure SQL Server has started. Sounds simple but this is often overlooked.
    • Ensure the TCP protocol is installed on the SQL Server and verify TCP/IP connectivity to it remotely.
      • Ensure firewalls and proxies allow connections on port 1433.
    • Ensure TCP protocol is enabled for SQL Server and verify the listening port(s).
    • Verify the SQL Server instance name(s).
    • Check the SQL Server ERRORLOG to verify the protocols, addresses, and ports to which SQL Server is listening:
      2006-10-12 11:31:18.06 server SQL server listening on 10.7.241.212: 1433.
      2006-10-12 11:31:18.06 server SQL server listening on 192.150.23.103: 1433.
      2006-10-12 11:31:18.06 server SQL server listening on 127.0.0.1: 1433.
      2006-10-12 11:31:19.60 server SQL server listening on TCP, Shared Memory, Named Pipes, Rpc.
    • Ensure installed Service Packs do not break connectivity:

    [More]

    Comments (0) | Print | Send | del.icio.us | Digg It! | Linking Blogs
OCT 12 2006

Errors connecting to SQL Server on TCP 1433

Related Categories: Breeze, ColdFusion, JRun

Some people are having issues connecting to SQL Server on the default TCP port 1433. This is not an issue with Adobe products (Breeze, CF, JRun, etc.). You have to go beyond enabling TCP/IP in the Server Network Utility (2000) or Network Configuration Manager (2005). The first step is to check the SQL Server error log ($sql_root\log\ERRORLOG). It will tell you what protocols SQL Server is listening at startup, and to which IP addresses and ports:

2006-10-12 11:31:18.06 server SQL server listening on 10.7.241.212: 1433.
2006-10-12 11:31:18.06 server SQL server listening on 192.150.23.103: 1433.
2006-10-12 11:31:18.06 server SQL server listening on 127.0.0.1: 1433.
2006-10-12 11:31:19.60 server SQL server listening on TCP, Shared Memory, Named Pipes, Rpc.
2006-10-12 11:31:19.62 server SQL Server is ready for client connections
If your ERRORLOG does not list TCP and you do not see 1433, then its not listening/bound to TCP port 1433.

[More]

Comments (1) | Print | Send | del.icio.us | Digg It! | Linking Blogs
DEC 26 2005

More on Enabling SSL

Related Categories: Breeze, CPS, FlashCom, Security ColdFusion, JRun,

About a month ago I posted my Enabling SSL entry for instructions on importing SSL certificates into Adobe (formerly Macromedia) server software. Last week a colleague had an issue where the customer swore they imported the correct certificate into CFMX, but <cfldap> was not working over SSL. I pointed my colleague to my blog entry and she was able to debug the JVM stack trace and verify the serial numbers and certificate subjects did not match. Not only that, the customer had several certificates from which to choose and the cert subjects all had varying case syntax.

I also had a military customer who had certificates for multiple servers which needed importing into CFMX in order for the servers to properly integrate with each other on their secured network. I had the customer identify two computers to test with and then use the debugging technique to validate the handshake in the JVM stack trace. It turned out there was a descrepancy in the host names used in the certificate and the web site.

My recommendation for both scenarios is to import the signing certificate authority's (CA) certificate into the JVM trust store. When you import the CA cert ensure you specify the -trustcacerts option so that any certificates signed by this CA are trusted. Your certificates should also use a consistent naming scheme -- i.e. same case syntax (usually lower case), alphanumerics, etc.

Comments (0) | Print | Send | del.icio.us | Digg It! | Linking Blogs

More Entries

Welcome to Sarge's personal blog A green acorn

Previous Month September 2010 Next Month

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

Subscribe
Enter your email address to subscribe to this blog.