1.5 Secure Connections to SGD Servers

You normally configure secure connections to SGD servers by installing SGD in secure mode. Secure mode is the default method of installing SGD and configures secure connections automatically, as described in Section 1.5.3, “Enabling Secure Connections (Automatic Configuration)”.

You can also install SGD without configuring secure connections. This is called installing in non-secure mode.

About Secure Mode Installation

When you install SGD in secure mode, the following connections are secured:

  • AIP connections. AIP connections are secured by installing an SSL certificate on the SGD server and enabling SGD security services. SGD security services enable SGD to use Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to provide secure connections to an SGD server.

    Caution

    If you do not specify certificate details during installation, a self-signed SSL certificate is created and installed automatically. Only use a self-signed SSL certificate for test purposes.

  • HTTP connections. HTTP connections are secured by enabling HTTPS connections on the SGD web server. HTTPS connections are enabled using the --https argument when the SGD server or the SGD web server is started.

    The SGD web server is preconfigured to be a HTTPS web server and use the same SSL certificate as the SGD server.

    If HTTPS connections have been enabled on an SGD server, you must enable HTTPS connections for every SGD web server in the array. You must not mix HTTP and HTTPS web servers in the same SGD array and every SGD web server in the array must use the same HTTPS port.

When you install in secure mode, firewall forwarding is disabled.

Once you enable secure connections, ensure that users have an HTTPS URL for the Login URL in their client profile. See Section 6.2, “Client Profiles”.

For an SGD server that has been installed in secure mode, you can reconfigure secure connections at a later date by using manual configuration. See Section 1.5.4, “Enabling Secure Connections (Manual Configuration)”.

About Non-Secure Mode Installation

When you install SGD in non-secure mode, the HTTP connections to the SGD web server are not secure. The initial AIP connection to an SGD server is secure, but after the user is logged in, the AIP connection is downgraded to a standard connection.

For an SGD server that has been installed in non-secure mode, you can enable secure connections at a later date by using automatic configuration or manual configuration. Automatic configuration is the easiest to use, see Section 1.5.3, “Enabling Secure Connections (Automatic Configuration)”.

This section includes the following topics:

1.5.1 SSL Certificates

An SSL certificate is an encoded file that a secure service, such as a web server, uses to identify itself to a client. When secure connections are enabled, an SGD server requires an SSL certificate.

The SGD web server is preconfigured to use the same SSL certificate as the SGD server. This is configured in the Apache configuration file, /opt/tarantella/webserver/apache/apache-version/conf/httpd.conf. You can use a separate SSL certificate for the SGD web server if you prefer.

SGD supports Privacy Enhanced Mail (PEM) Base 64-encoded X.509 certificates. These certificates have the following structure:

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

SGD supports the Subject Alternative Name (subjectAltName) extension for SSL certificates. The SSL certificate is accepted by the SGD Client if any of the Subject Alternative Names match the name of the SGD server you are connecting to.

SGD also supports the use of the * wildcard for the first part of the domain name, for example *.example.com.

Subject Alternative Names and wildcards can be specified when you generate a certificate signing request (CSR). See Section 1.5.1.4, “How to Generate a Certificate Signing Request”.

1.5.1.1 Supported Certificate Authorities

A server SSL certificate is issued by a Certificate Authority (CA). A CA is a trusted third party that digitally signs a server SSL certificate using a CA, or root, certificate.

SGD includes support for a number of CA certificates by default. The /opt/tarantella/etc/data/cacerts.txt file contains the X.500 Distinguished Names (DNs) and MD5 signatures of all the CA certificates that SGD supports.

If you need to create a certificate signing request (CSR) for signing by a CA, see Section 1.5.1.4, “How to Generate a Certificate Signing Request”.

You can use a server SSL certificate that is signed by an unsupported CA. However, by default, all users are prompted to accept or decline these certificates because they cannot be validated by SGD. This is a potential security risk. See Section 1.5.5, “Secure Connections and Security Warnings” for more details.

SGD supports the use of certificate chains. With certificate chains, an Intermediate CA signs an SSL certificate with a CA certificate that is issued by another CA.

If your server SSL certificate is signed by an unsupported CA, or an Intermediate CA, you must install the CA certificate or certificate chain.

1.5.1.2 Self-Signed SSL Certificates

SGD enables you to create self-signed server SSL certificates for test purposes, for example, while you are waiting to complete the registration requirements before the SSL certificate can be generated. Self-signed certificates are valid for 365 days.

Only use self-signed SSL certificates in a test environment because self-signed SSL certificates are not truly secure. While a self-signed SSL certificate can be used to give users secure connections, users have no guarantee that the server they are connecting to is genuine.

You can create self-signed SSL certificates with the following commands:

  • tarantella security selfsign – Enables you to self-sign a CSR generated with the tarantella security certrequest command

  • tarantella security enable – Enables you to configure a secure SGD server automatically and install a server SSL certificate

1.5.1.3 Using an SSL Certificate Obtained for Another Product

You can use an SSL certificate that was originally obtained for another product, such as a web server. To do this, you must have the private key for that certificate. If the private key is encrypted by a product that uses the SSLeay or OpenSSL certificate libraries, you can obtain the private key by decrypting it with the tarantella security decryptkey command. If you do not have the private key, you must obtain a new server SSL certificate.

1.5.1.4 How to Generate a Certificate Signing Request

  1. Log in as superuser (root) on the SGD host.

  2. Generate a CSR.

    Use the tarantella security certrequest command to generate the CSR.

    SGD supports the Subject Alternative Name (subjectAltName) extension for server SSL certificates. This enables you to associate more than one DNS name with an SSL certificate. See Section 1.2, “DNS Names” for details.

    SGD supports the use of the * wildcard for the first part of the domain name, for example *.example.com.

    Generating the CSR also creates the public and private key pair.

    On the SGD server, the CSR is stored in the /opt/tarantella/var/tsp/csr.pem file, and the private key is stored in the /opt/tarantella/var/tsp/key.pending.pem file.

    If you are replacing a server SSL certificate, for example because it is about to expire, you can generate a CSR without affecting your current certificate.

    In the following example, a CSR is generated for the SGD server boston.example.com. This server also has an external DNS name of www.example.com and so this name is added as a Subject Alternative Name.

    # tarantella security certrequest \
    --country US --state Massachusetts --orgname "Example Com"
     
    The certificate's common name (CN) will be:  boston.example.com
     
    This hostname is included in the Certificate Signing Request (CSR) and
    corresponds to the name of the server that users will connect to.
     
     - If DNS names are used to connect to the server, the hostname above
       MUST be a fully qualified DNS name.
     
     - If clients are required to connect to the server using an IP address,
       the hostname above should be the IP address. A DNS record for this
       IP address SHOULD NOT exist.
     
    For clients to accept the certificate once it's installed, a DNS
    lookup of the hostname followed by a reverse lookup of the result must
    return the original hostname.
     
    The hostname to be used in the certificate request is
    boston.example.com.
     
     
    Do you want to use this hostname? [yes] y
     
     
    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: www.example.com
    subjectAltName:
    2048 semi-random bytes loaded
    Generating RSA private key, 2048 bit long modulus
    ..++++++
    ...........................................................++++++
    e is 65537 (0x10001)
     
    --------------------------------------------------------------------------
    Certificate Signing Request (CSR): Summary
    --------------------------------------------------------------------------
     
    ...
    Subject:
     C=US, ST=Massachusetts, O=Example Com, CN=boston.example.com
     
    ...
     
    X509v3 Subject Alternative Names:
     DNS:boston.example.com, DNS:www.example.com
     
    ...
     
    The information above will be contained in the CSR.
     
    Create CSR now? [yes] y
     
    Send the following Certificate Signing Request (CSR) to a Certificate
    Authority, such as VeriSign (www.verisign.com). Check with your CA
    that you're providing all the information they need.
     
    ------CUT HERE------
    -----BEGIN CERTIFICATE REQUEST-----
    NhY2h1c2V0MIIB5TCCAU4CAQAwXDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3
    dpZS5VdHMxGTAXBgNVBAoTEEluZGlnbyBJbnN1cmFuY2UxGjAYBgNVBAMTEXJhZG
    sd+SmX7zz6Sy5TdW4uQ09NMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDbWM
    sMqBs7gQw8Q1Gk3NAypySP6aRiEItLrfSlZ8XgKXmjmlLtb03V9JonjLfhH3fBzk
    gnOG6EpTmJM4y3OOpEXZZ2yhtWgsQsXyLWbfTLWZPfHLPI5ztEEJ7Z0G6dpeG0xg
    wODA2ApAp6sIrmBqbZG2Aaf5poB+FQ4lsmQIDAQABoEkwRwYJKoZIhvcNAQkOMTo
    N1cmFuBgNVHREELzAtghFyYWRnaWUuVUsuU3VuLkNPTYIYd3d3LmluZGlnby1pbn
    V617E7oFKY2UuY29tMA0GCSqGSIb3DQEBBQUAA4GBAMsOieZzrGHN7fkW6LmYNHW
    sW1tmHeFjekpiUiTLYE+KUZXKKCH9f1eo+nfwFdi9VOomIdga4uehl+4acqqiGEe
    W4iIb9BC9b/V1pA/lGJwWN0aDDB3/d47UGAlli+spW37chg53Fp7eP2xIYWfJR6O
    35eSPZm42dyp
    -----END CERTIFICATE REQUEST-----
    ------CUT HERE------
     
    When you receive your certificate, use 'tarantella security certuse'
    or 'tarantella security enable' to install it.
    
  3. Send the CSR to a CA.

    See Section 1.5.1.1, “Supported Certificate Authorities” for details of the CAs that SGD supports by default.

    Either copy the CSR as output from the command line, or use the copy of the CSR that is stored in the /opt/tarantella/var/tsp/csr.pem file on the SGD server.

1.5.1.5 How to Replace a Server SSL Certificate

Use the following procedure to replace the server SSL certificate for an SGD server, for example because the original SSL certificate is about to expire.

  1. (Optional) Generate a CSR and send it to a CA.

    See Section 1.5.1.4, “How to Generate a Certificate Signing Request”.

  2. Install the server SSL certificate.

    See Section 1.5.4.1, “How to Install a Server SSL Certificate”.

  3. (Optional) Install the CA certificate.

    Perform this step only if the server SSL certificate is signed by an unsupported CA, or an Intermediate CA, see Section 1.5.1.1, “Supported Certificate Authorities”.

    The certificates that must be installed are as follows:

  4. Restart the SGD server and SGD web server.

    You must restart the SGD server to ensure that the new server SSL certificate is used for secure connections.

    Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

    Use the following command:

    # tarantella restart
    

1.5.2 Firewall Traversal

AIP connections to an SGD server are made on TCP ports 3144 and 5307. If it is not possible to open the required ports in your firewalls, you can direct all SGD traffic through a single port, usually port 443. To do this, you can use either of the following:

The SGD Gateway is the best solution for traversing firewalls, and has other benefits such as load-balanced HTTP connections.

1.5.2.1 The SGD Gateway

The SGD Gateway is an optional SGD component. It is a proxy server designed to be deployed in front of an SGD array in a demilitarized zone (DMZ), and it enables an SGD array to be located on your internal network. Additionally, all connections can be authenticated in the DMZ before any connections are made to the SGD servers in the array.

Instructions on how to install, configure, and use the SGD Gateway are included in the Oracle Secure Global Desktop Gateway Administration Guide.

1.5.2.2 Using Firewall Forwarding

If you are not using the SGD Gateway, you can use firewall forwarding to give users access to SGD using a single port. With firewall forwarding, you configure the SGD server to listen on port 443. The SGD server then forwards all traffic that is not AIP traffic to the SGD web server.

If SGD is configured for firewall forwarding, you cannot use some SGD features, such as those that depend on filtering the IP address of the client device. This means you cannot use the following features:

If you use firewall forwarding, you can configure a single external DNS name, for example *:www.example.com, and then use split DNS so that clients can resolve the name to different IP addresses, depending on whether they are inside or outside the firewall.

1.5.3 Enabling Secure Connections (Automatic Configuration)

The tarantella security enable command enables you to quickly configure and enable secure connections. You can only use this command if both of the following are true:

  • The SGD installation is a fresh installation using standard connections. There must have been no attempt to configure SGD secure connections.

  • The SGD server is not joined with other SGD servers in an array.

If these conditions are not met, the tarantella security enable command fails and you must enable security by configuring it manually. See Section 1.5.4, “Enabling Secure Connections (Manual Configuration)”.

The tarantella security enable command performs the following configuration:

To install an SSL certificate, you must already have the certificate and private key. If you need to submit a CSR for signing by a CA, see Section 1.5.1.4, “How to Generate a Certificate Signing Request”.

If you do not specify a server SSL certificate to install, the tarantella security enable command creates and installs a self-signed SSL certificate. If you want to install a server SSL certificate later, use the tarantella security disable command to restore the security settings to their previous state. You can then run the tarantella security enable command again and specify a server SSL certificate.

By default, the tarantella security enable command does not configure the SGD server to use firewall forwarding. Use the --firewalltraversal on option if you want to enable security with firewall forwarding. Alternatively, you can enable firewall forwarding at a later stage by doing either of the following:

  • Use the tarantella security disable command to restore the security settings to their previous state. Then use tarantella security enable with the --firewalltraversal on option to configure the SGD server for firewall forwarding.

  • Enable firewall forwarding manually. See Section 1.5.4.4, “How to Configure Firewall Forwarding” for details of how to do this.

Caution

SGD servers configured for firewall forwarding cannot be used with the SGD Gateway, or with tablet devices.

1.5.3.1 How to Enable Secure Connections (Automatic Configuration)

Before you begin, ensure you have access to the server SSL certificate, and the private key and CA certificate, if needed. The certificates must be in PEM format.

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

Ensure that the SGD server is running. You can use the tarantella status command to show the current status of an SGD server.

  1. Log in as superuser (root) on the SGD host.

  2. Install a server SSL certificate and enable SGD security services.

    Use the tarantella security enable command to install a server SSL certificate and enable SGD security services.

    If you used the tarantella security certrequest command to generate a CSR, you can omit the --keyfile option. The key stored in the /opt/tarantella/var/tsp/key.pending.pem file is used. When you install the server SSL certificate, the private key is moved to the /opt/tarantella/var/tsp/key.pem file.

    Caution

    If you use the --certfile option and the --keyfile option together, SGD creates symbolic links to the SSL certificate file and the key file in the /opt/tarantella/var/tsp directory on the SGD server. Do not delete or move the SSL certificate file or key file after running this command.

    If you do not specify a server SSL certificate to install, the tarantella security enable command generates a CSR, and then creates and installs a self-signed SSL certificate. Only use a self-signed SSL certificate for test purposes.

    SGD supports a number of CAs by default. Only use the --rootfile option if the server SSL certificate is signed by an unsupported CA, or by an Intermediate CA. See Section 1.5.1.1, “Supported Certificate Authorities” for details.

    If the server SSL certificate is signed by an Intermediate CA, combine all the certificates in the CA certificate chain into a file. The certificates must be in PEM format. The CA certificate used to sign the server SSL certificate must appear first, for example:

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

    If you specify the path to a certificate or key file, you must specify the full path to the file. The path must be readable by the ttasys user.

    Caution

    If you use the SGD Gateway, do not use the --firewalltraversal on option to enable security with firewall forwarding. SGD servers configured for firewall forwarding cannot be used with the SGD Gateway.

    If you do not specify a --firewalltraversal option, firewall traversal is disabled by default.

    The CSR, the SSL certificate, the private key, and the CA certificate are stored in the /opt/tarantella/var/tsp directory on the SGD server.

    A symbolic link to the SSL certificate is created in the /opt/tarantella/var/tsp/certs/array directory.

    The configuration profile on the SGD server is updated. See Section 1.5.6.1, “Configuration Profiles for iOS Devices”.

    A .crt certificate file, used by some tablet devices, is generated and installed on the SGD server. See Section 1.5.6.2, “Installing Certificates on Android Devices”.

    • If the server SSL certificate is signed by a supported CA, and the tarantella security certrequest command was used to generate a CSR, use the following command:

      # tarantella security enable --certfile certificate-path
      
    • If the server SSL certificate is signed by a supported CA, and the tarantella security certrequest command was not used to generate a CSR, use the following command:

      # tarantella security enable \
      --certfile certificate-path --keyfile key-path
      
    • If the server SSL certificate is signed by an unsupported CA, or an Intermediate CA, use the following command:

      # tarantella security enable \
      --certfile certificate-path [--keyfile key-path] \
      --rootfile CA-certificate-path
      
    • To enable SGD security services with firewall forwarding using a self-signed SSL certificate, use the following command:

      # tarantella security enable --firewalltraversal on
      

1.5.4 Enabling Secure Connections (Manual Configuration)

Enabling secure connections with manual configuration involves the following steps:

  1. (Optional) Generate a Certificate Signing Request (CSR) and send it to a CA.

    See Section 1.5.1.4, “How to Generate a Certificate Signing Request”.

    This step is optional if you obtain a server SSL certificate without using the tarantella security certrequest command to generate a CSR.

    If you already have an SSL certificate for another product, such as a web server, you might be able to use that certificate. See Section 1.5.1.3, “Using an SSL Certificate Obtained for Another Product”.

  2. Install an SSL certificate for each SGD server in the array.

    To use secure connections, an SGD server must present an SSL certificate to identify itself to an SGD Client. See Section 1.5.4.1, “How to Install a Server SSL Certificate”.

  3. (Optional) Install the CA certificate.

    Perform this step only if the server SSL certificate is signed by an unsupported CA, or an Intermediate CA, see Section 1.5.1.1, “Supported Certificate Authorities”.

    The certificates that must be installed are as follows:

  4. (Optional) Configure SGD for firewall forwarding.

    For details of when to use firewall forwarding, see Section 1.5.2, “Firewall Traversal”.

    See Section 1.5.4.4, “How to Configure Firewall Forwarding”.

  5. Enable SGD security services and restart SGD.

    To enable secure connections, you must enable SGD security services and restart SGD.

    See Section 1.5.4.5, “How to Enable SGD Security Services for an SGD Server”.

  6. (Optional) Configure the SGD server for connections from tablet devices.

    This step is only required if your users are connecting to the SGD server with a tablet device and the SGD server uses an untrusted certificate.

    See Section 1.5.6, “Secure Connections to Tablet Devices Using Untrusted Certificates”.

1.5.4.1 How to Install a Server SSL Certificate

Use the following procedure to install a server SSL certificate that was obtained by using the tarantella security certrequest command to generate a CSR.

Before you begin, ensure you have access to the server SSL certificate. The SSL certificate must be in PEM format.

  1. Log in as superuser (root) on the SGD host.

  2. Install the server SSL certificate.

    Use the tarantella security certuse command to install the SSL certificate.

    If you are replacing a server SSL certificate, for example because the original SSL certificate is about to expire, the tarantella security certuse command prompts you for confirmation before overwriting the SSL certificate and private key.

    When you install the server SSL certificate, the private key stored in the /opt/tarantella/var/tsp/key.pending.pem file is moved to the /opt/tarantella/var/tsp/key.pem file.

    If you specify the path to a file, you must specify the full path to the file. The path must be readable by the ttasys user.

    The CSR, the SSL certificate, and the private key are stored in the /opt/tarantella/var/tsp directory on the SGD server.

    A symbolic link to the SSL certificate is created in the /opt/tarantella/var/tsp/certs/array directory.

    • To install the SSL certificate from standard input, use the following command:

      # tarantella security certuse
      

      Paste the server SSL certificate in to standard input and press Control-D.

    • To install the SSL certificate from a temporary file, use the following command:

      # tarantella security certuse < /tmp/cert
      
    • To install the SSL certificate from a permanent file, use the following command:

      # tarantella security certuse --certfile /opt/certs/cert.pem
      
      Caution

      This command creates a symbolic link to the SSL certificate file stored in the /opt/tarantella/var/tsp directory on the SGD server. Do not delete or move the SSL certificate file after running this command.

1.5.4.2 How to Install the CA Certificate for an Unsupported CA

Before you begin, ensure you have access to the CA certificate. The CA certificate must be in PEM format.

  1. Log in as superuser (root) on the SGD host.

  2. Install the CA certificate.

    Use the tarantella security customca command.

    • To install the CA certificate from standard input, use the following command:

      # tarantella security customca
      

      Paste the CA certificate in to standard input and press Control-D.

    • To install the CA certificate from a file, use the following command:

      # tarantella security customca --rootfile /tmp/cert
      

      Specify the full path to the file. The path must be readable by the ttasys user.

1.5.4.3 How to Install a CA Certificate Chain

Before you begin, ensure that you have all the certificates in the CA certificate chain. The certificates must be in PEM format.

  1. Log in as superuser (root) on the SGD host.

  2. Combine all the certificates in the chain into a file.

    For example, create a file called chainedcerts.pem.

    The CA certificate used to sign the server SSL certificate must appear first, for example:

    -----BEGIN CERTIFICATE-----
    ...Intermediate CA's certificate...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...CA root certificate...
    -----END CERTIFICATE-----
    
  3. Install the CA certificate chain.

    Use the tarantella security customca command.

    • To install the CA certificate from standard input, use the following command:

      # tarantella security customca
      

      Paste the CA certificate chain in to standard input and press Control-D.

    • To install the CA certificate from a file, use the following command:

      # tarantella security customca --rootfile /tmp/chainedcerts.pem
      

      Specify the full path to the file. The path must be readable by the ttasys user.

1.5.4.4 How to Configure Firewall Forwarding

  1. Configure each SGD web server in the array to bind to localhost and TCP port 443.

    Repeat the following step on each SGD web server in the array.

    1. Log in as superuser (root) on the SGD host.

    2. Edit the Apache configuration file.

      The configuration file is /opt/tarantella/webserver/apache/apache-version/conf/httpd.conf.

    3. Change the <IfDefine SSL> directive in the SSL Support section.

      Change the directive to the following:

      <IfDefine SSL>
      Listen 127.0.0.1:443
      </IfDefine>
      
    4. Save the changes.

  2. Log in as superuser (root) on the primary SGD server in the array.

  3. Configure each SGD server in the array to use TCP port 443 for encrypted connections.

    Use the following command:

    # tarantella config edit --array-port-encrypted 443
    
    Tip

    You can also configure the port in the Administration Console. Go to the Global Settings, Communication tab. Enter 443 in the Encrypted Connections Port field.

  4. Configure each SGD server in the array to forward HTTP traffic to the SGD web server.

    Use the following command:

    # tarantella config edit --array \
    --security-firewallurl https://127.0.0.1:443
    
    Tip

    You can also configure the port in the Administration Console. Select an SGD server and go to the Security tab. Enter https://127.0.0.1:443 in the Firewall Forwarding URL field.

  5. Check that the firewall forwarding URL has taken effect for each SGD server in the array.

    Use the following command to check each server:

    # tarantella config list --server serv --security-firewallurl
    

1.5.4.5 How to Enable SGD Security Services for an SGD Server

Ensure that the SGD server is running. You can use the tarantella status command to show the current status of an SGD server.

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log in as superuser (root) on the SGD host.

  2. Enable SGD security services.

    Use the following command:

    # tarantella security start
    
  3. Restart the SGD server and SGD web server.

    Use the following command:

    # tarantella restart --https 
    

    Once security is enabled, security services are available whenever SGD restarts.

1.5.5 Secure Connections and Security Warnings

When using secure connections to SGD, users see some or all of the following security warnings:

  • Browser and Java Plug-in software security warnings

  • SGD server SSL certificate security warnings

  • Untrusted initial connection warnings

Note

Users might see these warnings even if SGD security services are not enabled. This is because the initial connection between an SGD Client and an SGD server is always secure.

This section describes why these warnings occur and what you can do about them.

1.5.5.1 Browser and Java Plug-in Software Security Warnings

If you have enabled secure connections (HTTPS) to the SGD web server, users see a warning if the CA or root certificate used to sign the web server SSL certificate is not available in the browser's certificate store. To enable the web server SSL certificate to be validated without displaying a security warning, import the CA or root certificate into the user's browser certificate store. Use the browser's tools to do this.

If Java technology is enabled in the browser, the Java Plug-in software might also warn users about the web server's SSL certificate. This depends on the configuration in the Java Control Panel. Note that for some versions of Java Plug-in Software, the default Java Security Level configuration means that security warnings are always displayed when untrusted certificates are used.

By default, the Java Plug-in software is configured to use the certificates in the browser certificate store. If the Plug-in software is not configured to do this, you might have to import the CA or root certificate using the Java Control Panel.

1.5.5.2 SGD Server SSL Certificate Security Warnings

When a user logs in to an SGD server that has a server SSL certificate, the SGD Client validates the certificate before proceeding.

If there is a problem with a server SSL certificate, users see a security warning message. The security warning message enables users to view the SSL certificate details before deciding to accept the SSL certificate permanently or temporarily, or to reject it. Figure 1.1, “Example SGD Server SSL Certificate Security Warning Message” shows an example security warning message.

Figure 1.1 Example SGD Server SSL Certificate Security Warning Message

Screenshot of an example security warning message.

If users reject the SSL certificate, the connection to SGD is terminated.

If users accept the SSL certificate temporarily, and they agree to the initial connection, the SSL certificate details are cached for the lifetime of the user session. When users next log in, they are prompted about the SSL certificate again. If users accept the SSL certificate permanently, and they agree to the initial connection, they are not prompted about the SSL certificate again. For details about agreeing to the initial connection, see Section 1.5.5.3, “Untrusted Initial Connection Warnings”.

Users see security warnings about SSL certificates in the following circumstances:

  • Invalid dates – The current date is earlier than the Not Before date in the SSL certificate, or the current date is later than the Not After date in the SSL certificate

  • Incorrect hostname – The name of the host the SGD Client is connecting to does not match the Subject or Subject Alt Name in the SSL certificate

  • Issuer unknown – The SSL certificate is signed by an unsupported CA

For details about how to avoid issuer unknown security warnings, see Avoiding Issuer Unknown Security Warnings.

1.5.5.3 Untrusted Initial Connection Warnings

SGD requires users to authorize their connections to SGD so that they only connect to servers they trust. The first time a user connects to an SGD server, they see an Untrusted Initial Connection message advising that they are connecting to a server for the first time, as shown in Figure 1.2, “Untrusted Initial Connection Warning”.

Figure 1.2 Untrusted Initial Connection Warning

Screen capture of the Untrusted Initial Connection warning.

Users can check the SSL certificate details by clicking the View Certificate button and checking that the Validity and Subject details are correct. Users must do this before clicking Yes to agree to the connection. When a user agrees to a connection, the following files are updated on the client device:

  • hostsvisited

  • certstore.pem

The hostsvisited and certstore.pem files are stored in the same location as the user's client profile cache. See Section 6.2.5, “About the Profile Cache” for details.

When a user agrees to a connection to an SGD server, the hostsvisited file on the client device is updated with the name of the SGD server. If the server SSL certificate is signed by an unsupported CA, the fingerprint of the CA certificate is also added. The user is not prompted about the connection again, unless there is a problem.

When a user agrees to a connection to an SGD server, and the server SSL certificate is valid, the server SSL certificate is added to the certstore.pem file on the client device.

If there is a problem with the server SSL certificate, for example because it is signed by an unsupported CA, users see a certificate security warning, as described in Section 1.5.5.2, “SGD Server SSL Certificate Security Warnings”. If a user permanently accepts the SSL certificate, or the SSL certificate and its CA chain, and agrees to the connection to an SGD server, the SSL certificate is added to the certstore.pem file on the client device. When the user next logs in, they are not prompted about the SSL certificate. If a user accepts the SSL certificate temporarily, and they agree to the connection to an SGD server, the SSL certificate is not added to the certstore.pem file on the client device. When the user next logs in, they are prompted about the SSL certificate.

If there is a problem with the connection, for example because the server SSL certificate has changed, a Potentially Unsafe Connection message displays, as shown in Figure 1.3, “Potentially Unsafe Connection Message”.

Figure 1.3 Potentially Unsafe Connection Message

Screen capture of the Potentially Unsafe Connection warning.

To ensure that users only connect to SGD servers that are trusted, SGD Administrators can do the following:

See also Avoiding Issuer Unknown Security Warnings for details of how to prevent users from seeing issuer unknown security warnings.

Using a Preconfigured hostsvisited File

A preconfigured hostsvisited file can be used to prevent users from seeing a warning when the SGD Client first connects to an SGD server. You can also use it to restrict the SGD servers to which the SGD Client can connect.

To use a preconfigured hostsvisited file, first create a file containing the host names of all the SGD servers. If the server SSL certificate for an SGD server is signed by an unsupported CA, you must also add the fingerprint of the CA certificate. The easiest way to do this is to copy and edit an existing hostsvisited file, and then install it on client devices. You can also obtain the CA certificate fingerprint using the tarantella security fingerprint command.

You can manually add an <allowhostoverride> line to the hostsvisited file. If the value of <allowhostoverride> line is 0, the SGD Client can only connect to SGD servers that have entries in the hostsvisited file. If the value of <allowhostoverride> line is 1, or if the <allowhostoverride> line is missing, the SGD Client can connect to any SGD server. Users only see a warning when the SGD Client connects to an SGD server that is not listed in the hostsvisited file.The following is an example hostsvisited file.

<?xml version="1.0" encoding="UTF-8" ?>
<array>
 <allowhostoverride>0</allowhostoverride>
 <server peername="boston.example.com">
  <certfingerprint>51:B7:6D:FA:6E:3B:BE:ED:37:73:D4:9D:5B:C5:71:F6
  </certfingerprint>
 </server>
</array>
Avoiding Issuer Unknown Security Warnings

Issuer unknown security warnings occur when the server SSL certificate for an SGD server is issued by an unsupported CA. The warning displays because the issuer of certificate cannot be validated.

The easiest way to avoid issuer unknown security warnings is to ensure that a server SSL certificate is signed by a supported CA. See Section 1.5.1.1, “Supported Certificate Authorities” for details.

To enable the SSL certificate to be validated, you must install the CA certificate or certificate chain. However, even if you install the CA certificate, users see a security warning about the SSL certificate the first time they connect to the SGD server. The only way to prevent users from being warned about the certificate is add the server SSL certificate to the certstore.pem file on the client device. The server SSL certificate is stored in the /opt/tarantella/var/tsp/cert.pem file on each SGD server.

1.5.6 Secure Connections to Tablet Devices Using Untrusted Certificates

The configuration described in this section only applies when the following are true:

  • Your users are connecting to a secure SGD array, either directly or through the SGD Gateway, from a tablet device.

  • Untrusted certificates, such as a self-signed certificates or an SSL certificate signed by a custom CA, are used by the servers in the array.

    Note

    Only use self-signed SSL certificates in a test environment. With a self-signed SSL certificate, users have no guarantee that the server they are connecting to is genuine.

The required security configuration for using untrusted certificates varies, according to the tablet device:

1.5.6.1 Configuration Profiles for iOS Devices

When an iOS device such as an iPad tablet connects to a secure SGD array, the tablet device uses a configuration profile to ensure that the required security certificates are installed. Users are prompted to download and install the configuration profile when they log in to SGD.

A configuration profile is present on each SGD server in the array and contains details of the security certificates used by the array members. A separate configuration profile is used when connecting through the SGD Gateway.

When you install SGD, configuration profiles for the SGD server are created automatically. Additional manual security configuration is required if you join the SGD server to an array, or are using the SGD Gateway. See Section 1.5.6.3, “Security Configuration for SGD Network Deployments”.

Configuration profiles are located in the /opt/tarantella/var/docroot/certs directory on an SGD server, as follows:

  • sgd.mobileconfig. A configuration profile used for connections to the SGD servers in the array.

  • sgdg.mobileconfig. A configuration profile used for connections through one or more SGD Gateways.

An MD5 checksum file for each configuration profile is also included in this directory. The checksum file is used by the SGD Client running on the tablet, to detect whether the configuration profile has changed.

After changes to a configuration profile, users are prompted to reinstall the profile when they next log in to SGD.

Tip

Configuration profiles are only required when untrusted certificates are used with iOS devices. If you are using trusted certificates, you may not want your users to be prompted to install a profile when they log in to SGD.

To disable profile install prompts, delete the MD5 checksum file in the profile installation directory.

To reenable profile install prompts, regenerate the MD5 checksum file by running the mobile_profile_create.sh script. See Section 1.5.6.4, “How to Configure an SGD Array for Secure Connections to Tablet Devices Using Untrusted Certificates”.

A link to download the configuration profile currently being used by SGD is shown when users tap the Info button on the workspace.

1.5.6.2 Installing Certificates on Android Devices

Android devices do not use configuration profiles to download and install certificates automatically. Users are not prompted to download and install a configuration profile when they log in to SGD.

Instead, the user must manually install the certificate used by an SGD server. Tapping the Info button on the workspace displays a link that enables the user to install the certificate on the Android device.

Android devices use .crt certificate files, SGD servers normally use .pem certificate files.

When you install SGD, the required .crt files for the SGD server are created automatically. Additional manual security configuration is required if you join the SGD server to an array, or are using the SGD Gateway. See Section 1.5.6.3, “Security Configuration for SGD Network Deployments”.

The .crt files are located in the /opt/tarantella/var/docroot/certs directory on an SGD server, as follows:

  • array/*.crt. Certificate files for the SGD servers in the array.

  • gateway/*.crt. Certificate files for the SGD Gateway.

The android_certs.html file is used on the Info page on the workspace for manual downloading of certificates.

1.5.6.3 Security Configuration for SGD Network Deployments

If you are using tablet devices to connect to an SGD server which has been secured using an untrusted certificate, some additional manual security configuration steps may be required. The additional security configuration depends on the SGD network deployment, as follows:

  • Standalone SGD server. For a standalone SGD server, no additional security configuration is normally required.

    For a default installation of SGD, the required security configuration is done automatically and the SGD server is configured to work with tablet devices.

    Configuration profiles and .crt certificate files are updated automatically when you use the tarantella security enable or tarantella security disable commands to change the security configuration of a standalone SGD server.

  • SGD array. For an SGD array with more than one array member, additional security configuration is required when using untrusted certificates with tablet devices.

    • The same sgd.mobileconfig configuration profile must be used by all array members. This file must be updated manually with details of the certificates used by the array members, and copied to each server in the array.

    • The .crt certificate file for each array member must be available to all SGD servers. Each SGD server must be updated manually to include the certificates used by the array members.

    See Section 1.5.6.4, “How to Configure an SGD Array for Secure Connections to Tablet Devices Using Untrusted Certificates”.

    Note

    Security configuration for the array must be repeated if there is a change to any of the server certificates, or if a new server certificate is introduced. For example, when a new array member joins the array.

  • Using the SGD Gateway. If the Gateway uses an untrusted certificate, additional security configuration is required when using tablet devices.

    • The Gateway SSL certificates must be copied to the SGD array.

      For Gateway SSL certificates signed by a custom CA or Intermediate CA, the CA certificates must also be included.

    • The configuration profile for the Gateway, sgdg.mobileconfig, must be updated manually with details of these certificates and copied to each array member.

    See How to Configure the SGD Gateway for Connections From Tablet Devices Using Untrusted Certificates in the Oracle Secure Global Desktop Gateway Administration Guide.

1.5.6.4 How to Configure an SGD Array for Secure Connections to Tablet Devices Using Untrusted Certificates

This procedure assumes you have enabled security services for the SGD servers in the array, either during a default installation or by enabling security automatically as described in Section 1.5.3, “Enabling Secure Connections (Automatic Configuration)”.

Before you begin, ensure you have access to the server SSL certificates used by each server in the array. The certificates must be in PEM format.

For server SSL certificates signed by a custom CA or Intermediate CA, you also need the CA certificates.

  1. Log in as superuser (root) on the primary SGD host.

  2. Copy the SSL certificates from the other SGD servers in the array to the primary SGD host.

    The SSL certificate for an SGD server is in the /opt/tarantella/var/tsp directory.

    When you copy the certificate, it is best practice to rename the certificate file so that you can identify what the file contains and the SGD server it came from.

    Repeat the following steps for each certificate.

    1. Copy the certificate file to the /opt/tarantella/var/tsp/certs/array directory on the primary SGD host.

      A symbolic link for the certificate used by the primary SGD host is already present in the /opt/tarantella/var/tsp/certs/array directory.

    2. Change the file permissions and ownership for the certificate. For example:

      # chmod 600 sgd1-example-com.pem
      # chown root:ttaserv sgd1-example-com.pem
  3. (Optional) Copy the CA certificate to the primary SGD host.

    This step is only required if the SSL certificates are signed by a custom CA, or by an Intermediate CA.

    1. Copy the CA certificate file to the /opt/tarantella/var/tsp/certs/array directory on the primary SGD host.

      For an Intermediate CA, copy the CA certificate chain.

    2. Check that the file permissions and ownership are correct. For example:

      # chmod 600 sgd-ca.pem
      # chown root:ttaserv sgd-ca.pem
  4. Update the security configuration for the SGD array.

    Use the script provided for this task:

    # /opt/tarantella/bin/scripts/mobile_profile_create.sh
    • The /opt/tarantella/var/docroot/certs/sgd.mobileconfig configuration profile file is updated with details of the certificates used by the SGD servers in the array. The corresponding MD5 checksum file is also updated.

    • The certificates used by the SGD servers in the array are processed and corresponding .crt certificate files are generated in the /opt/tarantella/var/docroot/certs/array directory. The android_certs.html file which lists the certificates is updated.

  5. Copy the updated security configuration files to the other SGD servers in the array.

    Updated security configuration files are in the certs/ directory.

    Repeat the following step on every server in the array.

    1. Copy the /opt/tarantella/var/docroot/certs directory from the primary server to the SGD web server.

      Ensure that file permissions and ownerships are preserved. For example:

      # cp -pr certs/ /opt/tarantella/var/docroot/