This action might not be possible to undo. Are you sure you want to continue?
By default, web browsing is being performed by use of the HTTP protocol, i.e. a connection between the client computer (using a web browser) to the web server (using IIS, Apache or any other sort of web server program). HTTP relies on TCP (Transmition Control Protocol) and uses port 80 on the listening server. The main security issue with HTTP is the fact that all the traffic between the client and the server is done as clear text, meaning that anyone could potentially "listen" to your talk and grab frames and valuable information from the net. To secure the transmission of information between your web server running IIS 6.0 on Windows Server 2003 and your browser clients, you can encrypt the information being transmitted by using SSL (Secure Sockets Layer). Note: The procedure for applying SSL on IIS 5.0 (on Windows 2000) and IIS 5.1 (on Windows XP) is quite the same. In order to successfully use SSL you need to obtain a Server Certificate. In this article I will only focus on obtaining a certificate from a local CA or importing an already existing certificate. However, it is possible (and in many cases preferred) that you obtain the Server Certificate from a trusted 3rd party CA such as Verisign or Thawte.
To configure SSL for your website on IIS 6.0 (running on Windows Server 2003) complete the following steps: Note: Although the screenshots are made with IIS 6.0 on Windows Server 2003, the same procedure applies for IIS 5.0 and IIS 5.1.
1. Click Start, point to All Programs, point to Administrative Tools, and then click
Internet Information Services (IIS) Manager.
2. In Internet Services Manager, in the console tree, expand SERVERNAME (your 3.
local computer), and then expand Web Sites. In the console tree, right-click Default Web Site, and then click Properties.
Note: It's possible that the site you've created was stored under a different virtual server. If your website is not stored within the Default Web Site, right-click your own web site and click Properties.
4. In the Default Web Site Properties dialog box, click Directory Security.
5. On the Directory Security tab, click Server Certificate. 6. In the Welcome to the Web Server Certificate Wizard, on the Welcome page,
7. On the Server Certificate page, verify that Create a new certificate is selected,
and then click Next.
Note: You can also import an already existing certificate. Do do so follow these steps:
1. Click Import a certificate from a .pfx file. Click Next.
1. In the Import Certificate path enter the path to where you've stored your existing certificate. Click
1. Enter the password configured for the .pfx file. Click Next.
4. Go to step #13. 5. On the Delayed or Immediate Request page, click Send the request
immediately to an online certification authority, and then click Next.
Note: If you don't have a Certificate Authority (CA) installed on your server or on a different server on the network you can prepare the request but you'll need to manually send it to the CA.
9. On the Name and Security Settings page, in the Name box, type
yourservername.domainname.com (or .net, .org, .mil etc. Use your own registered domain name, the one you want people to use when browsing to your site) and then click Next.
Note: You will need a different certificate for each website you'll run on this server, so make sure you provide the exact server URL. Important note - Internet use: You must make sure that either the Name or the Common Name fields (one of them or both of them) exactly match the external FQDN of the website. For example, if your server's NetBIOS name is SERVER1, and it is located in the MYINTERNALDOM.LOCAL domain, but it will host a website that will require users to enter WWW.KUKU.CO.IL to reach it, you must then use WWW.KUKU.CO.IL as the Name or Common Name in the certificate request wizard, and DO NOT use SERVER1.MYINTERNALDOM.LOCAL. Important note - Intranet use: For Intranet-only purposes you CAN use the internal FQDN of the server, or even just it's NetBIOS name. For example, if your server's NetBIOS name is SERVER1, and it is located in the MYINTERNALDOM.LOCAL domain, you can use SERVER1.MYINTERNALDOM.LOCAL or just SERVER1 for the Name or the Common Name fields. You can also change the Bit Length for the encryption key if you want.
10. On the Organization Information page, in the Organization box, type your own
company name. In the Organizational Unit box, type a descriptive name and then click Next.
9. On the Your Sites Common Name page, in the Common name box, type
yourservername.domainname.com (see important note in step #9) and then click Next.
9. On the Geographical Information page, in the State/province box, type the
required info and then click Next.
13. On the SSL Port page, in the SSL port this web site should use box, verify that
443 is specified, and then click Next.
Note: SSL can only listen once on port 443, requiring you to either select a different SSL port for each SSL protected website you're about to host on the server, or, even better, use a different static IP for each site, and share port 443 amongst them.
9. On the Choose a Certification Authority page, in the Certification Authorities
box, verify that your online CA is selected, and then click Next.
9. On the Certificate Request Submission page, click Next to submit the request,
and then click Finish to complete the wizard.
To use the certificate to secure the web site that is using SSL
1. In the Default Web Site Properties dialog box, on the Directory Security tab,
in the Secure communications area, click Edit.
Note: It's possible that the site you've created was stored under a different virtual server. If your website is not stored within the Default Web Site, right-click your own web site and click Properties. Note: It's also possible that you might not wish to protect the entire website, but merely one or two pages within the large website. In fact, this scenario is highly probable for most site operators that would only like to protect a couple or important pages, such as an online store or registration form. In that case you do NOT need to SSL-protect the entire site, so do NOT right-click the entire site. Right-click only the directory or pages within the site.
2. In the Secure Communications dialog box, click the Require secure channel
(SSL) check box, click the Require 128-bit encryption check box, and then click OK.
Note: Using a requirement of 128-bit encryption should pose no problem to current operation systems and web browsers, but keep in mind that older OSs might not be able to connect to your site.
3. On the Directory Security tab, in the Authentication and access control area, 4. 5.
click Edit. In the Authentication Methods dialog box, click Basic authentication (password is sent in clear text), and then click Yes to acknowledge the warning. Clear the Integrated Windows Authentication and Enable Anonymous Access check boxes, and then click OK.
Note: You are NOT required to disable anonymous access, this is just a security measure. It might be likely that your site is supposed to allow anonymous access, while still using SSL as the encryption method. This is true for websites that offer online shopping carts where surfers are supposed to enter their credit card numbers. You might not want to restrict these online shops only for people that hold a username and password. In that case keep the Enable Anonymous Access check boxes selected.
3. In the Default Web site Properties dialog box, click OK. 4. In all Inheritance Overrides dialog boxes, click OK.
8. Close Internet Information Services (IIS) Manager.
Verify that SSL is working
To test your new settings connect your open a browser and type your server's FQDN (or NetBIOS name, if on the LAN) in the address bar (for example: http://server200 for your Intranet, or http://www.kuku.co.il for the Internet). Note: Make sure you've followed the important note in step #9 above. Since you still used HTTP (plain text http, using TCP port 80) you'll get the following error message:
Now re-type the URL by using HTTPS instead of HTTP. You should be able to view the OWA website. You'll receive a Security Alert window. Click Ok.
If configured correctly, you should be able to connect to your now SSL-protected website.
To verify that you're using SSL try to find a small yellow lock icon on the browser lower right corner . Double click the lock icon.
A Certificate window will open. Review the information that is entered into the certificate and click Ok.
Note: Make sure you renew your certificate a few weeks before it expires in order to prevent mishaps like this one: Expired SSL Website Certificate.
The RPC virtual directory is now configured to use basic authentication. As stated in the Recommendations section of this article, you must configure SSL on your RPC Proxy server (i.e. on your single server). To enable SSL on the RPC virtual directory you must obtain and publish a certificate. Follow the guidelines on the Configure SSL on Your Website with IIS article for more info on this issue (This procedure assumes that you have obtained and published certificate). After setting up a Digital Certificate for the Default Website you will need to configure the RPC virtual directory to require SSL for all client-side connections. To configure the RPC virtual directory to require SSL for all client-side connections, follow these steps:
1. In Internet Information Services (IIS) Manager expand Web Sites, expand Default Web Site,
right-click Rpc, and then click Properties.
2. Click the Directory Security tab, and then click Edit under Secure communications.
3. Click to select the Require secure channel (SSL) check box and the Require 128-bit
encryption check box.
4. Click OK, click Apply, and then click Ok.
Configure the RPC proxy server to use specific ports
After you configure the RPC over HTTP networking component for Internet Information Services, configure the RPC proxy server. Configure the RPC proxy server to use specific ports to communicate with the directory service and with the information store on the Exchange computer.
Warning! This document contains instructions for editing the registry. If you make any error while editing the registry, you can potentially cause Windows to fail or be unable to boot, requiring you to reinstall Windows. Edit the registry at your own risk. Always back up the registry before making any changes. If you do not feel comfortable editing the registry, do not attempt these instructions. Instead, seek the help of a trained computer specialist. Tip: Instead of manually editing the registry, reader Harry Bates has most cleverly designed a small utility that will allow you to perform all these changes by pressing a couple of buttons. The tool is called RPCNoFrontEnd (19kb).
Run the tool on your Exchange server, input the server's names and you're done! Thanks Harry! If you've used the above tool you no longer need to perform any manual registry changes and you can safely skip the rest of this guide till the Global Catalog configuration section below. However, if you're still interested to know what's going on for your information, here are the required changes and information:
No action required - for your information only!
When you run Exchange Server 2003 Setup, Exchange is configured to use the ports in the following table: Server Port Service Store DSReferral DSProxy
Exchange Server (Global 6001 Catalog) 6002 6004
The three registry values that follow are automatically configured by Exchange Server 2003 Setup. Although you do not have to configure these registry values, you might want to verify that these registry values are configured correctly.
Do NOT modify these registry values. Just make sure they exist.
Action required - configure the RPC proxy server to use specific ports
To configure the RPC proxy server to use specific ports, follow these steps. 1. 2. On the RPC proxy server (i.e. your Exchange server - this is a single server scenario), start Registry Editor. Locate and then click the following registry subkey:
3. In the right pane, right-click ValidPorts, and then click Modify.
Note: The default value for the ValidPorts key is:
Where ServerNetBIOSName is the NetBIOS name of your server. 4. Remove all the information from the Value data box, and then type the following information:
Replace ServerNetBIOSName with the NetBIOS name of your server. Replace ServerFQDN with the fully qualified domain name (FQDN) of your server. Note: The above text is ONE LONG LINE. Copy and paste it into Notepad, and edit it there. Once done, copy it from Notepad and enter it in the Registry editor. Note: This is the part where most administrators fail. Take a look at the following table and enter the correct values based upon this example: Role Windows Server 2003 SP1 + Exchange 2003 SP1 + DC, FSMO, GC + RPC Proxy NetBIOS name: zeus (this is just an example, the name is bogus) (this is just an example, the name is bogus) Names FQDN - Internal: zeus.dpetri.net FQDN - External: mail.dpetri.net
Note: In the above table I've used the same domain name internally as externally (dpetri.net). This is NOT a best practice, as one SHOULD keep these two domain names separate, mostly for security and DNS issues. For example, if I would have to re-write this guide, I'd probably use dpetri.local for the internal domain name, and dpetri.net externally.
Text to enter in the registry:
Note: Some guides and articles instruct you to also add the external FQDN of the RPC Proxy, i.e. the FQDN used to access the server from the Internet. For example, in the above scenario, you should use:
I've experimented with both settings, both work. To be on the safe side I'd recommend using the longer version. 5. Click OK, and then quit Registry Editor.
Note: You can also use the Rpccfg tool to set and to troubleshoot port assignments. The Rpccfg tool is included in the Windows Server 2003 Resource Kit tools (Download Windows 2003 Reskit Tools):
Configure all your global catalogs to use specific ports for RPC over HTTP for directory services
Exchange Server 2003 Service Pack 1 note: Exchange Server 2003 Service Pack 1 has a new builtin RPC over HTTP/S GUI setting on the Exchange Server properties page in Exchange System Manager. If you configure the RPC over HTTP/S option from the GUI, there is NOT need to make any manual changes in the Registry. To make the changes via the GUI follow these steps:
1. Click Start, point to Microsoft Exchange, and then click System Manager.
Expand your organization, expand Administrative Groups > First Administrative Group > Servers. Right-click on your server name and select Properties. On the General tab, verify that you have SP1 installed. Verify that a tab called RPC-HTTP is present.
5. On the RPC-HTTP tab, click on RPC-HTTP Back-End Server.
You might get an error:
Exchange System Manager There is no RPC-HTTP front-end in your Exchange organization. There must be at least one RPCHTTP front-end server in the organization before the RPC-HTTP back-end server can be accessed. Acknowledge the error.
6. Click Ok all the way out.
7. You need to reboot your server for the settings to take place. If you did not install Exchange Server 2003 SP1, or if you did not configure the RPC over HTTP/S option from the GUI, then you MUST manually perform the changes in the Registry. To do this, follow these steps: 1. 2. Start Registry Editor. Locate and then click the following registry subkey:
On the Edit menu, point to New, and then click Multi-String Value. Note Make sure that you select the correct value type for the registry subkey. If the registry subkey type is set to anything other than Multi-String Value, you may experience problems.
3. Name the new registry value NSPI interface protocol sequences. 4. Right-click NSPI interface protocol sequences, and then click Modify.
5. In the Value data box, type
and then click OK. 6. Quit Registry Editor, and then restart the computer.
Configure the Outlook 2003 computer to use RPC over HTTP/S
You must now configure a client computer that meets the requirements specified at the beginning of this article to use RPC over HTTP/S. Follow the instructions found in the Configure Outlook 2003 to use RPC over HTTP/S article.
Test the RPC over HTTP/S connection
Next, the natural step is to test your configuration. Testing can be done on the LAN or on the WAN. Follow the instructions found in the Testing RPC over HTTP/S Connection article.
If a successful connection is made then you can start deploy
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.