Product Documentation

Digital Certificates and the Secure Gateway

Sep 15, 2015

SSL and TLS are leading Internet protocols providing security for e-commerce, Web services, and many other network functions. The SSL/TLS protocol uses cryptography to secure communications. Cryptography provides the ability to encode messages to ensure confidentiality. To establish an SSL/TLS connection, you need a digital certificate.

For more information about obtaining, exporting, and installing security certificates for your operating system, consult the Microsoft TechNet library available at http://technet.microsoft.com.

The SSL protocol is today’s standard for securely exchanging information on the Internet. Originally developed by Netscape, the SSL protocol became crucial to the operation of the Internet. As a result, the Internet Engineering Taskforce (IETF) took over responsibility for the development of SSL as an open standard. To clearly distinguish SSL from other ongoing work, the IETF renamed SSL as TLS. The TLS protocol is the descendant of the third version of SSL; TLS 1.0 is identical to SSL 3.1.

Some organizations, including U.S. government organizations, require the use of TLS to secure data communications. These organizations may also require the use of validated cryptography. FIPS (Federal Information Processing Standard) 140 is a standard for cryptography.

Support for Wildcard Certificates with the Secure Gateway

The Secure Gateway supports wildcard certificates that you can use if you have a load-balanced domain. The wildcard certificate has an asterisk (*) in the certificate name. Clients can choose different Web addresses, such as http://www1.citrix.com or http://www2.citrix.com. The use of a wildcard certificate allows several Web sites to be covered by a single certificate.

Understanding SSL and TSL

The SSL/TLS protocol allows sensitive data to be transmitted over public networks such as the Internet by providing the following important security features:

Authentication
A client can determine a server’s identity and ascertain that the server is not an impostor. Optionally, a server can also authenticate the identity of the client requesting connections.
Privacy
Data passed between the client and server is encrypted so that if a third party intercepts messages, it cannot unscramble the data.
Data integrity
The recipient of encrypted data knows if a third party corrupts or modifies that data.

Understanding Cryptography

Cryptography is also used to authenticate the identity of a message source and to ensure the integrity of its contents.

A message is sent using a secret code called a cipher. The cipher scrambles the message so that it cannot be understood by anyone other than the sender and receiver. Only the receiver who has the secret code can decipher the original message, thus ensuring confidentiality.

Cryptography allows the sender to include special information in the message that only the sender and receiver know. The receiver can authenticate the message by reviewing the special information.

Cryptography also ensures that the contents of a message are not altered. To do this, the sender includes a cryptographic operation called a hash function in the message. A hash function is a mathematical representation of the information, similar to the checksums found in communication protocols. When the data arrives at its destination, the receiver calculates the hash function. If the receiver’s hash function value is the same as the sender’s, the integrity of the message is assured.

Types of Cryptography

There are two main types of cryptography:

  • Secret key cryptography
  • Public key cryptography

In cryptographic systems, the term key refers to a numerical value used by an algorithm to alter information, making that information secure and visible only to individuals who have the corresponding key to recover the information.

Secret key cryptography is also known as symmetric key cryptography. With this type of cryptography, both the sender and the receiver know the same secret code, called the key. Messages are encrypted by the sender using the key and decrypted by the receiver using the same key.

This method works well if you are communicating with only a limited number of people, but it becomes impractical to exchange secret keys with large numbers of people. In addition, there is also the problem of how you communicate the secret key securely.

Public key cryptography, also called asymmetric encryption, uses a pair of keys for encryption and decryption. With public key cryptography, keys work in pairs of matched public and private keys.

The public key can be freely distributed without compromising the private key, which must be kept secret by its owner. Because these keys work only as a pair, encryption initiated with the public key can be decrypted only with the corresponding private key. The following example illustrates how public key cryptography works:

  • Ann wants to communicate secretly with Bill. Ann encrypts her message using Bill’s public key (which Bill made available to everyone) and Ann sends the scrambled message to Bill.
  • When Bill receives the message, he uses his private key to unscramble the message so that he can read it.
  • When Bill sends a reply to Ann, he scrambles the message using Ann’s public key.
  • When Ann receives Bill’s reply, she uses her private key to unscramble his message.

The major advantage asymmetric encryption offers over symmetric key cryptography is that senders and receivers do not have to communicate keys up front. Provided the private key is kept secret, confidential communication is possible using the public keys.

Combining Public Key and Secret Key Cryptography

The main disadvantage of public key cryptography is that the process of encrypting a message, using the very large keys common to PKI, can cause performance problems on all but the most powerful computer systems. For this reason, public key and secret key cryptography are often combined. The following example illustrates how this works:

  • Bill wants to communicate secretly with Ann, so he obtains Ann’s public key. He also generates random numbers to use just for this session, known as a session key.
  • Bill uses Ann’s public key to scramble the session key.
  • Bill sends the scrambled message and the scrambled session key to Ann.
  • Ann uses her private key to unscramble Bill’s message and extract the session key.

When Bill and Ann successfully exchange the session key, they no longer need public key cryptography—communication can take place using just the session key. For example, public key encryption is used to send the secret key; when the secret key is exchanged, communication takes place using secret key encryption.

This solution offers the advantages of both methods—it provides the speed of secret key encryption and the security of public key encryption.

Understanding Digital Certificates and Certificate Authorities

The ISO X.509 protocol defines a mechanism called a certificate that contains a user’s public key that is signed by a trusted entity called a certificate authority (CA).

Certificates contain information used to establish identities over a network in a process called authentication. Like a driver’s licence, a passport, or other forms of personal identification, certificates enable servers and clients to authenticate each other before establishing a secure connection.

Certificates are valid only for a specified time period; when a certificate expires, a new one must be issued. The issuing authority can also revoke certificates.

To establish an SSL/TLS connection, you require a server certificate at one end of the connection and a root certificate of the CA that issued the server certificate at the other end.

Server certificate
A server certificate certifies the identity of a server. The type of digital certificate that is required by the Secure Gateway is called a server certificate
Root certificate
A root certificate identifies the CA that signed the server certificate. The root certificate belongs to the CA. This type of digital certificate is required by a user device to verify the server certificate.

When establishing an SSL connection with a Web browser on a user device, the server sends its certificate to the client.

When receiving a server certificate, the Web browser (for example, Internet Explorer) on the user device checks to see which CA issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the Web browser prompts the user to accept or decline the certificate (effectively accepting or declining the ability to access this site).

When User A receives a message from User B, the locally stored information about the CA that issued the certificate is used to verify that it did indeed issue the certificate. This information is a copy of the CA’s own certificate and is referred to as a root certificate.

Certificates generally have a common format, usually based on International Telecommunication Union (ITU) standards. The certificate contains information that includes the:

  • Issuer - The organization that issues the certificates.
  • Subject - The party that is identified by the certificate.
  • Period of validity - The certificate's start date and expiration date.
  • Public key - The subject's public key used to encrypt data.
  • Issuer's signature - The CA's digital signature on the certificate used to guarantee its authenticity.

A number of companies and organizations currently act as CAs, including VeriSign, Baltimore, Entrust, and their respective affiliates.

Certificate Chains

Some organizations delegate the responsibility for issuing certificates to resolve the issue of geographical separation between organization units, or that of applying different issuing policies to different sections of the organization.

Responsibility for issuing certificates can be delegated by setting up subordinate CAs. The X.509 standard includes a model for setting up a hierarchy of CAs. In this model, the root CA is at the top of the hierarchy and has a self-signed certificate. The CAs that are directly subordinate to the root CA have CA certificates signed by the root CA. CAs under the subordinate CAs in the hierarchy have their CA certificates signed by the subordinate CAs.

Shows the hierarchical structure of a typical digital certificate chain

This illustration shows the hierarchical structure of a typical digital certificate chain.

CAs can sign their own certificates (that is, they are self-signed) or they can be signed by another CA. If the certificate is self-signed, they are called root CAs. If they are not self-signed, they are called subordinate or intermediate CAs.

If a server certificate is signed by a CA with a self-signed certificate, the certificate chain is composed of exactly two certificates: the end entity certificate and the root CA. If a user or server certificate is signed by an intermediate CA, the certificate chain is longer.

The following figure shows the first two elements are the end entity certificate (in this case, gwy01.company.com) and the certificate of the intermediate CA, in that order. The intermediate CA's certificate is followed by the certificate of its CA. This listing continues until the last certificate in the list is for a root CA. Each certificate in the chain attests to the identity of the previous certificate.


Shows a certificate chain

This illustration shows a typical digital certificate chain.

Certificate Revocation Lists

From time to time, CAs issue certificate revocation lists (CRLs). CRLs contain information about certificates that can no longer be trusted. For example, suppose Ann leaves XYZ Corporation. The company can place Ann's certificate on a CRL to prevent her from signing messages with that key.

Similarly, you can revoke a certificate if a private key is compromised or if that certificate expired and a new one is in use. Before you trust a public key, make sure that the certificate does not appear on a CRL.

Deciding Where to Obtain Certificates

When you identify the number and type of certificates required for your Secure Gateway deployment, decide where to obtain the certificates. Where you choose to obtain certificates depends on a number of factors, including:

  • Whether or not your organization is a CA, which is likely to be the case only in very large corporations
  • Whether or not your organization already established a business relationship with a public CA
  • Whether or not your organization already established a business relationship with a public CA
  • The cost of certificates or the reputation of a particular public CA

If Your Organization Is its Own Certificate Authority

If your organization is running its own CA, you must determine whether or not it is appropriate to use your company's certificates for the purpose of securing communications in your Secure Gateway installation. Citrix recommends that you contact your corporate security department to discuss this and to get further instructions about how to obtain certificates.

If you are unsure if your organization is a CA, contact your corporate security department or your organization's security expert.

If Your Organization Is Not its Own Certificate Authority

If your organization is not running its own CA, you need to obtain your certificates from a public CA such as VeriSign. Obtaining a digital certificate from a public CA involves a verification process in which:

Obtaining a digital certificate from a public CA involves a verification process in which:

  • Your organization provides corporate information so the CA can verify that your organization is who it claims to be. The verification process may involve other departments in your organization, such as accounting, to provide letters of incorporation or similar legal documents.
  • Individuals with the appropriate authority in your organization are required to sign legal agreements provided by the CA.
  • The CA verifies your organization as a purchaser; therefore your purchasing department is likely to be involved.
  • You provide the CA with contact details of suitable individuals whom they can call if there are queries.

Obtaining and Installing Server Certificates

Your organization's security expert should have a procedure for obtaining server certificates. Instructions for generating server certificates using various Web server products are available from the Web sites of popular CAs such as Verisign and others.

Several CAs offer Test Server Certificates for a limited trial period. It might be expedient to obtain a Test Certificate to test the Secure Gateway before deploying it in a production environment. If you do this, be aware that you need to download matching Test Root Certificates that must be installed on each user device that connects through the Secure Gateway.

To provide secure communications (SSL/TLS), a server certificate is required on the server running the Secure Gateway. The steps required to obtain and install a server certificate on a server running the Secure Gateway are as follows:

  • Create a certificate request.
  • Apply for a server certificate from a valid CA.
  • Save the certificate response file sent by the CA as an X.509 Certificate (.cer format).
  • Import the X.509 certificate into the certificate store.
  • Export the certificate into Personal Information Exchange format (.pfx, also called PKCS #12).
  • Install the server certificate on the server running the Secure Gateway.

Consider the following before obtaining and installing certificates:

  • When requesting a certificate, the greater the bit length, the higher the security. Citrix recommends that you select 1024 or higher. If you are specifying a bit length higher than 1024, ensure that the clients you deploy support it. For information about supported encryption strength on a user device, see the appropriate user device's documentation.
  • Part of an initial request for a certificate involves generating a public/private key pair that is stored on your server. Because the public key from this key pair is encoded in your certificate, loss of the key pair on your server renders your certificate worthless. Make sure you back up your key pair data on another computer, a floppy disk, or both.
  • Typically, the procedure for generating a key pair requires you to specify a password to encrypt the pair. The password prevents any person with access to the keypair data from extracting the private key and using it to decrypt SSL/TLS traffic to and from your server. Ensure that you store the password in a secure location.
  • When you import a certificate, you copy the certificate from a file that uses a standard certificate storage format to a certificate store for your computer account. Use the proper procedures or wizard as specified by your operating system to place certificates in the correct store on local computers. Do not attempt to import the server certificate file by double-clicking or right-clicking the certificate file within Windows Explorer. Doing so places the certificate in the certificate store for the current user.

Obtaining and Installing Root Certificates

A root certificate must be present on every user device that connects to the secure network through the Secure Gateway.

Support for most trusted root authorities is already built into the Windows operating system and Internet Explorer. Therefore, there is no need to obtain and install root certificates on the user device if you are using these CAs. However, if you decide to use a different CA, you need to obtain and install the root certificates yourself.

Obtaining a Root Certificate from a CA

Root certificates are available from the same CAs that issue server certificates. Well-known or trusted CAs include Verisign, Baltimore, Entrust, and their respective affiliates. Certificate authorities tend to assume that you already have the appropriate root certificates (this is because most Web browsers have root certificates built-in) so you need to specifically request the root certificate. Several types of root certificates are available. For example, VeriSign has approximately 12 root certificates that they use for different purposes, so it is important to ensure that you obtain the correct root certificate from the CA.

Support for Wildcard Certificates with the Secure Gateway

The Secure Gateway supports wildcard certificates that you can use if you have a load-balanced domain. The wildcard certificate has an asterisk (*) in the certificate name. Clients can choose different Web addresses, such as http://www1.citrix.com or http://www2.citrix.com. The use of a wildcard certificate allows several Web sites to be covered by a single certificate.