Apache (Windows)

Prerequisites

  1. Verify that the target hostname is accessible from the Windows Gateway Agent.
  2. If using a Windows Gateway, ensure it is installed within the same domain or domain forest as the target server.
  3. Confirm that the Apache service on the Windows server is running.
  4. Apache can be installed and managed on any drive; however, the user account configured in AppViewX to manage Apache must be a local administrator and have access to both the installation directory and the server.
  5. If an external credential is used for the authentication, ensure the Hostname or IP address used for device communication for the user is configured in the respective external credential vault.
Recommended Best Practice:

If the same issuer certificate exists in multiple locations, the system will use the first instance it finds. Therefore, it is recommended to store all trusted certificates in a single, centralized location.

Onboarding Apache (Windows) Server

  1. Go to (Menu) > CERT+ > ADMINISTRATION > Device Management.
    By default, the ADC tab opens.
  2. Click the Server tab.
  3. Click the (Add) icon.
    The Device details page is displayed.
  4. Select Apache Microsoft from the Vendors list.
  5. In the Server details section, select/enter the details as follows.
    Table 1. Server Details - Field Description Table
    Fields Description
    *Server Type Select the Apache radio button.
    *Server name Enter the name of the designated Apache server.
    *Hostname Enter the hostname of the Apache Server that is to be onboarded.
    Data center Choose the desired data center.
    Onboarding Group Select the onboarding group to assign the device.
    Note: Devices without an assigned group are automatically mapped to the Default group during migration, onboarding, and when edited without existing group mappings.
    Communication mode Select the Gateway or SSM protocol to be used for communication between the AppViewX node and the Apache server.
    Cert Sync Choose from any of the following:
    • Managed - AppViewX performs the config fetch operations and the certificates are discovered and managed in the inventory. CLM actions (push & bind, rollback etc.) can be performed on them.
    • Monitored - AppViewX performs the config fetch operations and the certificates are downloaded in the inventory in the read-only state. CLM actions cannot be performed on them.
    • Ignored - AppViewX only performs the config fetch operations for the devices. There is no certificate discovery performed.
    *: Mandatory fields
  6. In the Credentials section, select/enter the details as indicated below. The credentials entered in this section are used to authenticate the session between the AppViewX node and the Apache server device.
    If Communication mode = Gateway the fields are as follows:
    Table 2. Credentials - Field Description Table
    Fields Description
    *Credential Type Select the credential type from the dropdown.
    • Manual entry (default)
    • Credential List - AppViewX
    • Credential List - Thycotic
    • Credential List - BeyondTrust
    Note: If Credential list - (AppViewX, Thycotic, BeyondTrust) is selected, the *Credentials list dropdown field is displayed.
    *Username Enter the designated username for authentication.. (field displayed for Credential Type = Manual entry and SSH)
    *Password Enter the secure password. (field displayed for Credential Type = Manual entry only)
    *Credentials list Choose the appropriate Credential list from the drop-down list. (field displayed for Credential Type = Credentials list.
    *: Mandatory fields
    If Communication mode = SSM the fields are as follows:
    Table 3. Credentials - Field Description Table
    Fields Description
    *Credential Type Select the credential type from the dropdown.
    • Manual entry (default)
    • Credential List - cloudAccount
    Note: If Credential list - cloudAccount is selected, the *Account name dropdown field is displayed. Select any of the preconfigured credential values.
    *Access key Enter the access key to login to the EC2 instance of the AWS cloud machine.
    *Secret key Enter the secret key to login to the EC2 instance of the AWS cloud machine.
    *: Mandatory fields
  7. In the Vendor Specific Details section, select/enter the details as indicated below.
    If Communication mode = Gateway the fields are as follows:
    Table 4. Vendor Specific Details - Field Description Table
    Fields Description
    *Installation directory path Enter the directory/path where the application is installed.

    Example: C:\Apache24

    *: Mandatory fields
    If Communication mode = SSM the fields are as follows:
    Table 5. Vendor Specific Details - Field Description Table
    Fields Description
    *Installation directory path Enter the directory/path where the application is installed.

    Example: C:\Apache24

    *Region Enter the geographic region of the AWS instance.

    Example: us-east-2

    *Instance id Enter the unique identifier for an EC2 instance in AWS.

    It is required to perform actions or execute commands on a specific EC2 instance

    Example: i-02573cafcftext

    *SSM document name Enter the name of the SSM document that contains the script or action to be executed on the EC2 instance.

    Example: AWS-RunShellScript is an SSM document that allows you to execute shell scripts on EC2 instances.

    *SSM document version Specify the version of the SSM document to be executed.

    Example: 1

    *S3 bucket name Enter the S3 bucket name used to store command output or logs executed in the EC2 instance.

    Example: avxdiscoverydocument-c2

    Proxy required Select the checkbox to enable the secure proxy service.
    *: Mandatory fields
  8. Enter the Windows gateway details.
    Note: This section is displayed only when Communication mode = Gateway.
    Table 6. Windows Gateway Details - Field Description Table
    Fields Description
    *Windows Gateway Mode For communicating with Windows-based devices, from the following options, select the gateway agent mode to be used:
    • External

      This mode will use the AppViewX Windows Gateway Agent that is set up on a Windows device.

    • Integrated

      This mode will use the prepackaged gateway that is integrated in the AppViewX Cloud Connector (enabled only in the SaaS and Managed Kubernetes installations).

      Prerequisites for using the Integrated Windows Gateway mode

      Note: The integrated gateway functionality is not compatible with the following feature:
      • Server addition using the import feature
    *Gateway type From the following options, select the required gateway type:
    • PowerShell
    • WMI
    Note: The integrated gateway uses only the PowerShell gateway command execution mode and therefore, this field is not displayed when Windows Gateway Mode = Integrated.
    *Gateway location From the following options, select the gateway location:
    • Remote
    Note: By default, the integrated gateway is remotely located. and therefore, this field is not displayed when Windows Gateway Mode = Integrated.
    *Select gateway
    Note: This field is displayed only when Windows Gateway Mode = External.
    From the following options, select the gateway:
    • New
    • Existing
    *Windows gateway
    Note: This field is displayed only when Select gateway = Existing.
    From the dropdown list, select an existing Windows gateway.
    *Windows gateway name For Windows Gateway Mode = External and Select gateway = New, enter a name for the Windows Gateway.

    For Windows Gateway Mode = Integrated, this field is auto-populated with the value integrated-gateway.

    *Windows gateway URL
    Note: This field is displayed only when Windows Gateway Mode = External and Select gateway = New.
    Enter the URL of the Windows Gateway endpoint.
    Client authentication certificate
    Note: This field is displayed only when Windows Gateway Mode = External and Select gateway = New.
    Upload the client certificate used while installing Windows Gateway. You can use the default client certificate (ClientCertificateGateway.pfx) or a custom certificate.
    *: Mandatory fields
  9. Click Save.
    The device is onboarded successfully.

Validating the Device

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

Limitations

  • Discovery and binding of certificate and key files in the HTTPS SSL configuration do not currently support relative paths. It is recommended to use the absolute paths instead.
  • Certificates cannot be pushed as a bundle to the SSLCertificateFile (i.e., a chain of certificates in a single file)

Supported Features

  • On-demand or scheduled certificate discovery.
    • Along with the Apache SSL certificates, the system can discover the other certificates present in the Apache SSL Certificate directory.
  • CSR generation on the end device.
  • Apache Service restart after successful bind.
  • Authentication support using manual entry, SSM, and external vaults.
  • Support for pushing various types of certificates to the Apache server, followed by service restart.
  • Option to use existing configurations (the certificate and key are pushed to the paths defined in the virtual host section of the config file, without modifying the configuration itself).
  • Post enrolling the private key on the endpoint, it remains encrypted until the certificate is pushed. Only the push operation can decrypt the key and bind the certificate to the corresponding profile.
  • Supports push of trusted certificates to the device.