One way to access data from an SQL Server database over the internet is to use an encrypted connection directly to your database. This method is secure and much faster than using traditional ASMX or WCF web services in many cases. In order to set this up successfully, you need to configure your SQL Server to use static ports, purchased and install an SSL certificate on your SQL Server (which is rather interesting to do when SQL Server is running under a least privileged account), configure your firewall/router to do a static port map from your external 443 port to your static port of choice on your SQL Server, then the last step is to make your client applications access the database using a very specific connection string.
There are challenges to getting this working, so be prepared. Some of the biggest challenges come from the fact that you need to request a certificate without a specific element in it from your certificate provider and how you still may need to run a fix utility on the certificate before you can install it in the certificate store, then how you will need to apply the thumbprint of the certificate to your SQL Server instance.
While this blog is a work in progress, I will cover each step that you need to take in order to complete this process in a safe and secure fashion.
1) Configure your SQL Server to use static ports and disable the browser service.
2) Configure your SQL Server to run under a least privileged user.
3) Purchase the correct SSL certificate from your provider excluding the correct element (ANS1).
4) Import the .cer file back in to IIS, run the fix utility on it then export as a .pfx file with the private key.
-certutil -repairstore my “YOUR THUMB PRINT HERE”
-https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1222&nav=0,96
5) Import the .pfx file in to the personal certificate store of the least privileged user that SQL server is running under.
6) Apply the certificate’s thumbprint to the correct instance of SQL Server and restart the instance to make sure the certificate is accepted.
7) Configure your firewall to port map port 443 to your selected internal port (most personal and business firewalls do not block encrypted traffic of port 443 because it simply does not know what it is – this is the work around to the old open port 1433 problem when every ISP blocked this port).
8) Configure your application to use a specific DNS address, instance name and port number. An example of this would be: data.[yourdomainname].com\instancename,443. You can make this work using the .Net data libraries and an ODBC connection if you need MS Access to connect to a database over the internet that does not require a VPN connection.
This process allows you to access your database in a safe and secure fashion, over an encrypted connection, over a port that will not get blocked by an ISP and with the speed that you are accustomed to in a LAN environment.
While this process is great for legacy applications and other desktop applications that you need to connect over the internet without a VPN and still want great performance out of – I still use web services for most of my B2B applications because it affords us more flexibility while dealing with changing business requirements of our vendors and business partners. Please pick your technology with care and make sure it is secure before enabling access to live production data.
I will provide more details on this implementation over time. Challenges that come after this process are; enabling remote applications to work in environment which utilize mirrored databases and building a process by which you can rebuild a database server by way of a few scripts rather than from scratch.
