Configuring secure communication with a CA-signed certificate

To ensure secure communication, create a certificate that is signed by the certificate authority and upload it to License Metric Tool. Such approach is more secure than using a self-signed certificate that you can create in License Metric Tool.

Introduction

The private key encrypts communication. The public key, which is contained in a certificate, decrypts communication. To use encrypted communication, create a private key and a certificate that is associated with it. You can share the public key (certificate) with anyone because it is used only to read the communication. The safety of your communication depends mainly on your private key that proves your identity, and must be securely stored. The keys are created in such a way that a message encrypted with the private key can be decrypted only with the public key that is associated with it. If someone receives your public key and can decrypt your communication with this key, they know for certain that you are the originator of the message and that it was not tampered with on the way. Otherwise, the public key would be unable to decrypt it.

License Metric Tool provides self-signed certificates by default. However, they are not intended for production environments. To improve security, create your own private key and a certificate signing request (CSR) that can be transformed into a certificate after it is signed by a certificate authority (CA). By signing your request, a CA approves your public key and certifies that it can be trusted. You can create your own private CA, use the CA of your organization, or an internationally trusted CA, such as Entrust, VeriSign, or other.

The private key and the associated certificate are uploaded to License Metric Tool. After you enable encrypted communication, anyone who connects to the License Metric Tool server receives a certificate that contains your public key. All successive communication that originates from the server is encrypted with your private key. After a user receives the communication, it is decrypted with the certificate that they obtained from the server. If the certificate can decrypt the communication, it is known for certain that the server is the originator of the message and that it is valid.

Key pair requirements

Your key pair must meet the following requirements to be accepted by License Metric Tool.
Type
RSA
Key strength
  • For application update 9.2.10 and higher: maximum 16384 bits.
  • For application update 9.2.9 and lower: maximum 2048 bits. This limitation is caused by IBM Java policy. You can use stronger keys if you substitute default policy files with the unlimited jurisdiction ones. For more information, see: IBM SDK Policy files.
Format
PEM-encoded. Such an encoding is ensured if you create the key pair by using OpenSSL. You can also create your keys by using other methods, for example Makecert on Windows. Such keys are DER-encoded and therefore not supported by License Metric Tool. However, you can convert other formats to PEM, for example by using OpenSSL.
Private key format
  • PKCS#1
  • PKCS#8 (used by OpenSSL)
  • PKCS#12
The pvk format is not supported.

Limitations

Key pair that is generated for License Metric Tool can be used for Web Reports only if the private key is not password-protected.

Structure and format of the private key and certificate

Private key format
  • PEM-encoded in the PKCS#8 format without password protection. Ensure that the private key (private.key) is enclosed between the following statements:
    -----BEGIN PRIVATE KEY-----
    <<base64 string from private.key>>
    -----END PRIVATE KEY-----
  • PEM-encoded in the PKCS#8 format with password protection. Ensure that the private key (private.key) is enclosed between the following statements:
    -----BEGIN ENCRYPTED PRIVATE KEY-----
    <<base64 string from private.key>>
    -----END ENCRYPTED PRIVATE KEY-----
  • PEM-encoded in the PKCS#1 format. Ensure that the private key (private.key) is enclosed between the following statements:
    -----BEGIN RSA PRIVATE KEY-----
    <<base64 string from private.key>>
    -----END RSA PRIVATE KEY-----
    
X509 certificate format
PEM-encoded. If you received the intermediate and root certificates as separate files, combine them into a single file. For example, if you have the primary certificate file (certificate.crt) and the intermediate certificate file (ca_intermediate.crt), combine them in the following order.
BEGIN CERTIFICATE-----
<<primary certificate: base64 string from certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<intermediate certificate: base64 string from ca_intermediate.crt>>
-----END CERTIFICATE-----
If you received the root certificate (ca_root.crt) in addition to the intermediate certificate, combine them in the following order.
BEGIN CERTIFICATE-----
<<primary certificate: base64 string from certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<intermediate certificate: base64 string from ca_intermediate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<root certificate: base64 string from ca_root.crt>>
-----END CERTIFICATE-----
Single file (private key in the PKCS#8 format with certificates) format
PEM-encoded. This file can contain the private key and the primary certificate, or the private key and the chain of certificates combined in the following order:
  • Private key and primary certificate.
    -----BEGIN CERTIFICATE-----
    <<primary certificate: certificate.crt>> 
    -----END CERTIFICATE-----
    -----BEGIN PRIVATE KEY-----
    <<private key: base64 string from private.key>>
    -----END PRIVATE KEY-----
  • Private key, primary certificate, and intermediate certificate.
    BEGIN CERTIFICATE-----
    <<primary certificate: base64 string from certificate.crt>>
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    <<intermediate certificate: base64 string from ca_intermediate.crt>>
    -----END CERTIFICATE-----
    -----BEGIN PRIVATE KEY-----
    <<private key: base64 string from private.key>>
    -----END PRIVATE KEY-----
  • Private key, primary certificate, intermediate certificate, and root certificate.
    BEGIN CERTIFICATE-----
    <<primary certificate: base64 string from certificate.crt>>
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    <<intermediate certificate: base64 string from ca_intermediate.crt>>
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    <<root certificate: base64 string from ca_root.crt>>
    -----END CERTIFICATE-----
    -----BEGIN PRIVATE KEY-----
    <<private key: base64 string from private.key>>
    -----END PRIVATE KEY-----