Creating Subordinate CA from External Root CA

Note: If you are using the complimentary root CA created in AppViewX, then you can create subordinate CA from external root CA as explained here.

To create subordinate CA from external root CA:

  1. Go to (Menu) icon > PKI > CA Inventory.
    The CA Inventory page appears.
  2. Click +Create CA on the top-right corner of the page.
    The Create CA page is displayed.
  3. Enter the fields as described in the table.
    Table 1. Field Description for PKIaaS Management page
    Field Description
    *CA Name Provide a friendly name for reference with no special characters except dash (-) and underscore (_).
    Description Provide a description for the CA. The maximum character limit is 500. Special characters that are not supported include ', ", ;, <, >, &, $, |, #, \, `.
    Tier Select the CA tier. The available options are:
    • PQC Ready CA: Available only when the CA account was created using AppViewX PKIaaS Native CA. Enables post-quantum cryptography (PQC) options. See Creating Certificate Authority.
    • Standard CA: Available for standard PKI initialization. Uses classical cryptography and requires a region selection.
    Note: The PQC Ready CA tier will be available only if you have created a CA account using the AppViewX PKIaaS Native CA as explained in Creating Certificate Authority.
    * Policy

    (PQC Ready CA only)
    Note: This field is displayed when Tier = PQC Ready CA.Select an approved Subordinate CA policy from the dropdown list. Only the policies assigned to the user group are displayed in the list.

    The selected policy automatically restricts and pre-populates subsequent fields (Crypto Model, Validity, Key Type and Algorithm, Template, Path Length, and CSR Generation) based on the policy configuration.

    * Region

    (Standard CA only)
    Note: This field is displayed when Tier = Standard CA.
    Select the geographic region where the CA will be hosted. The dropdown list is populated with the available regions. For example, us-east1 (South Carolina).
    Certificate Authority Type
    Note: This field is displayed when Tier = PQC Ready CA.
    Select the type of CA to create Subordinate CA. When a CA Policy is selected, this field is automatically populated and constrained to the Subordinate CA type configured in the policy.

    On clicking Subordinate CA, you see Root CA field with External and PKIaaS options.
    Root CA
    Note: This field is displayed when Certificate Authority Type = Subordinate CA.
    Select External if root CA is outside of the AppViewX system.
    Crypto Model Select the cryptographic model that defines the type of algorithms used by this Certificate Authority hierarchy. It determines whether the CA uses traditional algorithms, quantum‑resistant algorithms, or a combination of both.
    • Classical Cryptography: Uses widely adopted algorithms such as RSA and ECC. Suitable for current, non‑quantum‑resistant environments and existing PKI deployments. This option is available for all CA types.
    • Post‑Quantum Cryptography (PQC): Uses quantum‑resistant algorithms designed to protect against future quantum computing threats. Recommended for long‑term security and crypto‑agile deployments. This option is available only when the selected CA is PQC.
    • Composite Cryptography (Hybrid Classical + PQC): Not Supported for External Root CA.
    *Template

    (PQC Ready CA only)
    Note: This field is displayed when Tier = PQC Ready CA.
    Select a certificate template from the dropdown list. The dropdown displays only templates that match the CA type (Subordinate CA) and whose Key Usage (KU) and Extended Key Usage (EKU) comply with the selected CA Policy. The template defines the key usage, extensions, and cryptographic parameters applied to the CA certificate.
    *Valid for Select the number of years to CA expiry.
    Configure CA Subject DN Details
    *CA Common Name Enter the root CA subject name.
    *Organization Enter the organization name owning the CA.
    Organization Unit Enter the business unit for CA operations.
    City Enter the city name.
    State Enter the state name.
    Country Enter the country of the organization.
    Configure CA Key Size and Algorithm

    The following table describes all fields in the Configure CA Key Size and Algorithm section. Where a field behaves differently per Crypto Model, the behavior is noted within the description.

    Note:
    • Classical: Supports traditional key types (RSA, EC, DSA). Padding field is shown.
    • PQC: Supports only post-quantum key types: FN-DSA, ML-DSA, and SLH-DSA. Padding field is not shown. Bit Length and Hash Function values are constrained to those supported by the selected PQC algorithm.
    • Composite: Not Supported for External Root CA.
    CSR Generation Select where the private key and CSR are generated:
    • AppViewX: Keys are generated and managed within AppViewX (including HashiCorp Vault integration).
    • HSM: Keys are generated on a Hardware Security Module. When selected, additional Device and Key Handler Name fields appear.
      Note: For all crypto modes, the HSM option is supported based on the selected CA policy. Currently, HSM is not supported for Composite crypto mode.
    Use Existing Key
    Note: This field is displayed only when CSR Generation = HSM.
    Select this option if you want to use an existing key from HSM.
    *Device
    Note: This field is displayed only when CSR Generation = HSM.
    Select a configured device from the dropdown list. This list is retrieved from the HSM configured under the platform.
    *Key Handler Name
    Note: This field is displayed only when CSR Generation = HSM.
    You can either create the new key in HSM by providing the reference name or use an existing key handler name (alias/label name) in HSM by running the following command:
    pkcs11-tool --module /path/to/pkcs11.so --list-objects
    Click Validate button:
    • If validation is successful, then a message, Key is available in the HSM, is displayed.
    • If validation is unsuccessful, then a message, Key is not available in the HSM, is displayed.
    • If the key provided is not supported by the CA being created, then a message, The algorithm for this key is not supported for CA creation, is displayed.
    * Key Type

    Select the key algorithm for the CA. The options available depend on the Crypto Model selected:

    • Classical: RSA, EC and DSA variants. Example: RSA.
    • PQC: PQC-supported algorithms only:
      • FN-DSA: Lattice-based signature scheme optimized for compact signatures.
      • ML-DSA: Lattice-based scheme (CRYSTALS-Dilithium / ML-DSA) with strong security guarantees.
      • SLH-DSA: Stateless hash-based scheme with conservative post-quantum security.
    • Composite: Not Supported for External Root CA.
    * Padding

    Select the padding scheme for the RSA key component from the options allowed by the selected CA policy. Behavior varies by Crypto Model:

    • Classical: Select PKCS1 or PSS based on the selected Key Type.
    * Bit Length

    Select the key size in bits. Available values depend on the selected Key Type and Crypto Model:

    • Classical: Standard RSA/ECC values. Example: 2048, 30724096.
    • PQC: Values are constrained by the selected PQC algorithm and are typically larger than classical equivalents. Example: 7176, 14344.
    * Hash Function

    Select the hashing algorithm used to sign the CA certificate. Available options depend on the Crypto Model:

    • Classical: SHA-based functions. Example: SHA256, SHA384, SHA512.
    • PQC: SHAKE-based functions constrained by the selected PQC algorithm. Example: SHAKE256.
    *Key Size and Algorithm
    Note: This field is displayed when Tier = Standard CA.
    Select the CA key size and algorithm from the dropdown list. By default, RSA_PKCS1_4096_SHA256 is selected.
    Configure CA Artifacts
    Path Length Constraint
    Note: This field is displayed when Tier = PQC Ready CA.
    Optional. Defines the maximum number of subordinate CA levels permitted below this CA in the PKI hierarchy. The allowed values are constrained by the selected CA policy and will be in the range of x – y or None

    For example, if it is set to 2, it means that only two intermediate CAs are allowed between the end-entity certificate and this CA certificate. None indicates unlimited.
    CRL Publishing
    Note: This field is displayed when Tier = PQC Ready CA.
    Select this option to enable or disable CRL publishing using the CRL Publishing checkbox, which is enabled by default.
    Note: Ensure the selected template includes the cRLSign key usage. If not, a warning is displayed and CA creation is blocked until you update the template or disable CRL publishing.
    Policy ID
    Note: This field is displayed when Tier = Standard CA.
    Select the certificate policy ID to embed in the CA certificate's Certificate Policies extension. The dropdown lists the available policy identifiers. Example value: 2.5.29.32.0 (anyPolicy).
    Custodian Settings
    Custodian By default, the SaaS trial customer (logged in user) is added as the custodian. He/she will get the approval links via email for all the actions performed in the PKI hierarchy creation.

    Click Manage to add more custodians.
    *: Mandatory fields
  4. Click Create.
    A window with the summary of values entered appears.
  5. Click Proceed to trigger the approval flow.
    Note: The backend validates the request parameters against the selected CA Policy. If validation fails, CA creation is blocked and an error message is displayed

    The newly created CA appears in the table with the status as Create - Approval Pending. If you want to abort the action, then click Abort.

    An email from AppViewX is sent to all the active custodians for approving the CA.

  6. Click the here hyperlink in the email to be redirected to the AppViewX login page.
    On successfully logging in, the approval request is displayed with the Approve and Reject buttons.
    Tip: You can also approve by clicking the (Notification Center) on the top right-hand-corner of the page.
  7. Enter the comments and click Approve.
    A confirmation popup window appears if you want to submit the request.
  8. Click OK. Once the approval count reaches the minimum approval as set by the quorum number, the custodian is approved.
  9. Click the (Refresh) icon.
  10. Click Activate. Until the signed certificate is uploaded, the status of the external subordinate CA remains as Pending Signed Certificate.
    The Certificate Authority Activation window appears.
  11. Click Download CSR.
  12. Once the CSR is downloaded, sign with valid root CA and click Upload.
    Note: Copy and paste or upload the complete certificate chain, ordered from leaf to root, starting with the subordinate certificate authority being activated.
    Note: Pre-Upload Checklist
    When you upload the signed Sub CA certificate, AppViewX automatically validates it against the original CSR generated in PKI. Ensure the following conditions are met before uploading:
    • Public Key Match: The public key in your Sub CA certificate must match the public key in the CSR.
    • Subject DN Match: The Subject DN in your Sub CA certificate must match the Subject DN in the CSR.
    • Key Usage Match: The Key Usage in your Sub CA certificate must match the Key Usage specified in the CSR.
    • Extended Key Usage (EKU) Match: The Extended Key Usage (EKU) in your Sub CA certificate must match the EKU in the CSR.
    • Certificate Policies Match: The certificate policies in your Sub CA certificate must match those in the CSR.
    • Extension Criticality & Values: The criticality and value of each extension in your Sub CA certificate must match the corresponding extension in the CSR.
    • Extension Presence: All extensions present in the CSR must also be present in your Sub CA certificate with the same value and criticality.
    • Chain Verification: The signature on your Sub CA certificate must be verifiable using the parent issuer's public key.
    Troubleshooting Upload Errors
    If the uploaded certificate fails validation during upload, AppViewX returns an error indicating the exact failure reason. Refer to the table below to resolve common upload errors:
    Failure Scenario Error Code Recommended Resolution
    Signature not verified by parent CA's public key SIGNATURE_VERIFICATION_FAILED_FOR _THE_UPLOADED_CERIFICATE_CHAIN Verify that the Sub CA certificate was signed by the correct parent CA. Upload the chain in the correct order and ensure the issuer certificate included in the chain contains the public key that can validate the Sub CA signature.
    Sub CA public key differs from the original CSR PKICA_PUBLICKEY_MISMATCH Do not generate a new key pair outside AppViewX. Re-sign the original CSR generated from PKI+ and make sure the issued Sub CA certificate uses the same public key as the CSR.
    Issuer DN does not match parent Subject DN SIGNATURE_VERIFICATION_FAILED_FOR _THE_UPLOADED_CERIFICATE_CHAIN Confirm that the issuer DN of the Sub CA certificate exactly matches the Subject DN of the parent certificate in the uploaded chain. Replace the parent certificate if an incorrect issuer certificate is included.
    Intermediate CA missing from chain SIGNATURE_VERIFICATION_FAILED_FOR _THE_UPLOADED_CERIFICATE_CHAIN Include all required intermediate CA certificates between the Sub CA and Root CA in the PEM chain. The chain should contain the Sub CA first, followed by each issuing intermediate, and finally the Root CA.
    Extension criticality mismatch (between Sub CA and CSR) PKICA_EXTENSION_CRITICALITY_MISMATCH Compare the CSR extensions with the issued Sub CA certificate. Reissue the certificate without changing the critical/non-critical flag of extensions such as Basic Constraints, Key Usage, EKU, or custom extensions.
    Extension value mismatch (between Sub CA and CSR) PKICA_EXTENSION_VALUE_MISMATCH Check whether the external CA modified extension values from the original CSR. Reissue the Sub CA certificate using the same Key Usage, EKU, Basic Constraints, certificate policies, path length, and custom extension values defined in the CSR.
    Certificate is X.509 v1 or v2 Certificate parse failure Issue an X.509 v3 Sub CA certificate. Ensure mandatory CA extensions such as Basic Constraints and Key Usage are present and aligned with the original CSR/template.
    Once the external subordinate CA is activated, the status changes to Active. Click Resubmit if the action fails for any reason.
  13. [Optional] Click the Audit Log against the CA to view the audit log details. You can also download the audit log by clicking the Download button on the Audit Log view page. The audit log is exported in the .xls format.
    Note: Once the audit log is fully loaded, the Loading button will turn to View. Refresh the page to see the View button.
  14. [Optional] Click the Approval Status column value link to check the update on approvals.