Enabling secure communication

You can enable Debug Profile Service to communicate over a secure connection using a PKCS#12 keystore, a RACF-managed key ring, or AT-TLS. Each of these keystore types can be configured with a CA-signed certificate.

Remote clients such as the z/OS Debugger Profiles view might perform hostname verification when communicating with Debug Profile Service. Make sure that the hostname is defined in the Subject Alternative Name (SAN) extension of the SSL certificate.

Enabling secure communication with a keystore file

This section explains how to create and use a PKCS#12 keystore.

  1. Determine whether to use self-signed or CA-signed certificate.
    Self-signed certificate
    You can enable secure communication using a self-signed certificate by either using the one created during the installation or generating a new one.
    Option 1: Using the Default Self-Signed Certificate:
    During SMP/E installation, the sample job EQA.SEQASAMP(EQAPRFSU) generates a self-signed certificate stored in a PKCS#12 keystore file at the default configuration path:
    /etc/debug/keystore.p12
    This certificate can be used without any additional steps.
    Option 2: Creating a New Self-Signed Certificate:
    If you prefer to generate your own self-signed certificate, the sample job EQA.SEQASAMP(EQAPKCS2) can assist you with this by invoking the eqapkcs2.sh shell script.
    Customize the sample job and run the script with the -init-self option to create a new PKCS#12 keystore file (default keystore.p12).
    PGM /bin/sh &SVRPATH/bin/eqapkcs2.sh -init-self
    CA-signed certificate
    To use a certificate signed by a Certificate Authority (CA), you must first generate a Certificate Signing Request (CSR) and then import the signed certificate once it is returned by the CA. The sample job EQA.SEQASAMP(EQAPKCS2) can assist with both steps by invoking the eqapkcs2.sh shell script.
    Step 1: Generate a CSR
    Customize the sample job and run the script with the -init-ca option to do the following:
    • Create a new PKCS#12 keystore file (default keystore.p12)
    • Create a Certificate Signing Request (CSR) file (default keystore.csr)
    • Create a placeholder file (default keystore.signed.cer) where the CA-signed certificate will be stored.
      PGM /bin/sh &SVRPATH/bin/eqapkcs2.sh -init-ca
    Submit the keystore.csr file to a Certificate Authority (CA).
    Step 2: Import the Signed Certificate
    Once you receive the signed certificate from the CA (ensure it is a PEM format and includes the complete X.509 certificate chain: leaf, intermediate, root certificates), copy its contents into the placeholder file created earlier (default keystore.signed.cer). Then, run the -sign-ca option to complete the trust chain.
    PGM /bin/sh &SVRPATH/bin/eqapkcs2.sh -sign-ca
    For example, if the CA provided a binary-encoded PKCS#7 (.p7b) file:
    Use the following OpenSSL command in your local host to convert it to a PEM format:
    openssl pkcs7 -in <filename>.p7b -out certificate_bundle.pem
    After conversion, you should see:
    The converted PKCS7 file should start with 
    “-----BEGIN PKCS7-----” and end with the footer 
    “-----END PKCS7-------”
    
    Now extract the individual X.509 certificates from the PKCS#7 bundle to the CER file (default keystore.signed.cer) using:
    openssl pkcs7 -in certificate_bundle.pem -out keystore.signed.cer 
    After conversion, the CER file will contain X.509 certificates, each wrapped like this. Copy all its contents into the placeholder CER file (default keystore.signed.cer) on z/OS host.
    The converted leaf certificate should start with 
    “-----BEGIN CERTIFICATE-----” and end with the footer 
    “-----END CERTIFICATE-------”
    
    The converted Intermediate CA certificate should start with 
    “-----BEGIN CERTIFICATE-----” and end with the footer 
    “-----END CERTIFICATE-------”
    
    The converted Root CA certificate should start with 
    “-----BEGIN CERTIFICATE-----” and end with the footer 
    “-----END CERTIFICATE-------”
    
  2. Edit /etc/debug/eqaprof.env and update the keystore variables to use the new keystore file.
    keystoreFile="$EQAPROF_CFG_DIR/keystore.p12" 
    keystorePass="liberty" 
    keystoreType="PKCS12"
    
  3. To ensure that the keystore file is only readable by the protected user ID STCEQA, change the owner and permission of the file with:
    chown STCEQA:STCGROUP keystore.p12
    chmod 640 keystore.p12
    
  4. If necessary, export the SSL certificate with:
    keytool -export -keystore keystore.p12 -alias liberty -storetype PKCS12 -file liberty.cer -rfc

The SSL certificate can be distributed to remote users to be imported into the client keystore.

For Eclipse users, manually importing the certificate for z/OS® Debugger Profiles view users is not required because you will be prompted to accept the certificate if it is not already in the keystore the first time the view connects to Debug Profile Service.

Z Open Debug users still need to manually import the self-signed certificate. For more information, see Setting up for IBM Z Open Debug.

Enabling secure communication with a RACF managed key ring

Instead of a keystore file, you can use a RACF managed key ring to enable secure communication with Debug Profile Service. To create a RACF key ring and certificates, you must have authorization to issue RACDCERT commands. For more information about the RACDCERT commands and authorizations that are required, see "RACDCERT (Manage RACF digital certificates)" in the z/OS Security Server RACF Command Language Reference.

  1. Create a RACF key ring for Debug Profile Service to use as its keystore:
    RACDCERT ADDRING(EQAPROF.Keyring) ID(STCEQA)
  2. Create a CA certificate and add it to the key ring:
    RACDCERT GENCERT CERTAUTH SUBJECTSDN(CN('CA for Debugger Services') O('IBM') OU('IBM z/OS Debugger') C('US')) SIZE(2048) WITHLABEL('zosDebuggerCA') NOTAFTER(DATE(2030-12-31))
    RACDCERT CONNECT(CERTAUTH RING(EQAPROF.Keyring) LABEL('zosDebuggerCA')) ID(STCEQA)
  3. Create a signed personal certificate and add to the key ring:
    RACDCERT GENCERT SUBJECTSDN(CN('Debug Profile Service') O('IBM') OU('IBM z/OS Debugger') C('US')) ALTNAME(DOMAIN('dps.hostname.com')) SIZE(2048) SIGNWITH(CERTAUTH LABEL('zosDebuggerCA')) WITHLABEL('EQAPROF') NOTAFTER(DATE(2030-12-31)) ID(STCEQA)
    RACDCERT CONNECT(RING(EQAPROF.Keyring) LABEL('EQAPROF')) ID(STCEQA)
  4. Confirm that the key ring and certificates were created correctly:
    RACDCERT LISTRING(EQAPROF.Keyring) ID(STCEQA)
    RACDCERT CERTAUTH LIST(LABEL('zosDebuggerCA'))
    RACDCERT LIST(LABEL('EQAPROF')) ID(STCEQA)
  5. Enable the protected user ID STCEQA authority to access the key ring:
    PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(STCEQA) ACC(READ)
    PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(STCEQA) ACC(READ)
    SETROPTS RACLIST(FACILITY) REFRESH
  6. Edit /etc/debug/eqaprof.env and update the keystore variables to use the key ring:
    keystoreFile="safkeyringjce://STCEQA/EQAPROF.Keyring"
    keystorePass="password"
    keystoreType="JCERACFKS"
    Similar to JCERACFKS, a JCECCARACFKS key ring uses RACF with the addition of ICSF to protect certificates and key material. To use a JCECCARACFKS key ring, edit /etc/debug/eqaprof.env with the following:
    keystoreFile="safkeyringjcecca://STCEQA/EQAPROF.Keyring"
    keystorePass="password"
    keystoreType="JCECCARACFKS"
    Notes:
    • The value for keystorePass must be exactly "password" to satisfy the underlying HTTP server, even though SAF key rings do not have a password.
    • Access to ICSF is protected by profiles in the CSFSERV security class. The protected user ID STCEQA must have the proper permissions in order to access the key ring. For more information, see the z/OS Cryptographic Services ICSF Administrator's Guide.
  7. Export the CA certificate that contains the public key to a z/OS sequential file:
    RACDCERT CERTAUTH EXPORT(LABEL('zosDebuggerCA')) DSN('<sequential data set>') FORMAT(CERTDER)
    The CA certificate can be distributed to remote users to be imported into the client keystore manually if necessary.

    For Eclipse users, manually importing the certificate for z/OS Debugger Profiles view users is not required because users will be prompted to accept the certificate if it is not already in the keystore the first time the view connects to Debug Profile Service.

    users still need to manually import the self-signed certificate.

Enabling secure communication with AT-TLS

You can also use the TCP/IP service called Application Transparent Transport Layer Security (AT-TLS) to enable secure communication with Debug Profile Service. For a step-by-step guide to setting up AT-TLS itself, see Setting up AT-TLS.
  1. In the eqaprof.env configuration file, specify SECURE="AT-TLS".
  2. Create an AT-TLS policy for the port used by Debug Profile Service as specified in the eqaprof.env configuration file. See the following sample policy.
    Note: The Jobname parameter in the TTLSRule statement is optional if you specify the LocalPortRange. However, if you choose to define it, set it to the job name shown in the output stream of the EQAPROF job. The EQAPROF job spawns a secondary process that runs the Liberty server.

    For example, the job name should be set to EQAPROF1:

    INFO EqaProfile - Server running with jobname EQAPROF1 has started, and is listening on
            HTTPS (AT-TLS) port=8143

    You can also run the TSO NETSTAT command to verify the server’s job name and check which job is listening on port 8143.

    TTLSRule EQAPROF
    {
         LocalPortRange               8143
         Direction Inbound
         TTLSGroupActionRef.          EQAPROF_group
         TTLSEnvironmentActionRef     EQAPROF_env
         TTLSConnectionActionRef      EQAPROF_conn
    }
    
    TTLSGroupAction  EQAPROF_group
    {
         TTLSEnabled                  On
    }
    
    TTLSEnvironmentAction EQAPROF_env
    {
         HandshakeRole                Server
         TTLSKeyringParms
         {
              # Keyring must be owned by the user id (STCEQA) running the EQAPROF started task
              Keyring                 eqaprof.keyring
         }
    }
    
    TTLSConnectionAction  EQAPROF_conn
    {
         HandshakeRole                                 Server
         TTLSCipherParmsRef                            EQAPROF_cipherparms
         TTLSConnectionAdvancedParmsRef.               EQAPROF_Conn_adv
         CtraceClearText                               Off
    }
    
    TTLSConnectionAdvancedParms EQAPROF_Conn_adv
    {
         TLSv1                         Off
         TLSv1.1                       Off
         TLSv1.2                       On
         SSLV3                         Off
         ApplicationControlled         Off
         SecondaryMap                  Off
         HandshakeTimeout.             20
    }
    
    TTLSCipherParms   EQAPROF_cipherparms
    {
         V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
         V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
         V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
         V3CipherSuites TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
         V3CipherSuites TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
         V3CipherSuites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    }

Securing Keystore and Keyring Passwords

If you choose to use a keystore or RACF key ring, you must specify a password as part of the configuration. While Liberty supports plain text passwords, it is strongly recommended to encrypt them to enhance security.

Password encryption can be done using Liberty’s securityUtility tool. You can choose to encrypt the password using Liberty’s default internal key or supply your own custom key. The tool will output the encrypted password as a string:

In the following example, ${liberty_dir} is the path of your liberty installation, <password> is the plain-text keystore or keyring password to encrypt, and <customkey> can be a random or pseudo-random string that the encryption tool will use.
Option 1: Using the default encryption key:
${liberty_dir}/bin/securityUtility encode --encoding=aes <password>
Option 2: Using a custom encryption key:
${liberty_dir}/bin/securityUtility encode --encoding=aes --key=<customkey> <password>
After encryption, edit /etc/debug/eqaprof.env and update the keystore password variable with the encrypted password in one of the following ways:
Option 1: Use the encrypted password directly:
keystorePass="{aes}..."
Option 2: Reference an external file containing the encrypted password.
keystorePassFile="/etc/debug/keystore.password"
If a custom encryption key is used to create the encrypted password, you must also reference an external file containing the custom encryption key.
keystorePassEncryptionKeyfile="/etc/debug/encryption.key"
The keystore.password and encryption.key files must be manually created and ensure they are only readable by the protected user ID STCEQA.
chown STCEQA:STCGROUP keystore.password
chown STCEQA:STCGROUP encryption.key
chmod 600 keystore.password
chmod 600 encryption.key