Secure Global Desktop 4.40 Administration Guide > Security > SGD Security Services and X.509 Certificates

SGD Security Services and X.509 Certificates

An X.509 certificate is an encoded file that a secure service, such as a web server, uses to identify itself to a client. An SGD server with security services enabled also requires a certificate in the same way.

An X.509 certificate is generated by a Certificate Authority (CA). A CA is a trusted third party that signs a certificate for a particular server. To obtain a certificate for a server, you send a Certificate Signing Request (CSR) to a CA. When a CA receives a CSR, they check the validity of the request and return an X.509 certificate. You then install the X.509 certificate for use by SGD.

This page includes the following topics:

• Supported X.509 Certificate Format
• Supported Certificate Authority Certificates
• Obtaining and Installing an X.509 Certificate
• Using an X.509 Certificate for Another Product With SGD
• Adding Support for Additional Certificate Authorities
• Using Chained Certificate Authority Certificates
• Sharing an SGD Server X.509 Certificate With the SGD Web Server

Supported X.509 Certificate Format

SGD security services support Base 64-encoded PEM-format X.509 certificates. These certificates have the following structure:

-----BEGIN CERTIFICATE-----
...
certificate
...
-----END CERTIFICATE-----

Supported Certificate Authority Certificates

SGD supports X.509 certificates that are signed with any of the following Certificate Authority (CA) certificates (root certificates):

• Baltimore CyberTrust Code Signing Root
• Baltimore CyberTrust Root
• Entrust.net CA
• Entrust.net Client CA 1
• Entrust.net Client CA 2
• Entrust.net Server CA 1
• Entrust.net Server CA 2
• Equifax Secure CA
• Equifax Secure eBusiness CA 1
• Equifax Secure eBusiness CA 2
• Equifax Secure Global eBusiness CA
• GeoTrust Global CA
• The Go Daddy Group, Inc. Class 2 CA
• GTE CyberTrust Root
• GTE CyberTrust Global Root
• GTE CyberTrust Root 5
• Starfield Technologies, Inc. Class 2 CA
• Thawte Personal Basic CA
• Thawte Personal Freemail CA
• Thawte Personal Premium CA
• Thawte Premium CA
• Thawte Server CA
• http://www.valicert.com
• VeriSign Class 1 Public Primary CA - G1
• VeriSign Class 1 Public Primary CA - G2
• VeriSign Class 1 Public Primary CA - G3
• VeriSign Class 2 Public Primary CA - G1
• VeriSign Class 2 Public Primary CA - G2
• VeriSign Class 2 Public Primary CA - G3
• VeriSign Class 3 Public Primary CA - G1
• VeriSign Class 3 Public Primary CA - G2
• VeriSign Class 3 Public Primary CA - G3
• VeriSign Class 4 Public Primary CA - G2
• VeriSign Class 4 Public Primary CA - G3
• VeriSign/RSA Secure Server

You can use an X.509 certificate from any other CA. However, by default, all users are prompted to accept or decline these certificates because they cannot be validated by SGD, see User Prompts and X.509 Certificates for details. With additional configuration you can add support for a new CA, or add support if your X.509 certificate is signed by an Intermediate CA, so that users are not prompted and certificates are validated.

Obtaining and Installing an X.509 Certificate

Use the following procedure to obtain and install an X.509 certificate for use with SGD security services. If you already have an X.509 certificate for another application, such as a web server, you might be able to share that certificate with the SGD server.

If you are using the multiple external DNS names feature for an SGD server, make sure you have a list of all the DNS names used for the SGD server. SGD supports the subject alternative name (subjectAlternativeName) extension for X.509 certificates. This allows you to associate more than one DNS name with an X.509 certificate.

1. Log in as superuser (root) on the SGD host.
2. Generate a Certificate Signing Request (CSR).
   1. Use the tarantella security certrequest to generate the CSR. For example:

      # tarantella security certrequest \
        --country US \
        --state Massachusetts \
        --orgname "Indigo Insurance" 

      The following prompt displays:

      The host name to be used in the certificate request is boston.indigo-insurance.com.
      
      Do you want to use this hostname? [yes]

      Note If the SGD server has been configured with multiple external DNS names, the first DNS name in the list is used by default.

   2. Accept or change the default host name.

      Type y to accept the default host name.

      Type n to change the default host name.

      Do you want to use this hostname? [yes] n
      Enter the fully qualified hostname [boston.indigo-insurance.com] www.indigo-insurance.com

      The following prompt displays:

      Do you want to add any additional hostnames? [no]

      Press the Return key if you do not want to add any additional host names to the CSR.

   3. (Optional) Add additional host names to the CSR.

      Type y and type the subject alternative names for the certificate.

      Press the Return key after typing each name.

      Press the Return key twice to finish entering the additional host names.

      Do you want to add any additional hostnames? [no] y
      
      Type in the subject alternative names for the certificate, one per line. Enter a blank line to finish.
      
      subjectAltName: boston.indigo-insurance.com
      subjectAltName:

3. Send the CSR to a supported Certificate Authority.
4. Copy the returned certificate to a temporary file and install it.

   Save the certificate to a temporary file, for example /tmp/cert.

   Install the certificate with the following command:

   # tarantella security certuse < /tmp/cert 

5. Restart the SGD server.
6. Enable secure connections to the SGD server.

   Use the tarantella security start command.

Using an X.509 Certificate for Another Product With SGD

To use an X.509 certificate that was originally obtained for another product (such as a web server) with SGD, you must have access to the private key for that certificate. If the private key was originally encrypted by a product that uses the SSLeay or OpenSSL certificate libraries, you can obtain the private key by decrypting it.

If you do not have access to the private key or the key was not originally encrypted by a product that uses SSLeay or OpenSSL certificate libraries, you must obtain and install a separate X.509 certificate.

To install an X.509 certificate by decrypting the private key:

1. Log in as superuser (root).
2. Copy the X.509 certificate and key file to a safe place that can only be accessed by root.

   For example:

   # cp /usr/local/apache/certs/boston.indigo-insurance.com.pem /opt/tarantella/var/tsp/
   # cp /usr/local/apache/certs/boston.indigo-insurance.com.key.pem /opt/tarantella/var/tsp/

3. Decrypt the X.509 certificate's key.

   Use the tarantella security decryptkey command, for example:

   # tarantella security decryptkey  \
     --enckey /opt/tarantella/var/tsp/boston.indigo-insurance.com.key.pem \
     --deckey /opt/tarantella/var/tsp/boston.indigo-insurance.com.key.out \
     --format PEM

4. Install the X.509 certificate using the decrypted key file.

   Use the tarantella security certuse command to install the X.509 certificate using the decrypted key file, for example:

   # tarantella security certuse
     --certfile /opt/tarantella/var/tsp/boston.indigo-insurance.com.pem
     --keyfile /opt/tarantella/var/tsp/boston.indigo-insurance.com.key.out

5. Restart the SGD server.
6. Enable secure connections to the SGD server.

   Use the tarantella security start command.

X.509 certificates are stored in the /opt/tarantella/var/tsp directory on each SGD server.

Adding Support for Additional Certificate Authorities

By default, the SGD supports a number of Certificate Authorities. You can use a Base 64-encoded PEM-format X.509 certificate from an unsupported Certificate Authority (CA) without extra configuration, but certificates are not validated and users are prompted to accept or decline the certificate. This is a potential security risk.

To support additional CAs and allow certificates to be validated, you must install the CA's certificate (or root certificate). If the X.509 certificate was signed by an Intermediate CA, you must create and install the certificate chain.

You install a CA certificate (root certificate) as follows:

1. Log in as superuser (root) on the SGD host.
2. Install the CA's certificate (root certificate).

   Use the following command:

   # tarantella security customca

   Paste the root certificate in PEM format to standard input.

3. Install the X.509 certificate on users' client devices.

   If the X.509 certificate is issued by an unsupported CA, the Sun Secure Global Desktop Client always prompts users about the certificate the first time they connect to the server. If users accept the certificate permanently, they are not prompted about the certificate again. The only way to prevent users from being prompted about the certificate is to do the following:

   1. Add the server certificate to the certstore.pem file on the client device. The certificate is in the /opt/tarantella/var/tsp/cert.pem file on each host. The certstore.pem file is stored in the same location as the user's client profile cache.
   2. Add the host name and fingerprint of the certificate to the hostsvisited file on the client device. Use the tarantella security fingerprint command on each host to obtain these details. The hostsvisited file is stored in the same location as the user's client profile cache.
4. Restart the SGD server.
5. Enable secure connections to the SGD server.

   Use the tarantella security start command.

Using Chained Certificate Authority Certificates

Chaining allows the use of intermediate Certificate Authorities. For example, an X.509 server certificate might be signed by an intermediate Certificate Authority, whose own certificate is issued by a different Certificate Authority.

You can use X.509 server certificates that are signed in this way with SGD. However, the certificates for all the links in the chain must be combined and then installed. You do this as follows:

1. Log in as superuser (root).
2. Combine all the certificates in the chain into a file.

   For example, create a file called mychainedcerts.pem.

   The certificate of the CA used to sign the X.509 certificate must appear first, for example:

   -----BEGIN CERTIFICATE-----
   ...
   Intermediate CA's certificate
   ...
   -----END CERTIFICATE-----
   
   -----BEGIN CERTIFICATE-----
   ...
   CA root certificate
   ...
   -----END CERTIFICATE-----

3. Install the certificate chain.

   Use the following the command:

   # tarantella security customca --rootfile mychainedcerts.pem

4. Restart the SGD server.
5. Enable secure connections to the SGD server.

   Use the tarantella security start command.

If any certificate in the chain is corrupt or invalid, users see a "Certificate Authority not recognized" message when they try to log in to SGD, and they are denied access.

Sharing an SGD Server X.509 Certificate With the SGD Web Server

The SGD Web Server is pre-configured to be a secure (HTTPS) web server and use the same X.509 certificate as the SGD server. This is configured in the Apache configuration file /opt/tarantella/webserver/apache/apache_version/conf/httpd.conf.

See Securing Connections Between Client Devices and SGD Servers for details on enabling HTTPS connections to the SGD Web Server.

Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.