Learning the Basics of Citrix XenApp 5 for Windows Server 2003 and XenServer 5.5 (Part 10 of 10)
In Part 9 of this 10-part series, you learned to allow external access to the published applications using the AltAddr method. In the final part of this series, you will learn how to:
- Generate an SSL certificate request
- Purchase an SSL Certificate from GoDaddy
- Complete the certificate request
- Test the certificate
- Install and configure Citrix Secure Gateway 3.1.2
- Test external and internal secure access to published applications
Using Citrix Secure Gateway (CSG) is better than using AltAddr because CSG is SSL based and helps to secure the logon and data traffic. CSG is also easy to install and configure
When you completed Part 9 you were in the Citrix Web Interface Management Console (WIMC). Before CSG can be installed and configured, the AltAddr configuration settings need to be removed.
Click XenApp Web Sites in the left column, your XenApp site in the middle column and then Secure Access in the right column, or Action Pane (Figure 1).
We need to change the Default access method from the Alternate method back to Direct. The current Direct method needs to be removed and then the current Alternate method needs to be changed back to Direct.
Click the line that has Direct for the access method and then click Remove (Figure 2).
Click the Default/Alternate line and then click Edit… (Figure 3).
Click the dropdown box, select Direct and then click OK (Figure 4).
Click Finish (Figure 5).
The only access method at this time is now the original default method of Direct access.
Now the AltAddr assigned to the server’s network interface needs to be removed.
Open a command prompt window. Type in altaddr /delete InternalIPAddress and press Enter. Substituting your real Internal IP Address. Type in altaddr and press Enter. Your results should be similar to Figure 6.
Type exit and press Enter to close the command prompt window.
CSG uses SSL so TCP ports 1494 and 2598 no longer need to be opened on your router and or firewall.
Your router and or firewall need to be configured to allow the necessary ports through.
Port Protocol 80 HTTP 443 HTTPS (SSL) 3389 Remote Desktop (optional)
Here is my router configuration (Figure 7).
Minimize the WIMC.
Click Start, Administrative Tools, Internet Information Services (IIS) Manager (Figure 8).
Expand Web Sites (Figure 9).
Select Default Web Site (Figure 10).
Right-click Default Web Site and then click Properties (Figure 11).
Click the Directory Security tab and then click Server Certificate… (Figure 12).
The Web Server Certificate Wizard starts. Click Next (Figure 13).
Select Create a new certificate and click Next (Figure 14).
Click Next (Figure 15).
You can type in any Name for the new certificate on Figure 16. I use citrix.domain.tld or for my certificate, citrix.websterslab.com. For GoDaddy.com SSL certificates, the Bit length must be 2048 or higher. Select a suitable Bit length value and then click Next.
Note: For compatibility with future versions of IIS, a Bit length of 4096 is recommended.
You can enter anything for Organization and Organizational unit (Figure 17). They should either be very easy for you to remember or should be documented in your Change Control processes. If you ever need to rekey your certificate, you will need this information. If what you enter during the GoDaddy rekeying process does not match what you enter here, the rekeying will not be allowed by GoDaddy. I prefer to keep everything simple and enter citrix.domain.tld or for my certificate, both fields will be citrix.websterslab.com.
Enter your Organization, Organizational unit and click Next.
Note: Other SSL providers may require these fields to map to the information contained in the domain WHOIS information.
For Your Site’s Common Name, enter citrix.domain.tld or for my certificate, citrix.websterslab.com and then click Next (Figure 18).
Select your Country/Region, enter your State/province, City/locality and click Next (Figure 19).
Note: Other SSL providers may require the State/province to be spelled out.
By default, the Certificate Request File Name is saved as c:\certreq.txt. The IIS Certificate Wizard allows you to specify a different location and filename of your choice. Either enter a new file name or accept the default and then click Next (Figure 20).
Verify the information on the Request File Summary page is correct. If anything needs to be corrected, click Back and make any necessary corrections. If all the information is correct, click Next (Figure 21).
Click Finish to complete the certificate request and generate the file (Figure 22).
Leave the Default Web Site Properties page up. Click Start, Run and type in the path and filename for your certificate request file. If you accepted the default, type in c:\certreq.txt and press Enter (Figure 23). This will open the file in Notepad (Figure 24).
Press Ctrl-A to select the entire certificate request and then press Ctrl-C to copy the file contents to the server’s clipboard (Figure 25). Do not change anything in this file. Doing so will invalidate the certificate request process and you will need to start over.
Exit Notepad, start Internet Explorer and go to http://www.godaddy.com (Figure 26).
Log in to your account and click on SSL Certificates (Figure 27).
Scroll down and under Standard SSL, select Single — List Price $49.99/yr, then the number of years you wish your certificate to be valid and then click Add (Figure 28).
You can safely bypass all the extra deals GoDaddy tries to sell you. Nothing else is needed for your SSL Certificate to work with the Citrix Secure Gateway and Web Interface.
Scroll down to the bottom of the screen and click “No thanks” (Figure 29).
Enter any promo codes you have, select your payment method and check the box by I have read and agree to the terms of the Universal Terms of Service and then click Continue With Checkout (Figure 30).
Enter the information for your payment method and complete that process (No, I’m not showing you mine!).
When the payment process is complete, click Login to Begin Using Your Products (Figure 31).
Once back on the main account page, you should have an alert showing to start the process to setup your SSL Certificate. Click the link Get Started (Figure 32).
On the Managing Secure Certificates screen, click the link to “Use Credit” for your new certificate (Figure 33).
The Set up New Certificate wizard starts. Click Continue (Figure 28).
Click Close on the Thank You! popup (Figure 35).
Back on the Managing Secure Certificates Control Panel, click the Manage Certificate link for the New Certificate (Figure 36).
Note: It may take a few minutes before your new certificate shows up in the list.
A new browser window opens up. Click Request Certificate (Figure 37).
Select Third Party or Dedicated/Virtual Dedicated Server w/o Simple Control Panel, click in the CSR box and press Ctrl-V, make sure the certificate issuing organization is Go Daddy and then click Next (Figure 38).
Verify the information is correct and then click Next (Figure 39). If the information is not correct, click Back and correct the information.
Click Finished (Figure 40).
You will receive an e-mail from Go Daddy in a few minutes telling you “Your SSL Certificate Has Been Issued”.
Back on the Manage Certificates control panel, select your new SSL Certificate and then click the Download arrow (Figure 41).
Select IIS6 from the dropdown box and then click Download Certificate for IIS6 (Figure 42).
Open the file… (Figure 43).
And extract the files to c:\sslcert (Figure 44).
Click Close (Figure 45).
Log out of GoDaddy.com and close all browser windows.
Click Start, Run, type in MMC and press Enter (Figures 46 and 47).
Click File and Add/Remove Snap-in… (Figure 48).
Click Add… (Figure 49).
Click Certificates and then click Add (Figure 50).
Select Computer account and click Next (Figure 51).
Select Local computer and click Finish (Figure 52).
Click Close to close the Add Standalone Snap-in dialog (Figure 53).
Click OK to return to the main MMC Window (Figure 54).
Click the “+” to expand the Certificates folder (Figure 55).
Right-click on Intermediate Certification Authorities, choose All Tasks and then click Import… (Figure 56).
Click Next (Figure 57).
Click Browse… (Figure 58).
Change the “Files of type” dropdown to PKCS #7 Certificates (*.spc, *.p7b) (Figure 59).
Browse to the location you extracted and saved your certificate files, select your certificate file and click Open (Figure 60).
Click Next (Figure 61).
Select Place all certificates in the following store and make sure the Certificate store is Intermediate Certification Authorities and click Next (Figure 62).
Click Finish on the Certificate Import Wizard (Figure 63).
Click OK (Figure 64).
Click the “+” next to Trusted Root Certification Authorities and then click Certificates (Figure (65).
Scroll down, right-click Go Daddy Class 2 Certification Authority and select Properties (Figure 66).
Select Disable all purposes for this certificate and click OK (Figure 67).
Exit the MMC console without saving changes.
Click on Default Web Site Properties dialog and then click Server Certificate… (Figure 68).
Click Next (Figure 69).
Select Process the pending request and install the certificate and click Next (Figure 70).
Click Browse… to locate your certificate file (Figure 71).
Change the Files of type to All files (*.*) (Figure 72).
Find and select your GoDaddy “crt” certificate file and then click Open (Figure 73).
Click Next (Figure 74).
Citrix Secure Gateway will process all incoming SSL traffic on Port 443 so the SSL Port that IIS uses must be changed. Type in 444 and click Next (Figure 75).
Note: This is one of the most common problems that keeps Citrix Secure Gateway from working. Citrix Secure Gateway MUST have Port 443 reserved for its use. IIS MUST use a different Port for SSL.
Verify the information on the Certificate Summary page is correct and click Next (Figure 76).
Click Finish (Figure 77).
Click OK (Figure 78).
Exit Internet Information Services Manager.
To verify the SSL Certificate was installed properly, you may need to create an entry in your Web Interface server’s Host file. Click Start, Run and type in Notepad %systemroot%\system32\drivers\etc\hosts and press Enter (Figure 79).
Go to the bottom of the Hosts file and type 127.0.0.1, press Tab and type in the Fully Qualified Domain Name your users will use to access the Citrix Secure Gateway. For me that is citrix.websterslab.com (Figure 80).
Save the changes and exit Notepad.
Open your Internet browser and go to https://FullyQualifiedDomainName:444/Citrix/XenApp. For me, I went to https://citrix.websterslab.com:444/Citrix/XenApp (Figure 81). Note the SSL Padlock icon.
Click the Padlock icon and click View certificates. (Figure 82).
Click each of the three tabs (Figures 83, 84 and 85).
Click OK and then log in to the Web Interface (Figure 86).
You can test running any published application if you wish. Log off the Web Interface and exit your Internet browser.
To start the installation of CSG change the VM’s DVD Drive to the XenApp 5 ISO file (Figure 87).
The XenApp 5 installation starts. Click Browse Media (Figure 88).
Double-click Secure Gateway (Figure 89).
Double-click Windows (Figure 90).
Double-click the CSG_GWY.msi file and click Next (Figure 91).
Click Next (Figure 92).
Select I accept the license agreement and then click Next (Figure 93).
Select Secure Gateway and then click Next (Figure 94).
Click Next to accept the default installation folder (Figure 5).
Citrix Best Practice is to place the Secure Gateway/Web Interface server in the DMZ and the server should not be a domain member. Since this server, outside of this Learning series, is an Internet facing server it should be protected by all means possible. This includes using an account that has the least possible privileges and not putting the server on your internal network.
On the Service Account page you have the option of running the Secure Gateway service under Local System or Network Service accounts. What is the difference and which one should be chosen? According to http://msdn.microsoft.com/en-us/library/ms684190(VS.85).aspx, the Local System account runs at a very high privilege level. The article recommends using the Network Service account if a high privilege level is not needed. The Secure Gateway service does not need, and should not be given, such a high privilege level. According to http://msdn.microsoft.com/en-us/library/ms684272(VS.85).aspx, the Network Service account has very few privileges. You should seriously consider using the Network Service account for the Secure Gateway service. It is very odd that this important decision is not mentioned in the Secure Gateway for Windows Administrator’s Guide or any Citrix Support Tech Notes.
Using the Network Service account reduces the attack surface should your Secure Gateway/Web Interface server be hacked. Since this account has no domain privileges it will make it harder for an attacker to compromise your domain.
If you do decide to place the Secure Gateway/Web Interface server on your internal network, then you must use the Network Service account.
Select NETWORK SERVICE from the dropdown list and then click Next (Figure 96).
Verify the install options (Figure 97). If any corrections need to be made, click Back and make the necessary corrections. If everything is correct, click Next.
Click Finish (Figure 98).
Click OK to start the Secure Gateway Configuration wizard (Figure 99).
Click OK to start configuring Secure Gateway (Figure 100).
The Standard configuration does not allow us to set, or verify, all the necessary options. Select Advanced and then click Next (Figure 101).
Select your SSL certificate and click Next (Figure 12). Click View… to view the information about your certificate. This is the same information that was seen in Figures 83, 84 and 85.
For “Select secure protocol“, select Secure Sockets Layer (SSLv3) and TLSv1. For “Select cipher suite“, select All and then click Next (Figure 103).
If you have a single network card with a single IP address, you can select Monitor all IPv4 addresses (Figure 104). If you have multiple network cards and or multiple IP addresses on this server, unselect Monitor all IPv4 addresses, click Add and add the network interface(s) you wish to monitor for TCP port 443 traffic.
Secure Gateway will handle all TCP port 443 traffic and IIS handles SSL traffic on TCP port 444 (or whatever you selected earlier). Enter 443 for the TCP port and then click Next.
Note: IPv6 is only supported under Windows Server 2008.
Select No outbound traffic restrictions and then click Next (Figure 105).
The Secure Ticket Authority (STA) is installed on every XenApp server. If you have multiple XenApp servers enter as many XenApp servers as you like to provide failover.
Click Add (Figure 106).
Note: Secure Ticket Authority (STA) is part of the XML Service that runs on all XenApp servers.
Enter citrixone for the Fully Qualified Domain Name (FQDN) and then click OK (Figure 107).
Click Next (Figure 108).
By default, Secure Gateway is limited to 250 concurrent connections. I would not recommend increasing this limit. If you need more than 250 concurrent connections then you should seriously consider Citrix’s hardware solution the Citrix Access Gateway.
Accept the defaults and click Next (Figure 109).
If you have any hardware load balancing appliances in front of your Secure Gateway/Web Interface server, enter the IP addresses here to exclude them from generating even log entries and then click Next (Figure 110).
Since the Secure Gateway and Web Interface are installed on the same server, select Indirect:…, check Installed on this computer and then click Next (Figure 111).
Select the level of logging you wish to receive from the Secure gateway service and click Next (Figure 112).
Check to Start the Secure Gateway service and then click Finish (Figure 113).
Exit the Explorer windows and the Citrix XenApp installation program.
To test external access to published applications, you will need a public DNS name for the server. Mine is citrix.websterslab.com. I use DynDNS to allow the use of a dynamic Public IP address for my lab server. In your router or firewall TCP port 443 must be routed from the Public IP address to the internal IP address of the Citrix Secure Gateway/Web Interface server.
Internet -> Public IP address -> Router/Firewall -> TCP Port 443 -> Private IP address
Internet -> 69.x.y.z -> Router/Firewall -> TCP Port 443 -> 192.168.1.105
Restore the Web Interface Management Console. In the Action pane under XenApp — Edit Settings, click Secure access (Figure 114).
Click the Default line and then click Edit… (Figure 115).
Select Gateway Direct from the dropdown list and then click OK (Figure 116).
Selecting Gateway Direct will send to the client the external Public IP address of the Secure Gateway/Web Interface server instead of the internal Private IP address of the XenApp server hosting the published application.
Click Next (Figure 117).
Enter the FQDN that users will use to access the Secure Gateway/Web Interface server and then click Next (Figure 39).
Click Add… (Figure 119).
Type in http://citrixone/scripts/ctxsta.dll and then click OK (Figure 120).
Click Finish (Figure 121).
From a computer that is external to your network, go to https://FQDN/Citrix/XenApp. For me, this is https://citrix.websterslab.com/Citrix/XenApp (Figure 122). Notice the SSL padlock appears.
Log in to the Web Interface and your published applications are shown (Figure 123).
Test running your published applications to verify they run successfully.
To verify the connection is using 256-bit SSL, right-click the Citrix Connection Center icon in the systray and select Open Connection Center (Figure 124).
Click the XenApp server and then click Properties (Figure 125).
The Client Connection Status dialog shows that 256-bit SSL is in use (Figure 126).
Exit the Client Connection Center, your published application, log off the Web Interface site and exit your Internet browser.
Repeat the tests from inside your network.
You have now successfully tested secure access to published application from both inside and outside your network.
In this final part, you learned to install and configure Citrix Secure Gateway 3.1.2 and test both external and internal secure access to published applications.
You have now learned how to complete all the goals set out for you in this 10-part series. You have:
- Created your MyCitrix.com account
- Requested your evaluation license code
- Downloaded your product license file
- Downloaded XenApp 5 Feature Pack 2 for Server 2003
- Downloaded XenServer 5.5
- Learned to create a VM optimized for XenApp
- Learned to install Windows Server 2003 R2 x86
- Installed the prerequisites for XenApp 5 Feature Pack 2 for Server 2003, Web Interface and the Citrix License Management Console
- Updated Windows Server 2003 R2 x86
- Learned to install XenApp 5 Feature Pack 2 for Server 2003
- Learned how to update XenApp 5 for Server 2003
- Learned how to create a Web Interface site and set basic configuration settings
- Created a test user account
- Learned how to publish applications
- Tested access to the published applications
- Learned basic XenApp farm maintenance procedures
- Learned how to use the AltAddr method to provide insecure, unencrypted external access to published applications
- Learned how to generate an SSL certificate request, purchase an SSL certificate and complete the certificate request
- Learned how to use Citrix Secure Gateway to provide secure, encrypted access to published application