Frequently Asked Questions about the TrueSight certificate and TLS

Transport Layer Security, or TLS, is a cryptographic protocol used to secure communication over a network, typically the internet. It ensures the confidentiality and integrity of data transmitted between two endpoints.

The Secure Sockets Layer (SSL) certificates are digital certificates that authenticate the identity of a website or server and enable secure, encrypted communication between a client (such as a web browser) and a server.

TLS works by establishing a secure connection between a client and a server. It involves a series of steps, including handshake, key exchange, encryption, and authentication, to ensure secure and private communication.

SSL/TLS certificates serve the following main purposes:

• They authenticate the identity of the server or website, assuring users that they are connecting to the intended destination.
• They facilitate encryption, ensuring that data transmitted between the client and server is encrypted and protected from eavesdropping or tampering.

There are various types of SSL/TLS certificates, including the following types:

• Domain Validated (DV) certificates: These only validate the ownership of the domain name.
• Organization Validated (OV) certificates: These authenticate the domain owner's identity along with domain ownership.
• Extended Validation (EV) certificates: These provide the highest level of authentication and display the organization's name in the browser's address bar.
• Wildcard certificates: These cover a domain and all its subdomains.
• Multi-Domain certificates: These secure multiple domains with a single certificate.

SSL/TLS certificates are typically issued by Certificate Authorities (CAs). The process involves verifying the domain ownership or organization's identity, depending on the certificate type. Once the verification is complete, the CA digitally signs the certificate, which can then be installed on the server.

A Certificate Authority is a trusted entity responsible for issuing and managing SSL/TLS certificates. CAs have a hierarchy, with root CAs at the top, followed by intermediate CAs. They verify the identity of certificate applicants and digitally sign the issued certificates.

In asymmetric encryption, such as RSA, a private key is kept secret and used to decrypt data or sign messages. A public key, derived from the private key, is freely distributed and used by others to encrypt data or verify signatures. In the context of TLS, the server holds the private key, and the public key is included in the SSL/TLS certificate.

To begin the certificate request process with the Certificate Authority, it is necessary to generate a pair of cryptographic keys - a public key and a private key. These keys are essential for establishing an SSL session.

Once the key pair is generated, it should be assigned to the appropriate certificate for a user or component of a BMC Software product.

The diagram below provides an overview of the certificate implementation process in TrueSight Operations Management.

A certificate chain is a sequence of certificates that establish a path of trust from the end-entity certificate (e.g., a website's SSL/TLS certificate) to a trusted root CA certificate. It ensures that the certificate presented by a server can be verified and trusted by the client.

SSL/TLS certificates have an expiration date, typically ranging from one to three years. To maintain secure communication, certificates should be renewed before they expire. The specific renewal period depends on the certificate's validity period and the CA's policies.

When importing a certificate, you typically need the certificate file itself, which is usually in the form of a .pem, .cer, .pfx, or  .p12 file. Additionally, you may need the password for the certificate if it is protected with one.

openssl req -verify -in example.csr

For example, you can execute the following command:

Ciphers Scan Windows Tool

1. Download sslscan-2.0.16.zip using https://github.com/rbsec/sslscan/releases/download/2.0.16/sslscan-2.0.16.zip
2. Extract sslscan-2.0.16.zip into folder
3. Navigate to the sslscan-2.0.16 folder
4. Run sslscan.exe tsps_hostname.domain.com.
   Output:
   

Ciphers Scan Linux Tool

1. git clone --depth 1 https://github.com/drwetter/testssl.sh.git
2. cd testssl.sh
3. ./testssl.sh <tsps_homename>.domain.com:port
   OR
   ./testssl.sh <tsim_homename>.domain.com:port
   Output:
   

To establish secure communication between the client and server components, the following steps need to be taken:

• Components function as both clients and servers during communication.
• To ensure TLS security, certificates are required to authenticate the connection between the client and server.
• The system security administrator needs to provide the necessary CA-signed public certificate (.crt) and PKCS private key file (. p12).
• Prior to configuring the BMC TrueSight Infrastructure Management components to enable TLS 1.2, it is essential to import the security certificates into the trust store or keystore files.

Security Architecture Diagram - TrueSight Infrastructure Management Server and related components

For more information, see TLS-considerations-for-TrueSight-Infrastructure-Management.

To import certificates for TrueSight Infrastructure Management and TrueSight Presentation Server, you have two options. You can either use the certificate import command or follow the manual steps provided in the documentation.

For more information, see Creating-and-importing-certificates-in-TrueSight-Infrastructure-Management and Creating-and-importing-certificates-in-TrueSight-Presentation-Server.

Yes, the description is available in the documentation. See Applying wildcard certificates to TrueSight Operations Management components.

Yes, Certificate Authority (CA) certificates can be utilized in various formats for importing into different systems and applications. The most common formats for CA certificates include:

• PEM (Privacy Enhanced Mail): This format uses Base64 encoding to represent the certificate in ASCII text. It typically has a .pem extension and is widely supported by many systems, such as web servers like Apache and Nginx.
• DER (Distinguished Encoding Rules): This format represents the certificate in binary form. It usually has a .der or .cer extension. DER certificates are commonly used in Java-based applications.
• PFX/P12: This format is a container that can hold the CA certificate along with its associated private key and other certificates in a password-protected file. PFX files often have a .pfx or .p12 extension. They are commonly used in Windows-based systems and for certificate distribution.

No, you cannot use the old certificate key with a renewed certificate. When a certificate is renewed, a new key pair (public key and private key) is generated. The new certificate is then issued based on this new key pair.

The key pair is a crucial component of a certificate and is mathematically linked to the certificate. The private key is used for encryption and digital signatures, while the public key is included in the certificate and used for verification. As a security measure, when a certificate is renewed, a new key pair is generated to ensure the integrity and confidentiality of the certificate.

Therefore, it is important to update the private key along with the renewed certificate to ensure proper encryption, signature verification, and security. Using the old key with the new certificate would result in cryptographic mismatches and could potentially compromise the security of the system or application using the certificate.

Yes, it is possible to utilize a single certificate with multiple Subject Alternative Names (SANs). This is known as a "SAN certificate" or a "multi-domain certificate." SAN certificates allow you to secure multiple domains or subdomains within a single certificate, simplifying the management and deployment of SSL/TLS certificates.

SAN certificates can include various types of SANs, such as domain names, IP addresses, email addresses, or URIs (Uniform Resource Identifiers). This flexibility enables you to secure multiple websites or services using a single certificate, reducing administrative overhead and cost.

When generating or requesting a SAN certificate, you provide a list of the SANs you want to include. The certificate authority (CA) then issues a single certificate that covers all the specified SANs. When clients connect to a server using this SAN certificate, they can validate the server's identity for any of the SANs listed in the certificate.

Self-signed certificates are self-generated and not trusted by default, while CA-signed certificates are issued by a trusted third-party CA and are automatically trusted by software and web browsers. CA-signed certificates provide a higher level of trust and are necessary for public-facing websites or applications where the credibility and security of the communication need to be established. Below command can be used to generate self-signed certificate.

Yes, you can import certificates issued by any trusted certificate authority. However, it is essential to ensure that the CA is recognized and trusted by the system or application where you are importing the certificate.

Yes, it is possible to import certificates issued by more than one Certificate Authority (CA) in TrueSight Operations Management. Most systems support the import of multiple certificates from different CAs.

To achieve this TrueSight Presentation Server root chain certificates must be imported in to TrueSight Infrastructure Management tsim_home /pw/pronto/conf/pnserver.ks  and tsim_home/pw/jre/lib/security/cacerts.

There are different communication channels established between the TrueSight Infrastructure Management components. Perform the TLS configurations per communication channel. Select the communication channel which you want to make TLS compliant and perform the tasks accordingly. The flowchart in the following diagram explains the complete TLS configuration workflow.

For more information, see Configuring-TrueSight-Infrastructure-Management-to-enable-TLS-1-2.

Verify the weak ciphers by using https://ciphersuite.info/. If its weak or insecure, remove it and restart the Remedy Single Sign-On server.

See Implementing-private-certificates-in-the-Remedy-Single-Sign-On-Server.

See Implementing-private-certificates-in-the-TrueSight-Presentation-Server.

There could be several reasons why the TrueSight console does not come up after renewing the  Remedy Single Sign-On certificate. Here are a few potential causes and troubleshooting steps to consider:

• Incorrect certificate installation: Ensure that the renewed Remedy Single Sign-On certificate is properly installed on the TrueSight Presentation Server server inside the cacerts file located in the tsps_home\truesightpserver\modules\jre\lib\security folder.
• Service restart: After renewing the Remedy Single Sign-On certificate and making any necessary configuration changes, restart the TrueSight Presentation Server service or server to ensure the new certificate is loaded correctly. This step may be necessary for the TrueSight Presentation Server application to recognize and use the renewed certificate.
• Log analysis: Check the TrueSight Presentation Server logs for any error messages or warnings related to the certificate. Logs can provide valuable information about any specific issues or failures encountered during the SSL handshake or certificate validation process.

If these troubleshooting steps do not resolve the issue, it may be beneficial to consult the documentation or support resources specific to the TrueSight Presentation Server and Remedy Single Sign-On applications. They can provide further guidance on the renewal process and help troubleshoot any specific issues related to the interaction between the two systems.

Verify that the root chain certificate was imported in the cacerts file. If not imported, navigate to tsps_home\truesightpserver\modules\jre\lib\security.

See Configuring-the-Infrastructure-Management-Server-to-Presentation-Server-communication-to-enable-TLS-1-2.

• bat properties set tsps.cell.conntype ssl
• bat properties set pronet.jms.conntype ssl
• Edit cell encryption key in mcell.dir to *TLS settings:-
  "tsps._install_dir\\truesightpserver\\conf\\mcell\.dir";
  Change mc   to   *TLS
• tssh server start

See Applying-TrueSight-Presentation-Server-certificate-to-the-TrueSight-Infrastructure-Management.

For TrueSight Infrastructure Management, see Configuring-TrueSight-Infrastructure-Management-to-enable-TLS-1-2.

For the Oracle server, see Implementing-private-certificates-in-Oracle-database.

See Implementing-private-certificates-in-the-Integration-Service.

Generally, it is recommended to use TLS (Transport Layer Security) for secure communication between components to ensure the confidentiality and integrity of data. If TrueSight Infrastructure Management and TrueSight Presentation Serverare configured to use TLS, it is advisable to configure the BMC Integration Service (IS) also to use TLS mode for consistent security measures.

However, if TrueSight Infrastructure Management or TrueSight Presentation Server is not configured to use TLS, you may still choose to configure the BMC Integration Service in TLS mode for additional security, but the communication between the Integration Service and these components would not be fully encrypted. In such cases, it is essential to evaluate your specific security requirements and consider other measures to ensure the protection of data. By using a text editor, open the pronet.conf file located in <Infrastructure Management Server Install directory>\pw\custom\conf directory and update below line and restart Integration Service:

For more information, see Configuring-Integration-Service-to-Infrastructure-Management-server-communication-to-enable-TLS-1-2.

See Enabling-TLS-1-2-for-PATROL-Agent-to-Integration-Service-communication.

See Configuring-the-PATROL-Agent-to-Integration-Service-communication-to-enable-TLS-1-2.

TrueSight Presentation Server:

• <TSPS_HOME>\truesightpserver\logs session
• TrueSight.log
• stdout*.log
• TSIMAudit.log
• rest-access.log
• tssh.log
• embedcomponents.log

TrueSight Infrastructure Management: 

• All log files from <TSIM_HOME>\pw\apache\logs
• The following log files from <TSIM_HOME>\pw\pronto\logs:
  • TrueSight.log
  • bppmws.log
  • httpd.out
  • pronet_cntl.out
  • jserver.out

TrueSight Integration Server:

• <TSIN_HOME>\pronto\logs
• TruesightAgent.log
• debug\Agent.log
• \common\security\log_v3.0\bppmpis_server.log

TrueSight Cell

TrueSight\pw\server\log\pncell_<<hostname>>\mcell-log

PATROL Agent

PATROL_HOME\..\common\security\log_v3.0\proxy_client

See the following documentation links:

Troubleshooting-TLS-configuration-issues

Troubleshooting-security-certificate-issues

Utilize a network sniffing tool like Wireshark or any other similar software for capturing network traffic.