Managing Certificate Authority Policy

Prerequisites

Ensure the following requirements are met before working with CA Policies:

Table 1. Prerequisites for CA Policies
Requirement	Details
Permission	You must have the Platform > Identity > Role > Authorized Functions Create/Modify RBAC permission to create or manage CA policies.
CPS document	For SaaS upload, the document must be a PDF, maximum 4 MB.

View the CA Policy Inventory

The CA Policy page provides a centralized view of all policies created for your instance.

Go to (Menu) > PKI.
In the PKI navigation pane, select CA Policy.

The CA Policy inventory page displays the following columns:

Table 2. CA Policy Inventory Columns
Column	Description
Policy Name	Unique name assigned to the policy.
Description	Brief description of the policy.
Type	Certificate Authority Type: Root CA or Subordinate CA.
Last Updated	Date and time the policy was last modified.

Filter and Sort Policies

Search: Enter a policy name in the search bar to filter results.
Type: Use the multi-select dropdown to filter by Root CA or Subordinate CA.
Sort: Select any column header (except Description) to sort ascending or descending.
Pagination: Navigate results using page controls. Choose 25, 50, or 100 records per page.

Note: If no policies exist, the page displays a Create CA Policy action. If no Native CA is initialized, the CA Policy menu displays an informational message indicating that Native CA configuration is required.

Create a CA Policy (On-Premise)

Manual entry allows you to define all policy parameters by selecting values from predefined options. This method is available on both On-Premise and SaaS deployments.

Navigate to PKI > CA Policy.
Click + Create in the command bar.

The Policy Creation form is displayed.

Policy Details

Table 3. Policy Details Fields
Field	Description
Policy Name *	Enter a unique name to identify the policy. Use letters, numbers, hyphens (-), and underscores (_). This name appears in the CA Policy list and during CA creation.
Description	Enter a brief description of the policy purpose or the standards it enforces.

CA Configuration

Configure the CA hierarchy, validity period, and cryptographic model that govern the CA created with this policy.

Table 4. CA Configuration Fields
Field	Description
Crypto Mode *	Select one crypto mode that defines the type of cryptographic mode available in this policy. Classical – Traditional cryptographic algorithms (RSA, EC, DSA) widely used in current PKI deployments. PQC (Post-Quantum Cryptography) – Quantum-resistant algorithms based on NIST post-quantum standards (FN-DSA, ML-DSA, SLH-DSA). Composite – A hybrid approach pairing one PQC and one classical algorithm for defense-in-depth (for example, ML-DSA + RSA). A policy supports one model only. Create separate policies to support multiple models.
Certificate Authority Type *	Select the CA type that the policy creates: root CA or subordinate CA Root CA – A self-signed CA at the top of the PKI hierarchy. Sub CA – A subordinate (intermediate) CA signed by an existing Root CA.
Validity Period *	Select one or more permitted validity periods for the CA certificate or enter custom value. Root CA: Select values in years from the predefined list, or type a custom value and press Enter. Subordinate CA: An additional months field is displayed. Select validity in years and/or months. During CA creation, users can only select values defined in this policy.

Path Length Constraint

Define the maximum number of subordinate CA certificate levels permitted below the CA created with this policy.

Select one or more predefined values from the list.
To add a custom integer value, type it in the input field and press Enter.

A value of 0 means no subordinate CAs can be created below this CA.
A value of 1 allows one level of subordinate CAs.

Cryptographic Settings

The fields in this section depend on the Crypto Mode selected in CA Configuration. Only the permitted algorithms, bit lengths, and key types defined here are available during CA creation.

Classical

Fields are displayed directly; select algorithm, then the related options appear.

Table 5. Classical Cryptographic Settings
Field	Description	Available Options
Cryptographic Algorithm	Select the classical cryptographic algorithm. Based on the selection, the related Bit Length and additional fields appear.	RSA, EC, DSA
Bit Length	Select the permitted key sizes for the chosen algorithm.	RSA: 2048, 3072, 4096 EC: 256, 384, 521 DSA: 1024, 2048.
Padding (RSA only)	Select the permitted RSA and EC padding schemes.	PKCS, PSS
Curve (EC only)	Select the elliptic curve type. Displayed only when an EC bit length is selected.	-
Hash Function	Select the permitted hashing algorithm. Displayed when RSA, DSA, or EC is selected.	-

PQC (Post-Quantum Cryptography)

Fields are displayed directly; select algorithm, then the related options appear based on the bit length and key types selected.

Table 6. PQC Cryptographic Settings
Field	Description
Cryptographic Algorithm	Select the post-quantum algorithm. Based on the selection, the related Bit Length & Key Type and additional fields appear. Available options: ML-DSA, FN-DSA, SLH-DSA
Bit Length & Key Type	Select the permitted parameter set (security level) for the chosen algorithm.
Key Version (SLH-DSA only)	Select the key version for the SLH-DSA parameter set. Displayed only when SLH-DSA is selected.
Hash Function	Select the permitted hashing algorithm.

Composite

Composite configuration follows a two-step flow. You must first select the Cryptographic Algorithm from the dropdown. After selection, the related PQC Key Type and Classical Key Type fields appear automatically based on that selection.

Table 7. Composite Cryptographic Settings
Field	Description
Composite Algorithm	Select the composite algorithm pairing first. This determines which PQC and classical key fields are displayed next.
Classical Key Type	Displayed after algorithm selection. Select the permitted key size for the classical component.
Padding (RSA only)	Displayed only when RSA is part of the composite combination.

Note: Classical and PQC models display their algorithm and key fields directly. For Composite, you must select the Cryptographic Algorithm first; only the corresponding PQC and classical fields then appear. Fields for other combinations remain hidden until the algorithm is chosen.

Key Usage and Extended Key Usage

Define the permitted Key Usage (KU) and Extended Key Usage (EKU) attributes for certificates issued by the CA. Certificate templates displayed during CA creation are dynamically filtered to match the KU and EKU values defined in the policy.

Key Usage (KU)

Select one or more Key Usage values:

Table 8. Key Usage Values
Key Usage	Description
Digital Signature	Verifies digital signatures for authentication and integrity.
Key Encipherment	Encrypts keys for secure transport.
Data Encipherment	Encrypts data directly (non-key data).
Key Agreement	Establishes shared secrets via key agreement protocols.
Certificate Signing	Signs other certificates; required for all CAs.
CRL Sign	Signs Certificate Revocation Lists. Required to enable CRL Distribution Points. Note: CRL Publish under Revocation & Distribution is enabled only when CRL Sign is selected as a Key Usage. Ensure you select CRL Sign first to activate the CRL Publish option.
Non-Repudiation	Provides proof of origin that the signer cannot deny.
Encipher Only / Decipher Only	Restricts the key to encryption only when used in conjunction with Key Agreement. Restricts the key to decryption only when used in conjunction with Key Agreement.

Extended Key Usage (EKU)

Select one or more Extended Key Usage purposes:

Server Authentication
Client Authentication
Code Signing
Email Protection
Time Stamping
OCSP Signing etc.

Note: Only templates that comply with the CA Policy are considered a match. All Key Usage (KU) and Extended Key Usage (EKU) values configured in the template must be permitted by the corresponding KU and EKU values defined in the CA Policy. The template must not contain any additional KU or EKU values that are not defined in the policy. Also, the Certificate Authority (CA) type of the template must match the CA type specified in the policy.

Go to Templates in the PKI navigation pane and verify that a template exists with the same CA Type, KU, and EKU combination. If not, create a matching template first or adjust your KU/EKU selections to align with an available template.

CSR Generation

Select where the private key and Certificate Signing Request (CSR) are generated.

Table 9. CSR Generation Options
Option	Description
AppViewX	Generates the CSR using AppViewX's internal key-generation capabilities.
HSM	Generates the CSR using a Hardware Security Module for enhanced key protection. HSM is supported only for Classical (RSA and EC) and PQC (ML-DSA) cryptographic models; it is not available for Composite.

Revocation & Distribution

Configure CRL distribution and OCSP signing settings for the policy.

Table 10. Revocation and Distribution Fields
Field	Description	Dependency
CRL Publish	Enable or disable CRL publishing for CAs created with this policy.	Available only when CRL Sign is selected in Key Usage. Automatically disabled otherwise.
Default OCSP Signing Certificate	Define the default certificate used for signing OCSP responses.	None.
Default CSR Generation for OCSP	Specify the CSR generation method for OCSP signing certificates.	None.

Review all configured values, and then click Create Policy.

The policy gets created and appears in the CA Policy inventory page.

Create a CA Policy by Uploading a CPS (SaaS Only)

On SaaS deployments, you can upload a Certification Practice Statement (CPS) document to automatically extract and populate CA policy fields using AI-powered parsing. This eliminates manual data entry and reduces configuration errors.

Restriction: CPS upload with AI parsing is available on SaaS deployments only. It is not supported on On-Premise or Managed Kubernetes environments.

The CPS document is typically prepared by the CISO or senior management. Administrators use this document within the platform to generate policies.

Phase 1: Upload and Parse the CPS Document

Go to PKI > CA Policy.
Select + Create and choose Upload CPS.
Select Upload CPS Document and choose a PDF file from your system.
Wait for parsing to complete. Do not navigate away from the page while processing is in progress.

File Requirements

Table 11. CPS File Requirements
Parameter	Requirement
File format	PDF only
Maximum file size	4 MB
Daily upload limit	25 uploads per user within a 24-hour period

The platform processes the document in these stages:

Content extraction – Reads the PDF and identifies policy-relevant sections.
AI analysis – Sends extracted text to the Amazon Bedrock AI framework for parameter identification.
Parameter mapping – Maps AI-extracted values to corresponding CA policy fields.
Validation – Validates extracted values against supported policy models.

Important: The parsing process is synchronous. If the AI service encounters an error, a notification is displayed. Re-upload the document to retry.

Phase 2: Review AI-Extracted Parameters

After successful parsing, the fields below are auto-populated from the CPS content:

Crypto model, Certificate Authority Type, Validity Period, Algorithm and Bit Length / Key Version, Key Usage (KU), Extended Key Usage (EKU),

Phase 3: Edit Extracted Values

Review every auto-populated field against the CPS.
Edit values directly in the form where needed.
Add values that were not extracted.
Clear values that should not be included.

Important: AI parsing is best-effort. The accuracy of extracted values depends on the clarity and structure of the CPS document. Always validate every extracted value before creating the policy.

Note: The details are auto populated from the CPS document. You can still modify the CA Policy attributes to add or delete the details. To know how to modify the attributes in detail, refer to the above section.

Phase 4: Create the Policy

Enter a Policy Name and optional Description.
Confirm that all required fields contain valid values.
Select Create Policy.

The policy is created and added to the CA Policy inventory page.

Policy Enforcement During CA Creation

When you initiate CA creation for a Native CA, the following behavior applies:

Select a Policy from the dropdown list on the CA creation page. Only policies assigned to your user group are displayed.
After selecting a policy, the CA creation form restricts all configuration fields to the values defined in that policy:
- Crypto Model – Only the model defined in the policy is available; others are disabled.
- Certificate Authority Type – Only the type defined in the policy is selectable.
- Validity – Only values configured in the policy are available.
- Algorithm and Bit Length / Key Version – Only options permitted by the policy are shown.
- Templates – Only templates matching the policy's KU and EKU settings are listed.
- CSR Generation – Restricted to the method defined in the policy.
Complete the remaining CA details and submit the CA creation request.

Note: For PQC-ready Native CAs, policy selection is required. For Standard CAs (such as Google GCP CA), the manual configuration workflow remains unchanged — policies do not apply.

Policy Disassociation

If a policy is deleted after it has been used to create one or more CAs:

Affected CAs display Disassociated in the Policy column on the CA Inventory page.
Existing CA configuration remains intact — deleting a policy does not alter or invalidate CAs already created with it.
A disassociated CA continues to function normally but is no longer linked to any policy definition.

Access Control and Policy Assignment

CA Policies are governed by AppViewX's Access Control List (ACL) framework. You can assign policies to specific user groups to control which users have access during CA creation.

Create a CA policy.
Go to Access Control > Resources and assign the policy to one or more user groups.
Users in those groups can view and select the policy during CA creation.
Users without access cannot view or use the policy.

Note: Policy assignment follows the same ACL patterns used for other PKI resources. Refer to the Access Control documentation for detailed instructions on group and resource management.

Note: The audit log messages for CA policy have been enhanced.

Troubleshooting

Table 12. Troubleshooting CA Policies
Issue	Resolution
Upload fails with "Invalid file type"	Upload a PDF. Other file formats are not accepted.
Upload fails with "File exceeds maximum size"	Reduce the PDF to 4 MB or below before uploading.
"Daily upload limit reached"	The user has reached the 25-upload daily limit. Wait until the next day to upload again.
AI parsing fails or returns no values	Review the CPS document for clarity, re-upload it, or contact support if the issue persists.
Create Policy button remains disabled	All required fields must contain valid values. Review each section and complete any empty required fields.
HSM is disabled and cannot be selected	HSM is available only when Cryptographic Model is PQC and Algorithm is ML-DSA. Select those values to enable HSM.