Skip to main content

Making SBS 2003 Server Play Ball with SSL Certificates

Overview

One of the most common problems with setting up Small Business Server 2003 (SBS2003) is how to make it work without the inherent SSL certificate issues that are created when you setup SBS2003 with the default method of using a self signed certificate. This is an SSL certificate that is not able to authenticate itself against the embedded list of public SSL certificates that every web browser is aware of. These public SSL certificates are sometimes automatically updated on a regular basis or can be manually updated or added to.

What is an SSL certificate? See here for an explanation:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
http://www.google.co.uk/search?sourceid=navclient&ie=UTF-8&rlz=1T4SKPB_enGB203GB203&q=define%3aSSL+Certificate


If the users of your SBS server are limited to your own web browsers and mobile devices it may be possible to manually import the public version of your self signed SSL certificate onto these PC's and devices. This would then allow them to see the self signed SSL certificate on the server as known in the same way as the public ones. However in most cases this kind of on-going administration becomes too difficult due to the expanse of users, mobile devices and web browsers you may wish to on occasion provide access to the internal and external side of your business services.

In undertaking the SSL configuration procedure documented here, we are setting out to achieve these three main objectives:

  1. 1. Provide proper secure access to mobile devices trying to synchronise using ActiveSync over SSL. These include Pocket PC or Windows Mobile 5/6/6.1 devices as well as the Nokia devices like the popular E50/E61/E71/E## etc using Mail for Exchange.

  2. 2. Make Exchange Outlook Web Access (OWA) and SBS Remote Web Workplace (RWW), work without getting certificate errors in the users web browser.

    Note: This can only otherwise be avoided by the need to work out how to merge the self signed SSL certificate which SBS server creates by default with the browser's list of public certificate authorities, which needs to be done for every new PC and user that accesses the external side of the SBS server in a secure way.

  3. 3. Make sure internal use is not affected or compromised.


There are several approaches to this:
  1. The first and easiest is to use an expensive certificate that allows many CN's (Common Names) to be associated with the one certificate. One of these will set you back a lot of money on an on-going yearly basis. Many of the major certificate vendors will provide you with these. Here is a link as to how to do this....

  2. The second and more complex way is to use an inexpensive certificate the cheapest of which I am aware of is to use a GoDaddy SSL certificate. The problem with these cheap certificates is that they can normally only be certified for access from one fully qualified domain name (FQDN) ie. yourservername.yourcompanyname.com but not a range of different addresses which the normal self signed SSL certificate does.



The normal self-signed certificate contains these five different CN (common names) two of which are FQDN's. The are the first one for Internet use and the last for intranet use. The others are short names used on the intranet for various different reasons.

  1. CN = yourservername.yourcompanyname.com

  2. CN = companyweb

  3. CN = yourservername

  4. CN = localhost

  5. CN = yourservername.yourcompanyname.local



In this article I will be focusing on the second and more complex scenario in this document as usually the high on-going cost of using an expensive multiple name certificate cannot be justified by most small businesses. While a little bit of initial effort can usually be justified.

Here are the steps we will go through:
1. Choosing a name for your external server.
2. External DNS configuration.
3. Check your Administrative email address.
4. Buy a new cheap SLL certificate.
5. Download tools.
6. Using the Metabase Explorer to copy the internal 'Default Web Site'
7. Fixing the IP address for the External Web Site.
8. Define new Port Forwarding Rules for the Router.
9. Test the new External Web Site and old Default Web Site.
10. Modifying the 'External Web Site' to make it more suitable for External use
11. On-going maintenance and Backup



Lets Get Started

We need to get our self a cost effective certificate (i.e. cheap single name SSL certificate). But before we can do this we need some information so we need to perform a few steps to get this information.



Choosing a name for your external server.

Make sure that you know the name you want to use for your external server access. Remember this is not usually the name used for your website i.e. it is not usually http://www.youcompanyname.com/

It might be this if you have also decided to host your own web site on your SBS2003 business server. If your are doing this then this is outside the scope of this article (at least for now). Most small businesses (should) host their web site on some external server provided by a hosting company. There are many good reasons for this the most important being security and bandwidth limitations.

Then most small businesses would have a different fully qualified domain name (FQDN) name for the external side of their SBS2003 server. The FQDN name of your server will probably be something along these lines:

yourservername.yourcompanyname.com
rww.yourcompanyname.com
owa.yourcompanyname.com
sbs2003.yourcompanyname.com
remote.yourcompanyname.com


My favorite is the last one for these reasons. Firstly if you use your server name and then you restructure your network as your business changes and grows you may need another certificate sooner than you think (and changes are never good for users or admins). Secondly the others while relevant to a technical person are hard for "normal" users to remember. The last is not!

Users can easily remember that name when they are in the Internet cafe in Bermuda and you don't get that stupid phone call "What is the web address?"

We could now order our SSL certificate but we should also check some other information about how our external domain name and server name is going to point to our server.



External DNS Configuration

You obviously need to know what the actual registered domain name is that your going to use. But you also have to create a DNS host entry for the servers FQDN (Fully Qualified Domain Name) that your going to use. So if you are going to have to do this you will need the external internet IP address that the server can be found on i.e. 66.77.88.199. If your currently browsing within your work environment you can probably use this http://www.whatismyip.com/ to find out what your external IP address is.

Note: This assumes you are using a fixed/static IP address for your internet connection. If you are not you may have to use a dynamic DNS service which is outside the scope of this document. Search for Dynamic DNS on google for more info.

http://www.google.com/search?sa=N&tab=nw&q=Dynamic%20DNS

You will need to create a subdomain, A record or CNAME record in the domain's DNS management tool you have access to. For example:

yourcompanyname.com
A---------remote--------66.77.88.199

If the server is already known with some other A record name then a CNAME record can be used to reference it (this allows the IP to change without having to update many different entries in the DNS). For example:
yourcompanyname.com
A---------servername---66.77.88.199
CNAME--remote--------servername.yourcompanyname.com

DNS (Domain Naming Service) management can be a difficult and confusing task, especially if you don't understand how DNS works or the company with whom you have your domain registered does not have an easy to use DNS management tool. Unfortunately because DNS's are (usually) managed by the companies with whom you register your domain there are as many different tools and techniques to managing them as there are companies. Hence the fine details of how you achieve this should be directed toward that companies customer support and are beyond the scope of this document. The above information is provided as a rough guide to the fundamentals required.



Check your Administrative email address

Now while your managing your domain's DNS to make the above changes, make sure you know that the administrative email address is accurate. This email address will be used by GoDaddy or whoever you choose to use to issue your SSL certificate to send you a domain verification email to make sure you are an authorised admin of the domain.

In theory this method ensures certificates are only issued to the rightful owner of the domain. This helps to prevent fake web sites from being created to capture information from legitimate users.



Buy a new cheap SLL certificate

In this step we are buying the right to create and use a certificate issued by a public provider of certificates to use for a certain limited period. This could be 1 year to 10 years. I typically buy them for 4 years.

I suggest buying one from GoDaddy.com they are cheap and they work. If you go to the site directly you will often not get the best discount. So search Google for SSL certificate and then look for a GoDaddy link usually this will discount the price you pay by a significant 50%.

http://www.google.com/search?hl=en&q=SSL+certificate

At the time of writing you can get one for $14.99 (USA) or about £8 (UK). If you went straight to the web site it would be double that at least. Also usualy when you buy them you don't have to activate them straight away so if you need more than one in the next 6 months then take advantage of the volume discounts they sometimes offer in the checkout.

You will need to follow their or my included instructions for IIS to request and install the SSL certificate. The most important thing when requesting the certificate is to make sure you don't misspell the name of your server when requesting it. Check it, double check it, triple check it then check it again otherwise you will waste time and money. Best method is to setup the dns and then cut and paste the name you use into a ping command to test it before you finalise your SSL certificate request.

Assuming your admin email was correct and all went well you should now have a new SSL certificate. We can now proceed with the process of how to use it properly in SBS 2003.

If we had bought an expensive multiple name SSL certificate we could just change the IIS configuration or even use the SBS 2003 Internet and Email Connection Wizard (IAECW) to reconfigure the server to use it (assuming we supplied all the correct names).

However to avoid the configuration issues of using the cheaper single FQDN SSL certificate we just purchased we need to perform some more complex tasks on the SBS 2003 server to ensure we don't create problems for ousrselves. Most other guides you can find using Google search ignore this problem as though it does not exist and take a very different approach at this point. I am not sure why they do this, porbably in ignorance, as from my experience it screws up your SBS intranet web site.



Configuring the SSL certificate

Before we can proceed further we first need to go to our SBS 2003 server run the IIS6 Administration tool to create a CSR (Certificate Signing Request). The following is a guide to doing this on IIS6 on Windows Servers.



Generating a Certificate Signing Request (CSR) IIS 6.x (>SP1)

Follow the below instructions to generate a CSR for your Web site. When you have completed generating your CSR, cut/copy and paste it into the CSR field on the SSL certificate-request page. Please note that you must have at least Service Pack 1 installed before generating a CSR.

  1. Open the "Administrative Tools menu (right click on "My Computer"; select "Manage" or "Control Panel"; select "Administrative Tools.")

  2. Select "Internet Information Services"

  3. Select the computer and Web site (host) that you wish to secure. Right mouse-click to select Properties.

  4. Click the "Directory Security" tab.

  5. Click the "Server Certificate." button (located in the "Secure communications" area)

  6. Click "Next" in the Welcome to the "Web Server Certificate Wizard" window.

  7. Select "Create a new certificate"; then click "Next."

  8. Select "Prepare the request now, but send it later" and click "Next."

  9. In the "Name and Security Settings" window, fill in the name field for the new certificate; then select the bit length (1,024 or higher). Click Next.

  10. Enter your Distinguished Name field information. The following characters cannot be accepted:
    < > ~ ! @ # $ % ^ * / \ ( ) ?&. 

    This includes commas.


    Distinguished Name Fields:

    • Organization: The name under which your business
      is legally registered. The listed organization must be the legal registrant of the domain name in the certificate request. If you are enrolling as an individual, please enter the certificate requestor's name in the "Organization" field, and the DBA (doing business as) name in the "Organizational Unit" field.

    • Organizational Unit: Optional. Use this field
      to differentiate between divisions within an organization. For example, "Engineering" or "Human Resources." If applicable, you may enter the DBA (doing business as) name in this field.

    • Common Name: The Common Name is the fully-qualified domain name - or URL - for which you plan to use your certificate, e.g., the area of your site you wish customers to connect to using SSL. For example, an SSL certificate issued for "www.yourcompanyname.com" will not be valid for "secure.yourcompanyname.com." If the Web address to be used for SSL is "secure.yourcompanyname.com," ensure that the common name submitted in the CSR is "secure.yourcompanyname.com."
    • Country: The two-letter International Organization for Standardization- (ISO-) format country code for the country in which your organization is legally registered.

    • State/Province: Name of state or province where your organization is located. Please enter the full name. Do not abbreviate.

    • City/Locality: Name of the city in which your organization is registered/located. Please spell out the name of the city. Do not abbreviate.



  11. Enter your Administrator contact information.

  12. Enter a path and file name for the CSR.

  13. Verify the information in the request and click "Next."

  14. On the "Completing the Web Server" screen, click "Finish."

  15. Open the generated CSR file; then, using a plain-text editor, such as Windows Notepad, copy and paste the CSR into our online enrollment form.





Installing the SSL Certitifcate





Download tools.

To do the following tasks we need a special tool to help us.

The one we need is part of the Internet Information Services (IIS) 6.0 Resource Kit Tools.

http://www.microsoft.com/downloads/details.aspx?FamilyId=56FC92EE-A71A-4C73-B628-ADE629C89499&displaylang=en

We need just one utility from this kit called the MetabaseExplorer

MetabaseExplorer (version 1.6 is the one used here) is a tool that provides a graphical user interface for viewing, comparing and editing local and remote metabase stores for Internet Information Services (IIS) 4.0, IIS 5.0, and IIS 6.0. You can also use it to edit security settings for keys, export and import keys and subkeys, copy and paste keys and subkeys, and compare records. The metabase is the repository of information that IIS uses to define how it is configured.

The Metabase Explorer (i.e. Internet Information Services 6.0 Resource Kit Tools) needs to be downloaded and installed on your SBS 2003 server so that we can manipulate the metabase structure of IIS to create a seperate external web site essentially by copying the internal 'Default Web Site' and making some simple modifications.


Using the Metabase Explorer to copy the internal 'Default Web Site'

Now lets explain how to use the Metabase Explorer to copy the internal 'Default Web Site' and making some simple modifications to turn it into the 'External Web Site'.

BLAH BLAH BLAH ...this is the complex detailed part that will take me ages to document.


CAVEAT! Do so at your own risk since it is easy to make mistakes with the Metabase Explorer

Fixing the IP addresses for the External Web Site

Now that we have 2 seperate web sites serving the same web pages (well very similar), we need to change the default configuration of the External Web Site to accept all incoming requests on port 80 (HTTP) and port 443 (HTTPS ie SSL) for its specific IP address. We need to seperate the requests so these two different web sites can now handle them appropriately. The 'Default Web Site' for the internal IP (192.168.100.2 in this example) and the 'External Web Site' for the external IP (192.168.100.100 in this example).

To change the combination of IP addesses, ports and headers that a particular website responds to we noramlly use IIS Admin. This is done by right clicking on the web site title and choosing the 'Properties' option which by default usually opens to the 'Web Site' tab which is where we want to make our changes.

The 'Default Web Site' in SBS 2003 is usually set to (All Unassigned) on TCP port 80 which is to say all except those IP addresses that are not already explicitly defined elsewhere in IIS. Thankfully this can remain this way without any changes as we will just simply define another IP address (192.168.100.100 in this example) to be used for the 'External Web Site'. This is nice and convienient as the ICAEW wizard will be able to simply re-apply these 'default' settings when it is run without adversely affecting either the default internal web site or the newly created 'External Web Site'.

The specific changes required are all done on the new 'External Web Site'. We now need to go into the 'Web Site' tab and change the web site identities used for the external site. Do this by clicking on the 'Advanced' button on the right and then proceed to 'Remove' all the existing entries.

Now we create a new entry and specifically choose the IP address used for the 'External Web Site' (192.168.100.100 in this example). Then type in the 'TCP port' of '80', you should leave the 'Host Header value' empty which implies any host header which is directed (typically through a DNS lookup) to this specific IP address on Port 80 will succeed in displaying the new external web site.

Note: the host header is the string in the web browser URL straight after the http:// and before the next /. for example 'news.google.com' in the URL http://news.google.com/news


There is also another IP address that needs to be considered as it is used by many of the administration tools on the server it is the "localhost" IP which is always 127.0.0.1. This will not normally be a problem so long as you follow this guide explicitly and leave the 'Default Web Site' configuration alone i.e. using (All Unassigned) as its IP address. If you do change this to use a specific IP address then all sorts of problems will start to occur. So this is mentioned here to warn you not to change this thinking you somehow know better.

If you where to change the 'Default Web Site' to use a specific IP address you would have to create a rather complex set of indetities for all aspects of the web site to work properly. These would have to include many different host header values and different ip address combinations.


Define New or Modify Existing Port Forwarding Rules for the Router

We need to now make sure the external HTTP/HTTPS requests that come into our site (i.e. where the SBS 2003 server is located) from the web can make their way to the correct 'External Web Site' on the SBS 2003 server. Well part of this has been done by adding a different internal IP address to the server network card properties explicitly for use by the 'External Web Site'. The other part of the puzzle relies on the router (a Netgear one in this case configured to use the internal address 192.168.100.1) in the network to redirect all traffic coming in on the external IP address for port 80 (HTTP) and port 443 (HHTPS) to the new internal IP address of the server on the same ports. This is done by creating two new port forwarding rules in the inbound security section or modifying the existing ones already defined for HTTP and HTTPS access.

In our example these rules would look something like this:
HTTP (port 80) -> redirect to -> 192.168.100.100 (port 80)
HTTPS (port 443) -> redirect to -> 192.168.100.100 (port 443)

They would be added or modified on the router usually using a web administration tool in from your internal browser by pointing it to the default gateway url (i.e. http://192.168.100.1/ in this example)


Test the External Web Site and make sure the internal Default Web Site is also working

Now that we have all the configuration done we need to thoroughly test both the 'External Web Site' and the internal 'Default Web Site'.

To be absolutley clear we should now esentially have two web sites running on SBS 2003 server hosted by IIS. One 'Default Web Site' remains pretty much untouched but is now restricted to internal access and the second is the 'External Web Site' which is effectively a slightly modified clone of the 'Default Web Site', this is accessed only from the outside. The sepeartion of these two allows IIS to use two different certificates for accessing them. The self signed SSL certificate that is created during the SBS 2003 server install or through the IAECW wizard remains intact for use internally. While the new single name GoDaddy certificate can be used to secure the external SSL sessions with a web browser (for RWW, OWA), mobile device (ActiveSync) or remote device (RPC-over-HTTP email, VPN).

Before running these tests you should probably restart the SBS 2003 server. Or at least restart IIS. Open a CMD prompt and type at the c:\> prompt


iisreset /noforce


Test from internal (i.e. intranet)

Open the SBS 2003 Server Management Interface and make sure the following pages open properly.

Standard Management->Monitoring and Reporting
Standard Management->Backup
Standard Management->Update Services (if your have SBS 2003 R2)
Advancement management->[YourServerName](Exchange)->Administrative Groups->first adminsitrative group->Folders->Public Folders

All these internal tools rely on different parts of the internal 'Default Web Site' and if they work OK without errors then it has not been affected by your changes. If they all don't work then probably you have made a mistake somewhere and you should review the process. If some work and others don't then you probably have some other problem with the ones that don't.


Test from external (i.e. internet/extranet)
Now test the 'External Web Site', to do this use a web browser and type in the URL for you external FQDN (the one you used to create the certificate). In our example this would be:
http://remote.yourcompanyname.com/
If the external site is working OK (remember DNS chnages may take up to 72 hours to propogate throughout the Internet) then you should see the external web site.

At this point in our configuration the internal and external web sites are actually identical they are just using different SSL certificates when accessed fromt he two different sides of the network. Thus we have now achieved what we set out to do. Which was to allow external access with a publicly recognised SSL certificate and not change the way the internal access works. In the next section we will make some simple modifications that enhance the benefits of this configuration.



Modifying the 'External Web Site' to make it more suitable

One of the side benefits of this procedure is you can essentially have two different web sites. We don't really want to make lots of changes but a few small ones will make using the external SBS 2003 web site more appropriate to you and any of your employees/users/partners/clients.

The most basic change is to copy the default.htm file in the Default Web Site root directory (C:\Inetpub\wwwroot) and rename it to index.htm then in the configuration for the external web site (Properties->Documents->Enable default content page) you can change the content page order to have it first open the index.htm while the default internal site will default to first open the default.htm file. In this way you can have two different opening pages for each section of the same web site (i.e. same IIS file directories) if you want.

Once you have renamed a copy of the default.htm file to index.htm open it with either a text editor such as Notepad.exe or perhaps a HTML editor such as Microsoft Frontpage and edit the HTML to:


1. Remove the un-required "Join a client computer to SBS network" option from the tabled list of options. Delete these lines from the html code in the page:

<tr>
<td width="30"></td>
<td class="linkText" id="ClientSetup_Desc">Join a client computer to the Windows Small Business Server network.</td>
</tr>
<tr>
<td width="30"></td>
<td></td>
</tr>


2. Change the page title in these two places to indicate it is the External Web Site in some way:

</style>
<title>Welcome to Windows Small Business Server 2003</title>
<body>

...

<table id="Table4" cellspacing="0" cellpadding="5" width="100%" border="0"></table>
<tbody>
<tr>
<td width="20"></td>
<td class="welcomeHeader" id="WelcomeText2">Welcome to Windows Small Business Server 2003</td>
</tr>



I would change them both to something like "Welcome to the [CompanyName] external web site for remote access".

3. Fix the Internal sharepoint server web site link for external access:

<table id="Table3" cellspacing="5" cellpadding="0" width="100%" border="0"></table><tbody>
<tr>
<td width="30"></td>
<td valign="center" align="middle" width="45" rowspan="2"><a href="http://companyweb">My Company's Internal Web Site</a></td>
</tr>


The HREF needs to be as per our example https://remote.yourcompanyname.com:444/
Please note: The use of HTTPS and not HTTP in the URL. The URL also includes the additonal port definition of ":444" which needs to be included to allow the browser to find the internal web site on the server.

I would also change the text to replace "My Company's" with your actual company name. Save the changes to the index.htm and refresh your external web site to enjoy.


On-going maintenance and Backup

Please remember this is just a simple guide your are pretty much free to make any level of changes that you like. Just remember that if you do a re-install without a proper backup of this information you will have to re-construct the modifications you do now, again later. So please make suitable notes and backups to be able to reinstate the changes in a recovery procedure.

Due to the way we have configured the 'External Web Site' it really just points to most of the internal workings of the 'Default Web Site', so you should not have much (if any) administration overhead associated with this modification. Also you should not have it corrupted by the IAECW configuration wizard. To avoid any chance of corruption you should save a backup copy of the new IIS Metabase branch using the Metabase Explorer tool so that you have something to refer to should you somehow corrupt it later or need to do a server rebuild at some point.



References

http://www.godaddy.com/gdshop/compare/gdcompare_ssl.asp?isc=sslxuk200&currencytype=GBP

Comments

Popular posts from this blog

Thin Mini-ITX Motherboard Overview [Updated APR 2022]

THIN MINI-ITX Primarily the Thin Mini-ITX form-factor and its motherboards are targeted at the business-oriented All-in-One (AIO) market but are also used in embedded systems, digital signage and the like.  They typically have LVD/eDP/LCD panel drivers built-in also and have slightly higher pricing because of this and other embedded features such as a single DC power supply input (which facilitates a smaller case). BACKGROUND The Intel Q series motherboard chipsets support the Intel vPro/AMT remote management with KVM over IP (or iKVM) functionality built into the CPU/chipset combination.  This is very convenient for administrators.  For example, with the correct configuration, you can watch a full reboot and manage the BIOS, install a new OS all remotely. http://www.wikiwand.com/en/Intel_Active_Management_Technology CASE Typically Thin Mini-ITX cases are smaller based on the thinness of the motherboard, its low profile components and the requirement to use an external power supp

Removing the WLAN / WiFi pcie card whitelist on Lenovo IdeaPad u410 Touch with BIOS update

WARNING! PLEASE READ THE ENTIRE POST BEFORE USING / DOING ANYTHING! BACKGROUND I recently (early 2016) acquired a 2013 Lenovo IdeaPad u410 Touch. It was not my first choice but still useful but I wanted to upgrade it to more recent tech and make it more usable as it is not the fastest CPU around, i.e. an i5-3337U dual core (quad thread) at 1.8GHz. http://ark.intel.com/products/72055/Intel-Core-i5-3337U-Processor-3M-Cache-up-to-2_70-GHz First thing I did was upgrade the BIOS to latest (as anyone would/should do really) version 65CN99WW (8/28/2014) available here: http://support.lenovo.com/au/en/products/laptops-and-netbooks/ideapad-u-series-laptops/ideapad-u410?beta=false I then added 2 x Kingston SO-DIMM KVR16LS11/8 1.35V (Low Voltage) 8G DDR3 1600 Notebook Ram SODIMM's despite the specs I could find all saying it would only take 8GB and it works fine with the 16GB as the Intel i5-3337U CPU (says 32GB) & Mobile Intel HM77 Express Chipset specifications suggest. 

Setting up the HOOK mechanism in libvirt for KVM/QEMU to manage customized networking requirements

This post is a belated follow-up to a post I did 3 years ago about configuring Linux KVM networking to use IP forwarding when IP spoofing is disallowed by your dedicated Linux server provider.  Such as 1and1 in my case. For further context and reference please refer to the original post here: http://roddines.blogspot.com/2014/09/how-to-configure-dedicated-server.html Refer to: https://www.libvirt.org/hooks.html A small bash script file that can be used to test the more complex hook script below #!/bin/bash # Location/File: ~/fixnet #Quick Fix IP Tables echo 'default' is usually 'virbr0' and this is assumed! sudo /etc/libvirt/hooks/network default started end Content of the bash script file located at /etc/ libvirt /hooks/network #!/bin/bash # Location/File: /etc/libvirt/hooks/network # Sep2014 Created by Rod Dines rod<at>roddines.com # Feb2016 edited by Rod Dines to refine scripting # July2017 edited by Rod Dines to setup for new server IPs