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).
Clik here to view.

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).
Clik here to view.

Click the Default/Alternate line and then click Edit… (Figure 3).
Clik here to view.

Click the dropdown box, select Direct and then click OK (Figure 4).
Clik here to view.

Click Finish (Figure 5).
The only access method at this time is now the original default method of Direct access.
Clik here to view.

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.
Clik here to view.

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).
Clik here to view.

Minimize the WIMC.
Click Start, Administrative Tools, Internet Information Services (IIS) Manager (Figure 8).
Clik here to view.

Expand Web Sites (Figure 9).
Clik here to view.

Select Default Web Site (Figure 10).
Clik here to view.

Right-click Default Web Site and then click Properties (Figure 11).
Clik here to view.

Click the Directory Security tab and then click Server Certificate… (Figure 12).
Clik here to view.

The Web Server Certificate Wizard starts. Click Next (Figure 13).
Clik here to view.

Select Create a new certificate and click Next (Figure 14).
Clik here to view.

Click Next (Figure 15).
Clik here to view.

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.
Clik here to view.

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.
Clik here to view.

For Your Site’s Common Name, enter citrix.domain.tld or for my certificate, citrix.websterslab.com and then click Next (Figure 18).
Clik here to view.

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.
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

Click Finish to complete the certificate request and generate the file (Figure 22).
Clik here to view.

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).
Clik here to view.

Clik here to view.

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.
Clik here to view.

Exit Notepad, start Internet Explorer and go to http://www.godaddy.com (Figure 26).
Clik here to view.

Log in to your account and click on SSL Certificates (Figure 27).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

On the Managing Secure Certificates screen, click the link to “Use Credit” for your new certificate (Figure 33).
Clik here to view.

The Set up New Certificate wizard starts. Click Continue (Figure 28).
Clik here to view.

Click Close on the Thank You! popup (Figure 35).
Clik here to view.

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.
Clik here to view.

A new browser window opens up. Click Request Certificate (Figure 37).
Clik here to view.

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).
Clik here to view.

Verify the information is correct and then click Next (Figure 39). If the information is not correct, click Back and correct the information.
Clik here to view.

Click Finished (Figure 40).
Clik here to view.

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).
Clik here to view.

Select IIS6 from the dropdown box and then click Download Certificate for IIS6 (Figure 42).
Clik here to view.

Open the file… (Figure 43).
Clik here to view.

And extract the files to c:\sslcert (Figure 44).
Clik here to view.

Click Close (Figure 45).
Clik here to view.

Log out of GoDaddy.com and close all browser windows.
Click Start, Run, type in MMC and press Enter (Figures 46 and 47).
Clik here to view.

Clik here to view.

Click File and Add/Remove Snap-in… (Figure 48).
Clik here to view.

Click Add… (Figure 49).
Clik here to view.

Click Certificates and then click Add (Figure 50).
Clik here to view.

Select Computer account and click Next (Figure 51).
Clik here to view.

Select Local computer and click Finish (Figure 52).
Clik here to view.

Click Close to close the Add Standalone Snap-in dialog (Figure 53).
Clik here to view.

Click OK to return to the main MMC Window (Figure 54).
Clik here to view.

Click the “+” to expand the Certificates folder (Figure 55).
Clik here to view.

Right-click on Intermediate Certification Authorities, choose All Tasks and then click Import… (Figure 56).
Clik here to view.

Click Next (Figure 57).
Clik here to view.

Click Browse… (Figure 58).
Clik here to view.

Change the “Files of type” dropdown to PKCS #7 Certificates (*.spc, *.p7b) (Figure 59).
Clik here to view.

Browse to the location you extracted and saved your certificate files, select your certificate file and click Open (Figure 60).
Clik here to view.

Click Next (Figure 61).
Clik here to view.

Select Place all certificates in the following store and make sure the Certificate store is Intermediate Certification Authorities and click Next (Figure 62).
Clik here to view.

Click Finish on the Certificate Import Wizard (Figure 63).
Clik here to view.

Click OK (Figure 64).
Clik here to view.

Click the “+” next to Trusted Root Certification Authorities and then click Certificates (Figure (65).
Clik here to view.

Scroll down, right-click Go Daddy Class 2 Certification Authority and select Properties (Figure 66).
Clik here to view.

Select Disable all purposes for this certificate and click OK (Figure 67).
Clik here to view.

Exit the MMC console without saving changes.
Click on Default Web Site Properties dialog and then click Server Certificate… (Figure 68).
Clik here to view.

Click Next (Figure 69).
Clik here to view.

Select Process the pending request and install the certificate and click Next (Figure 70).
Clik here to view.

Click Browse… to locate your certificate file (Figure 71).
Clik here to view.

Change the Files of type to All files (*.*) (Figure 72).
Clik here to view.

Find and select your GoDaddy “crt” certificate file and then click Open (Figure 73).
Clik here to view.

Click Next (Figure 74).
Clik here to view.

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.
Clik here to view.

Verify the information on the Certificate Summary page is correct and click Next (Figure 76).
Clik here to view.

Click Finish (Figure 77).
Clik here to view.

Click OK (Figure 78).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

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.
Clik here to view.

Click the Padlock icon and click View certificates. (Figure 82).
Clik here to view.

Click each of the three tabs (Figures 83, 84 and 85).
Clik here to view.

Clik here to view.

Clik here to view.

Click OK and then log in to the Web Interface (Figure 86).
Clik here to view.

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).
Clik here to view.

The XenApp 5 installation starts. Click Browse Media (Figure 88).
Clik here to view.

Double-click Secure Gateway (Figure 89).
Clik here to view.

Double-click Windows (Figure 90).
Clik here to view.

Double-click the CSG_GWY.msi file and click Next (Figure 91).
Clik here to view.

Click Next (Figure 92).
Clik here to view.

Select I accept the license agreement and then click Next (Figure 93).
Clik here to view.

Select Secure Gateway and then click Next (Figure 94).
Clik here to view.

Click Next to accept the default installation folder (Figure 5).
Clik here to view.

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).
Clik here to view.

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.
Clik here to view.

Click Finish (Figure 98).
Clik here to view.

Click OK to start the Secure Gateway Configuration wizard (Figure 99).
Clik here to view.

Click OK to start configuring Secure Gateway (Figure 100).
Clik here to view.

The Standard configuration does not allow us to set, or verify, all the necessary options. Select Advanced and then click Next (Figure 101).
Clik here to view.

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.
Clik here to view.

For “Select secure protocol“, select Secure Sockets Layer (SSLv3) and TLSv1. For “Select cipher suite“, select All and then click Next (Figure 103).
Clik here to view.

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.
Clik here to view.

Select No outbound traffic restrictions and then click Next (Figure 105).
Clik here to view.

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.
Clik here to view.

Enter citrixone for the Fully Qualified Domain Name (FQDN) and then click OK (Figure 107).
Clik here to view.

Click Next (Figure 108).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

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).
Clik here to view.

Select the level of logging you wish to receive from the Secure gateway service and click Next (Figure 112).
Clik here to view.

Check to Start the Secure Gateway service and then click Finish (Figure 113).
Clik here to view.

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
For me:
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).
Clik here to view.

Click the Default line and then click Edit… (Figure 115).
Clik here to view.

Select Gateway Direct from the dropdown list and then click OK (Figure 116).
Clik here to view.

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).
Clik here to view.

Enter the FQDN that users will use to access the Secure Gateway/Web Interface server and then click Next (Figure 39).
Clik here to view.

Click Add… (Figure 119).
Clik here to view.

Type in http://citrixone/scripts/ctxsta.dll and then click OK (Figure 120).
Clik here to view.

Click Finish (Figure 121).
Clik here to view.

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.
Clik here to view.

Log in to the Web Interface and your published applications are shown (Figure 123).
Clik here to view.

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).
Clik here to view.

Click the XenApp server and then click Properties (Figure 125).
Clik here to view.

The Client Connection Status dialog shows that 256-bit SSL is in use (Figure 126).
Clik here to view.

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