Generic Linux

Prerequisites

  1. Ensure that the Bash shell and its prompt are available.
  2. Ensure that SSH users have the required read and write permissions to perform CLM actions on the server device when access elevation is set to None.
    If access elevation is configured as sudo or dzdo, all commands for CLM operations will be executed using sudo or dzdo.
  3. If sudo/dzdo access elevation is enabled on the device onboarding page, ensure that the user has the necessary permissions to execute the sudo command provided below.
  4. Ensure that the following packages are installed to facilitate device addition:
    • sudo/dzdo (Only applicable if access elevation is selected as sudo/dzdo in the device onboarding page)
    • timeout
    • base64
  5. Ensure that the OpenSSL toolkit on the Linux machine is installed.
    Note: This package is essential for supporting endpoint enrollment. However, if endpoint enrollment is not required, the package is optional.
  6. Ensure the server's resource health remains above the 50% threshold.
  7. Ensure that the target IP address is accessible from the cloud connector and the port is open.
    Note: To SSH into a machine using a specific port, you can use the following command:
    ssh -p <port_number> <username>@<hostname_or_ip_address>
  8. Ensure that the SFTP is configured.
    Note:

    Avoid restricting SFTP sessions to a single connection, as this may cause failures in push use cases. To prevent such issues, adjust the settings in

    /etc/security/limits.conf

    to allow up to 5 connections.

  9. Ensure that GSKit is installed on the server to work with the KDB certificate.
    For the KDB use case, one of the available packages is utilized.

    To verify if the package is installed on the machine, use the following commands:

    dspmqver -p 64
    gsk8capicmd -version | grep FileVersion 
    gsk8cmd -version | grep FileVersion 
    gsk7capicmd -version | grep FileVersion
    gsk7cmd -version | grep FileVersion
    gskcmd -version | sed 's/version/Version/'
    gsk8capicmd_64 -version | grep FileVersion
    Note:
    • The first successfully executed command determines the package to be used.
  10. To discover a password-protected certificate, ensure the password is added to the password vault at (Menu) > CLM > ADMINISTRATION > Password Vault.
  11. SSH private keys are incompatible with password-enabled sudo/dzdo settings. Therefore, when using an SSH key for authentication, ensure that sudo/dzdo is configured for passwordless access.
  12. Certificates cannot be identified from the mounted paths /boot, /bin, /dev, /lib, and /sbin. It is recommended to move the certificate to an alternative location.
  13. Host-level configurations take precedence over global settings, allowing you to override global settings at the host level.
    Note: The global setting can be configured in the (Menu) > CLM > ADMINISTRATION > Device Management > Server > (Device Settings).
  14. Port scanning is disabled by default during Linux discovery. However, configurations are enabled at both the host level and global level to control this feature.
  15. If device onboarding fails due to host key algorithm mismatches, activate the required algorithms on the client or server. Add deprecated algorithms only if necessary.
  16. It is recommended to exclude the NAS mount paths from certificate scanning which might consume additional resources during scanning and might affect the server performance.

Supported Linux Feature

  1. On-demand or scheduled certificate discovery.
  2. CSR generation on the end device.
  3. Certificate deployment to Linux servers, supporting various certificate types.
  4. Delta discovery to identify new or modified certificates.
  5. Nightly configuration synchronization job.
  6. Authentication via manual entry, SSH, SSM, or external vaults.
  7. Service account usage for CLM operations.
  8. Global settings for including/excluding file paths in certificate discovery.
  9. Configurable port scanning for Linux discovery (disabled by default).
  10. Discovery of certificates with case-insensitive file extensions (for example, fileName.kdb or fileName.KDB).
  11. Mapping certificates to specific certificate groups and applying discovery filters.
  12. Bulk push support for root and intermediate certificates to one or more devices is now enabled for the Generic Linux vendor.
  13. The capability to modify permissions, ownership, group ownership, and other user permissions for pushed certificates is now enabled for Generic Linux in JKS, Keystore, PFX, PEM, and P12 formats.
  14. The discovery of extension less trust certificates will be performed if the path is configured with the aggressive scan type during device onboarding. Additionally, the scan will be limited to a maximum depth of 1, and no nested directory scanning will be performed.

Limitations

  1. When the same issuer certificate exists in multiple locations, the first one found is prioritized. As a result, even if a renewed certificate is available in another location, only the initial match is considered.
  2. In the AIX operating system, identifying certificates located in folders or files with spaces in their names is not supported. However, this functionality is available on non-AIX platforms.
  3. The exclusion or inclusion of files using wildcard paths at the global or host level is not supported.
  4. Support for elliptic curve (EC) certificates, used in elliptic curve cryptography (ECC), is unavailable in IBM MQ versions prior to version 9.0. This feature is introduced in IBM MQ version 9.0 and later.
  5. The push of auto-renewed, regenerated, or discovered password-protected certificates is not supported.
  6. App connector cert details cannot be updated when the discovered certificate has a file extension in uppercase.

Onboarding Linux

  1. Go to (Menu) > CLM > ADMINISTRATION > Device Management.
    By default, the ADC tab opens.
  2. Click the Server tab.
  3. Click the (Add) icon.
  4. Select the Linux logo from the Vendors list.
  5. In the Server Details section, enter details as mentioned below.
    Table 1. Server Details - Field Description Table
    Field Description
    *Server name Enter a unique name for the designated Linux server that is to be onboarded
    *IP address/ FQDN Enter the valid IP address or fully qualified domain name (FQDN) for device communication and integration with the Linux server.
    Data center Choose the desired data center.
    Onboarding Group Select the onboarding group to assign the device.
    Note: Devices without an assigned group are automatically mapped to the Default group during migration, onboarding, and when edited without existing group mappings.
    Communication mode Select the SSH or SSM protocol to be used for communication between the AppViewX node and the Linux server. SSH is the preferred communication mode.
    *SSH Port Retain the value 22; it is the default port used for the SSH communication mode. (The field is not displayed for SSM communication mode.)
    Cert sync Choose from any of the following:
    • Managed - AppViewX performs the config fetch operations and the certificates are discovered and managed in the inventory. CLM actions (push) can be performed on them.
    • Monitored - AppViewX performs the config fetch operations and the certificates are downloaded in the inventory in the read-only state. CLM actions cannot be performed on them.
    • Ignored - AppViewX only performs the config fetch operations for the devices. There is no certificate discovery performed.
    *: Mandatory fields
  6. In the Credentials section, select/enter the details as follows.
    If Communication mode = SSH the fields are as follows:
    Table 2. Credentials - Field Description Table
    Fields Description
    *Credential Type Select the credential type from the dropdown.
    • Manual entry (default)
    • Credential List - xyz (All the configured external vaults.)
    *Username This filed is displayed only if the Credential Type = Manual.

    Enter the designated username for authentication.

    *Password This filed is displayed only if the Credential Type = Manual.

    Enter the secure password.
    *Credentials list When Credential list - xyz is selected as the credential type, the Credentials List dropdown appears. Select the desired preconfigured credential list from the available options.
    *: Mandatory fields
    If Communication mode = SSM the fields are as follows:
    Table 3. Credentials - Field Description Table
    Fields Description
    *Credential Type Select the credential type from the dropdown.
    • Manual entry (default)
    • Credential List - cloudAccount
    • IAM ROLE ACCESS: An IAM role-based approach is used for authentication instead of direct access keys. Access is provided based on IAM roles.
      To enable this feature:
      1. Create a role in one of your AWS accounts that trusts the AppViewX AWS account OR the AWS account for an AppViewX node deployed in your organization's infrastructure that will be used as the trusted entity.
      2. From AppViewX, assume the role created in your account.
      3. Using the assumed role from the above step, assume the roles created in the respective child accounts to perform the required CLM actions.
      To do this, you can download the Cloud Formation template from the Device :: Cloud > Add AWS onboarding page, which can be used to create a role in your AWS account that trusts the AppViewX AWS account.
      For a SaaS deployment, the Trusted Node field is displayed that lets you select the node that must be trusted by AWS for communicating the temporary credentials.

      For an on-prem deployment or deployment in a non-AWS environment, a data center must be deployed on an EC2 instance to act as the trusted entity. The user must select this data center and enable strict routing so that all AWS access requests and related communications are routed through the selected AWS datacenter.
    *Access key This filed is displayed only if the Credential Type = Manual.

    Enter the access key to login to the EC2 instance of the AWS cloud machine.
    *Secret key This filed is displayed only if the Credential Type = Manual.

    Enter the secret key to login to the EC2 instance of the AWS cloud machine.
    *Account name If Credential list - cloudAccount is selected, the Account name dropdown field is displayed. Select any of the preconfigured cloud account values.
    Download Cloud Formation Template (CFT) For Credential type = IAM ROLE ACCESS, to download the CloudFormation template, click the Download Cloud Formation Template link that is displayed below the Credential Type dropdown list.
    The downloaded CloudFormation template is pre-configured with the AppViewX AWS account details that need to be trusted. Ensure that you:
    • Use the downloaded template to create a role in any of your AWS accounts.
    • Provide a unique string as the External ID for the role you are creating.
    To read more on CloudFormation templates, read the documentation here.
    *Trusted Node This field is displayed when Credential Type = IAM ROLE ACCESS. For retrieving temporary credentials for authentication and communication purposes, from the following options, select the node that must be trusted by AWS:
    • AppViewX Cloud DC: Select this option if the AppViewX cloud data center must act as the trusted entity. AWS access requests will then originate from the AppViewX-managed cloud environment.
    • Customer Selected Data Center: Select this option when a specific AppViewX node deployed within your organization's infrastructure must act as the trusted entity. AWS access requests will then originate from this location.
    *Master Account Role This field is displayed when Credential type = IAM ROLE ACCESS.

    Enter the Amazon Resource Name (ARN) of the AWS IAM role created using the downloaded CloudFormation Template.

    The IAM role input for this field can be:
    • a simple name (as a alpha-numeric string)
    • an identifier in a full path format (e.g., /service-prefix/role-name)

      AWS allows roles to be created within paths to help manage large numbers of roles and delegate permissions. With path support, users can onboard resources where the IAM Role is nested.
    *External Id This field is displayed when Credential type = IAM ROLE ACCESS.

    Enter the unique identifier generated to establish a secure trust relationship between AWS and AppViewX.
    *: Mandatory fields
  7. In the Service account credentials section, select/enter the details as indicated below. If interactive mode is not enabled for the service account on the Linux machine, the configured service account will switch the session from the logged-in SSH account to the service account using the command: su - {serviceUserName}. Once the session is switched, all subsequent commands will execute within the context of the service account session.
    Table 4. Service account credentials - Field description table
    Field Description
    Username Enter the designated username for authentication.
    Note: The service account is not used for authentication; instead, it is used to switch the session from the logged-in SSH user account to the service account.
    Password Enter the secure password.
    *: Mandatory fields
  8. In the Vendor Specific Details section, enter details as mentioned below.
    Table 5. Vendor Specific Details - Field Description Table
    Field Description
    Access Elevation Select from the following:.
    • None (default)
    • sudo- to execute with root privileges using sudo access
    • dzdo- to execute with root privileges using dzdo access.
    Note: SSH key-based authentication does not support password-enabled sudo/dzdo.
    Discover Formats The Discover Formats fields contain all the possible certificate formats that are applicable to the 'Default' scan type. The formats include KBD(*.kbd), PEM(*.crt), PEM(*.cer), PEM(*.pem), DER(*.der) DER(*.cer), PKCS#7(*.p7b), PKCS#7(*.p7c), PKCS#12(*.p12), PKCS#12(*.pfx), JKS(*.JKS), JKS(*.keystore).

    To delete the certificate format from the scan, click the 'x' icon in the respective cert type.

    To delete all the certificate formats from the scan, click 'Clear' on the top-right of the field.
    File Upload Temp Path This field is displayed if the Access elevation value is selected as sudo or dzdo. Enter the path of the temp folder

    Example: /cert/temp

    This field is applicable for Push and CSR generation operations. This directory must have common access (RW) for the logged-in user and the service admin user if Service Account credentials are entered.
    Enable access elevation for the service account? When enabled, the commands are executed with selected access elevation.
    Note:
    • By default, this field is disabled.
    • This field is enabled only for a service account user when an Access Elevation type, such as sudo or dzdo, is selected.
    Enable Network Scan Select the checkbox to perform a network scan in addition to the managed device discovery scan for these devices.
    Note:
    • By default, this field is disabled and can be enabled through a global device setting. [CLM > ADMINISTRATION > Device Management > Server > (Device Settings)]
    *: Mandatory fields
  9. In the Certificate details section, enter the details as indicated below.
    Table 6. Certificate Details - Field Description Table
    Field Description
    Certificate Directory Enter the actual directory/path where certificates are stored in the Linux server.

    Example: /cert/files
    Scan Type Select any of the following:
    • Default - System scans for all certificate formats and adds them in the certificate inventory.
      Note: It scans the provided directory and subdirectory as well.
    • Aggressive - System scans for all keystore files with non-standard SSL extensions and also scans for trust certificates from extension less files.
      Note: It scans only the given directory.
    *Operation Select the value include or exclude from the dropdown field. It indicates that the specified certificate directory will be included/excluded from the certificate scan process.
    *: Mandatory fields
  10. Click Add.
    The certificate location will be listed in the table.
  11. [Optional step] Click the (Delete) icon if you want to delete the certificate details from the list.
  12. Click Save.
    The Linux device is added successfully.

Device Settings

Configuring a Global Device setting requires specifying certificate paths to include or exclude from Device Certificate Discovery and Config Sync operations. When enabled for Linux servers, these settings are applied to all added Linux servers.
  1. Go to (Menu) > CLM > ADMINISTRATION > Device Management.
    By default, the ADC tab opens.
  2. Click the Server tab.
  3. Click the () device settings icon.
    The Device Settings page opens.
  4. In the Vendor Specific details section, enter the details as indicated below.
    Table 7. Certificate Details - Field Description Table
    Field Description
    Enable Network Scan Enable this checkbox to perform Network Scan along with Managed Device Discovery Scan for these devices.
    Certificate Ownership & Permission Enable the toggle button to customize certificate ownership and file permissions at the App Connector level.
    Update System TrustStore Enable this to update system trust store for root and intermediate certificates. Once enabled, this setting will be turned on at the device connector to update the trust store during certificate push. This can be disabled at individual level at the connector level, if required.
    *Health Value (%) Acceptable values range is 0-99.

    This threshold defines the minimum server resource health required. If the SAR-derived health value drops below this limit, the device will remain unresolved to prevent further processing. Only numeric values between 0 and 99 are allowed, with a default value of 50%. If the SAR package is unavailable, this health check will be skipped.
    *: Mandatory fields
  5. In the Certificate details section, enter the details as indicated below.
    Table 8. Certificate Details - Field Description Table
    Field Description
    Certificate Directory Enter the actual directory/path where certificates are stored in the Linux server.

    Example: /cert/files
    Scan Type Select any of the following:
    • Default - System scans for all certificate formats and adds them in the certificate inventory.
    • Aggressive - System scans for all keystore files with non-standard SSL extensions.
    *Operation Select the value include or exclude from the dropdown field. It indicates that the specified certificate directory will be included/excluded from the certificate scan process.
    *: Mandatory fields
  6. Click Add.
    The certificate location will be listed in the table.
  7. [Optional step] Click the (Delete) icon, if you want to delete the certificate details from the list.
  8. Click Save.
    The Linux device setting is configured successfully.

Fetch Config

A prerequisite check evaluates the server's health. If the server is deemed unhealthy, the device is marked as unresolved, blocking discovery for healthy devices. The check monitors average server idle CPU usage, and if it falls below 50%, the sync fails, and the device is marked as unmanaged.
  1. Go to ADMINISTRATION > Device Management.
    By default, the ADC tab opens.
  2. Select the device from the list to trigger fetch config.
  3. Click the () Fetch Config icon.
    The pop-up message is displayed as Fetch config has been triggered for the device (s).
  4. To override the default threshold value, in the Device Settings page, enter the appropriate value in the *Health Value (%) field.

CSR Generation at the End Device

In the CSR generation use case at the end device, the private key will be generated directly on the device. When the private key is generated on the device, the Private Key at End Device checkbox will be automatically set to true, and the Private Key Location field will be pre-filled in the push app connector.

Certificate Push

  1. The Linux push operation allows certificates to be pushed to the Linux server.
    • KDB
    • CRT
    • CER
    • PEM
    • DER
    • P7B
    • P7C
    • P12
    • PFX
    • JKS
    • Keystore
  2. For JKS, PEM, and PKCS12 certificates, the capability to modify Certificate Ownership and Permissions after the certificate is pushed has been introduced. This feature is disabled by default and can be enabled by navigating to: (Menu) > CLM > Device Management > Server > Device Settings.
  3. If no specific permissions are configured, the pushed certificate will default to 640 permissions. If the file already exists, its existing permissions will be retained.

Possible Error Messages with Linux CLM Use-case

Error Message Remediation
Communication to 192.168.143.30 has failed. Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods. Authentication failure. Check the credentials used for the authentication.
java.lang.Exception: No agent is available as all registered agents are either paused, rejected or deleted or agent resource limit exceeded. The possible reason(s) could be CC is down or busy processing the other request.
Communication to <ip/fqdn> has failed. Caused by: java.net.SocketException: Network is unreachable (connect failed) IP/FQDN provided is not reachable. Check manually by establishing an SSH session to the target device with the provided IP/FQDN.
Device prerequisite check failed: -bash: sudo: command not found. Install the necessary packages (base64, timeout, sudo) to on-board the Server. The base64, timeout, and sudo packages are required to proceed to onboard the Linux server into AppViewX.
Beyond trust vault response parsing failed::["Managed Account not found" ]. Verify that the Linux device hostname or IP address is configured for the user in BeyondTrust.
Delinea vault access token denied / not generated. Verify the Delinea vault integration with AppViewX.
No matching password object was found for the query. Ensure a password object exists in the Vault that meets the query criteria and verify that both the Provider and the application user have the necessary permissions to access and use the password. Verify the Delinea vault integration with AppViewX.
CredentialStore(s) does not exist. Verify that the Linux device hostname or IP address is configured for the user on the Delinea server.

Linux Commands

Operation Command Description Sudo/Dzdo Configuration Required
Session configuration commands (Executed post-creation of ssh session for all use cases) env PS1="avxbashprompt~" bash --norc --noprofile -i Switches the current shell to Bash mode. Executed immediately after SSH session is established and again after switching to the service account, before running any other commands. No
bind 'set enable-bracketed-paste off' Disable the bracketed-paste configuration for the current session. No
ulimit -s unlimited This would set the stack size limit to unlimited for the current shell session or user. No
export SUDO_PROMPT='[sudo] password for %p: ' Set the sudo password prompt to the standard value for the current session.
Note: This will be executed only when the access elevation is set as sudo or dzdo.
 Yes
export LANG=en_US.UTF-8 Defaulting the session language to English
Config fetch su - {serviceAccountUserName} Switch to the service account Yes
  • timeout --version
  • sudo --version (Optional, based on the access elevation defined in the device onboarding page)
  • base64 --version
 Mandatory package availability prerequisite verification. No
uname To fetch the OS Name No
sudo sar 2 5 | tail -1 | awk {'print $NF'} Server health check for Linux Yes
sudo sar 2 5 | tail -1 | awk {'print $5'} Server health check for AIX OS Yes
Discovery Timeout 120 sudo find <discovery_path> ( -path /AvxTempCertDiscovery -prune ) -o -type f -iname '.kdb' 2> /dev/null | xargs timeout 120 sudo cksum 2> /dev/null Find command to identify the KDB Certificates with its checksum.
Note: This will be executed only when the KDB cert type is selected
 Yes 
dspmqver -p 64
gsk8capicmd -version | grep FileVersion
gsk8cmd -version | grep FileVersion
gsk7capicmd -version | grep FileVersion
gsk7cmd -version | grep FileVersion
gskcmd -version | sed 's/version/Version/'
gsk8capicmd_64 -version | grep FileVersion
 The toolkit version is retrieved based on a specified order of preference. Once a version is identified from one of the toolkits, subsequent commands in the sequence are not executed. Yes
sudo <toolkit> -cert -list -db <key_database_path> -stashed List certificates in a specified Key Database (KDB). Yes
sudo <kdbtoolkit> -cert -export -db <key_database_path> -stashed -type cms -target_type pkcs12 -target /root/LinuxServerAvxTempCertDiscovery_1693815850667/click1602636522.p12 -target_pw ##### Convert KDB certs into p12 Yes
sudo find '<scan_directory>' -type d 2 > /dev/null -printf "%d\n" | sort -nr | head -n 1 To identify the depth of the directory. Depth search is not available in AIX. Yes
Timeout 120 sudo find /<directory> -mindepth 5 -maxdepth 8 \( -path */*AvxTempCertDiscovery* -prune \) -o -type f -iname '*.crt' -o -iname '*.cer' -o -iname '*.p7c' -o -iname '*.p7b' -o -iname '*.key' -o -iname '*.jks' -o -iname '*.pem' -o -iname '*.pfx' -o -iname '*.der' -o -iname '*.p12' -o -iname '.keystore' -o -iname '*.keystore' 2> /dev/null | xargs timeout 120 sudo cksum 2> /dev/null Use the command to identify a file's path along with its checksum. Yes
output="[ "; for a in '/opt/enrollrabitmq.key' ; do value=$(sudo base64 "$a" 2>/dev/null | tr -d '\n\r'); if [ -z "$value" ]; then error=$(sudo base64 "$a" 2>&1 >/dev/null); output="${output} {\"file\":\"$a\", \"error\": \"$error\" },"; else output="${output} {\"file\":\"$a\", \"value\": \"$value\" },"; fi done; output=${output%,}; output="${output} ]"; echo "$output" Download cert content from the Linux server in base64 format. Yes
for p in 

sudo netstat -anlt | grep tcp | 
awk -F " " '{print $4}' | 
awk -F ":" '{print $NF}' | sort | uniq
;do echo "port: $p"; timeout 5 openssl s_client -showcerts -servername server -connect localhost:$p < /dev/null;echo "exit status $?"; done		 Network scan Yes
Temp directory when sudo or service account is used.
Note: This is used during the CSR generation at endpoint and push operation.
 sudo mkdir -p {temp_directory} Create temp directory Yes
chmod 700 {temp_directory} && setfacl -m u:appviewx:rwx -m u:serviceUserName:rwx {temp_directory}

AIX OS Specific Command: chmod 700 {temp_directory} && ( aclget {temp_directory}; echo -e "extended permissions:\nenabled\npermit rwx u:sshUserName\npermit rwx u:serviceUserName") | aclput {temp_directory}

 To address security concerns raised by AppViewX EIS regarding 777 permissions, we are leveraging ACL commands to grant access to both the SSH/SFTP user and the service account user for the temp directory. This ensures secure access while allowing uploaded files in the temp directory to be copied to the configured target location.
Note: The service account username will only be used when the service account is enabled for device onboarding.

As a fallback for any failure in executing this command, chmod 777 is applied to the temporary directory created by AppViewX. Once the transaction is complete, the temporary folder is deleted.

 Yes
sudo cp /{temp_directory}/csr_1700139913719.cnf /home/appviewx/ From the temp directory, the uploaded files will be copied to the configured target location. Yes
sudo rm -rf /{temp_directory} Remove the temp directory which is created by AppViewX. Yes
CSR Generation at endpoint sudo openssl req -nodes -newkey rsa:2048 -sha256 -days <days> -keyout '<key>.key' -out '<file>.csr' -subj '...' -config '<configFile>' Generate a Certificate Signing Request (CSR) with a new RSA private key Yes
openssl dsaparam -out '<key>.key' <bitLength> Generate DSA key parameters file. Used when the CSR key type is DSA. Yes
openssl ecparam -name <algorithm> -genkey -noout -out '<key>.key' Generate EC (Elliptic Curve) private key. Supported algorithms: prime256v1, secp384r1, secp521r1. Yes
openssl req -nodes -new -<hashFunction> -days <days> -key '<key>.key' -out '<file>.csr' -subj '...' -config '<configFile>' Generate CSR using an existing EC/DSA key — uses -new -key instead of -newkey rsa:2048 Yes
set +o history Disable shell history before sensitive commands to prevent passphrase/key material leaking into bash history No
openssl enc -aes-256-cbc -e -in '<key>.key' -out '<key>.txt' -pass pass:<passCode> && rm -f '<key>.key' Encrypt the generated private key and delete the plaintext key file. Used when private key encryption at endpoint is enabled. Yes
set -o history Re-enable shell history after sensitive commands complete No
chmod 640 '<key>.key' (or '<key>.txt' when encryption is enabled) Set 640 permissions on the generated key or encrypted-key file immediately after CSR generation Yes
cat '<csrFileName>.csr' Read back the generated CSR content from the device. AppViewX uses this to retrieve the CSR for the user. Yes
Push Cert sudo find <path> / sudo find <dir> -type f -name '<file>' Check whether the certificate or private key already exists at the target location. Push fails if the private key (at endpoint) is not found. Yes
find '<directory>' -maxdepth 1 -type f -name '<filename>' Check whether a specific file exists at the target path — used to determine whether to retain existing file permissions or apply defaults Yes
sudo stat -c \\"%a\\" <file> / sudo stat -c \\"%U:%G\\" <file> Retrieve the existing file permissions and ownership before push Yes
sudo mkdir -p {push_path} ; sudo touch {push_path} Verify the target directory is writable Yes
sudo echo $HOME Identify the home directory Yes
sudo test -e <file> && echo file exist \|\| echo file not exist Check whether a certificate or key file already exists at the target location Yes
sudo cp -f '<src>' '<backup_path>' Take a backup of the existing certificate before overwriting Yes
sudo openssl pkey -pubout -in <key> \| openssl md5 Cert-and-key MD5 compatibility check — key side Yes
openssl x509 -noout -pubkey -in '<certFilePath>' \| openssl md5 Cert-and-key MD5 compatibility check — certificate side Yes
sudo openssl pkcs12 -export -in '<pem>' -inkey '<key>' -out '<p12>' -passout <pw> -name '<label>' Export certificate to PKCS12 format during P12 push Yes
sudo update-ca-certificates Update the system CA certificates bundle — Debian/Ubuntu Yes
sudo update-ca-trust extract Regenerate the trust store — RHEL/CentOS/Fedora Yes
set +o history Disable shell history before sensitive commands containing passwords or passphrases No
openssl enc -aes-256-cbc -d -in '<key>.txt' -out '<key>.key' -pass pass:<passCode> Decrypt an encrypted private key on the device. Used before push to perform the MD5 cert-and-key compatibility check. Yes
find '<keyPath>' Verify if the decrypted private key file already exists to avoid redundant decryption Yes
rm -f '<keyFilePath>' Delete the temporarily decrypted private key file after the MD5 check is complete Yes
cat '<keyFilePath>' Read private key content from the device (used during JKS push when the private key is located at the endpoint) Yes
base64 '<filePath>' Read file content in base64 format — used to download existing JKS/keystore content for modification (adding certs into an existing keystore) Yes
chmod <perm> <file> Set configured permissions on the pushed certificate or key file Yes
chown '<owner>:<group>' <file> Set configured ownership on the pushed certificate or key file Yes
chgrp '<groupName>' '<filePath>' Change group ownership only (used when owner name is not configured but group name is) Yes
set -o history Re-enable shell history after sensitive commands No
chmod 777 '<tempDir>' Fallback when setfacl/aclget/aclput ACL commands fail — controlled by the "Allow chmod on ACL failure" admin setting Yes

Sudo-enabled Commands

When sudo is enabled, "sudo" is prefixed to all the command executions listed below.
  • su
  • sar
  • cat
  • find
  • mkdir
  • netstat (only if port Scan is enabled)
  • chmod
  • chgrp
  • chown
  • openssl
  • base64
  • rm
  • mv
  • touch
  • echo
  • test
  • cp
  • cksum
  • stat
  • setfacl (Optional)
  • AIX-specific commands
    • aclget
    • aclput
  • Only if .kdb certs are required, depending on the toolkit currently installed
    • runmqakm
    • gsk8capicmd
    • gsk8cmd
    • gsk7capicmd
    • gsk7cmd
    • dspmqver
    • gskcmd
    • gsk8capicmd_64

Validating the Device

After the device is onboarded successfully, follow the steps to validate the device communication with AppViewX:
  1. Go to (Menu) > ADMINISTRATION > Device Management.
    By default, the ADC tab opens.
  2. Click the Server tab.
    The Server Inventory page is displayed.
  3. Check that the device name appears in the inventory (name column) with the specified Status column.
    The status column will have the value Managed/Monitored/Ignored if the connection is successful or displays Failed/Unresolved in case of failure.
  4. From the Status column, click the Managed/Monitored/Ignored/Failed/Unresolved.
    Device Status Log pop-up is displayed.
  5. Expand each value in the pop-up to know the Device communication, Device Version, Instance Information, and Certificate Discovery From Device.

What's Next

Once you have onboarded and validated the device connection, you are ready to proceed with the any of the following certificate actions: