Automating CLM for Microsoft SQL

Prerequisites

Access Requirements:
To perform certificate management operations, the user managed in AppViewX must have the following permissions:
- Read and write access to the trust store (to discover and push certificates).
- Read and write access to the Windows registry (to update certificate thumbprints and enforce encryption settings).
Ensure that PowerShell and WinRM tools are installed and running on the Windows machine.
Verify that Microsoft SQL instance are available and running on the Windows machine.
(Optional) If the Gateway type is selected as WMI, ensure that WMI is properly configured.
If the SQL Server instance is running under a service account that is neither Local System nor a member of the Administrators group:
- For a Domain Service Account: Add the account to the Administrators group on the server.
- For a Built-in Account (for example, Network Service): If the service account cannot be added to the Administrators group, use the Default connector to push the certificate. For the post-script execution, refer to Certificate Post script execution approach to Bind Certificates.
  - You can then leverage post-script execution to:
    - Grant read access to the certificate’s private key.
    - Perform the bind operation.

Prerequisites for Managing Windows Servers Using PowerShell Mode

To successfully manage Windows servers in PowerShell mode, ensure the following prerequisites are met.

Local Administrator Account on Target Machines.
1. The account used for onboarding the device must be a member of the Local Administrators Group on the target machine.
2. This account is required for device onboarding and enabling remote PowerShell sessions, as administrative privileges are essential for remote management.
  Note: If the onboarding account is not a Local Administrator on the Windows agent machine, it must be granted Allow Logon rights in the machine's policies.
Logon Service Account on the Windows Agent Machine: The Windows agent machine must have a logon service account with local administrator privileges to run the required services.
Network Ports.
To enable seamless communication between the target machines, the Windows agent machine, and the Cloud Connector (CC), ensure the following ports are open:
- Port 5985 (WSMAN) – Required on both the target machines and the Windows agent machine for remote PowerShell functionality.
- Port 445 (SMB) – Needed for certificate transfer to the target machines using the SMB protocol.
- Port 8999 – Must be open on the Windows agent machine to facilitate communication with the Cloud Connector (CC) or AppViewX (AVX).
Check Connectivity from CC to Gateway.
1. Login to AppViewX pods CLI to check communication.
  1. On Prem : Login in AppViewX CLI, go to vendor pods.
  2. Saas : Login to CC, platform pod.
2. After logging in run the below commands in terminal.
```
 nc -zv <Ip or hostname> <8999 or configured port>
```
  Note:
  - The <IP or hostname> refers to the hostname or IP address of the Windows agent machine.
  - Port 8999 is the default port for the Windows Agent. (If a custom port is configured, use the specified port instead.)
  - Expected Output:
```
Connection to 192.xxx.142.xx 8999 port [tcp/*] succeeded!
```
Check Connectivity from Windows Gateway Machine to Target Machine: Run the following command in Windows PowerShell, replacing <port> and <hostname> with the actual values of the Windows agent and target machine:
```
Test-NetConnection -ComputerName <hostname> -Port <port>
```
- Output Example:
```
ComputerName : computername
RemoteAddress : 93.184.xxx.xx
RemotePort : 80
InterfaceAlias : Ethernet
SourceAddress : 192.168.x.xx
PingSucceeded : True
TcpTestSucceeded : True
```
Check Remote Powershell Session from Windows Gateway Machine to Target Machine: Open an administrator powershell and run the following command from the Windows Gateway Machine to the target machine.
```
Enter-PSSession -computerName <hostname> -credential <username>
```
Note:
- <hostname>: Add the hostname of the remote machine.
- <username> : Username of the service account.
- For troubleshooting WinRM related errors, refer to PowerShell to a Remote Server via WinRM.
Ensure that Remote powershell is enabled in the target machines.Test using winrm quickconfig .

Kerberos Authentication.

Ensure all accounts are within the same domain to enable Kerberos authentication for remote PowerShell connections.
Validate the Kerberos setup between the target machines and the Windows agent machine to ensure proper authentication and communication.

Table 1. Prerequisites for Windows Gateway and Target Server Configuration
Requirement	AppViewX Windows Gateway	Target Server
User account type	Service account with local admin	Service account with local admin
Services	RPC Service WinRM Service WinRM Configuration Powershell remoting certutil.exe command availability	RPC Service WinRM Service WinRM Configuration Powershell remoting certutil.exe command availability
Ports	8999(Customisable) 5985 - WSMAN 445 - SMB: Required only for certificate push functionality.	5985 - WSMAN: Enables remote PowerShell functionality. 445 - SMB: Required only for certificate push functionality.

Onboarding Microsoft SQL Server

Go to (Menu) > CERT+ > ADMINISTRATION > Device Management.
By default, the ADC tab opens.
Click the Server tab.
Click the (Add) icon.
The Device details page is displayed.
Select Microsoft SQL from the Vendors list.

In the Server details section, select/enter the details as follows.

Table 2. Server Details - Field Description Table
Fields	Description
*Server name	Enter the name of the designated Microsoft SQL server.
Communication mode	Select the Gateway or SSM protocol to be used for communication between the AppViewX node and the Microsoft SQL Server.
*Hostname	Enter the hostname of the Microsoft SQL server.
Data center	Choose the desired datacenter. The communication to the device will be routed to through this datacenter from AppViewX and the communication will be routed to this datacenter alone when strict routing is enabled.
Cert Sync	Choose from the 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

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 Microsoft SQL device.

If Communication mode = Gateway 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 - AppViewX Note: The dropdown displays the credential types configured in the Device Credential section. Additionally, AppViewX supports the following external credential types: HashiCorp CyberArk BeyondTrust Thycotic.
*Username	Enter the designated username for authentication. Note: This field is displayed only if the credential type is selected as Manual Entry.
*Password	Enter the secure password. Note: This field is displayed only if the credential type is selected as Manual Entry.
*: Mandatory fields

If Communication mode = SSM the fields are as follows:

Table 4. 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

Enter/Select the Windows gateway details.

Note: This section is displayed only when Communication mode = Gateway.

Table 5. Windows Gateway Details - Field Description Table
Fields	Description
*Windows Gateway Mode	Note: Applicable only for SAAS. 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: This is only a tech preview, which means the feature is under development. The tech preview has been released for testing and evaluation by the general audience. Necessary improvements will be made before the official release. Currently, this feature is not recommended for production. Note: The integrated gateway functionality is not compatible with the following features: Server addition using the import feature Endpoint CSR generation
*Gateway type	Note: Applicable only for SAAS. 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

Enter/Select the Vendor Specific Details.

Note: This section is displayed only when Communication mode = SSM.

Table 6. Vendor Specific Details - Field Description Table
Fields	Description
*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 Note: Click the (Settings) icon next to the field to configure the ARN Advanced Settings.
*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 Note: Click the (Settings) icon next to the field to configure the S3 Advanced Settings.
Proxy Required	Select the checkbox to enable the secure proxy service.
*: Mandatory fields

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:

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

Discovering Certificates for Microsoft SQL

Go to (Menu) > CERT+ > CERTIFICATE DISCOVERY > Discovery > Managed Devices Scan.
The Discovery : Managed Devices Scan : Add Discovery page is displayed.

To initiate a managed devices scan, enter the Discover Details.

To specify the frequency at which the certificate discovery scan will be triggered, select the Discovery Run Type.

Table 7. Discovery run type options
Field	Description
On-demand	The certificate discovery scan will be triggered manually by the user as and when required.
Scheduled	The certificate discovery scan will be triggered automatically at the specified time and date.

Enter the details for initiating an on-demand managed devices certificate discovery scan.

Table 8. Field descriptions for **on-demand** discovery
Field	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

Enter the details for initiating a scheduled managed devices certificate discovery scan.

Table 9. Field descriptions for **scheduled** discovery
Field	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	Select your time zone.
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

In the Discover By section, enter the discovery details.

Table 10. Instruction for discovering certificates
Field	Description
*Discovery From	From the dropdown list, select Managed Servers.
Devices window	A list of all the managed server devices is displayed in the devices window. To select devices for certificate discovery, select the checkbox(es) for the required devices. The devices window has the following option: Search: Enter keywords to filter and select the desired vendor or device name from thematching results. Add as Favorites: You can mark your frequently used devices as favorites. All: Select this to see the complete list of devices (unfiltered). Selected: Select this to list only the selected devices. Unselected: Select this to list only the unselected devices. Delete: Delete the required devices from the favorites list.
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.
*Discovery Type	From the following options, select one: All Certificates: Select this to discover all certificates. Certificates in Use: Select this to discover only those certificates that are associated with a service.
*: Mandatory fields

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.

In the After Discover section, enter the following details:

Table 11. 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

Click Discover/Schedule to trigger the on-demand/scheduled discovery, respectively.
The discovered certificates are displayed in the certificate inventory.
AppViewX follows these steps to retrieve the appropriate server certificate.
1. Identify the certificate thumbprint currently bound in the Windows registry.
2. Retrieve all certificates from the local trust store.
3. Match the retrieved certificates against the stored thumbprint to determine the active server certificate.
  
  AppViewX automatically detects all SQL instances running on the target Microsoft SQL Server machine and creates individual profile connectors for each instance. These connectors enable certificate push and binding operations specific to each SQL instance.
Each profile connector is named using the following convention:
1. <hostName>:<instance>
  
  Note: This format ensures the unique identification of each SQL Server instance.
2. In addition, AppViewX automatically creates a default connector, which supports only the certificate push operation.

Enrolling a Server Certificate

Server certificate enrollment refers to the process of creating 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:

Go to (Menu) > CERT+ > CERTIFICATE ACTION > Enroll Certificate > Server
The Enroll Server Certificate page is displayed.
In the General Information section, from the dropdown list, select the required Assign Group.

Enter the CA Details.

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:

If the Override feature is enabled for the certificate group selected from the Assign Group dropdown list, auto renew settings done in the enrollment page will be overwritten by the group level settings.
If Regenerate Automatically has been enabled for the selected certificate group, the Renew Automatically field is not displayed here.

To automatically renew this certificate:

Turn on the Renew Automatically toggle.
The *Start Renewing field is displayed.
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:

Turn on the Regenerate Automatically toggle.
The *Start Regenerating field is displayed.
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.

*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 CA+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.

From the dropdown list, select the issuer name for issuing the certificate.

*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.

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:

Under CSR Generation, select HSM.

Fields for gathering your HSM-related inputs are displayed.

Table 13. To generate the private key and the CSR, enter/select the following details:
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 ADC Devices
*Vendors	Note: This field is applicable only when Device Type = ADC Devices.
*Devices	From the dropdown list, select the required HSM/ADC device. Note: This field is populated based on the Device Type and Vendors selected.
*Key Handler Name	Note: This field is applicable only when Device Type = HSM Devices. Enter the key handler name.
*Key Reference Name	Note: This field is applicable only when Device Type = ADC Devices. Enter the key reference name.

End Point:

Note: This option is disabled when Certificate Authority = Google and CSC Global.

Table 14. To generate the private key and the CSR in the selected end point device, enter the following inputs:
Field	Description
Category	From the following options, select the Server device category from the dropdown list.
Vendor	From the dropdown list, select the MS SQL vendor for the end point device from the dropdown list. 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.
*CSR File Location	Enter the valid CSR file location. For example, C:\filepath\filename. Note: This field is applicable only when Category = Server.
*Key File Location	Enter the valid key file location. For example, C:\filepath\filename. Note: This field is applicable only when Category = Server.

*: Mandatory fields

For the EJBCA certificate authority, enter/select the vendor details.

Table 15. 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

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 16. Field descriptions for the CSR Parameters
Field	Description
*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 (-).
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.
*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). Note: For renewal of the certificate being enrolled, country name is required.
Email Address	Enter a valid email address of the person responsible for maintaining the certificate.
*Validity	To specify the validity of the certificate being enrolled: From the first dropdown list, select the number of days/months/years. 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: From the first dropdown list, select 2. From the second dropdown list, select Months.
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.
*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

In the Attachments section, upload any additional documents that are relevant to the enrollment of the certificate (for example, approval emails).

Table 17. 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: Click Upload. Navigate to the location of the document to be uploaded. 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've uploaded multiple attachments, use the Search field to find the required one.
*: Mandatory fields

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.

Enter the relevant details in the Generic Fields. These are default fields for maintaining the IP address and device information, if required.

Table 18. 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: This field is displayed only when a CA setting with a registration authority is selected for certificate enrollment. 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: This field is displayed only when a CA setting with a registration authority is selected for certificate enrollment. First name (as a metadata) associated with the certificate to be enrolled
Last name	Note: This field is displayed only when a CA setting with a registration authority is selected for certificate enrollment. Last name (as a metadata) associated with the certificate to be enrolled
Organization	Note: This field is displayed only when a CA setting with a registration authority is selected for certificate enrollment. Organization name (as a metadata) associated with the certificate to be enrolled
Comment	Note: This field is displayed only when a CA setting with a registration authority is selected for certificate enrollment. Additional information (as a metadata) associated with the certificate to be enrolled
UUID	Note: This field is displayed only when a CA setting with a registration authority is selected for certificate enrollment. Universal Unique Identifier, or UUID, (as a metadata) associated with the certificate to be enrolled

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 19. 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 20. 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 21. 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 22. 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 23. 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 24. 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 25. 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 26. 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 27. 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 the Integration topic in the Automation Guide.
*: Mandatory fields

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.
On the holistic view, click the Submit button to trigger the request.
The submit action is triggered and the Submit dialog box is displayed.
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.
Click Approve to proceed.
The Approve dialog box is displayed.
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 .
Click Yes.
Once the approval process is complete, the Implement option is displayed in the holistic view.
Click Implement.
The Implement dialog box is displayed.
Enter your comments in the text field.
If the workflow request has to be implemented automatically in the future, click Schedule later .
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.

Adding and Pushing Certificates to Microsoft SQL Device

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

Adding an Application Connector for Microsoft SQL

MS SQL

On the certificate holistic view, click Add Connector.

Enter the General Information for the connector.

Table 28. Field descriptions for the connector General Information
Field	Description
*Category	From the dropdown list, select Server. If the certificate being pushed was enrolled with CSR generation at endpoint, this field is auto populated with the category selected at the time of certificate enrollment.
*Vendor	From the dropdown list, select MSSQL. If the certificate being pushed was enrolled with CSR generation at endpoint, this field is auto populated with the vendor selected at the time of certificate enrollment.
*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 MS SQL devices already onboarded in AppViewX.

To select the device(s) to which the certificate will be pushed, under SSL templates, from the list of Available Devices, click .
The Selected devices list is updated automatically.

Enter the Certificate Details.

Table 29. Field descriptions for the Certificate Details
Field	Description
Certificate Type	From the dropdown list, select the file type of the certificate to be pushed. AppViewX supports only PEM (*.crt) type as the certificate is imported to certificate store irrespective of the certificate type.
Push Root and Intermediate Certificates	To push the root and intermediate certificates, along with the end certificates, select this checkbox.
Private Key in Device	If the private key associated with the certificate being pushed has been stored on the MS SQL machine, select this checkbox.
*Key Location	This field is displayed when the Private Key in Device option is selected. Enter the file path to the private key location on the MS SQL machine.
Service Restart	Enabling this option will restart the SQL Server service to apply the configuration changes. Note: By default, this setting is enabled based on the global device configuration. To modify, go to: CERT+ > Device Management > Server > Device Settings > Vendors > Microsoft SQL. This feature requires Windows Gateway version v2024.1.0.0 or later. In earlier versions, the service restarts automatically by default.
Force Encryption	Enabling this option enforces encryption for all SQL server connections. Note: By default, this setting is enabled based on the global device configuration. To modify, go to: CERT+ > Device Management > Server > Device Settings > Vendors > Microsoft SQL. This feature requires Windows Gateway version v2024.1.0.0 or later. In earlier versions, the service restarts automatically by default.
Note: Bind Operation in AppViewX for MS SQL: During the bind operation, AppViewX updates the registry with the following keys: Certificate Thumbprint Key: Stores the thumbprint of the pushed certificate. ForceEncryption Key: Set to 1 to enable encryption for the SQL instance. After updating these keys, the SQL service is restarted to apply the changes.

Note:

When pushing certificates , the system now automatically selects the appropriate PKCS12 encryption algorithm based on the target Windows Server version:

Windows Server 2016 and earlier: Uses TripleDES encryption for compatibility
Windows Server 2019 and later: Uses the encryption algorithm from General Settings

Enter the Push Details.

Table 30. 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. Important: Read the pre and push script usage instructions here.
Pre - Push Script File Path	This field is displayed when Script Location = In Device. Enter the location on your local system where the pre-push script file is stored. Important: Read the pre and push script usage instructions here.
Post - Push Script File Name	Enter the file name of the post push script. Important: Read the pre and push script usage instructions here.
Post - Push Script File Path	This field is displayed when Script Location = In Device. Enter the location on your local system where the post-push script file is stored. Important: Read the pre and push script usage instructions here.
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.

Click Save.
The connector is displayed on the certificate holistic view.

What's Next

After adding the connector, you can proceed with pushing a server certificate to the device:

To push a server certificate to a device, see Pushing a Server Certificate to a Device.

Pushing a Server Certificate to a Device

Go to (Menu) > CERT+ > CERTIFICATE ACTION > Push to Device > Server.
The Server Certificate page is displayed.
To push a certificate, under Common Name, click the required certificate.
The certificate topology view is displayed.
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.
Enter your comments, if required, in the text field.
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.
To approve the push request, from the certificate topology view, click Approve.
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.
To implement the push request, from the certificate topology view, click Implement.
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.

Certificate Post script execution approach to Bind Certificates

Use the post-script execution method to bind certificates to SQL Server instances when using non-administrator or NT Service accounts for service logon.

If the SQL Server instance is running under a service account that is not 'Local System' or a member of the 'Administrators' group:

Post Push Script:

$InstanceName = "MSSQLSERVER"  # Replace with your SQL instance name
$ServiceAccountName = "Domain\Username"  # Replace with actual account
$ForceEncryption = $true  # Set to $false if encryption should not be forced
$ServiceRestart = $true   # Set to $false to skip service restart

Write-Host "Checkpoint 1: Starting script"

# Decode and parse JSON
$request = [Text.Encoding]::Utf8.GetString([Convert]::FromBase64String($args[0]))
Write-Host "Checkpoint 2: Base64 decoded"

$request = $request.Replace('dNSNames','dNSNamesIgnore').Replace('iPAddresses', 'iPAddressesIgnore')
$json_request = ConvertFrom-Json -InputObject $request
Write-Host "Checkpoint 3: JSON parsed"

# Extract thumbprint
if (-not $json_request.certificate.extension.thumbPrint) {
    throw "Thumbprint field not found in JSON input."
}
$vmThumbPrint = $json_request.certificate.extension.thumbPrint.Replace(":", "")
$certificateThumbprint = $vmThumbPrint.ToLower().Replace(" ", "")
Write-Host "Checkpoint 4: Extracted thumbprint $certificateThumbprint"

try {
    # Load certificate
    $store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My", "LocalMachine")
    $store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadOnly)
    $cert = $store.Certificates | Where-Object { $_.Thumbprint.ToLower() -eq $certificateThumbprint }

    if (-not $cert) {
        throw "Certificate with thumbprint $certificateThumbprint not found in LocalMachine\My store."
    }
    Write-Host "Checkpoint 5: Certificate loaded"

    # Verify private key
    if (-not $cert.HasPrivateKey) {
        throw "The certificate does not have an associated private key."
    }

    # Locate private key file
    $keyPath = $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
    $keyFullPath = "$env:ProgramData\Microsoft\Crypto\RSA\MachineKeys\$keyPath"

    if (-not (Test-Path $keyFullPath)) {
        throw "Private key file not found at $keyFullPath."
    }
    Write-Host "Checkpoint 6: Private key path resolved $keyFullPath"

    # Grant access to specified account
    Write-Host "Checkpoint 7: Using provided service account: $ServiceAccountName"
    $ntAccount = New-Object System.Security.Principal.NTAccount($ServiceAccountName)
    $sid = $ntAccount.Translate([System.Security.Principal.SecurityIdentifier])
    Write-Host "Checkpoint 8: SID resolved: $sid"

    $acl = Get-Acl $keyFullPath
    $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($sid, "Read", "Allow")
    $acl.AddAccessRule($accessRule)
    Set-Acl $keyFullPath $acl
    Write-Host "Checkpoint 9: Granted Read access on private key to $ServiceAccountName"

    # Set registry values
    $sqlRegKey = Get-Item -Path 'HKLM:\Software\Microsoft\Microsoft SQL Server\Instance Names\SQL'
    $sqlVersion = $sqlRegKey.GetValue($InstanceName)
    if (-not $sqlVersion) {
        throw "SQL Server version key not found for instance $InstanceName."
    }
    Write-Host "Checkpoint 10: SQL version key resolved as $sqlVersion"

    $sqlConfigPath = "HKLM:\Software\Microsoft\Microsoft SQL Server\$sqlVersion\MSSQLServer\SuperSocketNetLib"

    Set-ItemProperty -Path $sqlConfigPath -Name "Certificate" -Type String -Value $certificateThumbprint

    $forceVal = if ($ForceEncryption) { 1 } else { 0 }
    Set-ItemProperty -Path $sqlConfigPath -Name "ForceEncryption" -Type DWord -Value $forceVal
    Write-Host "Checkpoint 11: Registry updated - Certificate=$certificateThumbprint, ForceEncryption=$forceVal"

    # Optionally restart SQL service
    if ($ServiceRestart) {
        $sqlServiceName = if ($InstanceName -eq "MSSQLSERVER") { "MSSQLSERVER" } else { "MSSQL`$$InstanceName" }
        Restart-Service -Force $sqlServiceName
        Start-Sleep -Seconds 5

        $status = (Get-Service -Name $sqlServiceName).Status
        if ($status -eq "Running") {
            Write-Host "Checkpoint 12: Service $sqlServiceName restarted successfully."
            echo "AppResponseCode:0"
        } else {
            throw "Service $sqlServiceName failed to restart. Status: $status"
        }
    } else {
        Write-Host "Checkpoint 12: Service restart skipped as per input."
        echo "AppResponseCode:0"
    }
}
catch {
    Write-Error "An error occurred: $_"
    echo "AppResponseCode:1"
}

The post-push script performs the following actions:
- Grants read permission on the certificate’s private key to the specified SQL Server service account.
- Binds the certificate to the SQL Server instance using its certificate thumbprint.
- Optionally:
  - Enables or disables ForceEncryption on the SQL Server instance.
  - Restarts the SQL Server service, if configured.
To bind a certificate to a SQL Server instance using a post-script:
- Place the script on the SQL Server where the certificate will be installed.
- Update the following variables at the top of the script:
  - $InstanceName - Name of the SQL Server instance (for example, SQLEXPRESS or MSSQLSERVER).
  - $ServiceAccountName - The account under which the SQL Server service is running (for example, NT SERVICE\MSSQL$SQLEXPRESS or a domain account like domain\sqlsvc).
  - $ForceEncryption - Set to $true to enable SSL encryption, or $false to disable it.
  - $ServiceRestart - Set to $true to restart the SQL Server service after binding, or $false to skip the restart.
- In the AppViewX UI, while configuring the connector for MS SQL:
  - Select the Server Name (not the SQL instance name).
  - In the Push Details section:
    - Choose In Device.
    - Enter the full file path of the script placed on the server under Post-Push Script Filepath.

Note:

You must manually update the $InstanceName, $ServiceAccountName, $ForceEncryption, and $ServiceRestart variables at the top of the script before executing it.
The script is designed to be flexible and can be used with any SQL Server instance by modifying these variables as required.
Optionally, you can create multiple versions of the script, each preconfigured for a specific SQL instance and service account, to simplify reuse across environments.

Enabling Auto Renewal of Certificates

To enable auto renewal 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 pushing that certificate.

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

To enable auto renewal 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 Renew Automatically toggle button.
4. Click Update.
To enable auto renewal for the certificate connector:
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 renew 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 Renew Automatically toggle.
6. In the Start Renewing field, enter the number of days before expiration when the certificate should be renewed.
7. Click Update.
  The holistic view of the selected certificate is displayed.
  Note: For the auto renewal process to take effect, set the auto push in the application connector. For instructions, refer to the Enabling Auto Push section.

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.

Go to Menu > CERT+ > Certificate Inventory > Server.
The Server Certificate inventory is displayed.
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.
For an existing CA connector for the certificate, hover over .
From the menu displayed, click Edit.
The certificate details are displayed.
Under CA Details, turn on the Regenerate Automatically toggle.
In the Start Regenerating field, enter the number of days before expiration when the certificate should be regenerated.
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.

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.
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 MS SQL Windows

This section helps you troubleshoot the common problems that you might encounter when using certificate server functionalities. This guide will give more troubleshooting processes on server addition, deletion, import, export, push, bind, rollback and other actions associated with MS SQL Windows.

Issues in Communicating to MS SQL


Error Message	Possible Cause	Possible Solution
Communication to <hostname> has failed	Gateway agent not reachable. Device not reachable from the gateway agent	Ensure gateway is configured properly and the APIs are accessible from AppViewX. Ensure device and gateway agent are in the same domain and device is accessible from gateway agent.
Communication to <hostname> has failed	Hostname or Credentials configured is wrong	Ensure hostname and the device credentials configured while device addition is valid.
Device version fetch has failed.	MSSQLSERVER service instance is down	Restart the MSSQLSERVER instance
Device version fetch has failed.	Command not supported by MS SQL version	Execute the version command SQLCMD -Q 'SELECT @@VERSION;' -t 3 in the CLI of the device to check if it returns version response

Issues in Config Fetch


Error Message	Possible Cause	Possible Solution
Communication to <hostname> has failed	Gateway agent not reachable. Device not reachable from the gateway agent	Ensure gateway is configured properly and the APIs are accessible from AppViewX. Ensure device and gateway agent are in the same domain and device is accessible from gateway agent.
PTPLD178 has 0 instances.	No installed MS SQL instances. Installed instances are not up and running.	Execute (get-itemproperty 'HKLM:\\SOFTWARE\\Microsoft\\Microsoft SQL Server').InstalledInstances in the device as a powershell script and check if it returns the MS SQL instances

Issue in Discovery


Error Message	Possible Cause	Possible Solution
Received failed response from batch	No valid certificates in store that are binded to the MS SQL instances.	Ensure the certificates are binded to a MS SQL instance.

Issue in CSR generation


Error Message	Possible Cause	Possible Solution
CSR Submission Failed	User may have restricted access to the path configured for the “CSR FileName” and “Key File name”	Kindly ensure the user configured for device addition has read/write access to the path configured.

Issue in Push and Rollback


Error Message	Possible Cause	Possible Solution
Error while pushing certificate in Device : <device name>.PrivateKey not available.	Private key is not available to parse certs.	Kindly ensure to push certs with private key.If privatekey is available in device please select privateKeyInDevice option.
Error: “/LOCAL_MACHINE/CertificateAuthority” does not exist	CertificateAuthority Store is removed from the Store	Create a CertificateAuthority store.