Step-By-Step: Putting up a SharePoint Foundation Site on the Internet behind a Home Firewall

I had an unexpected visit to the ED last week and my wife fortunately had the presence of mind to bring my “health record binder’” where I keep a hard copy of all my doctor visits and labs and stuff.  But, I have all these stored on a development SharePoint Foundation site on my home network and it would be nice to be able to point clinicians to the searchable web site containing my PHR instead of the paper copies if that happens again.  So I embarked on a process to secure the site using SSL and open it up to the Internet.

The first step of course was to put the medical record under SharePoint.  Using both printed and electronic images of our health record, I scanned or stored them in a Picture Library in SharePoint.  With no special configuration, SharePoint will read the text from the image (using OCR) and then index the content.  Very cool.  Now, my doctor can quickly search for a term or test across all my health records.  But I need to get the content where he can access it from the web.

The next step was to create an internet addressable name.  For this illustration, I’ll use a bogus name that would be a sub-domain of my brucejackson.info domain:  MyMedRecord.BruceJackson.Info.

I use NameCheap as my Domain Registrar because they allow Dynamic DNS which I use to host domains behind a DHCP home Internet connection.  Like most home users, I have a single IP address that can change at any time so I need the dynamic DNS to allow the name to IP maps to be updated when the home IP changes.  To enable my new sub-domain, I went to Namecheap and added the DNS record pointing my new sub-domain name to my current IP address.

With the new domain, I next need to let SharePoint know that this is an alternate name now allowed for the site.

  • Open SharePoint Central Administration and click the “Application Management” link in the left column.
  • In the right column, you should now see a “Web Application” section.  Underneath that heading you will see an option “Configure Alternate Site Mappings”
    image
  • After you click the “Configure Alternate Site Mappings” link, you will see a list of valid URLs.    However, if the “Alternate Access Mapping Collection” is not pointing to the SharePoint site you would like to configure, then click on the “No Selection” drop down and select the appropriate web site.
    image
  • Input the new URL in the Internet text box and then press the Save button.  Once you complete, your list should look something like this:
    image

We next need to add a certificate to the web site so logins will be encrypted.  IIS 7+ has the facility to use a self-signed certificate; however the self-signed certificate created by IIS is mapped to the server name which prevents Host Headers from working.  For example, the server below is named SVR08R2BASE and I’m unable to set the Host Name using the “MyMedRecord” self-signed certificate in IIS Manager.

image
To get around the problem, I created my own self-signed certificate using the MakeCert utility.  On my system, this utility was located in my Visual Studio tools directory, the Windows SDK, and the Fiddler2 folder and is likely available with the “free” version of Visual Studio Express.

Copy over the MakeCert tool to the server hosting the SharePoint site.  For my server, I created a “star” certificate which is a wildcard sub-domain certificate using a command that looks like this:

makecert “c:tempmycert.cer” -a sha1 -n “cn= *.BruceJackson.info” -sr LocalMachine -ss My -pe -len 2048 -r -sky exchange

Once the certificate is successfully created, I go back into IIS and select the SharePoint site from the list of web sites in IIS manager, then select the Bindings, and then add a new binding for https using the certificate I just created.  As you can see from the next screenshot, I can now input the Host Name.

image

One problem with using this “free” self-signed certificate is that the client cannot verify the trust of the issuer (no surprise there).  But, since I would presumably be supplying my own username and password to the attending physician, the only credentials at risk are mine.

The final step was to configure the appropriate Port Mapping at the Internet Router to route the traffic to this server and site.

I probably will not leave the site up all the time since I hope to not need again any time soon.  However, it is nice to know that either my wife or I can launch the virtual machine (this was hosted on a development machine initially as a proof-of-concept) if we need it and our health data is readily available.

Leave a Reply

Your email address will not be published. Required fields are marked *

one + 16 =