When a secure HTTPS connection is used to access a connected object store, SSL certificates are required to setup the secure connection. To ensure the data that is exchanged between the TS7700 and the cloud provider is encrypted, we recommend the use of a secure http connection (https) for accessing the cloud storage.

This chapter provides a brief explanation of certificate authority types and how to configure the TS7700 to trust these certificates.

This chapter includes the following topics:

When an SSL connection is established, one or more certificates are used to secure the connection. The certificates provide a method to encrypt the connection and provides an identity signature that helps any client to certify the server or object store is valid. This identity can be verified through the SSL authority signature that is within the certificate.

The signature can be self-signed by the server device, signed by an organization’s internal authority, or publicly signed by a third party public authority. Independent of how it is signed, a client must trust the authority, which requires the client have a corresponding trust entry that is associated with the certificate authority that signed the certificate. The authority that signed the certificate is referred to as the certificate authority (CA).

Self-signed certificates are generally signed by the server device and then distributed by all exchanges from that point forward. That is, the server device acts as the CA.

After some duration, such as before the certificate expires, a newly self-signed certificate might need to be generated and used from that point forward. By using the same self-signed certificate for a duration of time, client devices’ trust authority lists must be updated only periodically for that server’s internal CA.

However, because each server acts as its own CA and generates its own signature, each client must be updated to trust every server’s internal CA within the organization. A server can also create its own root-like CA in which all self-signed certificates that are generated by that server from that point forward are signed by the same internal CA. In this case, new certificates can be periodically created by that server, yet the clients do not need a trust authority update because they are all signed by the same previously trusted CA for that server.

Internally signed certificates are signed by a centralized authority within the organization. For example, it might be an organization’s own internal root CA, or an assigned CA, acting as authority for all devices within the organization. This method provides a centralized level of control for all devices within an organization. That is, server devices that are not signed by the organization’s root CA, or cannot provide a chain of trust to the root CA, cannot be trusted.

In addition, clients must create only a trust entry, or a chain of trust entry, for the organization’s root CA because all certificates that are used by any server are signed by the same CA. This trust entry results in fewer certificate trust updates across numerous devices. After a client’s trust list includes the organization’s CA, or a chain of trust to the root CA, new certificates can be generated for existing and new devices without the need to update the client’s trust list.

Last, publicly signed certificates are fee-based certificates that are signed by a well-known publicly trusted CA. Client devices have a list of trusts for public CAs; therefore, if the server provides a publicly signed certificate or a chain of certificates that leads to a publicly signed certificate, the client can trust that the server is who it states it is.

Client devices do not need to be manually updated to trust publicly signed CAs because the CA is well-known and trusted. Publicly signed certificates often are associated with broad domain names (for example, *ibm.com) and therefore, often are used by publicly addressable object stores only.

For all cases where a non-public CA is used to sign a certificate, the trusted CA list of the TS7700 must be updated. The TS700 is the client in this case and must trust the server (for example, IBM COS) and the certificates it provides.

The TS7700 management interface can be used to upload a trust of CA or manually download it from a server device. Once within the TS7700, the trusted CA can be assigned to URL connections to selected object stores that are providing the TS7700 permission to trust those connections.

In most use cases, any private object store (for example, IBM COS Private) require a trust CA update in the TS7700. A public object store (for example, *amazonaws.com) most likely does not require a trust update unless you configured your AWS S3 account to use your organization’s own internal CA signed certificates.

In the following sections, we describe how to upload a trust CA into the TS7700 and associate it with connections to a particular object store that uses non-public CAs.

In this section, we describe how to set up your IBM Cloud Object Store and TS7700 to use a self-signed certificate or an external organization-signed certificate.

A self-signed certificate can be generated by using IBM Cloud Object Storage Manager. When an IBM Cloud Object Storage system is initially configured, it automatically generates a self-signing CA that is used to generate certificates for all its addressable nodes. You can choose to have the IBM Cloud Object Storage generate a new CA at any time.

To have an IBM Cloud Object Storage generate a new self-signing CA, select the Administration menu and click the Configure in Certificate Authority Configuration field. In the Certificate Authority Configuration panel, click Edit in the Internal CA field and click Generate new CA.

All client devices that use this IBM Cloud Object Storage device need their trusted CA list updated to communicate with this IBM Cloud Object Storage device after a CA is generated. Therefore, generating a new CA should be done only under agreement from all users of the IBM Cloud Object Storage device.

An internal organization’s CA, or chain of trust to its CA, can be added to IBM Cloud Object Storage by using IBM Cloud Object Storage Manager. Although this CA is internal to the organization, the IBM Cloud Object Storage device views it as external; therefore, it must be updated to use the organization’s CA.

To add the CA into your IBM Cloud Object Storage set up, select the Administration menu and click Configure in Certificate Authority Configuration field. In the Certificate Authority Configuration panel, click Add CA. In the Add External CA panel, follow the steps as described in IBM Knowledge Center.

All client devices that use this IBM Cloud Object Storage device might need their trusted CA list updated if they are not configured to trust the organization's CA. Therefore, having the IBM Cloud Object Storage changed to use a new external CA should be done only under agreement from all users of the IBM Cloud Object Storage device.

After a SSL certificate CA is set up on your IBM Cloud Object Storage, you must update the TS7700 to trust the CA that is used by the IBM Cloud Object Storage device. Which CA type is used determines which method is used to update the TS7700.

For self-signed IBM Cloud Object Storage CAs, you must get a copy of the IBM Cloud Object Storage-generated public trust CA from your IBM Cloud Object Storage device and upload it into the TS7700. By uploading this CA, the TS7700 trusts the certificates that are signed by that particular IBM Cloud Object Storage internal CA. You can have the TS7700 automatically retrieve the trust of CA from the IBM Cloud Object Storage set up, or you can manually upload by using a text file. The manual upload method is recommended, because the CA automatically retrieved from an ICOS setup can expire sooner than the CA manually uploaded.

To automatically retrieve an ICOS CA, select Access  → SSL Certificates using TS7700 Management Interface (MI). On the SSL Certificates panel, press New Certificate. On the Add Certificate panel, select Retrieve Certificate from server as shown in Figure 6-1.

Then, enter the IP address of your IBM Cloud Object Storage (ICOS) accesser node and press Next as shown in Figure 6-2.

Enter an alias of your internal SSL certificate (e.g. icoscert) and press Finish as shown in Figure 6-3. The alias is used later when assigning different URLs to this specific CA, so choose a simple alias name that is memorable.

When manually uploading the trust of CA through a text file, select the Security menu in IBM Cloud Object Storage Manager and click certificate authority in the System Fingerprint field. Copy all the text that is displayed in your web browser, including “-----BEGIN CERTIFICATE-----” and “-----END CERTIFICATE-----”. Paste the text into a simple text editor, and save it as a text file (for example, icos.pem), as shown in Example 6-1.

Next, you must upload the certificate file to the TS7700 using Management Interface (MI). Complete the following steps.

You can now use the https protocol for newly created URLs and assign this CA to the URLs by using the chosen alias. For more information about assigning the URLs, see Chapter 9, “Configuring TS7700 for cloud storage tier” on page 77.

For internally-signed CAs that are used by your organization, the chain of trust CA must be uploaded into your TS7700 at least once. The method that is used is similar to the self-signed method that is described in “Self-signed IBM Cloud Object Storage CA” on page 32, but the certificate file, its contents, or the server address must be obtained by the organization’s CA administrator. The *.der (binary) or *.pem (text) type certificate types can be upload into the TS7700.

Because all *amazonaws.com accessible buckets use a public signed CA, you do not need to update the TS7700’s CA for Amazon S3 connections. When you configure the cloud storage tier and create a cloud URL, select None as a certificate alias. TS7700 always uses https protocol when connecting to an Amazon S3 bucket, even if no SSL certificate is provided.