In depth: SSL certificates and Citrix Secure Gateway (second part)
In this second part I wanted to proceed with the generation of a certificate for use with our Secure Gateway.
The certificate management is often tricky because you always end up not intuitive to use tools and talk formats of certificates strange ideas only to confuse those not already very practical. In fact, field experience has led me to suggest that you use the management tools of the Internet Information Server to manage SSL certificates for the Secure Gateway. This means installing IIS on the server where our Secure Gateway, Web Interface and Secure Gateway often reside on the same machine, but if not, the installation of an unused IIS should not cause problems.
We use IIS for certificate management, but in reality we are interested in leaving the port 443 (HTTPS service of the) free for Citrix Secure Gateway. We will then configure IIS to use the certificate on a different port, for example 444.
Going on the properties of the default site (or one on which we installed the Web Interface) can start the wizard to create an SSL certificate by selecting the pulsed "Server Certificate" under the tab "Security Dirctory" 
The first step is to create a new certificate:
If our server is added to Ativ Directory domain and has been a Certification Authority, we can send the request directly. Often our Secure Gateway is plugged into a DMZ and may not be in the domain, which is why in this article we consider the long way ....
Therefore choose to prepare the request, but not send it automatically (if we are not in AD, the second option is grayed out and not selectable). At this point you are prompted for information needed to create our certificate.
The first two parameters to include is the name of the certificate and its length:
The mnemonic name is entered here, and we need to know that we are creating the certificate, not to be confused with the Common Name, which must match the FQDN that will be required later.
We must then enter the name of our company and requesting office:
These values are then looking at the certificate properties available, so do not write too fancy values (a certificate be required by "bar" of the "foo" may not be very credible).
Soon after we are required to enter the Common Name to which the certificate is revered:
This is one of the most important information of the certificate: is the name by which the site is called, the fully qualified domain name (FQDN)! If this name does not match the name of our Secure Internet Gateway, the certificate is invalid (failed one of three tests) and the ICA Client is unable to connect.
Finally we enter geographic information about our company:
This information will be visible within the certificate. At this point we insert the path to save the request (the default is saved to the root of the system disk) and we arrived at the end of the first phase of creating the certificate.
... Next and Finish.
Now we send our request to the Certification Authority. By default, the Microsoft CA installed some web pages that allow us to make a certificate request using a web browser. If the server we are using is not able to connect to the CA via the web, you must copy the file certreq.txt we just created on a PC on the LAN.
Open your browser and go to http:// <CA-Server> / certsrv /, which in my case the server is called DemoDC
Obviously we have to request a certificate ....
Of dfault we will propose a user certificate request, but to us a certificate for the server, our server .... We must therefore make a request.
Open the file certreq.txt we created earlier (with a double click, the file is opened in notepad): its content is text, unreadable for us: it is actually in base64 format. Then select the second option (Submit a certificate request by using base-64-encoded CMC or PKCS # 10 files ...)
We select the text from Notepad and put this in the application form.
We just need to check the Certificate Template: our need for a Web Server certificate! We must then select the Certificate Templates and set the correct value.
Our certificate was issued. In fact, if you're using a user who has the rights to issue certificates on our Certification Authority, it is necessary that an administrator user to connect to the server in question and, using the snap-in management of the Certification Authority, authorizing the issuance of our certificate, we did this back on the web page and download the CA certificate (Download CA Certificate ....). Now select the format and download the certificate. If we download the "certificate chain", we also simply downloading the certificate of public (or) who have signed our CA certificate. With our file certnew.cer we can now return to our IIS and process the request before: back in the "Directory Security" section of our website and select "Server Certificate".
We select our certnew.cer files we downloaded from the website of our Certification Authority:
We must now specify the port to use for SSL traffic. Comq anticipated at the beginning, we do not care that IIS uses the certificate directly, rather we need that port 443 is free for the Secure Gateway. Then select a different port, not in use by other services, such as port 444.
We have completed the creation of our certificate is now ready for use. The last window shows us the specifications of the certificate (which should be identical to those displayed in the first phase of the summary):
Also read more about: SSL certificates and the Secure Gateway (Part One)
Other articles on similar topics:
- In depth: SSL certificates and Citrix Secure Gateway (Part One)
- Vulnerability in Citrix Secure Gateway 3.1
- Vulnerability TSL and SSL protocols: Citrix upgrade the Secure Gateway, NetScaler and Access Gateway Enterprise - Update
- Citrix Secure Gateway version 3.1 is available
- Vulnerability in Citrix Secure Gateway 3.1.4
- Citrix Secure Gateway version 3.1.2 arrives
- Deployment of the ICA Client using Web Interface integrated with Access Gateway Advanced 4.6
