With CloudFront Integration

This document will guide you through the process of integrating the CloudFront AWS service with AppViewX, providing detailed steps, configuration guidelines, and automation techniques.

CloudFront

CloudFront is a Content Delivery Network (CDN) service. It speeds up the delivery of your web content by caching copies of your content at edge locations around the world.

Onboarding AWS Resources with CloudFront Integration in AppViewX

Onboarding AWS Standalone Accounts in AppViewX

A standalone AWS account operates independently with its own set of resources and is not connected to any other AWS accounts.

Prerequisites for Migrating AWS Standalone Accounts from Older Versions

Important:
  • AWS standalone device migration is supported only from the following versions of CERT+ SaaS: v2020.1, v2020.2, v2020.3 - v2020.3 FP7. The following prerequisites are also applicable to only these versions.
  • AWS device migration is not supported from the following versions of CERT+ SaaS: v2012.x, v2019.x, and v2021.x. For these versions, it is recommended that you delete all AWS devices (both, standalone and cross accounts) before migration and add them after the migration to 22.1 is complete.
Note:
  • For customers migrating from versions 20.1.x, 20.2.x, and 20.3.6, AppViewX recommends that you delete the following before migration:
    • All of their Amazon CA settings
    • Any EC2 instances that were added manually from the server inventory (excluding the EC2 instances auto-discovered from the cloud accounts).
  • For customers migrating from version v2020.3.10 (mandatory):
    • Delete all of their Amazon CA settings before migration.
    • Trigger config fetch for all of their cloud accounts after migration.
The following actions have to be performed for the standalone AWS cloud accounts migrated from the above listed versions to version v2022.1 FP1:
For standalone accounts where one of the associated services is not EC2
  1. After you have upgraded the product from a version < v2020.3 FP8 to v2022.1 FP1, from the top left corner of the AppViewX user interface, go to (Menu) > CERT+ > Administration > Device Management.

    The Device :: ADC page is displayed.

  2. From the Device :: ADC page, select Cloud.

    The Device :: Cloud page is displayed.

  3. From the device accounts listed under Account Name, select the required migrated standalone accounts.
    Troubleshooting: If you cannot see the migrated standalone accounts listed, request the super user to grant you the required permissions. Only superusers and users authorized by the superuser can view these migrated accounts in the list.
  4. From the top-right corner of the Device :: Coud page, click the (Fetch config).

    This step is mandatory to upgrade the data recorded for the older devices to the latest format followed in v2022.1 FP1.

For standalone accounts where one of the associated services is EC2

In versions v2020.1/v2020.2/v2020.3-v2020.3FP7, for accounts in which multiple regions are associated with the EC2 service, individual S3 buckets are used to store the permissions for each region.

In v2022.1 FP1, this has been modified to use only one S3 bucket to store the permissions for all regions, irrespective of the number of associated regions.
Note: For accounts with only one associated service region, skip the following steps, since only one S3 bucket includes all permissions anyway. For such accounts, trigger Fetch Config manually from the inventory page.
  • Before migration
    1. Merge permissions from all individual buckets into any one S3 bucket.
  • After migration
    1. Select a migrated standalone account from the Device :: Cloud page.

      The Device :: Cloud > Modify page is displayed, with the details of the selected account.

    2. In the Amazon Cloud Service Settings section, click Fetch collection type.
    3. From the Collection type dropdown list, select the S3 bucket into which all permissions for this account were merged.
    4. Click Add.
    5. Click Save.

      Fetch Config is automatically triggered and the account details are upgraded according to the latest version.

Permissions Required for Onboarding Standalone Accounts

IAM Prerequisites for Discovering and Managing SSL Certificates in CloudFront
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:GetServerCertificate",
                "acm:GetCertificate",
                "acm:ListCertificates",
                "iam:ListServerCertificates",
                "ec2:DescribeRegions",
                "cloudfront:ListDistributions",
                "acm:ImportCertificate",
                "acm:AddTagsToCertificate",
                "acm:ListTagsForCertificate",
                "acm:RemoveTagsFromCertificate",
                "cloudfront:UpdateDistribution",
                "cloudfront:GetDistributionConfig",
                "cloudfront:ListTagsForResource",
                "iam:UploadServerCertificate",
                "iam:ListServerCertificateTags",
                "iam:TagServerCertificate",
                "iam:UntagServerCertificate"
            ],
            "Resource": "*"
        }
    ]
}

Onboarding AWS Standalone Accounts with CloudFront Integration

  1. Go to (Menu) > CERT+ > ADMINISTRATION > Device Management.
    The Device :: ADC page is displayed.
  2. From the Device :: ADC page, select Cloud.
  3. On to the Device :: Cloud page and click (Add).
    The Device :: Cloud > Add page is displayed.
  4. On the Device :: Cloud > Add page, from the list of Vendors, select AWS.
  5. Enter/Select the Basic information.
    Table 1. Field description for the Basic Information section
    Field Description
    Account Type*

    From the dropdown list, select Standalone.
    Account name*

    Enter the customer’s unique AWS account name.

    Constraints:

    • A duplicate account name should not exist in the cloud inventory.
    • The account name should include only alphanumeric and period (.) characters.
    Account number* Enter the customer’s AWS account number.
    Account Description Enter a description of the device to be added.
    Proxy required To use a proxy server for communication, select this checkbox.
    Data center* From the dropdown list, select the data center through which communication with the Certificate Authority will be established.
    *: Mandatory fields
  6. Enter/Select the Credentials-related information.
    Table 2. Field description for the Credentials section
    Field Description
    Credential type* From the dropdown list, from the following options, select the authentication method that will be used for integrating AWS with AppViewX:
    • Manual Entry: The required credentials will be entered manually.
    • Credential List - CyberArk: The required credentials will be retrieved from CyberArk, a Privileged Access Management (PAM) solution.
    • 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 in your SaaS environment:
      1. Create a role in one of your AWS accounts that trusts the AppViewX AWS account.
      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.
    *Access key This field is displayed when Credential type = Manual Entry.

    Enter the access key generated for your AWS account.
    *Secret key This field is displayed when Credential type = Manual Entry.

    Enter the secret key generated for your AWS account.
    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.
    *Master Account Role 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 Enter the unique identifier generated to establish a secure trust relationship between AWS and AppViewX.
    *Credential List This field is displayed when Credential type = Credential List - CyberArk.

    From the dropdown list, select the CyberArk account with the AWS credentials that will be used for onboarding the standalone account.

    The options listed in this dropdown list are the existing CyberArk accounts integrated with AppViewX. For instructions on integrating CyberArk with AppViewX, click here.
    *: Mandatory Fields
  7. Enter/Select the details for the Amazon Cloud Service Settings.
    Table 3. Field description for the Amazon Cloud Service Settings section
    Field Description
    Services* From the dropdown list, select CloudFront.
    Default region* Based on the customer’s requirement, select the default region in which the customer’s AWS cloud account is deployed. AppViewX will use this region to communicate with the other (geographically farther) regions.
    Cert sync

    Select from one of the following options:

    • Managed: AppViewX will connect with the customer’s AWS account and discover certificates. These certificates will be added to the inventory. Users with the relevant permissions can then perform the required certificate-related actions.
    • Monitored: AppViewX will connect with the customer’s AWS account and discover certificates. These certificates will be added to the inventory where the users will be allowed to only view the certificates.
    • Ignored: AppViewX will connect with the customer’s AWS account but certificate discovery will be disabled.
    Custom SSL Client Support For configuring custom SSL client support for CloudFront, from the dropdown list, you need to specify how CloudFront will handle the SSL/TLS connections from different types of clients.
    Select one from the following options:
    • Clients that Support Server Name Indication

      Server Name Indication (SNI) is an extension of the SSL/TLS protocol that allows a client to specify the hostname it is trying to connect to at the start of the handshake process. This allows a server to present multiple SSL/TLS certificates on the same IP address and TCP port number, enabling the use of different certificates for different domains.

    • Legacy Clients Support’

      Legacy clients refer to older browsers and devices that do not support SNI. These clients cannot specify the hostname during the SSL/TLS handshake, meaning they may not be able to establish a secure connection if the server relies on SNI to serve the correct certificate.
    Security Policy The security policy determines which cryptographic algorithms and protocols are available for secure communication, ensuring data integrity, confidentiality, and protection against various security threats.

    From the dropdown list, select the protocol CloudFront will use to establish secure SSL/TLS connections with viewers.
    *: Mandatory Fields
  8. Click Add.
    Account details are now available in the device inventory. Once the account is onboarded, you can discover the corresponding certificates and manage them.

Onboarding AWS Cross Accounts in AppViewX

AppViewX streamlines the management and visibility of your AWS resources by putting in place a simple workflow that lets you onboard your AWS resources onto AppViewX’s holistic certificate lifecycle management solution. One part of this configuration will be done on the AWS management console and the rest of the configuration will be facilitated via the AppViewX interface.

You can onboard the following AWS account types to AppViewX: a standalone account (all resources are available in the same account) and a cross or federated account (resources are distributed across multiple accounts).

This section of the documentation will guide you through the process of onboarding an AWS cross account, for both discovery types, in AppViewX. In AWS, cross-account discovery can be set up in two ways:

  • Organization-based: A centralized discovery mechanism that automatically finds and accesses resources across accounts in your AWS Organization using built-in trust and roles
  • IAM Policy-based: A more flexible discovery mechanism that allows to connect to only the required accounts by manually configuring roles and permissions

Note: The following steps cover only the bare minimum requirements for onboarding a cross account AWS account in AppViewX. The optional fields are out of scope and their configuration is left to the discretion of the user.

Prerequisites for Onboarding a AWS Cross Account in AppViewX

  • Ensure that the following configurations are done on the AWS Management Console:
    • In your AWS master account:
      1. Create an IAM user in the AWS master account.
      2. Generate user identity.
      3. Attach policies to the created user.

        For the AWS IAM permissions to be added for the master account, click here.

    • In your AWS child account:
      1. Create a role in the child account in AWS.
      2. Attach policies to the created role.

        For the AWS IAM permissions to be added for the child account, click here.

      3. Create an EC2 role. This will be used to manage the existing EC2 instance in the AppViewX device inventory.
      4. Attach policies to the EC2 role.

        For the AWS IAM permissions for the EC2 policy, click here.

        For the AWS IAM permissions for the EC2 role, click here.

    Note: For detailed instructions, you can access the corresponding AWS documentation using the references given here.
  • If credentials for onboarding have to be fetched from a credential list in CyberArk:
    • Ensure that your AWS access credentials are saved in your CyberArk account. For instructions on creating AWS access details in the CyberArk account , refer to the documentation here.
      Important: For this use case, in the Account Parameters, the Password field must be considered a mandatory parameter. This field is used to specify the AWS access secret key information.
    • Ensure that CyberArk is integrated with AppViewX and a credential list is created. For instructions, refer to the documentation here.

Onboarding a Cross Account in AppViewX for Organization-based Discovery

  1. Go to (Menu) > CERT+ > ADMINISTRATION > Device Management.
    The Device :: ADC page is displayed.
  2. From the Device :: ADC page, select Cloud.
  3. On to the Device :: Cloud page and click (Add).
    The Device :: Cloud > Add page is displayed.
  4. On the Device :: Cloud > Add page, from the list of Vendors, select AWS.
  5. Enter/Select the Basic information.
    Table 4. Field description for the Basic Information section
    Field Description
    *Account Type From the dropdown list, from the following options, select Cross or Federated.
    *Account name Enter your AWS account name.

    Constraints:

    • A duplicate account name should not exist in the cloud inventory.
    • The account name should include only alphanumeric and period (.) characters.
    Description Enter a description of the device to be added.
    *Account number Enter your AWS account number.
    *Data center From the dropdown list, select the data center through which communication with the Certificate Authority will be established.
    Proxy required To use a proxy server for communication, select this checkbox.

    Proxy settings configured in the Platform module will be used for communication. To read more on how proxy settings are configured and managed, click here.
    *: Mandatory fields
  6. Enter/Select the Credentials-related information.
    Table 5. Field description for the Credentials section
    Field Description
    *Credential type From the dropdown list, from the following options, select the authentication method that will be used for integrating AWS with AppViewX:
    • Manual Entry: The required credentials will be entered manually.
    • Credential List - CyberArk: The required credentials will be retrieved from CyberArk, a Privileged Access Management (PAM) solution.
    • 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 in your SaaS environment:
      1. Create a role in one of your AWS accounts that trusts the AppViewX AWS account.
      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.
    *Access key This field is displayed when Credential type = Manual Entry.

    Enter the access key generated for your AWS account.
    *Secret key This field is displayed when Credential type = Manual Entry.

    Enter the secret key generated for your AWS account.
    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.
    *Master Account Role 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 Enter the unique identifier generated to establish a secure trust relationship between AWS and AppViewX.
    *Credential List This field is displayed when Credential type = Credential List - CyberArk.

    From the dropdown list, select the CyberArk account with the AWS credentials that will be used for onboarding the standalone account.

    The options listed in this dropdown list are the existing CyberArk accounts integrated with AppViewX. For instructions on integrating CyberArk with AppViewX, click here.
    *: Mandatory fields
  7. Enter/Select the information required to Discover Resources.
    Table 6. Field description for the Discover Resources section
    Field Description
    Auto Discover Resources To discover all the cross or federated/child accounts for the master account details provided, enable this field.
    Advanced Settings To customize the auto discovery process, enable this field.
    Auto Discovery Mode* To onboard a cross account for organization-based discovery:
    1. Select Organization Based Discovery.

      The Organization based Discovery dialog box is displayed.

    2. Enter/Select the details required to configure organization-based discovery.
    Note: For the Auto Discovery Mode, you can select both options, Organization Based Discovery as well as Policy Based Discovery. For instructions on configuring Policy Based Discovery, click here.
    Service* From the Select the Service(s) dropdown list, select the CloudFront service component required for the CLM operations.
    Service Region* To select a service region:
    1. To fetch the service regions for the account information provided, click Fetch Region.

      The retrieved service regions are populated in the Select the Region(s) dropdown list.

    2. From the Select the Region(s) dropdown list, select the required service region.
    Cert Sync* Select from one of the following options:
    • Managed: AppViewX will connect with the customer’s AWS account and discover certificates. These certificates will be added to the inventory. Users with the relevant permissions can then perform the required certificate-related actions.
    • Monitored: AppViewX will connect with the customer’s AWS account and discover certificates. These certificates will be added to the inventory where the users will be allowed to only view the certificates.
    • Ignored: AppViewX will connect with the customer’s AWS account but certificate discovery will be disabled.
    Auto Sync To enable/disable automatic synchronization, use the Auto Sync key.

    If Auto Sync is enabled, select the checkbox for the type of synchronization from the following options:

    • Trigger Based (For steps on configuring trigger-based sync, click here.)
    • Schedule Based (For steps on configuring schedule-based sync, click here.)
    *: Mandatory fields
  8. To add the new device to the cloud device inventory, click Add.
  9. Click Save.
    The added device is listed in the outer inventory on the Device :: Cloud page.
Configuring Organization Based Discovery
  1. In the Organization based discovery popup window, under Organisation Accounts, enter/select the discovery details.
    Table 7. Field description for the Organisation Accounts section
    Field Description
    Role Name* Enter the IAM role name for the target account here.
    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.
    Account Number*

    By default, the AWS account number is automatically fetched from the value entered in the Account Number field in the Basic information section.

    To enter a different account number:

    1. From the Account Number field in the Organization based discovery popup window, click Self.
    2. Enter the required account number.
    Role Session Name

    Role Session Name is an identifier for the assumed role session.

    Use the Role Session Name to uniquely identify a session when the same rule is assumed by different principals or for different reasons.
    Duration Seconds

    Enter the duration, in seconds, for which the credentials should remain valid.

    Acceptable durations for IAM user sessions:
    • Minimum: 900 seconds (15 minutes)
    • Maximum: 129,600 seconds (36 hours)
    • Default: 3600 seconds (1 hour)
    External Id External Id is a unique identifier that might be required when you assume a role in another account.
    Source Identity The source identity is specified by the principal that is calling the AssumeRole operation.
    Session Tags

    Session Tags are key-value pairs that you pass when you assume an IAM role or federate a user in AWS STS.

    To create a session tag:
    1. In the Enter Key field, enter a key for the key-value pair.
    2. In the Enter Value field, enter a value for the key-value pair.
    3. Click Add.

    The added key-value pair is shown in the table below the fields.
    *: Mandatory fields
  2. Enter/Select the required details in the Child Accounts section.
    Table 8. Field description for the Child Accounts section
    Field Description
    Role Name* Enter the IAM role name for the target account here.
    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.
    Role Session Name

    Role Session Name is an identifier for the assumed role session.

    Use the Role Session Name to uniquely identify a session when the same rule is assumed by different principals or for different reasons.
    Duration Seconds

    Enter the duration, in seconds, for which the credentials should remain valid.

    Acceptable durations for IAM user sessions:
    • Minimum: 900 seconds (15 minutes)
    • Maximum: 129,600 seconds (36 hours)
    • Default: 3600 seconds (1 hour)
    External Id External Id is a unique identifier that might be required when you assume a role in another account.
    Source Identity The source identity is specified by the principal that is calling the AssumeRole operation.
    Session Tags

    Session Tags are key-value pairs that you pass when you assume an IAM role or federate a user in AWS STS.

    To create a session tag:
    1. In the Enter Key field, enter a key for the key-value pair.
    2. In the Enter Value field, enter a value for the key-value pair.
    3. Click Add.

    The added key-value pair is shown in the table below the fields.
    *: Mandatory fields
  3. Click Save.
    The Organization based discovery popup window is closed and you will be navigated back to the Discover resources section.
    Note:
    • If the popup is closed without values entered for at least one field, then the Organization based discovery checkbox will be unchecked.
    • Values once saved in the popup will be stored and made available on the screen always, regardless of the number of times the Organization based discovery checkbox is checked or unchecked, unless the values are updated.
Configuring Trigger Based Sync
  1. In the Discover Resources section, enable Auto Sync and select Trigger Based.
    The Trigger Based Sync popup window is displayed.
  2. Enter/Select the required Queue Parameter details.
    Table 9. Field description for the Queue Parameter section
    Field Description
    SQS URL* Enter the URL of the SQS queue.
    Dead Letter Queue

    Enter the URL of the Dead Letter Queue.

    Note: This field is optional and can be used for user reference purposes only. Currently, AppViewX does not have any insights based on DLQ messages.
    *: Mandatory fields
  3. Enter/Select the STS Token details.
    Table 10. Field description for the STS Token section
    Field Description
    Role ARN* Enter the Amazon Resource Name that will interact with the SQS queue through the AWS STS.
    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.
    Role Session name

    Role Session Name is an identifier for the assumed role session.

    Use the Role Session Name to uniquely identify a session when the same rule is assumed by different principals or for different reasons.
    Duration Seconds

    Enter the duration, in seconds, for which the credentials should remain valid.

    Acceptable durations for IAM user sessions:
    • Minimum: 900 seconds (15 minutes)
    • Maximum: 129,600 seconds (36 hours)
    • Default: 3600 seconds (1 hour)
    External Id External Id is a unique identifier that might be required when you assume a role in another account.
    Source Identity The source identity is specified by the principal that is calling the AssumeRole operation.
    Session Tags

    Session Tags are key-value pairs that you pass when you assume an IAM role or federate a user in AWS STS.

    To create a session tag:
    1. In the Enter Key field, enter a key for the key-value pair.
    2. In the Enter Value field, enter a value for the key-value pair.
    3. Click Add.

    The added key-value pair is shown in the table below the fields.
    *: Mandatory fields
  4. Enter/Select the SQS Attributes.
    Table 11. Field description for the SQS Attributes section
    Field Description
    SQS Polling Interval* Enter an interval value for the SQS message polling from AppViewX.
    Max Number of Messages* Enter the maximum number of messages that will be returned by the queue per request.
    Visibility Timeout in Minutes*

    After messages are retrieved by a ReceiveMessage request, they need to be made invisible to subsequent retrieve requests for a custom duration.

    In this field, enter this duration in minutes.

    Wait time in seconds* Enter a duration, in seconds, for which a call will wait for a message to arrive in the queue before returning.
    *: Mandatory fields
  5. In the Auto Sync Services section, select the list of services for which the trigger-based sync mechanism is required.
  6. In the Service Specific Parameters section, from the EC2 Sync Delay Time dropdown list, select the delay interval (in hours) for the synchronization of EC2 instances when they are discovered for the first time.
    Note: This section is displayed only if the EC2 service is selected in the Auto Sync Services section.
  7. Click Apply.
Configuring Schedule Based Sync
  1. In the Discover Resources section, enable Auto Sync and select Schedule Based.
    The Schedule Based Sync popup window is displayed.
  2. Enter/Select the General Information.
    Table 12. Field description for the General Information section
    Field Description
    Frequency of Sync*

    To schedule the sync, set a frequency using the two dropdown lists for this field. For example, to set the frequency to 1 day:

    1. From the first dropdown list, select 1.
    2. From the second dropdown list, select Days.
    Advance Settings For the current release, this field is set to Off and is disabled. This field and the associated features will be enabled in the upcoming release.
    *: Mandatory fields
  3. Click Apply.

Onboarding a Cross Account in AppViewX for IAM Policy-based Discovery

  1. Go to (Menu) > CERT+ > ADMINISTRATION > Device Management.
    The Device :: ADC page is displayed.
  2. From the Device :: ADC page, select Cloud.
  3. On to the Device :: Cloud page and click (Add).
    The Device :: Cloud > Add page is displayed.
  4. On the Device :: Cloud > Add page, from the list of Vendors, select AWS.
  5. Enter/Select the Basic information.
    Table 13. Field description for the Basic Information section
    Field Description
    *Account Type From the dropdown list, from the following options, select Cross or Federated.
    *Account name Enter your AWS account name.

    Constraints:

    • A duplicate account name should not exist in the cloud inventory.
    • The account name should include only alphanumeric and period (.) characters.
    Description Enter a description of the device to be added.
    *Account number Enter your AWS account number.
    *Data center From the dropdown list, select the data center through which communication with the Certificate Authority will be established.
    Proxy required To use a proxy server for communication, select this checkbox.

    Proxy settings configured in the Platform module will be used for communication. To read more on how proxy settings are configured and managed, click here.
    *: Mandatory fields
  6. Enter/Select the Credentials-related information.
    Table 14. Field description for the Credentials section
    Field Description
    *Credential type From the dropdown list, from the following options, select the authentication method that will be used for integrating AWS with AppViewX:
    • Manual Entry: The required credentials will be entered manually.
    • Credential List - CyberArk: The required credentials will be retrieved from CyberArk, a Privileged Access Management (PAM) solution.
    • 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 in your SaaS environment:
      1. Create a role in one of your AWS accounts that trusts the AppViewX AWS account.
      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 CloudFormation 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.
    *Access key This field is displayed when Credential type = Manual Entry.

    Enter the access key generated for your AWS account.
    *Secret key This field is displayed when Credential type = Manual Entry.

    Enter the secret key generated for your AWS account.
    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.
    *Master Account Role 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 Enter the unique identifier generated to establish a secure trust relationship between AWS and AppViewX.
    *Credential List This field is displayed when Credential type = Credential List - CyberArk.

    From the dropdown list, select the CyberArk account with the AWS credentials that will be used for onboarding the standalone account.

    The options listed in this dropdown list are the existing CyberArk accounts integrated with AppViewX. For instructions on integrating CyberArk with AppViewX, click here.
    *: Mandatory fields
  7. Enter/Select the information required to Discover Resources.
    Table 15. Field description for the Discover Resources section
    Field Description
    Auto Discover Resources To discover all the cross or federated/child accounts for the master account details provided, enable this field.
    Advanced Settings To customize the auto discovery process, enable this field.
    Auto Discovery Mode* To onboard a cross account for IAM policy-based discovery:
    1. Select Policy Based Discovery.

      The Policy based Discovery dialog box is displayed.

    2. Enter/Select the details required to configure IAM policy-based discovery.
    Note: For the Auto Discovery Mode, you can select both options, Organization Based Discovery as well as Policy Based Discovery. For instructions on configuring Organization Based Discovery, click here.
    Service* From the Select the Service(s) dropdown list, select the CloudFront service component required for the CLM operations.
    Service Region* To select a service region:
    1. To fetch the service regions for the account information provided, click Fetch Region.

      The retrieved service regions are populated in the Select the Region(s) dropdown list.

    2. From the Select the Region(s) dropdown list, select the required service region.
    Cert Sync* Select from one of the following options:
    • Managed: AppViewX will connect with the customer’s AWS account and discover certificates. These certificates will be added to the inventory. Users with the relevant permissions can then perform the required certificate-related actions.
    • Monitored: AppViewX will connect with the customer’s AWS account and discover certificates. These certificates will be added to the inventory where the users will be allowed to only view the certificates.
    • Ignored: AppViewX will connect with the customer’s AWS account but certificate discovery will be disabled.
    Auto Sync To enable/disable automatic synchronization, use the Auto Sync key.

    If Auto Sync is enabled, select the checkbox for the type of synchronization from the following options:

    • Trigger Based (For steps on configuring trigger-based sync, click here.)
    • Schedule Based (For steps on configuring schedule-based sync, click here.)
    *: Mandatory fields
  8. To add the new device to the cloud device inventory, click Add.
  9. Click Save.
    The added device is listed in the outer inventory on the Device :: Cloud page.
Configuring IAM Policy Based Discovery
  1. In the IAM Policy based discovery popup window enter/select the Child Accounts details.
    Table 16. Field description for the Child Accounts section
    Field Description
    Role Session Name

    Role Session Name is an identifier for the assumed role session.

    Use the Role Session Name to uniquely identify a session when the same rule is assumed by different principals or for different reasons.
    Duration Seconds

    Enter the duration, in seconds, for which the credentials should remain valid.

    Acceptable durations for IAM user sessions:
    • Minimum: 900 seconds (15 minutes)
    • Maximum: 129,600 seconds (36 hours)
    • Default: 3600 seconds (1 hour)
    External Id External Id is a unique identifier that might be required when you assume a role in another account.
    Source Identity The source identity is specified by the principal that is calling the AssumeRole operation.
    Session Tags

    Session Tags are key-value pairs that you pass when you assume an IAM role or federate a user in AWS STS.

    To create a session tag:
    1. In the Enter Key field, enter a key for the key-value pair.
    2. In the Enter Value field, enter a value for the key-value pair.
    3. Click Add.

    The added key-value pair is shown in the table below the fields.
  2. Click Save.
    The IAM Policy based discovery popup window is closed and you will be navigated back to the Discover resources section.
    Note:
    • If the popup is closed without values entered for at least one field, then theIAM Policy based discovery checkbox will be unchecked.
    • Values once saved in the popup will be stored and made available on the screen always, regardless of the number of times the IAM Policy Based Discovery checkbox is checked or unchecked, unless the values are updated.
Configuring Trigger Based Sync
  1. In the Discover Resources section, enable Auto Sync and select Trigger Based.
    The Trigger Based Sync popup window is displayed.
  2. Enter/Select the required Queue Parameter details.
    Table 17. Field description for the Queue Parameter section
    Field Description
    SQS URL* Enter the URL of the SQS queue.
    Dead Letter Queue

    Enter the URL of the Dead Letter Queue.

    Note: This field is optional and can be used for user reference purposes only. Currently, AppViewX does not have any insights based on DLQ messages.
    *: Mandatory fields
  3. Enter/Select the STS Token details.
    Table 18. Field description for the STS Token section
    Field Description
    Role ARN* Enter the Amazon Resource Name that will interact with the SQS queue through the AWS STS.
    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.
    Role Session name

    Role Session Name is an identifier for the assumed role session.

    Use the Role Session Name to uniquely identify a session when the same rule is assumed by different principals or for different reasons.
    Duration Seconds

    Enter the duration, in seconds, for which the credentials should remain valid.

    Acceptable durations for IAM user sessions:
    • Minimum: 900 seconds (15 minutes)
    • Maximum: 129,600 seconds (36 hours)
    • Default: 3600 seconds (1 hour)
    External Id External Id is a unique identifier that might be required when you assume a role in another account.
    Source Identity The source identity is specified by the principal that is calling the AssumeRole operation.
    Session Tags

    Session Tags are key-value pairs that you pass when you assume an IAM role or federate a user in AWS STS.

    To create a session tag:
    1. In the Enter Key field, enter a key for the key-value pair.
    2. In the Enter Value field, enter a value for the key-value pair.
    3. Click Add.

    The added key-value pair is shown in the table below the fields.
    *: Mandatory fields
  4. Enter/Select the SQS Attributes.
    Table 19. Field description for the SQS Attributes section
    Field Description
    SQS Polling Interval* Enter an interval value for the SQS message polling from AppViewX.
    Max Number of Messages* Enter the maximum number of messages that will be returned by the queue per request.
    Visibility Timeout in Minutes*

    After messages are retrieved by a ReceiveMessage request, they need to be made invisible to subsequent retrieve requests for a custom duration.

    In this field, enter this duration in minutes.

    Wait time in seconds* Enter a duration, in seconds, for which a call will wait for a message to arrive in the queue before returning.
    *: Mandatory fields
  5. In the Auto Sync Services section, select the list of services for which the trigger-based sync mechanism is required.
  6. In the Service Specific Parameters section, from the EC2 Sync Delay Time dropdown list, select the delay interval (in hours) for the synchronization of EC2 instances when they are discovered for the first time.
    Note: This section is displayed only if the EC2 service is selected in the Auto Sync Services section.
  7. Click Apply.
Configuring Schedule Based Sync
  1. In the Discover Resources section, enable Auto Sync and select Schedule Based.
    The Schedule Based Sync popup window is displayed.
  2. Enter/Select the General Information.
    Table 20. Field description for the General Information section
    Field Description
    Frequency of Sync*

    To schedule the sync, set a frequency using the two dropdown lists for this field. For example, to set the frequency to 1 day:

    1. From the first dropdown list, select 1.
    2. From the second dropdown list, select Days.
    Advance Settings For the current release, this field is set to Off and is disabled. This field and the associated features will be enabled in the upcoming release.
    *: Mandatory fields
  3. Click Apply.

Account Level/Inner Inventory

For the child accounts added, this table explains the fields that AppViewX displays to show the details of each account.
Field Description
Account Name Name of the account to which the cloud device belongs
Role Name Role name of the account creator
Service Region The service region selected for the account
Service Service integrated for the cloud device
Status Status of the discovered accounts.
This field takes the following values:
  • For the master account:
    • Managed
    • Failed
  • For the child account:
    • Success
    • Partial Success
    • Queued
    • In Progress
    • Failed
Resource Discovery Status
Note: Resource discovery status is not applicable for master accounts. For master accounts, the resource discovery status is set to Not Applicable.
This field indicates the status of the resource discovery for the individual entities belonging to a discovered account using the following values:
  • Not started: Resource discovery for the entity is yet to begin.
    Note: At this point, it is not mandatory for the associated account to be in the Managed (account credentials validated) state.
  • In-Progress: Resource discovery for the entity by AppViewX in the customer’s AWS environment is currently in progress. The aggregated resource discovery status is In-Progress till the resource discovery status for all individual entities is Completed.
    Note: This is possible only when the account is in the Managed state.
  • Completed: Resource discovery by AppViewX in the customer’s AWS environment is complete.
    Note: This is possible only when the account is in the Managed state.
    Note:
    • Completed resource discovery only implies completion of the discovery process by AppViewX on AWS. All resources may not be discovered all the time. The count of resources discovered with respect to the total resources will be shown in detailed reporting.
    • The resource discovery status of all entities mapped to the account should be Completed.
  • Not Applicable: The resource discovery status is set to Not Applicable:
    • when Status = Failed or Resolved,
    • for ACM and ELB resources,
    • for all existing devices and child accounts as part of data migration.
Cert Discovery Status
Note: Cert discovery status is not applicable for master accounts. For master accounts, the cert discovery status is set to Not Applicable.
This field indicates the status of the certificate discovery for the individual entities belonging to a discovered account using the following values:
  • Not started: Certificate discovery for the entity is yet to begin
    Note: At this point, the resource discovery status of the associated account can be Not started, In-Progress, or Completed.
  • In-Progress: Certificate discovery for the entity by AppViewX in the customer’s AWS environment is currently in progress. The status is In-Progress till the certificate discovery status for all accounts is either Completed or Not Applicable.
  • Completed: Certificate discovery by AppViewX in the customer’s AWS environment is complete.
    Note: This is possible only when the certificate discovery status for all the entities associated with the account is Completed.
    Note: Completed certificate discovery only implies completion of the discovery process by AppViewX on AWS. All certificates may not be discovered all the time. The count of resources discovered with respect to the total resources will be shown in detailed reporting.
    .
  • Not Applicable: The certificate discovery status is set to Not Applicable:
    • when Status = Failed or Resolved
    • for EC2 when no EC2 instances are discovered
    • for all existing devices and child accounts as part of data migration
Note: The cert discovery status is based on the status of only those entities for which the cert discovery status is not Not Applicable.
Cert sync Cert sync type (Managed, Monitored, Ignored) selected for the entity
State Outcome of the device addition (Success, Failed)

AWS IAM Prerequisites for Master Account

Permissions for Discovering Child Accounts using Policy-based Discovery
Note: This is required if IAM Policy-based account discovery is enabled in AppViewX. This IAM user account should be dedicated for the AppViewX Platform.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "iam:GetPolicyVersion",
        "iam:GetPolicy",
        "iam:GetUserPolicy",
        "iam:ListGroupsForUser",
        "iam:ListGroupPolicies",
        "iam:ListAttachedUserPolicies",
        "iam:ListAttachedGroupPolicies",
        "iam:ListUserPolicies",
        "iam:GetGroupPolicy",
        "iam:GetUser"
      ],
      "Resource": "*"
    }
  ]
}
Permissions for Discovering Child Accounts using AWS Organization Services
Note: The permissions mentioned below should be enabled in the account in which organization service is enabled. 
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "organizations:Describe*",
                "organizations:List*"
            ],
            "Resource": "*"
        }
    ]
}
Permissions for Enabling Assume Role Access to all AWS Accounts
Note: This action helps to automatically discover CLM resources in the newly created cloud accounts without manual intervention. This is an optional action, required only if the user prefers to grant access to all the child accounts for the IAM user.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "arn:aws:iam::<child account 1>:role/<Assume-role>",
        "arn:aws:iam::<child account 2>:role/< Assume-role>",
        "arn:aws:iam::<child account 3>:role/< Assume-role>"
      ]
    }
  ]
}
Permissions for Enabling Assume Role Access for a Specific Child Account
Note: If a user prefers not to grant assume role access to all accounts, they can define the RoleARN of a specific child account in the IAM policy, as is shown in the policy below.
Note: This is mandatory when IAM Policy-based account discovery is enabled in AppViewX for child account discovery.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole"
      ],
      "Resource": "arn:aws:iam::<child-account>:role/AppViewX"
    }
  ]
}
Permissions for Enabling S3 Bucket Access to the AppViewX Platform
Note: The permissions mentioned below are required only if the EC2 service has been added in AppViewX. IAM role should be created in the account with S3 permissions where the S3 bucket resides.
Note: This permission is required when assume role access is granted only to a specific RoleARN.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": "arn:aws:iam::<child-account>:role/AppViewX-S3-Bucket-Access"
        }
    ]
}
Permissions for Accessing Organization Services to Discover AWS Accounts
Note: This permission is required when assume role access is granted only to a specific RoleARN.
Note: This permission enables AppViewX to discover the AWS accounts associated to a specific organization.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole"
      ],
      "Resource": "arn:aws:iam::<child-account>:role/AppViewX"
    }
  ]
}

AWS IAM Prerequisites for Child Account

Permissions for Establishing a Trust Relationship in Child Accounts
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::master-account-number:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
Permissions for Discovering and Managing SSL Certificates in CloudFront
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:GetServerCertificate",
                "acm:GetCertificate",
                "acm:ListCertificates",
                "iam:ListServerCertificates",
                "ec2:DescribeRegions",
                "cloudfront:ListDistributions",
                "acm:ImportCertificate",
                "acm:AddTagsToCertificate",
                "acm:ListTagsForCertificate",
                "acm:RemoveTagsFromCertificate",
                "cloudfront:UpdateDistribution",
                "cloudfront:GetDistributionConfig",
                "cloudfront:ListTagsForResource",
                "iam:UploadServerCertificate",
                "iam:ListServerCertificateTags",
                "iam:TagServerCertificate",
                "iam:UntagServerCertificate"
            ],
            "Resource": "*"
        }
    ]
}
Permissions for Managing SSM Permissions for the EC2 Policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ssm:SendCommand",
		 "ssm:DescribeDocument",
		 "ec2:DescribeInstances",
		 "s3:ListAllMyBuckets",
		 "ssm:DescribeInstanceInformation",
		 "ssm:GetDocument",
		 "ssm:CreateDocument",
		 "ssm:GetCommandInvocation",
		 "ec2:DescribeRegions"
            ],
            "Resource": "*"
        }
    ]
}
Permissions for Managing SSM Permissions for EC2 Role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ssm:DescribeDocument",
                "ec2messages:GetEndpoint",
                "ec2messages:GetMessages",
                "ssmmessages:OpenControlChannel",
                "ec2messages:DeleteMessage",
                "ssm:UpdateInstanceInformation",
                "ec2messages:FailMessage",
                "ssmmessages:OpenDataChannel",
                "ssm:GetDocument",
                "ssm:ListTagsForResource",
                "ec2messages:AcknowledgeMessage",
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ec2messages:SendReply"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:PutObject",
                "s3:GetEncryptionConfiguration",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::appviewx-s3/*",
                "arn:aws:s3:::appviewx-s3"
            ],
            "Effect": "Allow"
        }
    ]
}

Onboarding Certificates for AWS Resources in AppViewX

There are two ways you can onboard certificates in AppViewX:
  • Via certificate discovery, for existing certificates
  • Via certificate enrollment, for new certifcates

Discovering Certificates for AWS Resources

  1. Go to (Menu) > CERT+ > CERTIFICATE DISCOVERY > Discovery > Cloud Scan.
    The Discovery : Cloud Scan : Add Discovery page is displayed.
  2. To initiate a cloud certificate discovery scan, enter the Discover Details.
    1. To specify the frequency at which the certificate discovery scan will be triggered, select the Discovery Run Type.
      Table 21. Discovery run type options
      Frequency Type Description
      On-demand Cloud certificate discovery scan is triggered manually by the user as and when required.
      Scheduled Cloud certificate discovery scan is triggered automatically at the specified time and date.
    2. Enter the details for initiating an on-demand cloud certificate discovery scan.
      Table 22. Field descriptions for on-demand discovery
      Frequency Type Description
      Discovery Instance Name Enter a name for the discovery instance.
      Description Enter additional details related to the discovery option.
      Note: Character limit: 2000 characters

      OR

      Enter the details for initiating a scheduled cloud certificate discovery scan.

      Table 23. Field descriptions for scheduled discovery
      Frequency Type Description
      Discovery Instance Name Enter a name for the discovery instance.
      Description Enter additional details related to the discovery option.
      Note: Character limit: 2000 characters
      *Time Zone From the dropdown list, select the time zone in which the scheduled discovery instance will be triggered.
      Occurrence Type From the dropdown list, from the following options, select an occurrence frequency:
      • Daily
      • Weekly
      • Monthly
      • Yearly
      *Repeat On
      Note: This field is displayed only when Occurrence Type = Weekly.
      Select the checkbox corresponding to the day of the week on which you want the discovery occurrence to repeat.
      *Starts On Click (Calendar widget) to select a date to start the scheduled discovery.
      *Ends From the following options, select when the scheduled discovery is to end:
      • Never: Discovery never stops.
      • After: Discovery stops after the number of occurrences specified in the text field.
      • On: Discovery stops on the date selected using (Calendar widget)
      Summary Displays a summary of the selections made for scheduled discovery
      *: Mandatory fields
  3. To filter the discovered certificates, enter the Discover By details.
    Table 24. Field descriptions for the Discover By section
    Field Description
    *Discovery From From the dropdown list, select Cloud (the source to discover a certificate from).
    *Vendor From the dropdown list, select AWS.
    *Account type From the following options, select the AWS account type for certificate discovery:
    • Stand-alone account sign-in (In a stand-alone account, the user account and the resources are available in the same account.)
    • Cross account sign-in (In a cross-account resources are available across multiple accounts and users are given role-based access.)
    *Select Account View
    Note: This field is displayed only when you've selected Account type = Cross account sign-in.
    From the given options, select one to specify if the discovery will be performed for the master account or for the child accounts.
    *Select Filter Type
    Note: This field is enabled when:
      • Account type = Stand-alone account sign-in
      • Account type = Cross account sign-in AND Select Account View = Child Account.
    From the following options, select one to specify how the discovery results should be filtered:
    • Account View
    • Service View
    Selected Resources To search for a resource:
    1. (Optional) In the Type your search and press Enter field, enter a search keyword to filter the list of resources.
    2. Select the checkbox corresponding to the required resource.
    To add an existing resource to the list:
    1. Click .
    2. From the Add Accounts dialog box, select the checkbox corresponding to the required resource(s).
    3. Click Add Selected.
      Note: The Add Selected button is enabled after at least one resource is selected.
    To delete a resource from the list:
    1. Select the checkbox corresponding to the resource you want to delete.
    2. From the Action field, click .

      OR

      Click .
      Note: To delete multiple resources at once:
      1. Select the checkboxes for the resources to be deleted.
      2. Click .
    Execute Batches Sequentially To execute the discovery operation on the specified batches sequentially, select this checkbox.
    *Interval Between Batches If Execute Batches Sequentially is selected, enter an interval duration (in minutes) in this field. The sequential execution of the batches is spaced according to the interval value entered here.
    *: Mandatory fields
  4. In the Discovery Rules section, from the Associate Rule dropdown list, select a rule that will be used to filter the discovered certificates.
    A set of filters is combined to create a rule, from the Rules menu. The selection of rules will apply respective filters on discovered certificates.
  5. In the After Discover section, enter the following details:
    Table 25. Field descriptions for the After Discover section
    Field Description
    *Move Certificate to Inventory with Status Select from one of the following options:
    • Do not move: The newly discovered certificates and their objects will not be moved to the inventory.
    • Managed: The newly discovered certificates and their objects will be moved to the inventory with the status set to Managed.
    • Monitored: The newly discovered certificates and their objects will be moved to the inventory with the status set to Monitored.
    Use Access Control Rule To apply the rule configured using Access Control, select this checkbox.
    Note: If this checkbox is enabled, the certificate group will be associated automatically by the rule in access control.
    *Certificate Group From the dropdown list, select a certificate group to which the discovered certificates will be associated.

    Based on the group association, a policy will also be applied to these certificates, which will help ascertain compliance or non-compliance.

    *: Mandatory fields
  6. In the Discovery Notifications section, to receive discovery status update notifications:
    1. Select the Subscribe for discovery status notifications checkbox.
    2. In the Who should be notified? field, select one from the following options:
      • Notify User: Send a notification only to the user configuring/modifying this discovery instance.
      • Notify User Group: Send a notification to all the users in the triggering user's user group.
  7. Click Discover/Schedule to trigger the on-demand/scheduled discovery, respectively.
    The discovered certificates are listed in the certificate inventory.

Enrolling Certificates

Enrolling a Server Certificate

Prerequisites
[For Linux-based vendor] OpenSSL is used to generate a private key and a Certificate Signing Request (CSR) as part of the endpoint enrollment process. Ensure that OpenSSL is installed and properly configured on the system before proceeding.
Enrolling a Server Certificate
Server certificate enrollment refers to the process ofcreating a digital ID for an application/web server hosted in the network. It starts with the generation of a key pair (private and public key) and CSR, and then submitting the CSR to the required CA to procure a certificate. CERT+ supports the generation of keypair on the device, HSM, AppViewX. Users can also upload the CSR for enrolling for a digital certificate.

To enroll a server certificate:

  1. Go to (Menu) > CERT+ > CERTIFICATE ACTION > Enroll Certificate > Server
    The Enroll Server Certificate page is displayed.
  2. In the General Information section, from the dropdown list, select the required Assign Group.
  3. Enter the CA Details.
    Table 26. Field descriptions for the CA Details section
    Field Description
    *Certificate Authority From the dropdown list, select the certificate authority to request the certificate enrollment.
    Note: The IDnomic CA can be used for issuing certificates only in an on-prem deployment. Certificates issued through IDnomic CA can be renewed only if they are enrolled using a Registration Authority workflow.
    *Renew Automatically
    Note:
    To automatically renew this certificate:
    1. Turn on the Renew Automatically toggle.

      The *Start Renewing field is displayed.

    2. In the Days Before Expiry field, specify how many days prior to a certificate's expiry the renewal process should start.

      Valid range for number of days: 1 to 120

    Note: The auto renew settings from the parent certificate will be transferred to the child certificate only if the toggle was enabled; they will not transfer if the certificate was renewed manually. After migration, these settings will be disabled for the parent certificate, so enable them manually if needed.
    *Regenerate Automatically To automatically regenerate this certificate:
    1. Turn on the Regenerate Automatically toggle.

      The *Start Regenerating field is displayed.

    2. In the Days Before Expiry field, specify how many days prior to a certificate's expiry the regeneration process should start.

      Valid range for number of days: 1 to 120

      Note: This value can exceed the certificate's validity in case of short-lived certificates.
    Note:
    • This feature can be enabled only for valid certificates (not for revoked/suspended and expired certificates).
    • The auto regenerate settings from the parent certificate will be transferred to the child certificate only if the toggle was enabled; they will not transfer if the certificate was regenerated manually. After migration, these settings will be disabled for the parent certificate, so enable them manually if needed.
    *Re-enroll Automatically To automatically regenerate this certificate:
    1. Turn on the Re-enroll Automatically toggle.

      The *Start Re-enrollng field is displayed.

    2. In the Days Before Expiry field, specify how many days prior to a certificate's expiry the regeneration process should start.

      Valid range for number of days: 1 to 120

      Note: This value can exceed the certificate's validity in case of short-lived certificates.
    Note: User overrides are allowed unless Group Override is active, in which case the group's configuration takes precendence.
    *CA Account From the dropdown list, select the CA account to which the certificate enrollment request will be submitted.
    Certificate Type From the dropdown list, select the required certificate type.
    *Division
    Note: This field is applicable only for Digicert CA.
    From the dropdown list, select the division with which the certificate will be enrolled.
    Certificate Profile
    Note: This field is displayed for only selected CAs. For the IDnomic CA, this field is displayed when only-CA setting is selected from the CA Account dropdown list.

    From the dropdown list, select the certificate profile with which the certificate must enroll.
    *RA Workflow
    Note: This field is displayed when Certificate Authority = IDnomic and a RA setting is selected from the CA Accounts dropdown list.
    From the dropdown list, select the RA workflow that will be used for certificate enrollment.

    For the details of a workflow, you can check them on your CA portal on IDnomic.

    *Issuer Location
    Note: This field is applicable only for Google CA.

    From the dropdown list, select the issuer location associated with the CA account.
    *Issuer Name
    Note: This field is applicable only for Google CA and AppViewX PKIaaS Native.

    From the dropdown list, select the issuer name for issuing the certificate.
    Template Name
    Note: This field will be displayed only when Certificate Authority = AppViewX Native CA.

    Select a template name from the dropdown list.

    Template Name is editable. The selected template will be displayed in the Template/Profile column of the Server Certificate Inventory irrespective of the Managed/Monitor status. You can also search and filter certificates based on the template name within the CERT+ Inventory.
    *Issuance Policy
    Note: This field is applicable only for Futurex.
    From the dropdown list, select the issuing policy for this certificate.

    An issuance policy defines the rules Futurex must follow to process the certificate enrollment request. The selected issuance policy will determine the approval requirements for the certificate, the cryptographic settings, notification triggeres and other configuration parameters.
    *Root CA
    Note: This field is applicable only for Futurex.
    From the dropdown list, select the root CA for the certificate being enrolled.

    This is the trusted root certificate authority that anchors the certificate chain. All issued certificates will ultimately chain up to this root.
    *Signing CA
    Note: This field is applicable only for Futurex.
    From the dropdown list, select the Certificate Authority that will sign the requested certificate.
    *Extension Profiles
    Note: This field is applicable only for Futurex.
    Extension profiles enable you to further modify your certificates with additional field, attributes, and requirements.

    From the dropdown list, select the extension profile that will be used for the certificate being enrolled.

    To read more on and for instructions to create extension profiles, refer the Futurex documentation. For links, see the References section.

    *Approval Group Name
    Note: This field is applicable only for Futurex.
    An approval group is a predefined set of users or roles authorized to approve the certificate enrollment request.

    From the dropdown list, select the approval group to authorize this enrollment request.

    To read more on and for instructions to create and manage approval groups, refer the Futurex documentation. For links, see the References section.
    *Connector Name Enter a friendly name for the CA connector.

    On saving this form, the name entered here will be displayed in the holistic view.
    Description
    Note: Character limit: 2000 characters

    Enter the description in this field.
    *CSR Generation
    Note: This field is applicable for all CAs except Amazon.

    From the following options, select the required method for generating the CSR:

    • AppViewX: Private key and CSR will be created in AppViewX based on CSR parameters given.
      Note: If auto regeneration has been enabled for this cerificate, AppViewX can be enforced as the default CSR generation source (irrespective of any selections made here) every time the certificate is regenerated. To do this, execute the following db script:
      db.cert_metadata.insertOne({"_id":"CERT_AUTO_REGENERATE_DEFAULT_APPVIEWX_CSR", "flag":true})
    • Upload CSR: You can upload a file that contains the CSR details. This source file will be used to populate the CSR parameters, which will then be submitted to the CA.
      1. Under CSR Generation, select Upload CSR.

        The Please paste your CSR field is displayed.

      2. From the Please paste your CSR field, select Browse.
      3. Navigate to the location of your CSR file, and click Open.
      4. Click Upload.

        On successful upload of this file, the CSR fields are populated with the corresponding details.

    • HSM:
      Note: This option is disabled/not displayed when Certificate Authority = Google, CSC Global, and DigiCert One.
      To generate the private key and the CSR, based on the CSR parameters given in an HSM device:
      1. Under CSR Generation, select HSM.
      2. To enter the configuration details for CSR generation, refer the field descriptions given here.
    • End Point:
      Note: This option is disabled when Certificate Authority = Google and CSC Global.
      To generate the private key and the CSR, based on the CSR parameters given in an endpoint device:
      1. Under CSR Generation, select End Point.
      2. To enter the configuration details for CSR generation, refer the field descriptions given here.
    *: Mandatory fields
    Table 27. Field descriptions for using HSM as the CSR generation source
    Field Description
    *Device Type From the dropdown list, from the following options, select the type of device on which the private key and the CSR will be generated:
    • HSM Devices (AppViewX will directly communicate with the HSM device for the CSR generation.)
    • ADC Devices (The selected ADC device will interact with the HSM to generate the CSR and subsequently transmit the relevant details to AppViewX.)
    *Vendors This field is displayed only when Device Type = ADC Devices.

    From the dropdown list, select the required ADC device vendor.
    Module Number This field is displayed when Device Type = ADC Devices and Vendors = Thales.

    In the event that multiple HSMs are configured on a system, module number is a unique identifier assigned to each HSM.

    In this field, enter the module number assigned to the selected Thales device.
    *Devices From the dropdown list, select the required HSM/ADC device.

    This field is populated based on the Device Type and Vendors selected.

    • For Device Type = HSM Devices

      The dropdown list is populated with HSM devices that were enabled for CSR generation at the time of onboarding and have been successfully onboarded. To read more on onboarding HSM devices in AppViewX, click here.

    • For Device Type = ADC Devices

      The dropdown list is populated with F5 devices that are in the Managed state.

      Currently, AppViewX enables HSM key generation only through F5 devices for the following HSM vendors and their respective supported versions:
      • Fortanix (v14 and onwards)
      • Thales (v12 and onwards)
      • Safenet (v12 and onwards)
    *Key Handler Name This field is displayed when Device Type = HSM Devices.

    Key handler name refers to an identifier used to reference a cryptographic key managed by an HSM device.

    Enter the desired handler name in the field.
    *Key Reference Name This field is displayed when Device Type = ADC Devices.

    Key reference name refers to an identifier used to reference a private key that is stored locally on an ADC device or is securely accessible to the device via an external HSM.

    In this field, enter the reference name assigned to the private key stored in/accessible to the selected ADC device.
    Table 28. Field descriptions for using an endpoint device as the CSR generation source
    Field Description
    Category From the following options, select the ADC device category:
    • ADC
    • Cloud
    • Server
    • WAF
    • Firewall
    Note:
    • Run the following script to enable endpoint CSR generation support for GlobalSignAtlas:
      db.getCollection('cert_metadata').insertOne({
    "_id": "CSR_GENERATION_ENDPOINT_SUPPORTED_VENDOR_GLOBALSIGNATLAS",
    "objectMap": {
        "Server": [
            "ABAP",
            "Web Dispatcher"
        ]
    }
});
    • On selecting GlobalSignAtlas CA, Category is automatically populated as Server.
    Vendor The dropdown list for this field is populated based on the Category selected. From the dropdown list, select the vendor for the end point device.
    Note:
    • On selecting GlobalSignAtlas CA, Vendor is populated with ABAP and Web Dispatcher.
    *Devices This field lists the end point devices present in your environment that belong to the above selected Category and Vendor.
    From the dropdown list, select the end point device on which you want to generate the private key and the CSR.
    Note: On selecting Vendor = Fortinet, both Fortigate and FortiManager devices are populated. Auto-regeneration of certificates with FortiManager as endpoint is not supported.
    *Profile This field is applicable only when Category = Server/WAF. Select a profile from the dropdown list.
    Note: On selection of Vendor = Imperva, CSR generation at the endpoint is supported only for SaaS platforms. Profiles will not be displayed for AWS/on-prem deployments.
    *Tenant This field is applicable only when Category = AD. Enter the tenant ID.
    *Service name From the dropdown list, select the cloud service running on the selected cloud Devices.
    CSR Location This field is applicable only when Category = Server.
    *Template Name This field is applicable only when Category = Firewall.

    Select the required template from the dropdown list.

    Note:
    • This field will be enabled when the Platform = Panorama while onboading PaloAlto device at Menu > CERT+ > Device Management > Inventory> Firewall > Add.
    • Templates and partitions are used to enroll certificates at the template level. To enroll a certificate at the Panorama level, set the template to None.
    Partition This field is applicable only when Category = Firewall.
    *CSR File Name Enter the name of the file that contains the CSR parameters.
    Note:
    • As the extension is already included in the field, ensure that you enter the file name without the file extension.
    • Starting v2023.1.0 FP2, for enrolling Apache server certificates, this field is labeled as CSR File Location.
    *Key File Name Enter the name of the file that contains the private key details.
    Note:
    • As the extension is already included in the field, ensure that you enter the file name without the file extension.
    • Starting v2023.1.0 FP2, for enrolling Apache server certificates, this field is labeled as Key File Location.
    *Certificate File Name This field is displayed only when Category = Cloud. Enter the certificate file name.
    *Key vault This field is displayed only when Category = Cloud, Vendor = Azure, and Service name = Key Vault (Azure).
    *Service
    Note: This field is displayed when Category = Server and Vendor = Microsoft Server.
    This dropdown list is populated based on the Device selected.

    From the options in the dropdown list, select the service.
    *Exchange Server
    Note: This field is displayed when Category = Server and Vendor = Microsoft Server.
    From the dropdown list, select the name of the MS Exchange server for which the certificate is being enrolled.
  4. For the EJBCA certificate authority, enter the vendor details.
    Table 29. Field descriptions for the EJBCA Vendor Specific Details section
    Field Description
    * End Entity Profile Name From the dropdown list, select the end entity profile name.
    End entity user name Enter the name of the end user entity.
    * Issuer Common Name From the dropdown list, select the issuer common name.
    *Certificate Profile Name From the dropdown list, select the certificate profile name.
    *: Mandatory fields
    Note: When generating a new private key on an endpoint, existing keys (including .txt encrypted key files) are not overwritten immediately.
    • For non–password-protected certificate types (PEM-.crt, PEM-.cer, PEM-.pem, DER-.der, DER-.cer, PKCS7-.p7b, PKCS7-.p7c), the .txt file is decrypted into the original key filename (keyfile.key) during the push. If a key with the same name already exists, it will be replaced.
    • For password-protected certificate types (Default JKS-.jks, JKS-.keystore, PKCS12-.p12, PKCS12-.pfx):
      • During the push , the encrypted .txt file is decrypted into a temporary, timestamped key file (keyfile_.key).
      • This decrypted key is then combined with the certificate to create the final bundled output (e.g., .pfx, .jks).
      • After bundling, the temporary timestamped key file is deleted; Because the decrypted key file is temporary and timestamped, no key replacement occurs, and no existing key files are overwritten.
    This is currently applicable for:
    • Linux vendors - Generic Linux, Apache Linux, Tomcat Linux, and Nginx Linux.
    • Windows vendors - Windows Apache, Windows Tomcat, and Microsoft SQL.
  5. For the certificate being enrolled, enter the CSR Parameters.
    Note: For DigiCert One, all CSR parameters that are assigned static values in the certificate profile will be auto-populated and disabled for editing.
    Table 30. Field descriptions for the CSR Parameters
    Field Description
    Replace PSE File The Replace PSE File checkbox enables users to generate the CSR or private key in the Server. This checkbox is displayed only in the case described below:
    1. Select the CSR Generation radio button as Endpoint.
    2. Select Category as Server, Vendor as ABAP or Web Dispatcher The Profiles dropdown is the only other field displayed below it and is populated with a list of .pse file names.
    3. Select the required Profile from the dropdown. Based on the values selected, the fields in the CSR Parameters section are auto-populated.

    The Replace PSE File checkbox is disabled by default and the SAN details fields in CSR Parameters section are also disabled. Selecting the checkbox will make the SAN details enabled and allow for values to be updated.
    *Common Name Enter the certificate's common name.

    The common name is one of the key values of Certificate Signing Request (CSR) to be present in the certificate. For example, <appviewx>.

    Note: Constraints:
    • Character limit: 64 characters
    • No special characters allowed except en dash (_) and hyphen (-).
    • For VMware vCenter, enter the device's FQDN to avoid certificates being rejected. If left blank, the FQDN will be auto-detected and populated.
    Subject Alternative Name From the dropdown list, select the Subject Alternative Name category for the certificate being enrolled.

    In the corresponding field(s) displayed for the selection made, enter the required values.

    Note:
    • Multiple values must be separated by a comma.
    • After enrollment, the cumulative count of SANs is displayed in the certificate property pop-up window from the holistic view.
    • For VMWare vCenter, enter the device's FQDN to avoid certificates being rejected. If left blank, the FQDN will be auto-detected and populated.
    DNS Mutiple SAN values must be separated by a comma (,).
    Organization The organization name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note: For VMWare vCenter, this is a mandatory field.
    Organization Unit Organization Unit name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note: For VMWare vCenter, this is a mandatory field.
    Locality The locality name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note: For VMWare vCenter, this is a mandatory field.
    State The state name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note: For VMWare vCenter, this is a mandatory field.
    Country Country name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on configuration. It must be a 2-letter country code (for example, US, and so on).
    Note:
    • For renewal of the certificate being enrolled, country name is required.
    • For VMWare vCenter, this is a mandatory field.
    Email Address Enter a valid email address of the person responsible for maintaining the certificate.
    Note: For VMWare vCenter, this is a mandatory field.
    *Validity To specify the validity of the certificate being enrolled:
    1. From the first dropdown list, select the number of days/months/years.
    2. From the second dropdown list, select the unit of the duration from the following values: Days/Months/Year.
      For example, if the validity of the certificate is 2 months:
      1. From the first dropdown list, select 2.
      2. From the second dropdown list, select Months.
    Note: The uploaded certificate validity for Globalsign MSSL is set to 365 days.
    Challenge Password Challenge password is one of the CSR parameters to be present in the certificate. Password must contain at least one alphabet (uppercase and lowercase), one number, and one special character.
    Confirm Password Re-enter the password entered in the Challenge Password field.
    *Hash Function The Hash function with which the CSR has to be signed. Any information specific to any CA or vendor has to be covered in the Note section. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note: For Certificate Authority = HydrantID, irrespective of the hash function selected, by default, the CA returns a certificate with SHA256. Therefore, admins must restrict users from creating a certificate with a hash function other than SHA256. To accomplish this, create policy with a single hash value (SHA256).
    *Key Type The key type is used while creating a private and public key pair. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note:
    • FortiManager supports only RSA key type of 512, 1024, 1536, 2048, 3072, 4096 bits.
    • VMWare supports only RSA of 2048, 3072, 4096, 7680, 8192 bits and EC key type.
    *Bit Length The bit length is used while creating a private and public key pair. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    *: Mandatory fields
  6. In the Attachments section, upload any additional documents that are relevant to the enrollment of the certificate (for example, approval emails).
    Table 31. Field descriptions for the Attachments section
    Field Description
    Name Enter a name for the document. This need not be the actual name of the document; it can be an alternate name that will be used for reference only.
    Comments Enter any details relevant to the document being attached.
    Note: Character limit: 2000 characters
    Upload File To upload an attachment:
    1. Click Upload.
    2. Navigate to the location of the document to be uploaded.
    3. Select the document to be document and click Open.

      The selected document is uploaded and listed in the table displayed below these fields in the Attachments section.

      Tip: If you have uploaded multiple attachments, use the Search field to find the required one.
    *: Mandatory fields
  7. In the Certificate Attributes section, enter organization-specific values, for the certificate attributes and custom attributes for the issuing CA, that need to be mentioned along with the CSR.
    These values will not be a part of the certificate but will be available in the AppViewX inventory. For example, cost center.
    Note: This additional information can be used to filter certificate details in the inventory.
  8. Enter the relevant details in the Generic Fields. These are default fields for maintaining the IP address and device information, if required.
    Table 32. Field descriptions for the Generic Fields
    Field Description
    Device Name Enter the name of the device.
    Application IP Address Enter the IP address of the application.
    Tracking ID A free-form business alpha-numerical identifier, included in the audit logs, that may be used to correlate audit log entries (typically enrollment and revocation events)
    Certificate holder Email
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    An email address that may be used to send notifications to certificate holder depending on the notification policies configured for the requested workflow
    First name
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    First name (as a metadata) associated with the certificate to be enrolled
    Last name
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Last name (as a metadata) associated with the certificate to be enrolled
    Organization
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Organization name (as a metadata) associated with the certificate to be enrolled
    Comment
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Additional information (as a metadata) associated with the certificate to be enrolled
    UUID
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Universal Unique Identifier, or UUID, (as a metadata) associated with the certificate to be enrolled
  9. In the Vendor-Specific Details section, enter the CA-specific details. Some of the CAs will expect additional details other than CSR parameters as meta data for their operational purposes. Details common to all CAs will be taken from the AppViewX user information of the logged in user.
    Table 33. Field descriptions for the common vendor specific details
    Field Description
    Certificate ID The Certificate ID is auto-populated based on the value entered in the Common Name field (in the CSR Parameters section).
    • The Certificate ID can be modified by the user.
    • If the user edits the Certificate ID, any change to the Common Name will not reflect in the Certificate ID.
    • If the user deletes the Certificate ID, the value of the Certificate ID field is set to the Common Name suffixed with the timestamp.
    Table 34. Field descriptions for the CSC Global CA vendor specific details
    Field Description
    *Server Type From the dropdown list, select the server on which the application that requires the requested certificate is hosted.
    *Business Unit Enter the name of the business unit that is requesting the certificate.
    *Organization Contact Enter the email address of the contact in the organization requesting the certificate.
    *Phone Number Enter the phone number of the Organization Contact in the followung format: +<country code>-<phone number>.
    Note: For CSC Global, the phone number is not fetched from the AppViewX user information because of the difference in format.
    *Domain Control Validation Type From the following options in the dropdown list, select the method CSC Global will use for authentication before issuing a certificate:
    • EMAIL: CSC Global will send an approval/confirmation request to the registered email ID. Certificate issuance happens only after approval is received.
    • CNAME: On requesting certificate issuance, CSC Global will provide you with a dynamic string. Add a CNAME record with this string to your DNS settings. CSC will issue the certificate requested only after validating this CNAME record.
    Note: CSC Global will perform domain validation for all CLM actions.
    *: Mandatory fields
    Table 35. Field descriptions for the Custom CA vendor specific details
    Field Description
    *CRL and OCSP required To control the inclusion of CRL and OCSP settings, turn this toggle button on/off as required.
    *: Mandatory fields
    Table 36. Field descriptions for the DigiCert CA vendor specific details
    Field Description
    *Server Type From the dropdown list, select the server on which the application that requires the requested certificate is hosted.
    *Payment Method From the dropdown list, select one from the following payment methods:
    • Bill To Account Balance: This option allows you to pay for the DigiCert certificate using the available balance in your DigiCert account.
      Note: Ensure that the option to bill to account balance is enabled for the account and the account has sufficient balance.
    • Bill To Default Credit Card: This option will charge the cost of the DigiCert certificate to the credit card set as the default payment method in your DigiCert account.
      Note: Ensure that a credit card is configured as the default payment method for your account.
    Additional Email Enter email addresses that will receive notifications for renewals, reissues, and duplicates for the specified order.
    Renewal Message Enter a custom message that will be sent with the renewal notifications.
    Notes Enter a custom note that will be sent with the order.
    *: Mandatory fields
    Table 37. Field descriptions for the DigiCert One CA vendor specific details
    Field Description
    Seat ID Enter the seat ID that will be assigned to the certificate being enrolled.
    Seat ID is a unique user-defined value assigned to identify an entity in the DigiCert One account. The seat ID for a certificate is used for certificate enrollment, renewal, and regeneration.
    Note: The Seat ID field is displayed only if the Allow Seat ID during enrollment option is selected for the CA account. In this case, the value entered in the Seat ID field is now a unique identifier for the certificate being enrolled. Otherwise, a common seat ID is assigned to all certificates enrolled for the selected CA account
    Table 38. Field descriptions for the GlobalSign MSSL CA vendor specific details
    Field Description
    *Profile name A profile name is defined at the time of creating an account on the GlobalSign MSSL portal. AppViewX retrieves all your profile names from the GlobalSign MSSL portal and populates them in this dropdown list.

    From the dropdown list, select the profile name the enrolled certificate should be mapped to.
    *: Mandatory fields
    Table 39. Field descriptions for the Hydrant ID CA vendor specific details
    Field Description
    Expiry Emails Enter a comma-separated list of email addresses that will receive the certificate expiry notification from HydrantID.
    Note: HydrantID CA does not accept updates to these email addresses during the renewal process.
    Table 40. Field descriptions for the Nexus CA vendor specific details
    Field Description
    Procedures The Procedures dropdown list will display only the procedures mapped to the server and the default procedure. From the dropdown list, select the required procedure.
    Table 41. Field descriptions for the LetsEncrypt CA vendor specific details
    Field Description
    *Challenge Type Specifies the method for verifying domain ownership. Select the required domain for the validation. The available challenge types are:
    • HTTP
    • DNS.
    Challenge Verify Determines how the DNS challenge will be verified. Select the required verification process. The available challenge verifies are:
    • Manual
    • Automatic.
    The value Automatic suggests that the system will automatically handle the verification process without manual intervention.
    Note: This field appears when the challenge type is selected as DNS.
    Vendor Indicates the DNS provider responsible for managing DNS records. The available DNS service providers are:
    • Cloudflare
    • Azure.
    Note: This field appears when the challenge verify is selected as Automatic.
    *Settings Allows for additional configuration settings related to the DNS challenge. The selected value None implies that no extra settings are applied.
    Note: This field appears when the challenge verify is selected as Automatic.
    Note:
    • Make sure that you have enabled LetsEncrypt DNS Automation from the workflow.
    • To add new vendors for the integration and configuration, refer to Integration topic in the Automation Guide.
    *: Mandatory fields
  10. Click Add.
    Once the details are added, you will be redirected to a page where the CSR and CA details are added as a connector. This page is called the holistic view and from here, any action on the certificate can be performed including provisioning the certificate to a server.
  11. On the holistic view, click the Submit button to trigger the request.
    The submit action is triggered and the Submit dialog box is displayed.
  12. Enter your comments in the text field and click Yes.
    If the approval required option is enabled in the CA policy, the request is moved to the Approve and Implementation stages.
  13. Click Approve to proceed.
    The Approve dialog box is displayed.
  14. Enter your comments in the text field.
    Note: If the workflow request has to be approved automatically in the future, click the Schedule later button .
  15. Click Yes.
    Once the approval process is complete, the Implement option is displayed in the holistic view.
  16. Click Implement.
    The Implement dialog box is displayed.
  17. Enter your comments in the text field.
    If the workflow request has to be implemented automatically in the future, click Schedule later .
  18. Click Yes.
    CSR Submission to CA is in progress.Once the CSR submission is successful, the request state will be changed to Submit certificate - retrieval in progress state.

    If the enrollment request is compliant with conditions defined and auto-approval enabled in the targeted CA, the certificate will be fetched in a few seconds.

    If auto-approval disabled in the targeted CA, you will have to be logged into the CA and approve the request.

    Once the certificate is issued successfully, the certificate will be retrieved into AppViewX. You can now push the enrolled certificate(s) to the required endpoint.

Enrolling Client Certificates

  1. Go to (Menu) > CERT+ > CERTIFICATE ACTION > Enroll Certificate > Client
    The Enroll Client Certificate page is displayed.
  2. In the General Information section, from the dropdown list, select the required Assign Group.
  3. Enter/Select the CA Details.
    Table 42. Field descriptions for the CA Details section
    Field Description
    *Certificate Authority
    Note: Depending on the CA selected, the rest of the fields will be displayed.
    From the dropdown list, select the required certificate authority (CA).
    Note: For enrolling certificates with policies using Google CA, consider the following points:
    Certificate Enrollment - Strict Policy
    • The Common Name will not be pre-filled from the policy.
    • The following validation will be seen based on strict policy guidelines.
      • If the Common Name’s domain name is not present in the Allowed Domain Name list, an error validation will be shown upon saving the policy details.
    Certificate Enrollment - Suggestive Policy
    • The Common Name will not be pre-filled from the policy
    • The following validation will be seen based on strict policy guidelines.
      • If the Common Name’s domain name is not present in the Allowed Domain Name list, the non-compliant policy will be created.
      • If the Common Name’s domain name is present in the Blocked Domain Name list, an error validation will be shown upon saving the policy details.
    Note: For Certificate Authority = EJBCA, an additional set of fields, Vendor specific details is displayed after the CA Details section. Instructions on specifying the vendor specific details are covered in step 4.
    *Renew Automatically
    Note:
    To automatically renew this certificate:
    1. Turn on the Renew Automatically toggle.

      The *Start Renewing field is displayed.

    2. In the Days Before Expiry field, specify how many days prior to a certificate's expiry the renewal process should start.

      Valid range for number of days: 1 to 120

    Note: The auto renew settings from the parent certificate will be transferred to the child certificate only if the toggle was enabled; they will not transfer if the certificate was renewed manually. After migration, these settings will be disabled for the parent certificate, so enable them manually if needed.
    Note: The IDnomic CA can be used for issuing certificates only in an on-prem deployment. Certificates issued through IDnomic CA can be renewed only if they are enrolled using a Registration Authority workflow.
    Subscribe Email Alerts for Auto-Renewal This field is displayed when Renew Automatically is enabled.

    To receive email notifications every time this certificate is auto-renewed, select this checkbox.

    The email notification includes certificate details, the type of auto action (renewal, in this case), and the outcome (success/failure). These notifications help administrators stay informed of automated lifecycle actions, reducing the overhead to manually track them.

    If enabled here, this setting overrides the group setting for email alerts subscription, unless group-level overrides have been enforced.

    *Regenerate Automatically To automatically regenerate this certificate:
    1. Turn on the Regenerate Automatically toggle.

      The *Start Regenerating field is displayed.

    2. In the Days Before Expiry field, specify how many days prior to a certificate's expiry the regeneration process should start.

      Valid range for number of days: 1 to 120

      Note: This value can exceed the certificate's validity in case of short-lived certificates.
    Note:
    • This feature can be enabled only for valid certificates (not for revoked/suspended and expired certificates).
    • The auto regenerate settings from the parent certificate will be transferred to the child certificate only if the toggle was enabled; they will not transfer if the certificate was regenerated manually. After migration, these settings will be disabled for the parent certificate, so enable them manually if needed.
    Subscribe Email Alerts for Auto-Regenerate This field is displayed when Regenerate Automatically is enabled.

    To receive email notifications every time this certificate is auto-regenerated, select this checkbox.

    The email notification includes certificate details, the type of auto action (regeneration, in this case), and the outcome (success/failure). These notifications help administrators stay informed of automated lifecycle actions, reducing the overhead to manually track them.

    If enabled here, this setting overrides the group setting for email alerts subscription, unless group-level overrides have been enforced.

    *Re-enroll Automatically To automatically regenerate this certificate:
    1. Turn on the Re-enroll Automatically toggle.

      The *Start Re-enrollng field is displayed.

    2. In the Days Before Expiry field, specify how many days prior to a certificate's expiry the regeneration process should start.

      Valid range for number of days: 1 to 120

      Note: This value can exceed the certificate's validity in case of short-lived certificates.
    Note: User overrides are allowed unless Group Override is active, in which case the group's configuration takes precendence.
    *CA Account To which account the enrollment request to be submitted.
    Certificate Type Select the desired certificate type from the dropdown list.
    *Division Select the division to which the certificate must be enrolled.
    Note: This field will be shown only for Digicert CA.
    Certificate Profile
    Note: This field is applicable only for AppViewX CA and Google CA. For the IDnomic CA, this field is displayed when only-CA setting is selected from the CA Account dropdown list.

    From the dropdown list, select the profile with which the certificate must enroll.
    *RA Workflow
    Note: This field is displayed when Certificate Authority = IDnomic and a RA setting is selected from the CA Accounts dropdown list.
    From the dropdown list, select the RA workflow that will be used for certificate enrollment.

    For the details of a workflow, you can check them on your CA portal on IDnomic.

    *Issuer Location Select the location of the issuer CA from the dropdown.
    Note: This is applicable only for Google CA.
    *Issuer Name Select the name of the issuer CA from the dropdown.
    Note: This is applicable only for Google CA.
    *Issuance Policy
    Note: This field is applicable only for Futurex.
    From the dropdown list, select the issuing policy for this certificate.

    An issuance policy defines the rules Futurex must follow to process the certificate enrollment request. The selected issuance policy will determine the approval requirements for the certificate, the cryptographic settings, notification triggeres and other configuration parameters.
    *Root CA
    Note: This field is applicable only for Futurex.
    From the dropdown list, select the root CA for the certificate being enrolled.

    This is the trusted root certificate authority that anchors the certificate chain. All issued certificates will ultimately chain up to this root.
    *Signing CA
    Note: This field is applicable only for Futurex.
    From the dropdown list, select the Certificate Authority that will sign the requested certificate.
    *Extension Profiles
    Note: This field is applicable only for Futurex.
    Extension profiles enable you to further modify your certificates with additional field, attributes, and requirements.

    From the dropdown list, select the extension profile that will be used for the certificate being enrolled.

    To read more on and for instructions to create extension profiles, refer the Futurex documentation. For links, see the References section.

    *Approval Group Name
    Note: This field is applicable only for Futurex.
    An approval group is a predefined set of users or roles authorized to approve the certificate enrollment request.

    From the dropdown list, select the approval group to authorize this enrollment request.

    To read more on and for instructions to create and manage approval groups, refer the Futurex documentation. For links, see the References section.
    *Connector Name Enter the friendly name for Certificate Authority connector in this field which will be displayed in the holistic view on saving this form.
    Description Enter the description in this field.
    Note: Character limit: 2000 characters
    *CSR Generation Select the CSR generation option as required.

    Options are:

    • Upload CSR: Uploaded CSR will be used as the source to populate CSR parameters and submit to CA.
      To upload a CSR:
      1. Under CSR Generation, select Upload CSR.

        The Please paste your CSR field is displayed.

      2. From the Please paste your CSR field, select Browse.
      3. Navigate to the location of your CSR file, and click Open.
      4. Click Upload.

        On successful upload of this file, the CSR fields are populated with the corresponding details.

    • HSM: The private key and CSR will be created in the selected HSM device based on CSR parameters given.
      To generate the private key and the CSR, based on the CSR parameters given in an HSM device:
      1. Under CSR Generation, select HSM.
      2. To enter/select the configuration details for CSR generation, refer the field descriptions given here.
    • End Point: The private key and CSR will be created in the selected end point device based on the CSR parameters given.
      To generate the private and the CSR, based on the CSR parameters given in an endpoint device:
      1. Under CSR Generation, select End Point.
      2. To enter/select the configuration details for CSR generation, refer the field descriptions given here.
    • AppViewX - Private key and CSR will be created in AppViewX based on CSR parameters given.
      Note: If auto regeneration has been enabled for this cerificate, AppViewX can be enforced as the default CSR generation source (irrespective of any selections made here) every time the certificate is regenerated. To do this, execute the following db script:
      db.cert_metadata.insertOne({"_id":"CERT_AUTO_REGENERATE_DEFAULT_APPVIEWX_CSR", "flag":true})
    Note: For all CA types except Amazon, you have the option to generate the CSR.
    *: Mandatory fields
    Table 43. Field descriptions for using HSM as the CSR generation source
    Field Description
    *Device Type From the dropdown list, from the following options, select the type of device on which the private key and the CSR will be generated:
    • HSM Devices (AppViewX will directly communicate with the HSM device for the CSR generation.)
    • ADC Devices (The selected ADC device will interact with the HSM to generate the CSR and subsequently transmit the relevant details to AppViewX.)
    *Vendors This field is displayed only when Device Type = ADC Devices.

    From the dropdown list, select the required ADC device vendor.
    Module Number This field is displayed when Device Type = ADC Devices and Vendors = Thales.

    In the event that multiple HSMs are configured on a system, module number is a unique identifier assigned to each HSM.

    In this field, enter the module number assigned to the selected Thales device.
    *Devices From the dropdown list, select the required HSM/ADC device.

    This field is populated based on the Device Type and Vendors selected.

    • For Device Type = HSM Devices

      The dropdown list is populated with HSM devices that were enabled for CSR generation at the time of onboarding and have been successfully onboarded. To read more on onboarding HSM devices in AppViewX, click here.

    • For Device Type = ADC Devices

      The dropdown list is populated with F5 devices that are in the Managed state.

      Currently, AppViewX enables HSM key generation only through F5 devices for the following HSM vendors and their respective supported versions:
      • Fortanix (v14 and onwards)
      • Thales (v12 and onwards)
      • Safenet (v12 and onwards)
    *Key Handler Name This field is displayed when Device Type = HSM Devices.

    Key handler name refers to an identifier used to reference a cryptographic key managed by an HSM device.

    In this field, enter the reference name assigned to the Master Encryption Key stored in the selected HSM device.
    *Key Reference Name This field is displayed when Device Type = ADC Devices.

    Key reference name refers to an identifier used to reference a private key that is stored locally on an ADC device or is securely accessible to the device via an external HSM.

    Enter the desired handler name in the field.
    Table 44. Field descriptions for using an endpoint device as the CSR generation source
    Field Description
    Category From the following options, select the ADC device category:
    • ADC
    • Cloud
    • Server
    • Firewall.
    Vendor From the dropdown list, select the vendor for the end point device.
    Note: The dropdown list for this field is populated based on the Category selected.
    *Devices This field lists the end point devices present in your environment that belong to the above selected Category and Vendor.

    From the dropdown list, select the end point device on which you want to generate the private key and the CSR.
    Tenant
    Note: This field is applicable only when Category = ADC.
    Enter the tenant ID.
    *Service name From the dropdown list, select the cloud service running on the selected cloud Devices.
    CSR Location
    Note: This field is applicable only when Category = Server.
    *Template Name
    Note: This field is applicable only when Category = Firewall.

    Select the required template from the dropdown list.

    Note:
    • This field will be enabled when the Platform = Panorama while onboading PaloAlto device at Menu > CERT+ > Device Management > Inventory> Firewall > Add.
    • Templates and partitions are used to enroll certificates at the template level. To enroll a certificate at the Panorama level, set the template to None.
    Partition
    Note: This field is applicable only when Category = Firewall.
    *CSR File Name Enter the name of the file that contains the CSR parameters.
    Note: Since the extension is already included in the field, ensure that you enter the file name without the file extension.
    Note: Starting v2023.1.0 FP2, for enrolling Apache server certificates, this field is labeled as CSR File Location.
    *Key File Name Enter the name of the file that contains the private key details.
    Note: Since the extension is already included in the field, ensure that you enter the file name without the file extension.
    Note: Starting v2023.1.0 FP2, for enrolling Apache server certificates, this field is labeled as Key File Location.
    *Certificate File Name
    Note: This field is displayed only when Category = Cloud.
    Enter the certificate file name.
    *Key vault
    Note: This field is displayed only when Category = Cloud, Vendor = Azure, and Service name = Key Vault (Azure).
    *Service
    Note: This field is displayed when Category = Server and Vendor = Microsoft Server.
    This dropdown list is populated based on the Device selected.

    From the options in the dropdown list, select the service.
    *Exchange Server
    Note: This field is displayed when Category = Server and Vendor = Microsoft Server.
    From the dropdown list, select the name of the MS Exchange server for which the certificate is being enrolled.
  4. For the EJBCA certificate authority, enter/select the vendor details.
    Table 45. Field descriptions for the EJBCA Vendor Specific Details section
    Field Description
    * End Entity Profile Name From the dropdown list, select the end entity profile name.
    End entity user name Enter the name of the end user entity.
    * Issuer Common Name From the dropdown list, select the issuer common name.
    *Certificate Profile Name From the dropdown list, select the certificate profile name.
    *: Mandatory fields
  5. Enter/Select the CSR Parameters.
    Table 46. Field descriptions for the CSR Parameters section
    Field Description
    *Common Name The common name is one of the key values of Certificate Signing Request (CSR) to be present in the certificate. For example, <appviewx>.

    No special characters allowed except en dash (_) and hyphen (-).
    *Common Name Indicator
    Important: See note.
    This field is displayed when the selected CA Account is DigiCert and Certificate Type is one of the following:
    • Secure Email for Business
    • Digital Signature
    • Premium
    As part of DigiCert's revised security regulations, the common name for the above listed DigiCert certificate types is derived from the one of the input attributes, as selected from the dropdown list.

    For the common name indicator, from the dropdown list, select one of the following:

    • First Name and Last Name
    • Pseudonym
    • Email (applicable only for the Secure Email for Business certificate type)
    *First Name This field is displayed when:
    • Common Name Indicator = First Name and Last Name
    • Common Name Indicator = Email and Indicator Type = First Name and Last Name

    Enter the verified first name of the individual subject.

    For Common Name Indicator = First Name and Last Name

    A combination of the first name and last name will be used to derive the certificate's common name, which will be displayed in the certificate's Common Name field or the Subject DN (in the certificate details that can be accessed from the holistic view).

    For Common Name Indicator = Email and Indicator Type = First Name and Last Name

    The first and last name will be appended as mandatory additional information to the Subject Alternative Name.
    *Last Name This field is displayed when:
    • Common Name Indicator = First Name and Last Name
    • Common Name Indicator = Email and Indicator Type = First Name and Last Name

    Enter the verified last name of the individual subject.

    For Common Name Indicator = First Name and Last Name

    A combination of the first name and last name will be used to derive the certificate's common name, which will be displayed in the certificate's Common Name field or the Subject DN (in the certificate details that can be accessed from the holistic view).

    For Common Name Indicator = Email and Indicator Type = First Name and Last Name

    The first and last name will be appended as mandatory additional information to the Subject Alternative Name.
    *Pseudonym This field is displayed when:
    • Common Name Indicator = Pseudonym
    • Common Name Indicator = Email and Indicator Type = Pseudonym

    Enter the pseudonym of the individual subject. A pseudonym is a fictitious name assumed for a particular person.

    For Common Name Indicator = Pseudonym

    The entered pseudonym will be displayed in the certificate's Common Name field or the Subject DN (in the certificate details that can be accessed from trhe holistic view).

    For Common Name Indicator = Email and Indicator Type = Pseudonym

    The pseudonym will be appended as mandatory additional information to the Subject Alternative Name.
    *Indicator Type This field is displayed when Certificate Type = Secure Email for Business and Common Name Indicator = Email.

    In this case, the issuer's email address, as specified in the CSR parameters, is used to derive the common name.

    For Common Name Indicator = Email, it is mandatory to include additional information in the form of the first name and last name or the pseudonym, which will be appended to the Subject Alternative Name.

    From the following options, select the required indicator type to be used as mandatory information along with the email:
    Subject Alternative Name You can see the count of subject alternative names (SAN) available for a certificate in the CSR parameter section, inventory grid, and CA connector page.

    Select the subject alternative subject name from the dropdown list.

    The possible options are,

    • Select all
    • DNS
    • IP Address.
    Note:
    • Multiple values must be separated by a comma.
    • The cumulative count SANs appears in the certificate property pop-up window from the holistic view.
    *Organization The organization name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Organization Unit Organization Unit name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Locality The locality name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    State The state name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    *Country Country name is one of the CSR parameters to be present in the certificate. This field will be auto-filled and editable based on configuration. It must be a 2-letter country code (for example, US, and so on).
    Email Address The email contact details of the person responsible for maintaining the certificate. Enter the valid e-mail address.

    Except for SwissSign, this field is mandatory or optional based on the value selected for the Email Address mandatory for Client Certificate field in the corresponding CA policy.
    *Order Validity Enter the number in this field and select the entered validity list to be in Days, Months, and Years from the dropdown list.
    The Order Validity for the following DigiCert S/MIME certificate types cannot exceed 2 years:
    • Secure Email for Business
    • Digital Signature
    • Premium
    Note: As per revised security regulations for DigiCert S/MIME certificates, the maximum lifespan of the the above listed certificate types is two years.
    Challenge Password Challenge password is one of the CSR parameters to be present in the certificate. Password must contain at least one alphabet (uppercase and lowercase), one number, and one special character.
    Confirm Password Reenter the same password to confirm that is entered in the Challenge Password field.
    *Hash Function The Hash function with which the CSR has to be signed. Any information specific to any CA or vendor has to be covered in the Note section. This field will be auto-filled and editable based on the configuration in the selected group’s policy.
    Note: For Certificate Authority = HydrantID, irrespective of the hash function selected, by default, the CA returns a certificate with SHA256. Therefore, admins must restrict users from creating a certificate with a hash function other than SHA256. To accomplish this, create policy with a single hash value (SHA256).
    *Key Type From the dropdown list, select the cryptogrpahic algorithm that will be used for generating the certificate's key pair.

    The dropdown list is populated based on the CA policy configured for the selected CA.
    *Bit Length From the dropdown list, select the required key size (in bits).

    The dropdown list is populated based on the CA policy configured for the selected CA.
    *ECDSA curve For Key Type = EC, from the dropdown list, select the elliptic curve that will be used to create the public and private key pairs.
    *: Mandatory fields
  6. In the Attachments section, upload any additional documents that are relevant to the enrollment of the certificate (for example, approval emails).
    Table 47. Field descriptions for the Attachments section
    Field Description
    Name Enter the alternate name for the document to be uploaded.
    Comments Enter the comments in this field.
    Note: Character limit: 2000 characters
    Upload File Click the Upload button to select the file.
  7. Other than the CSR fields, you can add organization-specific values along with CSR. These values will not be part of the certificate but will be available in the AppViewX inventory. For example, cost center. Inventory can be filtered based on these attributes as well. In the Certificate Attributes can be added under Administration > certificate attributes, it will be reflected on the enrollment page:
  8. Enter the relevant details in the Generic Fields. These are default fields for maintaining the IP address and device information, if required.
    Table 48. Field descriptions for the Generic Fields
    Field Description
    Device Name Enter the name of the device.
    Application IP Address Enter the IP address of the application.
    Tracking ID A free-form business alpha-numerical identifier, included in the audit logs, that may be used to correlate audit logentries (typically enrollment and revocation events)
    Certificate holder Email
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    An email address that may be used to send notifications to certificate holder depending on the notification policies configured for the requested workflow
    First name
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    First name (as a metadata) associated with the certificate to be enrolled
    Last name
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Last name (as a metadata) associated with the certificate to be enrolled
    Organization
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Organization name (as a metadata) associated with the certificate to be enrolled
    Comment
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Additional information (as a metadata) associated with the certificate to be enrolled
    UUID
    Note: For the IDnomic CA, this field is displayed only when the selected CA account has been configured using a Registration Authority (RA).
    Universal Unique Identifier, or UUID, (as a metadata) associated with the certificate to be enrolled
  9. In the Vendor-Specific Details section, enter the CA-specific details. Some of the CAs will expect additional details other than CSR parameters as meta data for their operational purposes. Details common to all CAs will be taken from the AppViewX user information of the logged in user.
    Table 49. Field descriptions for the common vendor specific details
    Field Description
    Certificate ID The Certificate ID is auto-populated based on the value entered in the Common Name field (in the CSR Parameters section).
    • The Certificate ID can be modified by the user.
    • If the user edits the Certificate ID, any change to the Common Name will not reflect in the Certificate ID.
    • If the user deletes the Certificate ID, the value of the Certificate ID field is set to the Common Name suffixed with the timestamp.
    Table 50. Field descriptions for the DigiCert CA vendor specific details
    Field Description
    *Server Type From the dropdown list, select the server on which the application that requires the requested certificate is hosted.
    *Payment Method From the dropdown list, select one from the following payment methods:
    • Bill To Account Balance: This option allows you to pay for the DigiCert certificate using the available balance in your DigiCert account.
      Note: Ensure that the option to bill to account balance is enabled for the account and the account has sufficient balance.
    • Bill To Default Credit Card: This option will charge the cost of the DigiCert certificate to the credit card set as the default payment method in your DigiCert account.
      Note: Ensure that a credit card is configured as the default payment method for your account.
    Additional Email Enter email addresses that will receive notifications for renewals, reissues, and duplicates for the specified order.
    Renewal Message Enter a custom message that will be sent with the renewal notifications.
    Notes Enter a custom note that will be sent with the order.
    *: Mandatory fields
    Table 51. Field descriptions for the Hydrant ID CA vendor specific details
    Field Description
    Expiry Emails Enter a comma-separated list of email addresses that will receive the certificate expiry notification from HydrantID.
    Note: HydrantID CA does not accept updates to these email addresses during the renewal process.
    Table 52. Field descriptions for the Nexus CA vendor specific details
    Field Description
    Procedures The Procedures dropdown list will display only the procedures mapped to the server and the default procedure. From the dropdown list, select the required procedure.
  10. Click Add.
    Once the details are added, you will be redirected to a page where the CSR and CA details are added as a connector. This page is called the holistic view and from here, any action on the certificate can be performed including provisioning the certificate to a server.
  11. On the holistic view, click the Submit button to trigger the request.
    The submit action is triggered and the Submit dialog box is displayed.
  12. Enter your comments in the text field and click Yes.
    If the approval required option is enabled in the CA policy, the request is moved to the Approve and Implementation stages.
  13. Click Approve to proceed.
    The Approve dialog box is displayed.
  14. Enter your comments in the text field.
    Note: If the workflow request has to be approved automatically in the future, click the Schedule later button .
  15. Click Yes.
    Once the approval process is completed, the Implement option is displayed in the holistic view.
  16. Click Implement.
    The Implement dialog box is displayed.
  17. Enter your comments in the text field.
    If the workflow request has to be implemented automatically in the future, click Schedule later .
  18. Click Yes.
    CSR Submission to CA is in progress.Once the CSR submission is successful, the request state will be changed to Submit certificate - retrieval in progress state.

    If the enrollment request is compliant with conditions defined and auto-approval enabled in the targeted CA, the certificate will be fetched in a few seconds.

    If auto-approval disabled in the targeted CA, you will have to be logged into the CA and approve the request.

    Once the certificate is issued successfully, the certificate will be retrieved into AppViewX. You can now push the enrolled certificate(s) to the required endpoint.

Pushing Certificates to AWS Resources with CloudFront Integration

Important: Refer to the pre- and post-push script usage instructions here.

Adding an Application Connector for AWS Resources with CloudFront Integration

  1. On the certificate holistic view, click Add Connector.
  2. Enter/Select the General Information for the connector.
    Table 53. Field descriptions for the connector General Information
    Field Description
    *Category From the dropdown list, select Cloud.
    *Vendor From the dropdown list, select AWS.
    Service Types From the dropdown list, CloudFront.
    *Connector Name
    Enter a name for this connector, to be able to identify it later.
    Tip: AppViewX recommends naming connectors according to use cases so they are easily distinguishable.
    Description Enter any additional details you want to record for this connector.
    Based on the information entered here, the SSL templates section is populated with the list of available AWS cloud devices already onboarded in AppViewX.
  3. To select the device(s) to which the certificate will be pushed, under SSL templates, from the list of Available Devices, for the required device(s), click .
    The Selected devices list is updated automatically.
  4. Enter/Select the Certificate Details.
    Table 54. Field descriptions for the Certificate Details
    Field Description
    *Certificate Type From the dropdown list, select the file type of the certificate to be pushed.
    *Certificate Location Certificates can be stored in either AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM).

    From the options given, select the required certificate location.
    Certificate ARN
    Note: This field is displayed when Certificate Location = ACM.
    The ARN (Amazon Resource Name) is a unique identifier assigned to each certificate that is managed by ACM. It is used to reference the certificate in API calls, policies, and so on.

    In this field, enter the ARN of the certificate to be pushed.
    *Certificate File Name
    Note: This field is displayed when Certificate Location = IAM.
    In this field, enter the file name of the certificate to be pushed. The file extension is auto-populated based on the Certificate Type selected.
    Push Root and Intermediate Certificates To push the root and intermediate certificates, along with the end certificate, select this checkbox.

    For AWS, this field is enabled by default and is non-editable.
  5. Enter the Certificate Tags.
    A certificate tag is a label that you can assign to a certificate. To capture any details relevant to a certificate, you can associate certificate tags with a certificate. Certificate tags are key-value pair attributes that you can pass when you assume an IAM role or federate a user in AWS STS. These tags will be pushed along with the certificate to the endpoints. On certificate discovery, the tags associated with the certificate will be populated in the certificate inventory.

    To enter the certificate tags:

    1. Enter Key and Enter Value, in the respective fields, for the tag.
    2. Click Add.
      The tag, as a key-value pair, is listed in the table shown below the fields.
  6. Enter/Select the Push Details.
    Table 55. Field descriptions for the Push Details
    Field Description
    *Script Location Script files are commonly used to perform certain tasks required to be completed before and/or after a certificate is pushed to the target system.

    The script to be run before the certificate is pushed is called a pre-push script and the script to be run after the push is called a post-push script.

    From the following options, select the location of the script file(s):

    • In AppViewX
    • In Device
    Pre - Push Script File Name Enter the file name of the pre-push script.
    Post - Push Script File Name

    Enter the file name of the post push script.
    Push Automatically To automatically push the certificate after it is renewed/reissued to the target system, enable this checkbox.
    Note: The auto push feature for a certificate works only if enabled for the certificate application connector as well the associated certificate group. To enable this feature at the certificate group level, refer the instructions here.
  7. Click Save.
    The connector is displayed on the certificate holistic view.

Pushing a Server Certificate

  1. Go to (Menu) > CERT+ > CERTIFICATE ACTION > Push to Device > Server.
    The Server Certificate page is displayed.
  2. To push a certificate, under Common Name, click the required certificate.
    The certificate topology view is displayed.
  3. Click Push to Device. The Push to Device option will be shown if the app connector is already added to the certificate otherwise add the app connector and then proceed.
    Note:
    • Only server certificates that include their private keys will be eligible for push operations to cloud connectors.

      After push, during subsequent discovery, when the CC machine is healthy and discovery returns the pushed certificate, the pushed AppConnector should be in Sync status, else the associated AppConnector must be transitioned to an Out of Sync status.

      If a new certificate is pushed to the gateway while the old certificate for the AppConnector still exists in the inventory, then after the next discovery, the AppConnector must move to Out of Sync status for the old certificate.

    • Endpoint CSR generation is not supported for cloud connectors.
    • The Push to Device option is displayed only after an app connector is added to certificate.
    The Confirmation dialog box is displayed.
  4. Enter your comments, if required, in the text field.
  5. Click OK.
    • The approval process is triggered. The current flow is based on the default policy of two-level approvals.
    • A request ID and work order ID are generated automatically and the work order status is displayed alongside the connector in the certificate topology view.
  6. To approve the push request, from the certificate topology view, click Approve.
  7. In the Confirmation dialog box:
    1. In the Manual Implementation field, to choose the mode of implementation, use the On/Off toggle.
    2. If you select Off, set the date and time to schedule the certificate push.
    3. Enter your comments in the text field and click Yes.
    The work order status displayed beside the connector updates to Push-Review In Progress.
  8. To implement the push request, from the certificate topology view, click Implement.
  9. In the Confirmation dialog box:
    1. In the Manual Implementation field, to choose the mode of implementation, use the On/Off toggle.
    2. If you select Off, set the date and time to schedule the certificate push.
    3. Enter your comments in the text field and click Yes.
    The push action is triggered. After the push action is completed, the status updates to Completed.
    To refresh the certificate topology view, from the top-right corner of the screen, click Refresh.
    An automatic HTTPS-based verification job is run at regular intervals to validate that certificates are correctly installed after the push operations triggered between the intervals; the system compares served certificates with the expected ones across all associated IP:ports. The data gathered by this job is used to create the Push Validation Report that highlights the proportion of successful versus failed push operations, providing a quick view of overall push reliability.

Pushing a Client Certificate

  1. Go to (Menu) > CERT+ > CERTIFICATE ACTION > Push to Device > Client.
    The Client Certificate page is displayed.
  2. To push a certificate, under Common Name, double click the required certificate.
    The certificate topology view is displayed.
  3. Click Push to Device. The Push to Device option will be shown if the app connector is already added to the certificate otherwise add the app connector and then proceed.
    Note: The Push to Device option is displayed only after an app connector is added to certificate.
    The Confirmation dialog box is displayed.
  4. Enter your comments, if required, in the text field.
  5. Click OK.
    • The approval process is triggered. The current flow is based on the default policy of two-level approvals.
    • A request ID and work order ID are generated automatically and the work order status is displayed alongside the connector in the certificate topology view.
  6. To approve the push request, from the certificate topology view, click Approve.
  7. In the Confirmation dialog box:
    1. In the Manual Implementation field, to choose the mode of implementation, use the On/Off toggle.
    2. If you select Off, set the date and time to schedule the certificate push.
    3. Enter your comments in the text field and click Yes.
    The work order status displayed beside the connector updates to Push-Review In Progress.
  8. To implement the push request, from the certificate topology view, click Implement.
  9. In the Confirmation dialog box:
    1. In the Manual Implementation field, to choose the mode of implementation, use the On/Off toggle.
    2. If you select Off, set the date and time to schedule the certificate push.
    3. Enter your comments in the text field and click Yes.
    The push action is triggered. After the push action is completed, the status updates to Completed.

    An automatic HTTPS-based verification job is run at regular intervals to validate that certificates are correctly installed after the push operations triggered between the intervals; the system compares served certificates with the expected ones across all associated IP:ports. The data gathered by this cron job is used to update the Push Validation Report that highlights the proportion of successful versus failed push operations, providing a quick view of overall push reliability.

Enabling Auto Regeneration of Certificates

Enabling Auto Regeneration for a Certificate Group

You can enable and configure the auto regeneration feature at the certificate group level, which will apply to all certificates assigned to that group.

For details and instructions to enable auto regeneration at the certificate group level, click here.

Enabling Auto Regeneration at the Certificate Level

Enabling Auto Regenerate for Certificate Enrollment

While you can enable auto regenerate for all types of certificates, for clarity, in this section, we'll look at the instructions for enabling auto regenerate for a server certificate.

For details and instructions to enable auto regeneration at the time of server certificate enrollment, click here.

Enabling Auto Regenerate for Discovered Certificates

While you can enable auto regenerate for all types of certificates, for clarity, in this section, we'll look at the instructions for enabling auto regenerate for a server certificate.
  1. Go to Menu > CERT+ > Certificate Inventory > Server.
    The Server Certificate inventory is displayed.
  2. From the inventory, for the certificate you want to enable auto push for, click the common name.
    The holistic view of the selected certificate is displayed.
  3. For an existing CA connector for the certificate, hover over .
  4. From the menu displayed, click Edit.
    The certificate details are displayed.
  5. Under CA Details, turn on the Regenerate Automatically toggle.
  6. In the Start Regenerating field, enter the number of days before expiration when the certificate should be regenerated.
  7. Click Update.
    The holistic view of the selected certificate is displayed.
    Note: For the auto regenerate process to take effect, set the auto push in the application connector. Refer to the Enabling Auto Push section.

Enabling Auto Push of Certificates to Endpoints

After setting the auto renew/regenerate in the CA connector, you must now enable the auto push in the application connector to ensure the renewed/regenerated certificates are pushed to the end device.

To enable auto push of certificates, you need to enable the corresponding option for the group to which the certificate in question belongs, as well as the connector created for that certificate.

  1. To enable auto push for the certificate group:
    1. Go to Menu > CERT+ > Groups & Policies > Groups.
      The Group page is displayed.
    2. From the Name field, select the required certificate group.
      The Group : Modify : <group name> page is displayed.
    3. From the Other Details section of this certificate group, turn on the Push Certificate Automatically toggle button.
    4. Click Update.
  2. To enable auto push for the certificate connector:
    1. From the holistic view, for an existing application connector for the certificate, hover over (More) icon.
      To add an application connector, follow the instructions given here.
    2. From the menu displayed, click Edit.
      The Edit Application Connector pop-up is displayed.
    3. Select the Push automatically checkbox.
      Important: The auto-push feature works only when it is enabled at the connector level and disabled at the group level. If enabled at the group level but disabled at the connector level, the feature will not function.
    4. Click Save.
      The holistic view of the selected certificate is displayed.
      Note: An Auto Renew Certificates job is scheduled to run every 6 hours. It auto renews the configured certificates based on the number of days before expiry. AppViewX will disable the push automatically option in the Parent certificate application connector and enable it in the renewed certificate application connector.
      Note: An Auto Regenerate Certificates job is scheduled every day. It auto regenerates the configured certificates based on the number of days before expiry.

Troubleshooting AWS CloudFront

Overview

This section helps you troubleshoot the common problems that you might encounter when using AWS cloud functionalities for CloudFront service. This guide will give more troubleshooting processes on certificate discovery & certificate push.

Supported Web Browsers

Browser Version Notes
Firefox Till latest (Version 84.0.4147.135) NA
Chrome Till latest (Version 80.0) NA
IE Limited support in 9, Full support from 10+ No support for IE9 post AppViewX Version 11.0
Safari

Till latest (Windows - Version 5.1.7,

macOS - Version 13.1.2)

 From AppViewX Version 11.1
Opera Till latest (Version 70) From AppViewX Version 11.1

Issues in Discovery in CloudFront

Issues in Push-Bind and Rollback

Table 56. Error messages and resolutions
Error Message Possible Cause Possible Solution
Unable to initiate request.
  1. Pushing to device when certificate is unavailable, i.e, in a new state.
  2. Previous work order is in progress and not completed.
  3. AppConnector might not be in sync.
  1. Push to device after certificate has been retrieved from CA.
  2. Initiate push after previous work order is finished.
  3. Synchronize the AppConnector and retry.
Unable to initiate request, template is in disabled state Given workflow is not in enabled state Enable the push/rollback workflow from the Workflow section.
User is not authorized User does not have required permissions to push to the device. Retry after getting the access for required action.
Private Key is required to push certificate to ACM inventory Private key content is not available for the certificate. Private key is mandatory for the certificate to be pushed.
Application connector(s) not found Application connector info was not found. Provide the correct connectorId if not pushing using AppViewX UI.
Request associated with the application connector is in progress Previous work order is in progress and not completed. Initiate this request after the previous work order is finished.
Push not triggered or succeeded or No existing data available for backup process. Rollback couldn’t proceed because push was not successful. Only successfully pushed certificates can be rolled back.
Certificate not found. Pushing to device when certificate is unavailable, i.e, in a new state. Push to device after certificate has been retrieved from CA.
Provided certificate is not a valid self signed. Please provide either a valid self-signed certificate or certificate chain Provided certificate is not a valid certificate. Push a valid certificate.
Push failed as there exists another certificate with commonName Certificate with the same common name is present in certificate manager Check whether it is a duplicate certificate and remove the invalid one.
Cert Association failed with profile Modify access may not be available on the selected resource Provide “Modify” access for the resource and retry.
Association failed with profile-<PROFILE_NAME>as no such profile available Profile may not be available on the cloud account Perform config fetch on the device from ADC module and retry association of cert.
Certificate cannot be pushed as selected Amazon CA certificate is in <SOURCE_REGION> region and region you tried is <DESTINATION_REGION> Selected certificate is in ACM in a different region than the region to be pushed Use certificates available in the <DESTINATION_REGION> (or) Push a new certificate to the <DESTINATION_REGION>