• No results found

General Stealth Feature Overview

3.3. Certificates Overview

Stealth uses various certificates to guarantee security, including for encryption, signing, and authorization.

It is important to protect the private keys of your certificates, because they are the foundation for the security of your environment. Certificates should be protected from unauthorized usage and protected from loss. (See5.4.2 Exporting a Certificatefor more information on exporting certificates so that they can be backed up in a secure location.) In some cases, loss of a certificate will cause loss of data.

The following table provides a summary of all certificates used by Stealth. See the following topics for more information.

Table 3–1. Certificate Summary

• Endpoints – Trust chain

Creating new

Required Yes Created on the Management Server;

automatically imported to the Management Server key store

On the system on which it is created, stored in the Local Machine Trusted Personal store of the user account used to install

Table 3–1. Certificate Summary (cont.)

Required Yes Management Server – Stored in the Personal store of the user account used to install Enterprise Manager 3.3.4 SSL Certificates Required Yes Management Server Creating new

certificates is not Stored in the Personal store of the user account used to install Enterprise Manager used by the endpoint – Trust chain If you create a new certificate for a new user role, you must install that certificate on all endpoints that you want to use the new role.

Management Server License certificates are managed automatically and cannot be changed or replaced.

3.3.1. Signing Certificate

A signing certificate is used to protect the integrity of the settings.xml and crypto.xml files, which are included in the endpoint software package. It is important to use a signing certificate to sign the endpoint package, because the endpoint package contains the IP addresses and certificates of the Authorization Services. If that information is corrupted,

A signing certificate and associated trusted root certificate are automatically generated by the Stealth software, and these certificates cannot be replaced in this release.

The signing certificate must be authorized by a trusted root certificate. This is known as the trust chain. The XML files in the endpoint software package are signed as well as any certificates created for use with Certificate-Based Authorization. The signature is verified by the signing certificate, and in turn, the signing certificate is verified by the trust chain.

This certificate security is automatically managed by the Stealth(cloud) automation.

3.3.2. Authorization Certificates

Authorization certificates are used to secure COI information between the Authorization Service and the endpoints.

Once you configure Stealth authorization, Enterprise Manager uses a collection of certificates to identify different entities (such as users, endpoints, COIs, Certificate Authorities (CAs), and so on) and to authenticate the identity of those various entities.

Enterprise Manager also validates the contents of the certificates and other blocks of data exchanged between entities.

Stealth uses the following types of asymmetric key pairs for authorization:

• 3072-bit RSA keys – This key pair is used for encrypting and decrypting data.

• 256-bit Elliptic Curve (EC) keys – This key pair is used for signing and validating blocks of data that use the SCIP/IPsec protocol. (The signing algorithm used is the EC Digital Signing Algorithm.)

3.3.3. Management Certificate

The Management certificate is used to secure the configuration of the Management Server. Sensitive configuration data is encrypted before it is stored in the configuration database.

When the Management Server software is installed, a self-signed certificate is created automatically. The private key resides on the Management Server. After a period of time (for example, every six months) you might want to replace the certificate for security reasons. Sensitive information in the Enterprise Manager database is automatically rewrapped with the new certificate (that is, information is decrypted using the old certificate and then re-encrypted using the new certificate in one secure operation). It can take several minutes to perform this rewrapping, because all of the protected information in the database must be re-encrypted.

This certificate is required to restore the database in case of a critical failure. If this

certificate is lost, your sensitive data (passwords and COIs) will need to be recreated, and so you should back up this certificate. See5.2 Backing Up the Enterprise Manager Databasefor more information.

3.3.4. SSL Certificates

SSL certificates are used to enable the security of HTTPS communications to a server. Different certificates are used for messages between the following:

• Administrators and the Enterprise Manager interface

• Endpoints and the Authorization Service that authorizes them

• The Management Server and the systems it monitors

• Stealth services running on the Management Server

SSL certificates are created automatically by the service providing the HTTPS server, and the private key resides on that server.

SSL is automatically configured during the software installation.

3.3.5. Import/Export Certificates

Import/export certificates are temporary certificates that can be used to transfer COI information between Management Servers (that reside in separate VPCs) or between a Management Server in the AWS environment and a Management Server in the data center.

Note: A Stealth network can include only one Management Server. However, if you have multiple, separate networks (for example, one production environment and one test environment or multiple test environments), you could configure multiple Management Servers.

These certificates are created on the destination server (and the private key resides on the destination server), and the certificate is imported on the sending server. The private key resides on the destination server.

3.3.6. Certificate-Based Authorization Certificates

Certificate-based authorization (CBA) certificates are used to authorize endpoint instances.

By default, when a new Management Server instance is launched, a new CBA certificate is created for each Stealth user that you specify. These CBA certificates are saved in the Local Machine Personal certificate store for the Management Server instance. When a new endpoint instance is launched, the CBA certificate associated with the user name you selected is saved in the Local Machine Personal certificate store of the endpoint.

If you create additional users using the Enterprise Manager interface, you must create an additional CBA certificate for each user. To stop using a certificate for authentication, you must explicitly remove it from the store.

If you create a CBA certificate, it is signed by the current valid root certificate on the Signing subtab. See3.3.1 Signing Certificate.

3.3.7. License Certificates

License certificates are used to secure license information between Unisys and the server on which the license file is installed (the Management Server).