> For the complete documentation index, see [llms.txt](https://docs.certinext.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.certinext.io/documentation/certificate-authorities-and-trust-stores/certificate-authorities-and-product-profiles.md).
# Certificate Authorities and Product Profiles
### \[1] Introduction and Overview
This guide provides step by step instructions for PKI administrators who set up a private Certificate Authority hierarchy in CERTInext and create the certificate product profiles that issue certificates from it.
Follow the steps in sequence. A CA hierarchy must be completed before a Product Profile can be configured, and a Product Profile must exist before any certificate can be issued.
The guide covers four workflows:
• Creating a Private CA, including the Root CA and the Subordinate CA types (Intermediate CA, Signing CA and Delegated CA)
• Creating a Product Profile, which defines the template used when issuing certificates from a Signing CA
• Downloading the certificate files that CERTInext produces
• Distributing the trust chain so that the machines in your organisation accept the certificates you issue
#### What a private PKI is
A private PKI is a certificate authority you operate yourself, for names that exist only inside your organisation. It works exactly like a public CA with one difference that governs everything in this guide: no machine trusts it until you install its Root CA certificate. A public CA’s root already ships inside every browser and operating system. Yours does not, and putting it there is a step you perform, described in Section \[9].
#### CA Hierarchy
CERTInext supports a multi tier private PKI hierarchy. The CA types available are:
| CA Type | Purpose | Role | Can Issue |
| -------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| Root CA | Not applicable | The trust anchor of the entire PKI. Self signed. Sits at the top of the hierarchy. | Subordinate CA certificates only |
| Subordinate CA | Intermediate CA | Sits between the Root CA and the issuing CA. Used when a multi tier hierarchy is required for policy separation. | Other Subordinate CA certificates only |
| Subordinate CA | Signing CA | The issuing CA at the bottom of the hierarchy. Directly issues end entity certificates to servers, devices and users. Must be selected when creating a Product Profile. | End entity (leaf) certificates only |
| Subordinate CA | Delegated CA | A Signing CA whose key pair is generated and held by an external operator. A certificate signing request from that operator is mandatory. | End entity (leaf) certificates only |
CERTInext supports multiple hierarchy configurations. Common setups include:
• Two tier: Root CA to Signing CA to End Entity Certificates
• Three tier: Root CA to Intermediate CA to Signing CA to End Entity Certificates
• Extended: Root CA to multiple Intermediate CAs to multiple Signing CAs to End Entity Certificates
The hierarchy you choose depends on your organisation’s size, policy requirements, and the level of separation needed between issuing CAs. There is no restriction on the number of CA hierarchies you can create within CERTInext, and a single account can hold two tier and three tier hierarchies at the same time.
Note: Always create the Root CA first, then Subordinate CAs in order from top to bottom. You cannot create a Signing CA without a parent CA to sign it.
#### The single rule that prevents most failures
Restrict usage at the leaf, never at a CA. A CA certificate should carry Key Cert Sign and CRL Sign in its Key Usage, and no Extended Key Usage at all. An Extended Key Usage on a CA is not a label, it is a ceiling on every certificate beneath it. A web server certificate issued under a CA restricted to Client Authentication can never be valid for HTTPS, no matter what the certificate itself requests.
### \[2] Before You Begin
#### Permissions and access
• An account with access to Certificates > Certificate Authorities, including permission to create CAs and Products.
• Administrator rights on every Windows machine that will browse the site, and root on every Linux server that will present a certificate, if you intend to complete Section \[9].
#### Decisions to make first
| Decision | Why it matters |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Names for the Root CA and each Subordinate CA | The name is written permanently into the certificate and appears in every client’s trust store. Choose names that will still make sense in a few years. |
| Lifetime of each CA | The Root CA must outlive the Intermediate CA, and the Intermediate CA must outlive the Signing CA, with enough margin to renew comfortably before the parent expires. |
| Key algorithm family | The algorithm family cannot be changed after creation, and a child CA must stay within the same family as its parent. |
| How certificate requests will arrive | Automated requests through ACME, SCEP or the Discovery and Provisioning flows usually supply only a domain name. This decides which subject fields you can mark as Mandatory in the Product Profile. |
Important: Nothing on the CA creation screens is editable after creation. Names, key algorithm, lifetime and extensions are all fixed when a CA is created. Correcting any of them means creating a replacement CA and redistributing it to every machine that already trusts the old one. Read this section before you start.
#### Order of work
1\. Create the Root CA.
2\. Create the Intermediate CA beneath it, if your design calls for three tiers.
3\. Create the Signing CA beneath the Root CA or the Intermediate CA.
4\. Create one or more Product Profiles against the Signing CA.
5\. Request a certificate, download the files, verify the chain, and distribute trust.
### \[3] Creating a Private Certificate Authority
#### Navigation Path
Log in to CERTInext, then go to Certificates > Certificate Authorities > Create CA.
Figure 1: Certificates > Certificate Authorities. The CA Grid View lists every CA in the account. Select Create CA at the top right to open the wizard.
The CA creation wizard has six steps shown in the left panel. Complete each step and click Next to proceed. Steps already completed can be revisited with Back, or with the Edit button that appears on each completed step.
#### Step 1: Create Private CA
This step defines the fundamental role of the CA within the hierarchy.
**CA Type**
| Option | When to Select |
| -------------- | ----------------------------------------------------------------------------------------------------------------- |
| Root CA | When creating the first CA in the hierarchy. Self signed, no Parent CA required. |
| Subordinate CA | When creating an Intermediate, Signing or Delegated CA beneath an existing CA. Requires selection of a Parent CA. |
Note: If no Root CA exists in the account, the Subordinate CA option cannot be used and CERTInext prompts you to create a Root CA first.
**Parent CA (Subordinate CA only)**
Select the CA that will sign this certificate. The dropdown lists every CA in the account that is permitted to sign another CA, which means Root CAs and Intermediate CAs. Signing CAs and Delegated CAs never appear here, because nothing may be created beneath them.
Selecting a Parent CA has three immediate effects on the form:
1\. The Validity field is pre filled with the parent’s remaining validity minus ten days, and the unit is switched to Days.
2\. The Key Algorithm list on Step 3 is filtered to the parent’s algorithm family. See Step 3 for the exact rule.
3\. The Purpose options become available.
**Purpose (Subordinate CA only)**
| Purpose | Screen Description | Use When |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Intermediate CA | This CA will only sign other CA certificates beneath it. It cannot directly issue end entity (leaf) certificates. | You need a policy separation layer between the Root CA and the CAs that issue certificates day to day. |
| Signing CA | This CA will directly issue end entity certificates. No additional CAs can be created under it. | This is the CA that will be attached to a Product Profile and will issue server, device and user certificates. |
| Delegated CA | This CA is delegated to an external operator. It will directly issue end entity certificates, a certificate signing request is mandatory, and no additional CAs can be created under it. | An external party generates and holds the CA key pair, and you sign their CSR under your hierarchy. |
Important: Only CAs created with the Signing CA or Delegated CA purpose appear in the Subordinate CA dropdown on the Product Profile screen. If your CA is set as Intermediate CA, create a Signing CA beneath it first. The purpose cannot be changed after creation.
**CA Path Length Constraints**
Path length states how many further CA levels may exist below this CA. The field behaves differently for each purpose:
| CA Type and Purpose | Field Behaviour | Meaning |
| ------------------------------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Root CA | Hidden | Not applicable at the trust anchor. |
| Subordinate CA, Intermediate CA | Dropdown with values 1, 2 and 3 | The number of additional CA levels permitted beneath this CA. A value of 1 allows one more CA level, which would be the Signing CA. |
| Subordinate CA, Signing CA | Fixed and displayed as 0 | Nothing but end entity certificates may sit below this point. |
| Subordinate CA, Delegated CA | Fixed and displayed as 0 | Nothing but end entity certificates may sit below this point. |
A path length of zero states the intent precisely and limits the damage if the key were ever misused, because the CA cannot mint further CAs.
**Validity**
Enter the validity period as a whole number and select the unit. The unit list offers Year(s), Month(s), Week(s) and Day(s), and CERTInext displays the equivalent number of days beside the field so the result is unambiguous. Leap years and varying month lengths are accounted for in that conversion.
Rules enforced by the form:
• The value must be a whole number greater than zero. Decimals and leading zeros are rejected or trimmed.
• For a Subordinate CA, the total must not exceed the parent CA’s remaining validity minus ten days. The ten day margin exists so the parent is still comfortably valid when the child is due for renewal.
| CA Type | Recommended Validity |
| --------------- | ----------------------------------------------------- |
| Root CA | 20 years for production, 2 years for a test hierarchy |
| Intermediate CA | 10 years, and it must expire before the Root CA |
| Signing CA | 5 years, and it must expire before its parent CA |
Note: Replacing a Root CA means revisiting every trust store you have distributed to, which is why production roots are given long lifetimes.
***
#### Step 2: Configure CA Information
This step defines the Distinguished Name embedded in the CA certificate’s subject. These fields identify the CA in all certificate chains built from it.
| Field | Description | Example | Status | Maximum Length |
| ---------------------- | --------------------------------------------------------------------------------------- | ---------------------- | -------- | -------------- |
| CA Common Name (CN) | Name of this CA as it appears in the certificate chain and in every client trust store. | Acme Corp Issuing CA 1 | Required | 64 |
| Organization Name (O) | Legal name of the organisation that owns and operates this CA. | Acme Corporation | Required | 64 |
| Organization Unit (OU) | Department or unit responsible for the CA. | IT Security | Optional | 64 |
| Country (C) | Two letter ISO 3166 country code, selected from the list. | IN, GB, US | Required | Selected |
| State / Province (ST) | State or province of the organisation. | Maharashtra | Optional | 128 |
| Locality (L) | City where the organisation operates. | Mumbai | Optional | 128 |
The optional fields add detail to a name that nobody types. They are worth filling in for a production CA where the distinguished name may end up in an audit, and worth skipping otherwise.
Tip: Use a consistent naming convention for the Common Name, for example \[Organisation] \[Tier] CA \[Number], giving names such as “Acme Corp Issuing CA 1”. Both the Root CA and the Signing CA end up visible in client trust stores and in certificate viewers, so make the names clearly distinguishable. An operator reading a chain should not have to compare serial numbers to tell them apart.
Important: CERTInext displays a banner on this step confirming that these values cannot be modified after creation.
#### Step 3: Key Information
This step selects the cryptographic algorithm for the CA’s key pair, and for a Delegated CA it also collects the CSR.
**Key Generation (Delegated CA only)**
This field appears only when the Purpose selected in Step 1 is Delegated CA.
| Option | Behaviour |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| System | CERTInext generates the CA key pair. The Key Algorithm dropdown and the Key Store Password field remain in use. |
| Requester | The external operator generates the key pair outside CERTInext and supplies a CSR. The Key Algorithm dropdown and the Key Store Password field are hidden, because the public key and the signature algorithm are taken from the CSR itself. |
When Requester is selected, the CSR becomes mandatory and can be supplied in either of two ways:
• Upload CSR: a .csr or .txt file.
• Paste CSR: the PEM text pasted into the text area. It must begin with -----BEGIN and contain CERTIFICATE REQUEST-----.
**Key Algorithm**
CERTInext offers twenty eight algorithms across three families. This setting cannot be changed after creation.
Figure 2: Step 3, Key Information. The Key Algorithm list, grouped into the RSA, ECC and PQC families. RSA 2048 (SHA 256) is the default selection.
| Algorithm Family | Options Available | Notes |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| RSA | RSA 2048 (SHA 256), RSA 3072 (SHA 256), RSA 4096 (SHA 384) | The most widely supported family. RSA 2048 removes compatibility as a variable while you prove a new hierarchy works. RSA 4096 (SHA 384) is the usual choice for a production Root CA. |
| ECC | ECC P256 (SHA 256), ECC P384 (SHA 384) | Smaller keys and faster handshakes with equivalent security. ECC P256 is a good production default and is well supported by modern clients. |
| PQC | DILITHIUM2, DILITHIUM3, DILITHIUM5, FALCON-512, FALCON-1024, and SPHINCSPlus in eighteen parameter sets across the SHA2, Shake and Haraka hash families | Quantum resistant algorithms, for hierarchies built to survive a future quantum capability. |
Important: No shipping browser or operating system trust store validates a Dilithium, Falcon or SPHINCS+ chain today. A certificate signed with a PQC algorithm will not be accepted by a standard TLS client, however correct the rest of the hierarchy is. Select PQC only where the consuming application is known to support it.
**How the parent CA restricts the choice**
When a Parent CA is selected in Step 1, CERTInext filters this dropdown so that the child stays in the same broad family as its parent:
| Parent CA Algorithm | Options Offered to the Child |
| ------------------- | ---------------------------- |
| RSA or ECC | RSA and ECC only |
| PQC | PQC only |
| No parent (Root CA) | All twenty eight options |
Within the permitted set the child does not have to match the parent exactly. Matching simply removes one variable while you prove that the chain works. If you do mix, keep the Root CA at least as strong as the CA beneath it, because the Root CA’s key has to outlast everything it signs.
**Key Store Password (Delegated CA with System key generation only)**
The password that protects the generated key store. CERTInext does not store this value in a recoverable form, so record it before you continue.
#### Step 4: Extensions
This step configures the X.509 extensions embedded in the CA certificate. Extensions are pre populated with defaults taken from the platform configuration, and each can be enabled or disabled with the checkboxes shown.
**CRL Distribution**
| Setting | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| CRL Distribution | Adds the CRL Distribution Point extension to the CA certificate. The Default CRL URL is pre populated by the platform. |
| Use Custom CRL URL | Replaces the platform URL with one or more URLs of your own. At least one URL is required and each is validated as a well formed URL. |
| Emergency CRL | Available where the platform has the emergency CRL feature enabled. Publishes a second CRL endpoint used for out of band revocation. |
**AIA, containing OCSP and CA Issuer**
| Setting | Description |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AIA, OCSP | Adds the Authority Information Access extension carrying the OCSP responder URL, so clients can check revocation status in real time. The Default OCSP URL is pre populated. |
| Use Custom OCSP URL | Replaces the platform URL with one or more URLs of your own. Each is validated. |
| CA Issuer | Adds the CA Issuer URL to the AIA extension, so a client that receives an incomplete chain can download the issuing CA certificate and repair it. The Default CA Issuer URL is pre populated. |
| Use Custom CA Issuer URL | Replaces the platform URL with a URL of your own. |
Note: If AIA is enabled, at least one of OCSP or CA Issuer must also be selected. The form rejects the step otherwise.
**Certificate Policy**
| Setting | Description |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Certificate Policy (CP) | Adds a Certificate Policy OID and CPS pointer to the certificate. The Default CPS URL and Default CPS OID are pre populated by the platform. |
| Use Custom CPS Details | Enables three inputs: CPS URL, CPS OID and Policy OID. The CPS OID on the first row is mandatory when this option is selected, and every OID entered is validated as a dotted decimal value. A notice text field is also available where the platform permits it. |
**Key Usage (KU)**
Key Usage defines the permitted cryptographic operations for the CA key. The Include KU checkbox is mandatory on this screen, and at least one value must be selected. A Critical checkbox sits beside the heading and is selected by default, which is the correct setting for a CA.
Figure 3: Step 4, Extensions. Include KU is mandatory and Critical is selected by default. Tick Key Cert Sign and CRL Sign only, and leave Include EKU cleared.
| Value | What it permits | Correct on a CA |
| ----------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| Digital Signature | Signing data other than certificates, for example a TLS handshake. | No. This is an end entity usage and is the most common cause of a CA that cannot sign. |
| Non Repudiation | Signatures intended to be provable to a third party. | No |
| Key Encipherment | RSA key transport, used by older TLS cipher suites. | No |
| Data Encipherment | Encrypting data directly with the certificate key. | No |
| Key Agreement | Establishing a shared secret, for example ECDH. | No |
| Key Cert Sign | Signing other certificates. This is what makes a CA a CA. | Yes, always |
| CRL Sign | Signing Certificate Revocation Lists. | Yes, always |
| Encipher Only | Restricts Key Agreement to encryption only. | No |
| Decipher Only | Restricts Key Agreement to decryption only. | No |
Important: RFC 5280 is explicit. If a Key Usage extension is present, the key must not verify signatures on certificates unless Key Cert Sign is set. A certificate whose Basic Constraints say CA but whose Key Usage omits Key Cert Sign contradicts itself, and every validator rejects it. Tick Key Cert Sign and CRL Sign, and nothing else.
**Extended Key Usage (EKU)**
Extended Key Usage defines the application level purposes for which the certificate may be used. The Include EKU checkbox is optional. If it is selected, at least one value must be chosen. The Critical checkbox beside the heading is cleared by default.
| Value | Typical Use |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Server Authentication | TLS server certificates. This is what a browser checks. |
| Client Authentication | TLS client certificates, and server to server calls. |
| Code Signing | Signing executables and packages. |
| Email Protection | S/MIME signing and encryption. |
| Time Stamping | Time stamp authority responses. |
| OCSP Signing | Signing OCSP responses. Offered only when the Purpose is Signing CA or Delegated CA, because an Intermediate CA never signs OCSP responses directly. |
| MSFT Document Signing | Microsoft document signing. |
| Smart Card Logon | Windows smart card authentication. |
| Adobe Certified Document Signing | Adobe document certification. |
| Encryption File System | Windows EFS. |
Important: Leave Include EKU cleared on every CA. An EKU on a CA acts as a ceiling. Windows applies EKU nesting, so a CA restricted to Client Authentication makes Server Authentication impossible for everything beneath it, whatever the leaf certificate requests. This is the second most common cause of a private PKI that does not work.
**Custom Extension**
Select Add Custom Extension to embed a non standard X.509 field. Use this only when an application or compliance requirement mandates a proprietary field not covered above. Click Add to insert further rows.
| Column | Description | Notes |
| ---------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| Custom OID | Full dotted decimal OID string. | For example 1.2.3.4.5 |
| Value | The value carried by the extension. | Free text |
| Data Type | ASN.1 encoding applied to the value. | TeletexString, PrintableString, UniversalString, UTF8String, BMPString, IA5String, NumericString, BITSTRING |
| Critical | Marks the extension as critical. | Clients that do not recognise the OID must reject the certificate. |
Important: Marking a Custom Extension as Critical will cause standard TLS clients and browsers that do not recognise the OID to reject the certificate. Only set Critical if the receiving application explicitly requires and supports the OID.
**Recommended settings by CA role**
| Setting | Root CA | Intermediate CA | Signing CA |
| ------------------ | ------------------------------------------ | ------------------------------------------ | ------------------------------------------ |
| Key Usage | Key Cert Sign, CRL Sign, Critical selected | Key Cert Sign, CRL Sign, Critical selected | Key Cert Sign, CRL Sign, Critical selected |
| Extended Key Usage | Not included | Not included | Not included |
| CRL Distribution | Not required | Recommended in production | Recommended in production |
| AIA, OCSP | Not required | Recommended in production | Recommended in production |
| CA Issuer | Not required | Recommended in production | Recommended in production |
| Certificate Policy | Optional | Recommended in production | Recommended in production |
A Root CA is self signed, so there is nothing above it to point at. Its own CRL and AIA are never consulted when validating it, which is why those extensions are left off. One level down they describe a certificate that something else issued, and they become genuinely useful.
Note: In a test hierarchy it is reasonable to leave CRL, OCSP and CA Issuer off on every CA, so that the test does not depend on those endpoints being reachable. An unreachable CRL or OCSP responder causes handshake delays and, under stricter client policies, outright failures. The trade off is that without a CA Issuer URL a client cannot repair a chain by downloading a missing intermediate, so the intermediate has to be distributed deliberately as described in Section \[9].
#### Step 5: Additional Information (Optional)
All fields in this step are optional and are used for internal management of the CA. Nothing entered here is written into the certificate.
| Field | Description |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Reporting Tags | Add one or more name and value pairs for internal categorisation and filtering. Click Add Tag to open the tag dialog. Tags appear in the CA grid and can be used as report filters. |
| Remarks | Free text field for internal notes about this CA, such as its purpose, scope or any relevant operational information. Maximum 50 characters. |
| Key Profile | Associates this CA with a key profile that determines where the CA private key is generated and stored. The row appears only where the key profile feature is enabled for the account. |
**Key Profile**
The Key Profile dropdown lists profiles already configured for the account. Accounts with their own dedicated emCA tenant can also create one inline using Create Key Profile.
| Key Profile Type | Where the key lives | Additional fields |
| ---------------- | --------------------------------------------------------- | ------------------------------------------------------ |
| PKCS12 | A software key store held by the platform. | Keystore Password |
| HSM | A hardware security module configured for the tenant. | Keystore Password |
| Crypto4A | A Crypto4A hardware security module reached over its API. | Crypto4A Base URL, Crypto4A API Key, Keystore Password |
Test Connection must succeed before the wizard will proceed. This confirms that CERTInext can reach the key store and that the credentials are valid, which is far easier to correct now than after a failed CA creation.
#### Step 6: Summary and Payment
This step presents a complete summary of everything configured. Review each section carefully before confirming.
• Verify the CA Type, Purpose and Parent CA are correct.
• Verify the CA Path Length Constraints value.
• Confirm the Distinguished Name fields reflect the intended CA identity.
• Confirm the Key Algorithm meets your security requirements.
• Check the Extensions block, and in particular confirm that the Key Usage line reads Key Cert Sign, CRL Sign.
• Review any Custom Extension rows.
• Review the Tags, Remarks and Key Profile entries.
• Review any applicable charges in the Payment section, where billing is enabled for the account.
• Click Create CA to complete creation. Where billing is enabled the buttons read Save and Pay Now instead.
Important: CA configuration, and in particular key parameters and extensions, cannot be modified after creation. Use the Back or Edit buttons to return and correct any setting before confirming.
After CA creation: the new CA appears in the Certificate Authorities list. Verify that the Status shows Active before creating anything beneath it or attaching a Product Profile to it.
| Status | Meaning |
| --------- | ------------------------------------------------------------------------ |
| Active | The CA is signed and available for use. |
| Pending | Creation has been submitted and the certificate has not yet been signed. |
| Revoked | The CA certificate has been revoked. Nothing beneath it will validate. |
| Suspended | The CA is temporarily withdrawn from use. |
***
#### Viewing the CA Hierarchy
Once CAs have been created, the Certificate Authorities page provides two ways to view and manage the hierarchy. The toggle sits at the top right of the page.
| View | Description | When to Use |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| CA Tree View | Displays all CAs as an interactive visual tree. Each node represents a CA, and lines connect parent CAs to their subordinate CAs, showing the full signing hierarchy. Nodes are colour coded by type. | To understand the full CA hierarchy at a glance, verify parent and child relationships, and navigate between CAs visually. |
| CA Grid View | Displays all CAs in a tabular list with columns for Name, Type, Purpose, Products, Key Usage, Extended Key Usage, Key Algorithm, Organisations, Expires On, Status, Tags and Action. | To manage, filter, sort and perform actions on individual CAs. |
**Node type legend, CA Tree View**
| Colour | Node Type | Description |
| ------------- | --------------- | ------------------------------------------------------------------------------------------------- |
| Grey | Root | The top level self signed Root CA. Trust anchor of the hierarchy. |
| Purple | Sub CA | A Subordinate CA signed by the Root CA or another Subordinate CA. |
| Teal or Green | Intermediate CA | A Subordinate CA configured with the Intermediate CA purpose. Can only sign other CAs. |
| Orange | End Entity | A Subordinate CA configured with the Signing CA purpose. Issues end entity certificates directly. |
**Grid actions**
Each row in CA Grid View carries a Select action menu. The options shown depend on the permissions held by the signed in user and on the state of the CA.
| Action | Availability |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| View CA | Requires the View All CA permission. |
| Download Certificate | Available for any CA that is not in Pending status. Returns that CA certificate on its own. |
| Download CRL | Available where the CA is not Revoked or Suspended. |
| Download Emergency CRL | Shown only where the emergency CRL feature is enabled for the CA. |
| Download Certificate Chain | Shown only for a CA that has a parent, since a Root CA is its own chain. Returns the CA together with everything above it, as a zip. |
The Download All Certificates button at the top right of the page returns every CA in the account in a single zip. This is the quickest way to collect the Root CA and the Signing CA together.
The Products column shows how many Product Profiles are attached to each CA, and the number is a link that opens the Products list filtered to that CA.
***
### \[4] Creating a Product Profile
A Product Profile defines the template used when issuing end entity certificates from a Signing CA. It controls which subject fields are collected, which SAN types are permitted, which key algorithms a requester may use, which X.509 extensions are embedded, and whether administrator approval is required.
Neither the Root CA nor the Signing CA decides any of this. Until a Product Profile exists, the hierarchy cannot issue anything.
#### Navigation Path
Certificates > Certificate Authorities > Products tab > Create Product
Note: The Certificate Authorities page opens on the Certificate Authorities tab by default. Click the Products tab before clicking Create Product. All five configuration sections appear on one scrollable page, and every section must be completed before clicking Create at the bottom.
Alternatively, use Import Profile at the top right to upload an existing profile in JSON format. The imported file populates every section of the form, which you can then adjust before saving. A profile is exported from the Products grid using the Export Profile action, which makes it straightforward to copy a proven profile between accounts or environments.
***
#### Section 1: Configure Product
This section establishes the identity of the profile, the CA that will issue under it, the certificate lifetime and the key algorithms permitted. All fields are mandatory.
| Field | Description | Example |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| Product Name | A unique, descriptive name for this profile. It appears wherever a requester chooses a product. | Internal-ServerTLS-365 |
| Subordinate CA | The Signing CA that will issue certificates under this profile. Only CAs created with the Signing CA or Delegated CA purpose appear here. | Acme Corp Issuing CA 1 |
| Validity In Days | Lifetime of certificates issued under this profile, expressed in days. | 365 |
| Key Algorithm | The key algorithms a requester is permitted to use. This is a multi select field. | RSA 2048 (SHA 256), ECC P256 (SHA 256) |
| Description | Internal description of the profile’s purpose and intended use. Not embedded in the certificate. Maximum 500 characters. | For internal web servers on example.internal |
Figure 4: Products tab, Create Product. Section 1 establishes the profile name, the Signing CA that will issue under it, the certificate lifetime and the permitted key algorithms.
**Subordinate CA**
Selecting the CA does more than record a parent. CERTInext immediately fetches that CA’s configured repository URLs and uses them as the Default values offered in the Extensions section: the Default CRL URL, the Default OCSP URL, the Default CA Issuer URL, the Default CPS URL and the Default CPS OID. Selecting the CA before configuring extensions therefore saves re typing all five values.
Note: If your issuing CA is missing from this list, its Purpose was saved as Intermediate CA rather than Signing CA. An Intermediate CA cannot issue leaf certificates and must be replaced with a Signing CA.
**Validity In Days**
When a Subordinate CA is selected, this field is pre filled with that CA’s remaining validity in days. Reduce it to the lifetime you actually want. The value must not exceed the Signing CA’s remaining validity, because a certificate cannot outlive the CA that signed it.
A very short lifetime combined with a renewal window measured in days leaves almost no margin for a failed attempt to retry. Ten days is useful for exercising renewal behaviour during testing. Use 90 days or more in practice.
**Key Algorithm**
This is a multi select field, and at least one algorithm must be chosen. Every algorithm you select becomes an option the requester may use. Every algorithm you leave out is refused at request time. The same twenty eight options described in Section \[3] Step 3 are offered here.
Selecting a small set, typically RSA 2048 and ECC P256, is the usual approach. It gives requesters a genuine choice while keeping the certificates your estate contains predictable.
Figure 5: The Key Algorithm field on a Product Profile is multi select, and offers the same twenty eight algorithms, including the PQC parameter sets. Every algorithm selected becomes an option a requester may use.
#### Section 2: Setup Profile
This section defines which fields appear in the certificate request form and how they behave. It is divided into two tables, Subject Attributes and SAN Attributes. Use the Add button at the top right of each table to add rows, the red action button to delete a row, and the drag handle at the left of each row to reorder it. The order of the Subject Attribute rows is the order in which the attributes appear in the certificate’s subject distinguished name.
Figure 6: Section 2, Setup Profile. The form opens with six Subject Attribute rows and two SAN Attribute rows, all marked Mandatory. Trim them before using the profile for automated issuance.
**Subject Attributes, column definitions**
| Column | Description | Options |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Subject Field (OID) | The X.509 Distinguished Name attribute to include in the certificate subject. The list is searchable, and a value not on the list can be typed in directly. | See the OID list below |
| Request Field | Which field of the certificate request supplies the value for this attribute. This is a multi select field, so one subject attribute can be fed from more than one request field. | See the Request Field list below |
| Presence | Whether the attribute must be present in the request. Mandatory means a request that omits the value is rejected. | Mandatory or Optional |
| Data Type | The ASN.1 string encoding applied to the value when it is written into the certificate. | TeletexString, PrintableString, UniversalString, UTF8String, BMPString, IA5String, NumericString, BITSTRING |
| Field Restriction Type | Whether the requester supplies the value, whether it is locked to a value you set, or whether it must match a pattern. | Dynamic, Fixed or Regex |
| Value | The pre set value when Field Restriction Type is Fixed, or the regular expression when it is Regex. Disabled when the type is Dynamic. | Free text |
**Field Restriction Type in detail**
| Type | Behaviour | Value column |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------- |
| Dynamic | The requester provides the value on the request form. | Disabled |
| Fixed | The value you enter is written into every certificate issued under this profile. The requester cannot change it. | Enabled, and the value is required |
| Regex | The requester provides the value, but it is accepted only if it matches the regular expression you enter. A Test button opens a dialog where you can paste a sample value and confirm the pattern behaves as intended before saving. | Enabled, and the expression is required |
Note: Regex is not offered for Country Name or State Or Province, because those values are selected from a controlled list rather than typed.
Tip: Set the Fixed restriction on Organization Name, Country, State and Locality so that every certificate carries a consistent organisational identity, and leave Common Name as Dynamic so the requester supplies the host or user name.
**Presence and automated requests**
The form starts with six Subject Attribute rows already added and all marked Mandatory: Common Name, Organization Name, Organizational Unit Name, Locality Name, State Or Province Name and Country Name.
Automated requests, including ACME, SCEP and the Discovery and Provisioning flows, normally carry only a domain name. Every attribute left as Mandatory must be present in the request, so leaving all six defaults in place will cause automated issuance to fail. For an automated TLS profile, keep Common Name and delete the other five, or set them to Fixed so a value is always available regardless of what the request contains.
Nothing is lost by trimming, because browsers ignore the Subject entirely and match on the Subject Alternative Name.
**Available Subject OIDs**
| OID | Field Name | Common Use | Recommended Data Type |
| ------------------------ | ---------------------------------------------- | --------------------------------------------------------------------------------------------------- | --------------------- |
| 2.5.4.3 | Common Name (CN) | Domain name or user identity, the primary identifier in the certificate | UTF8String |
| 2.5.4.10 | Organization Name (O) | Legal name of the organisation | UTF8String |
| 2.5.4.11 | Organizational Unit Name (OU) | Department or business unit | UTF8String |
| 2.5.4.7 | Locality Name (L) | City or locality | PrintableString |
| 2.5.4.8 | State Or Province Name (ST) | State or province | PrintableString |
| 2.5.4.6 | Country Name (C) | Two letter ISO 3166 country code | PrintableString |
| 1.2.840.113549.1.9.1 | Email Address | Subject email, used in Email Protection profiles | IA5String |
| 2.5.4.5 | Serial Number | Device or user serial number | PrintableString |
| 2.5.4.4 | Surname | Surname of an individual subject | UTF8String |
| 2.5.4.42 | Given Name / First Name | First name of an individual subject | UTF8String |
| 2.5.4.12 | Title | Job title or role | UTF8String |
| 2.5.4.20 | Telephone Number | Contact telephone, rarely used in TLS profiles | PrintableString |
| 2.5.4.9 | Street Address | Physical street address | UTF8String |
| 2.5.4.17 | Postal Code | Post code or ZIP code | PrintableString |
| 2.5.4.97 | Organization Identifier | Unique organisation identifier, used in CA/Browser Forum profiles | UTF8String |
| 2.5.4.65 | Pseudonym | Privacy sensitive subject pseudonym | UTF8String |
| 2.5.4.15 | Business Category | Type of business: Private Organization, Government Entity, Business Entity or Non Commercial Entity | UTF8String |
| 1.3.6.1.4.1.311.60.2.1.1 | Incorporation Locality / Jurisdiction Locality | Jurisdiction of incorporation at city level. Used in EV certificates. | UTF8String |
| 1.3.6.1.4.1.311.60.2.1.2 | Incorporation State / Jurisdiction State | Jurisdiction of incorporation at state level. Used in EV certificates. | PrintableString |
| 1.3.6.1.4.1.311.60.2.1.3 | Incorporation Country / Jurisdiction Country | Jurisdiction of incorporation at country level. Used in EV certificates. | PrintableString |
CERTInext defaults the Data Type to UTF8String for Common Name, Organization Name and Organizational Unit Name, and to PrintableString for the remaining attributes. Override it only when a consuming application requires a specific encoding.
**Available Request Fields**
The Request Field column maps a certificate attribute to the field on the request form that supplies its value. The following request fields are available:
First Name, Last Name, Identity Document Type, Identification Number, Domain Name, Organization Name, Additional Domain Names, Organization Identification Number, Registered ID, Organization Unit, Business Category, Email ID, Designation, Mobile Number, Street Address 1, Street Address 2, Country, State / Province, Locality, Zip Code / Post Office Box Number, Jurisdiction of Incorporation Country, Jurisdiction of Incorporation State / Province, Jurisdiction of Incorporation Locality, Domain Component, Pseudonym and IP Address.
Where the account has custom fields enabled, those custom fields also appear in this list, marked with a (Custom Fields) suffix. This lets a profile carry an attribute that is specific to your organisation without needing a platform change.
Tip: For a TLS server profile, map Common Name to Domain Name. For an S/MIME profile, map Email Address to Email ID.
**Subject Alternative Name (SAN) Attributes**
SAN fields define additional identity information beyond the Subject DN. For TLS certificates the SAN is the field browsers and clients use to validate the certificate against the hostname. Modern TLS clients ignore the Common Name entirely and rely exclusively on the DNS Names SAN for hostname validation.
The column definitions are identical to the Subject Attributes table.
| SAN Field | OID | Description | When to Use | Status |
| ------------------------- | -------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------- | ----------- |
| DNS Names | 1.3.6.1.2.1.32.1.1.4.1.1.1 | Domain names the certificate is valid for. Supports wildcards and multiple entries. | All Server TLS and Mutual TLS profiles | Recommended |
| IP Address | 1.3.6.1.2.1.4.20.1.3 | IP addresses to which the certificate applies. | Services accessed by IP address rather than hostname | Optional |
| RFC822 Name | 1.3.6.1.2.1.198.1.1.2 | Email addresses in the SAN. Used in S/MIME certificates. | Email Protection profiles | Optional |
| URI | Not applicable | Uniform Resource Identifiers for application specific certificate types. | Application specific use cases | Optional |
| Others | 1.3.6.1.4.1.8321.1 | Custom or non standard alternative name types, carried as otherName. | Specialised application requirements | Optional |
| User Principal Name (UPN) | 1.3.6.1.4.1.311.20.2.3 | The Windows User Principal Name, carried as an otherName. | Smart Card Logon and Windows client authentication profiles | Optional |
The form starts with two SAN rows added and both marked Mandatory: DNS Names and IP Address.
Important: A Mandatory IP Address SAN fails any request that carries only a hostname, which is every automated request. Delete the IP Address row, or set its Presence to Optional, unless every request will genuinely supply an IP address.
Important: Certificates without a DNS Names SAN will fail hostname validation in all modern browsers and TLS clients. Always include DNS Names in Server TLS and Mutual TLS profiles.
#### Section 3: Extensions
Extensions define the technical capabilities, permitted uses and trust chain information embedded in the certificates issued under this profile. Click Add to insert a row. Each row starts with an OID and a Type, and the remaining columns change according to what you select.
**Available extension OIDs**
| OID | Full Name | Description | Rows permitted | Recommendation |
| --------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------- | -------------- | -------------- |
| KU | Key Usage | Restricts the cryptographic operations the certificate key may perform. | 1 | Always include |
| EKU | Extended Key Usage | Specifies the application purposes for which the certificate may be used. | 1 | Always include |
| CRL | Certificate Revocation List | The URL from which the CRL can be downloaded. Clients use this to check revocation status. | 1 | Recommended |
| OCSP | Online Certificate Status Protocol | The URL of the OCSP responder, for real time revocation status checking. | 1 | Recommended |
| CP | Certificate Policy | References the Certificate Policy document and assurance level for this profile. | Up to 4 | Recommended |
| CA Issuer | Authority Information Access, CA Issuers | The URL from which the issuing CA certificate can be downloaded, so clients can build the full chain. | 1 | Recommended |
CERTInext groups rows of the same OID together automatically as you add them, so the table stays readable when several Certificate Policy rows are present.
**Type: Default or Custom**
For CP, CRL, OCSP and CA Issuer the Type column offers two values:
| Type | Behaviour |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Default | Uses the URL already configured on the Signing CA selected in Section 1. The value is displayed read only, so you can confirm it is the one you expect. |
| Custom | Presents an input where you enter a URL of your own, which overrides the CA level value for certificates issued under this profile. |
The fields presented for each combination are:
| OID and Type | Fields shown |
| ------------------ | -------------------------------------------------------------------------------- |
| CRL, Default | Default CRL URL, read only |
| CRL, Custom | Custom CRL URL |
| OCSP, Default | Default OCSP URL, read only |
| OCSP, Custom | Custom OCSP URL |
| CA Issuer, Default | Default CA Issuer URL, read only |
| CA Issuer, Custom | Custom CA Issuer URL |
| CP, Default | Default URL and Default OID, both read only, plus Policy OID and Purpose of Cert |
| CP, Custom | CPS URL, CPS OID, Policy OID and Purpose of Cert, all editable |
Policy OID is the identifier of the policy under which the certificate is issued. Purpose of Cert is the user notice text carried alongside it, which some certificate viewers display to a human reader. Additional Certificate Policy rows beyond the first present only Policy OID and Purpose of Cert, because the CPS URL and CPS OID are shared across them.
Tip: If a CRL or OCSP URL is not reachable from your clients, leave that row off rather than publishing an address nothing can fetch. An unreachable revocation endpoint causes handshake delays and, under stricter client policies, outright failure.
**Key Usage on a certificate profile**
Selecting KU replaces the Type column with a multi select list of Key Usage values, and adds a Critical checkbox which is selected by default.
| Value | Meaning for an end entity certificate | Use in a Server TLS profile |
| ----------------- | ------------------------------------------------------------------ | ------------------------------- |
| Digital Signature | The key may sign data, which includes the TLS handshake signature. | Required |
| Key Encipherment | The key may be used for RSA key transport. | Recommended |
| Non Repudiation | Signatures intended to be provable to a third party. | Not used |
| Data Encipherment | Encrypting data directly with the certificate key. | Not used |
| Key Agreement | Establishing a shared secret, for example ECDH. | Used in some Mutual TLS designs |
| Encipher Only | Restricts Key Agreement to encryption only. | Not used |
| Decipher Only | Restricts Key Agreement to decryption only. | Not used |
Digital Signature alone is enough for modern browsers, which negotiate ECDHE, but it silently disables RSA key transport cipher suites, so older clients fail to connect. Adding Key Encipherment costs nothing and removes that edge case.
Note: CERTInext protects you here. Key Cert Sign and CRL Sign are deliberately not offered on this screen. The CA screens list them, and the certificate profile screen does not, because an end entity certificate must never be able to sign other certificates.
**Extended Key Usage on a certificate profile**
Selecting EKU replaces the Type column with a multi select list of Extended Key Usage values, and adds a Critical checkbox which is cleared by default. Leaving EKU non critical is the normal convention.
The values offered are Server Authentication, Client Authentication, Code Signing, Email Protection, Time Stamping, OCSP Signing, MSFT Document Signing, Smart Card Logon, Adobe Certified Document Signing, Encryption File System, and KDC Authentication (1.3.6.1.5.2.3.5) for Kerberos domain controller certificates.
Recommended values by certificate purpose:
| Certificate purpose | Extended Key Usage to select |
| ------------------------ | ------------------------------------------------------------------------------------------ |
| Server TLS | Server Authentication, and Client Authentication where server to server calls are expected |
| Client TLS | Client Authentication |
| Mutual TLS | Server Authentication and Client Authentication |
| Email Protection, S/MIME | Email Protection |
| Smart Card Logon | Client Authentication and Smart Card Logon |
| Domain Controller | Server Authentication, Client Authentication, Smart Card Logon and KDC Authentication |
Important: Server Authentication is what a browser checks, and adding it is the step that makes HTTPS work. Do not add every value available. A certificate valid for every purpose is poor hygiene on a public facing key. Equally, do not leave EKU out entirely: Apple platforms reject TLS server certificates that carry no Extended Key Usage at all, where Windows accepts them.
#### Section 4: Custom Extension
This section lets you embed non standard X.509 fields using a custom OID. Use it only when an application or compliance requirement mandates a proprietary field not covered by the standard extensions above. Leave this section empty if no custom OIDs are required. Click Add to insert further rows.
| Column | Description | Options |
| ---------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Custom OID | Full dotted decimal OID string for the custom extension. | For example 1.2.3.4.5.6 |
| Request Field | Which field of the request supplies the value. Multi select. | The same request field list as Subject Attributes |
| Presence | Whether the value must be present in the request. | Mandatory or Optional |
| Data Type | ASN.1 data type of the extension value. | TeletexString, PrintableString, UniversalString, UTF8String, BMPString, IA5String, NumericString, BITSTRING |
| Field Restriction Type | Whether the requester provides the value or it is locked to a value you set. | Dynamic or Fixed |
| Value | The pre set value when Fixed is selected. | Free text |
| Critical | Marks the extension as critical. | Use with caution |
Important: Marking a Custom Extension as Critical will cause standard TLS clients and browsers that do not recognise the OID to reject the certificate. Only set Critical if the receiving application explicitly requires and supports the OID.
#### Section 5: Advanced Settings (Optional)
This section controls whether certificate requests require manual administrator review, and defines the steps an approver must complete.
**Administrator Approval**
A single checkbox labelled Automatically approve the certificate requests governs this behaviour.
| Setting | Behaviour | Recommended Use |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- |
| Checked | Requests are approved and issued immediately with no manual review. The Validation Checklist is hidden, because there is no approver to present it to. | Automated pipelines, scheduled renewals, internal low risk certificates |
| Unchecked (default) | Requests are placed in a pending state and must be manually approved or rejected before issuance. The Validation Checklist becomes available. | High trust certificates, compliance sensitive environments |
Important: Automated provisioning cannot wait for a human. If certificates under this profile will be requested by ACME clients, SCEP devices or the Discovery and Provisioning flows, select Automatically approve the certificate requests. Manual approval is the right setting where issuance is a controlled, audited event rather than a scheduled renewal.
**Specify Validation Checklist**
The checklist defines the steps an administrator must verify during manual approval. It is relevant only when automatic approval is left unchecked. Conditions added here are displayed as a validation checklist on the order summary page, and the approver must respond to each condition before approving or placing the certificate request.
Click Add to insert further checklist items, and use the drag handle to reorder them.
| Column | Description | Example |
| --------- | -------------------------------------------------------------- | -------------------------------------- |
| Condition | Description of the validation step the approver must complete. | Verify domain ownership via DNS record |
| Presence | Whether this item is mandatory or optional for the approver. | Mandatory |
***
#### Finishing and creating the profile
Once all sections are complete, scroll to the bottom of the page.
| Button | Action |
| ------ | ------------------------------------------------------------------------------------------------------------ |
| Cancel | Discards all entries without saving and returns to the Products list. |
| Create | Saves the profile and makes it immediately available for certificate issuance under the selected Signing CA. |
Important: There is no auto save. If you navigate away before clicking Create, all entries will be lost. Complete and save the profile in a single session. Where a profile is long, build it once, export it with Export Profile, and use Import Profile to recreate it elsewhere.
After creation: the profile appears in the Products tab under Certificate Authorities and can be viewed or edited at any time.
***
#### Viewing the Product Hierarchy
The Products tab provides a separate view of all Product Profiles and their relationship to the CAs they are linked to.
| View | Description | When to Use |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- |
| Product Tree View | Displays all Product Profiles as an interactive visual tree. Each product node is linked by a line to the CA node it is associated with, showing which Signing CA issues certificates for each product profile. Node colours match the CA Tree legend. | To understand which products are linked to which CAs and how the full product to CA chain flows visually. |
| Product Grid View | Displays all Product Profiles in a tabular list with columns for Product Name, Product Code, Subordinate CA, Validity, Status and Action. | To manage, filter and perform actions on individual product profiles. |
**Grid actions**
| Action | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| View | Opens the full profile in read only form, showing every subject attribute, SAN attribute and extension configured. |
| Deactivate | Withdraws the profile from use. New requests can no longer be placed against it. Requires the product create or product edit permission. |
| Export Profile | Downloads the profile as a JSON file, which can be re imported with Import Profile on the Create Product page. Not available to the Manager role. |
**How CA Tree View and Product Tree View are linked**
Together the two tree views represent the complete PKI structure within CERTInext:
• The CA Tree View shows the CA signing hierarchy: Root CA, then Intermediate CAs, then Signing CAs.
• The Product Tree View shows Product Profiles as leaf nodes attached to the Signing CA they were created under.
• A Signing CA that appears as an End Entity node in the CA Tree View appears as a parent node in the Product Tree View, with all its associated Product Profiles branching from it.
• A single Signing CA can carry multiple Product Profiles. For example, one for Server TLS and one for Client TLS, both visible as child nodes of that CA.
Tip: Use the Product Tree View as a quick reference to confirm that a newly created Product Profile has been correctly linked to the intended Signing CA. If the product does not appear under the expected CA node, verify the Subordinate CA selected in Section 1 of the profile.
### \[5] Worked Example: A Two Tier Hierarchy for Internal TLS
This example builds a Root CA, a Signing CA beneath it, and a Product Profile that issues TLS server certificates for internal hostnames. Values shown in bold are the ones to enter.
#### Part 1: The Root CA
| Step | Field | Value |
| ---- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| 1 | Type | Root CA |
| 1 | Validity | 2 Year(s), shown as 731 days |
| 2 | CA Common Name | EMUDHRA ROOT CA PKI |
| 2 | Organization Name | Emudhra |
| 2 | Country | India |
| 3 | Key Algorithm | RSA 2048 (SHA 256) |
| 4 | Include KU | Key Cert Sign and CRL Sign, Critical selected |
| 4 | Include EKU | Cleared |
| 4 | CRL Distribution, AIA, OCSP, CA Issuer, Certificate Policy, Custom Extension | All cleared |
| 5 | Additional Information | Optional, skip or add tags |
| 6 | Summary | Confirm the Extensions line reads Key Cert Sign, CRL Sign, then Create CA |
Wait for the Root CA to show status Active before continuing.
#### Part 2: The Signing CA
| Step | Field | Value |
| ---- | -------------------------- | ---------------------------------------------------------------------------------- |
| 1 | Type | Subordinate CA |
| 1 | Parent CA | EMUDHRA ROOT CA PKI |
| 1 | Purpose | Signing CA |
| 1 | CA Path Length Constraints | 0, set automatically |
| 1 | Validity | 721 Day(s) |
| 2 | CA Common Name | EMUDHRA INT CA |
| 2 | Organization Name | Emudhra |
| 2 | Country | India |
| 3 | Key Algorithm | RSA 2048 (SHA 256) |
| 4 | Include KU | Key Cert Sign and CRL Sign, Critical selected |
| 4 | Include EKU | Cleared |
| 5 | Additional Information | Optional |
| 6 | Summary | Confirm Subordinate CA, path length 0, and Key Cert Sign, CRL Sign, then Create CA |
Both CAs now show as Active, and EMUDHRA INT CA lists its Purpose as Signing CA.
#### Part 3: The Product Profile
| Section | Field | Value |
| ------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Product Name | emudhra pki trust test |
| 1 | Subordinate CA | EMUDHRA INT CA |
| 1 | Validity In Days | 10 for a renewal test, or 365 in practice |
| 1 | Key Algorithm | RSA 2048 (SHA 256) |
| 1 | Description | Internal TLS server certificates |
| 2 | Subject Attributes | Keep Common Name (2.5.4.3) only, and delete the other five rows. Request Field Domain Name, Presence Mandatory, Data Type UTF8String, Field Restriction Type Dynamic |
| 2 | SAN Attributes | Keep DNS Names, and delete the IP Address row. Request Field Domain Name, Presence Mandatory, Data Type PrintableString, Field Restriction Type Dynamic |
| 3 | Extensions, row 1 | OID KU, values Digital Signature and Key Encipherment, Critical selected |
| 3 | Extensions, row 2 | OID EKU, values Server Authentication and Client Authentication, Critical cleared |
| 3 | Extensions, rows 3 and 4 | OID CP and OID CRL, Type Default, both optional |
| 4 | Custom Extension | Leave empty |
| 5 | Advanced Settings | Select Automatically approve the certificate requests |
| | | Click Create |
***
### \[6] Downloading the Certificate Files
Everything up to this point happens inside CERTInext. The sections that follow work on files, so you need the Root CA certificate, the Signing CA certificate, and one certificate issued from the profile. All three are downloaded from the portal, and nothing is generated by hand.
#### The CA certificates
Go to Certificates > Certificate Authorities. Each row carries a Select action menu offering Download Certificate, which gives you that CA on its own, and Download Certificate Chain, which gives you that CA together with everything above it as a zip. Files are named after the CA’s Common Name.
The quickest route is the Download All Certificates button at the top right of the same page. It returns every CA in the account in a single zip, so the Root CA and the Signing CA arrive together.
#### The issued server certificate
Request a certificate from the profile you created, then open it under Certificates > Orders and choose Download. A format prompt appears with four options:
• DER encoded binary X.509 (.CER)
• Base 64 encoded X.509 (.CER)
• Base 64 encoded X.509 (.CRT)
• Zip
The three single file options give you the server certificate alone. The Zip bundles it with the issuing CA, which is the chain a server has to present.
#### Which format to choose
The format is not cosmetic. Two of the steps ahead reject a file in the wrong encoding, and the error they give does not say so clearly.
| What you are doing | Format to take | Why |
| ------------------------------ | ------------------------------------ | ------------------------------------------------------------------------------------------ |
| Chain check in Section \[8] | Either encoding | The check reads both without conversion. |
| Installing trust on Windows | Either encoding | The Windows certificate store accepts DER and Base 64 alike. |
| Installing trust on Linux | Base 64, saved with a .crt extension | The system store reads PEM only, and ignores files that do not end in .crt. |
| Building the file nginx serves | Base 64 | The certificate and the issuing CA are joined into one text file, which only works in PEM. |
Base 64 and PEM are the same thing. Open the file in a text editor. If it starts with -----BEGIN CERTIFICATE----- it is PEM and can be concatenated and read by Linux tooling. If it looks like binary, it is DER, and this command converts it:
openssl x509 -inform der -in RootCA.cer -out root-ca.pem
***
### \[7] Verifying the Chain
Run this check before you distribute anything or put a certificate on a server. Every mistake described in this guide surfaces here, and finding one now costs a minute rather than a rebuild after certificates are already deployed.
With the files from Section \[6] in hand, run the following on a Windows machine. It needs PowerShell but no administrator rights, and it performs the same evaluation a browser does.
\# Full path to the server certificate you downloaded in Section 6.\
\# Example: C:\certs\\[www.example.internal.cer](http://www.example.internal.cer)\
$leafPath = Read-Host "Path to the server certificate file"\
\
$leaf = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($leafPath)\
$ch = New-Object System.Security.Cryptography.X509Certificates.X509Chain\
$ch.ChainPolicy.RevocationMode = 'NoCheck'\
\[void]$ch.ChainPolicy.ApplicationPolicy.Add(\
(New-Object System.Security.Cryptography.Oid '1.3.6.1.5.5.7.3.1'))\
$ch.Build($leaf)\
$ch.ChainStatus | ForEach-Object { $\_.Status }
| Result | Meaning | What to do |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| True | The chain is correct. | Continue to Section \[8]. |
| UntrustedRoot | Expected until you install the Root CA. The chain itself is sound. | Continue to Section \[8]. |
| NotValidForUsage | A CA in the chain carries an Extended Key Usage that excludes Server Authentication, or a CA’s Key Usage omits Key Cert Sign. | Return to Section \[3] and reissue the CA with corrected extensions. |
***
### \[8] Distributing Trust
This is the step that makes the certificates actually work. Everything up to now happened inside CERTInext, and nothing outside it knows your PKI exists yet.
Two different jobs are involved, and they are often confused. The Root CA goes to whatever browses. The Signing CA goes to whatever serves.
| Certificate | Where it goes | Required | Why |
| ----------- | ---------------------------------------- | -------- | ------------------------------------------------------ |
| Root CA | Every client that browses the site | Yes | The trust anchor. Nothing else grants trust. |
| Signing CA | Every server that presents a certificate | Yes | So the server sends a complete chain in the handshake. |
| Signing CA | Clients | No | The server sends it. Installing it anyway is harmless. |
Before starting, confirm that Section \[7] passed, because distributing a chain that does not validate only spreads the problem.
#### Windows clients and IIS servers
Run the following in an elevated PowerShell on each machine.
\# Full path to the Root CA file. The file is named after the CA's Common Name.\
\# Example: C:\certs\EMUDHRA ROOT CA PKI.cer\
$rootPath = Read-Host "Path to the Root CA certificate file"\
\
\# Full path to the Signing CA file.\
\# Example: C:\certs\EMUDHRA INT CA.cer\
$issuingPath = Read-Host "Path to the Signing CA certificate file"\
\
\# Root CA to Trusted Root Certification Authorities\
Import-Certificate -FilePath $rootPath -CertStoreLocation Cert:\LocalMachine\Root\
\
\# Signing CA to Intermediate Certification Authorities (servers only)\
Import-Certificate -FilePath $issuingPath -CertStoreLocation Cert:\LocalMachine\CA
Restart the browser afterwards, because Chrome and Edge cache trust decisions for the session. Firefox ignores the Windows store entirely unless security.enterprise\_roots.enabled is set to true.
Tip: At scale, use Group Policy. Push both CAs through Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies: the Root CA into Trusted Root Certification Authorities, and the Signing CA into Intermediate Certification Authorities. Link the policy at the domain root so workstations are covered, not only servers. Machines that are not domain joined need Intune, configuration management, or a manual install.
#### Linux servers
On Debian and Ubuntu, install both CAs in PEM format with a .crt extension.
\# Set these to the files you copied onto this server in Section 6.\
ROOT\_CRT=/root/certs/root-ca.crt # Base 64 Root CA\
ISSUING\_CRT=/root/certs/issuing-ca.crt # Base 64 Signing CA\
LEAF\_PEM=/root/certs/server.pem # certificate issued to this server\
\
mkdir -p /usr/local/share/ca-certificates/private-pki\
cp "$ROOT\_CRT" /usr/local/share/ca-certificates/private-pki/root-ca.crt\
cp "$ISSUING\_CRT" /usr/local/share/ca-certificates/private-pki/issuing-ca.crt\
update-ca-certificates\
\
openssl verify "$LEAF\_PEM"
A successful result reads /root/certs/server.pem: OK.
Important: nginx does not use the system trust store to serve. The step above makes the machine trust your PKI as a client, and it does not change what nginx sends. nginx presents exactly what is in ssl\_certificate, so that file must hold the leaf certificate followed by the Signing CA.
\# The hostname in the certificate's SAN, and the port nginx listens on.\
SITE\_FQDN=example.internal\
SITE\_PORT=443\
\
cat "$LEAF\_PEM" "$ISSUING\_CRT" > /etc/nginx/ssl/"$SITE\_FQDN"-fullchain.pem\
\# point ssl\_certificate at that file, then:\
nginx -t && systemctl reload nginx\
\
\# confirm two certificates are sent, not one\
openssl s\_client -connect "$SITE\_FQDN":"$SITE\_PORT" -showcerts 2>/dev/null | grep "^ \*\[0-9] s:"
Finally, confirm from a client that the whole chain validates:
openssl s\_client -connect "$SITE\_FQDN":"$SITE\_PORT" 2>/dev/null | grep "Verify return code"
A result of Verify return code: 0 (ok) means the chain is complete and trusted.
#### Reaching the server by the name in the certificate
Trust is only half of what a browser checks. It also compares the name typed in the address bar against the Subject Alternative Name in the certificate, and a mismatch produces a warning that looks exactly like an untrusted root. This step is easy to miss, because the certificate, the chain and the trust store can all be perfectly correct and the padlock still refuses to appear.
You need this step when the certificate was issued to a hostname but your network has no DNS record for that hostname, so the only way to reach the machine is by its IP address. Browsing the IP fails, because the IP is not in the SAN.
On Windows, open C:\Windows\System32\drivers\etc\hosts in an editor started as Administrator, add the mapping, save, and clear the resolver cache.
\# \ \\
10.0.0.25 example.internal
ipconfig /flushdns
On Linux and macOS the file is /etc/hosts and the line is identical. No cache flush is normally needed. Afterwards, browse to rather than the IP address.
Note: A hosts entry only affects the machine it is on. It is not a network setting and it is not distributed with the Root CA certificate. Anyone else who needs to reach the site has to install the Root CA and resolve the name themselves.
For more than a few machines, add an A record for the hostname on your internal DNS server instead. That resolves the name for everyone at once and survives an address change. Adding the IP address to the certificate’s SAN is a third option, but it ties the certificate to an address and forces a reissue whenever that address changes, so the name is the better thing to certify.
### \[9] Where to Go Next
This guide covers building a private hierarchy, defining what it issues, and making it trusted. For anything beyond that:
• Deploying the certificates this hierarchy issues: see the CERTInext IIS Discovery and Provisioning guide, and the CERTInext Nginx Discovery and Provisioning guide. Once a profile exists, provisioning works the same way as for any other CA.
• Public CA connectors (emSign, AD CS, DigiCert, Sectigo): see the CERTInext Provisioning reference documentation. Use these instead of a private PKI when the names are publicly resolvable.
• Renewal and rotation of an already deployed certificate: covered in the Discovery and Provisioning guides, including the scheduled renewal triggers.
• Certificate types other than TLS server certificates: code signing, S/MIME and document signing use the same CA hierarchy but a different Product Profile, with a different Extended Key Usage.
### \[10] Frequently Asked Questions
1\. The browser still says Not secure after I installed the Root CA. What did I miss?
Check the error code behind Advanced on the warning page, because two very different problems look identical at a glance. ERR\_CERT\_AUTHORITY\_INVALID means the Root CA really is not trusted on that machine. Confirm you installed it into Trusted Root Certification Authorities under the local machine rather than the current user, and fully quit the browser rather than just closing the tab. ERR\_CERT\_COMMON\_NAME\_INVALID is not a trust problem at all: you are browsing a name that is not in the certificate’s SAN, most often an IP address. Browse the hostname instead, adding a hosts entry or a DNS record if that name does not resolve.
2\. I installed the Root CA on the server. Why do other people still get a warning?
Because the server is not the thing that decides trust. Installing the Root CA on a server helps only when that server is acting as a client to something else. Every machine that browses the site needs the Root CA in its own trust store, and that includes laptops, monitoring systems, load balancer health checks and mobile devices.
3\. The chain check returns NotValidForUsage, but every certificate looks right. Why?
Look at the CAs, not the leaf. This almost always means a CA in the chain carries an Extended Key Usage that does not include Server Authentication, which caps everything beneath it regardless of what the leaf requests. The other cause is a CA whose Key Usage omits Key Cert Sign. Both require reissuing the CA, and neither can be corrected on the certificate itself.
4\. Can I fix a wrongly configured CA without reissuing everything under it?
Sometimes. If the CA can be renewed with its existing key pair, you can reissue the CA certificate with corrected extensions and existing certificates keep validating, because the signing key has not changed and their Authority Key Identifier still matches. If the CA is rekeyed instead, every certificate beneath it must be reissued. On a test hierarchy this hardly matters. Across hundreds of servers it is the difference between a configuration change and a full re rotation.
5\. My Signing CA does not appear in the Subordinate CA list on the Create Product page. Why?
Its Purpose was saved as Intermediate CA rather than Signing CA. An Intermediate CA can only sign other CA certificates, and Purpose cannot be changed after creation. Create a new Subordinate CA with the Signing CA purpose beneath the same parent.
6\. Automated requests fail even though the profile looks correct. What is wrong?
Check the Presence column in Section 2 of the profile. The form adds six Subject Attribute rows and two SAN rows by default, all marked Mandatory. Automated requests normally carry only a domain name, so any other Mandatory attribute causes the request to be rejected. Trim the rows you do not need, set the remainder to Optional, or set them to Fixed so a value is always supplied.
7\. The site works in Chrome but not on an iPhone. What is different?
Apple platforms reject TLS server certificates that carry no Extended Key Usage at all, where Windows accepts them. Check that the leaf certificate has Server Authentication in its EKU. Separately, the Root CA must also be installed and enabled for full trust on the iOS device, which is a two step process there rather than one.
8\. Do I need the CRL and OCSP settings for a working private PKI?
Not to make certificates validate. You need them to be able to revoke a certificate in a way clients actually observe. A test hierarchy can run without them, and doing so removes a class of failure caused by unreachable endpoints. A production hierarchy should publish both, on URLs every client and server can reach, including anything in a DMZ.
9\. Should the Signing CA use the same key algorithm as the Root CA?
It does not have to, within the family restriction CERTInext enforces. A child of an RSA or ECC parent may be RSA or ECC, and a child of a PQC parent must be PQC. Matching them exactly simply removes a variable while you prove the chain works. If you do mix, keep the Root CA at least as strong as the CA beneath it, because the Root CA’s key has to outlast everything it signs.
10\. What is a Delegated CA for?
Use it when an external operator generates and holds the CA key pair, and you sign their certificate signing request under your hierarchy. The CA behaves as a Signing CA in every other respect: it issues end entity certificates directly, its path length is fixed at zero, and nothing can be created beneath it.
11\. Can I reuse a profile across accounts or environments?
Yes. Open the profile in the Products grid and use Export Profile to download it as JSON, then use Import Profile on the Create Product page in the target account. Review the Subordinate CA selection after importing, because the CA in the target account will be a different one.
### \[11] Quick Reference
#### Field behaviour by CA purpose
| Field | Root CA | Intermediate CA | Signing CA | Delegated CA |
| ---------------------------------- | -------------- | ------------------------- | ------------------------- | -------------------------------------------------------- |
| Parent CA | Not shown | Required | Required | Required |
| CA Path Length Constraints | Hidden | Dropdown 1, 2 or 3 | Fixed at 0 | Fixed at 0 |
| Key Generation | Not shown | Not shown | Not shown | System or Requester |
| Upload or Paste CSR | Not shown | Not shown | Not shown | Required when Key Generation is Requester |
| Key Store Password | Not shown | Not shown | Not shown | Required when Key Generation is System |
| Key Algorithm | All 28 options | Filtered by parent family | Filtered by parent family | Filtered by parent family, hidden when a CSR is supplied |
| OCSP Signing EKU offered | No | No | Yes | Yes |
| Appears in Product Profile CA list | No | No | Yes | Yes |
#### Rules the forms enforce
| Rule | Where |
| -------------------------------------------------------------------------------------- | ------------------------- |
| Validity must be a whole number greater than zero | Create CA, Step 1 |
| Subordinate CA validity must not exceed the parent’s remaining validity minus ten days | Create CA, Step 1 |
| A child CA’s key algorithm must be in the same family as its parent | Create CA, Step 3 |
| Include KU must be selected, with at least one Key Usage value | Create CA, Step 4 |
| If Include EKU is selected, at least one Extended Key Usage value is required | Create CA, Step 4 |
| If AIA is selected, at least one of OCSP or CA Issuer is required | Create CA, Step 4 |
| Custom CRL, OCSP, CA Issuer and CPS URLs must be well formed URLs | Create CA, Step 4 |
| Policy OIDs and CPS OIDs must be valid dotted decimal values | Create CA, Step 4 |
| The Key Profile connection test must succeed before proceeding | Create CA, Step 5 |
| At least one Key Algorithm must be selected | Create Product, Section 1 |
| Only one KU, EKU, CRL, OCSP and CA Issuer row is permitted, and up to four CP rows | Create Product, Section 3 |
| Key Cert Sign and CRL Sign are never offered on a certificate profile | Create Product, Section 3 |
#### Extension defaults on a certificate profile
| Extension | Critical by default | Recommended for Server TLS |
| ------------------------ | ------------------- | --------------------------------------------- |
| KU (Key Usage) | Selected | Digital Signature, Key Encipherment |
| EKU (Extended Key Usage) | Cleared | Server Authentication, Client Authentication |
| CP (Certificate Policy) | Not applicable | Default type, one row |
| CRL | Not applicable | Default type, only where the URL is reachable |
| OCSP | Not applicable | Default type, only where the URL is reachable |
| CA Issuer | Not applicable | Default type |
### \[12] Best Practices and Minimum Requirements
Sections \[3] and \[4] describe every field the two creation screens offer. This section answers the two questions those descriptions leave open: what is the least you must set for a hierarchy to work at all, and what should you set beyond that minimum before a hierarchy carries production traffic.
Read it before you create anything. Nothing on the CA screens is editable after creation, so a setting that is merely acceptable at creation time is a setting you live with for the life of the CA.
#### The minimum a CA certificate must carry
Four settings decide whether a CA can function. Everything else on the Extensions step improves operations, and none of it makes the difference between a chain that validates and one that does not.
| Requirement | Value | Why it is a minimum |
| ------------------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Key Usage, Key Cert Sign | Selected | RFC 5280 states that where a Key Usage extension is present, the key must not verify signatures on certificates unless Key Cert Sign is set. Without it the CA cannot sign anything, and every validator rejects the chain. |
| Key Usage, CRL Sign | Selected | The CA signs its own revocation list. Without it revocation cannot be published, and some validators treat the omission as a malformed CA. |
| Key Usage, Critical | Selected | Marking Key Usage critical is what forces a client to honour the restriction rather than ignore an extension it chooses not to parse. It is selected by default and should stay selected. |
| Extended Key Usage | Not included | An EKU on a CA is a ceiling on every certificate beneath it, not a label. Leaving Include EKU cleared keeps the hierarchy usable for any certificate purpose you later define in a Product Profile. |
Nothing else in the Key Usage list belongs on a CA. Digital Signature is the value most often added by mistake, because it reads like something a signing authority would need. It governs signatures over data rather than over certificates, it does not grant the ability to sign a certificate, and its presence on a CA is a reliable sign that the CA was configured from intuition rather than from the specification.
The remaining three settings are structural rather than cryptographic, and they are set on Step 1 rather than Step 4.
| Requirement | Value | Why it is a minimum |
| -------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purpose on the issuing CA | Signing CA | Only a Signing CA or a Delegated CA appears in the Subordinate CA list when a Product Profile is created. An Intermediate CA cannot issue leaf certificates and the purpose cannot be changed afterwards. |
| CA Path Length Constraints on the issuing CA | 0 | Set automatically for a Signing CA. It states that nothing but end entity certificates sits below this point, and it prevents the key minting further CAs if it were ever misused. |
| Validity | Shorter than the parent, by more than the renewal window | A subordinate CA cannot exceed the parent’s remaining validity minus ten days, and the form enforces that. Ten days is the floor, not a target. |
#### The minimum an end entity certificate must carry
The Product Profile decides what an issued certificate contains. For a TLS server certificate, four entries are the working minimum.
| Requirement | Where it is set | Value |
| ------------------ | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Key Usage | Section 3, OID KU | Digital Signature at minimum. Add Key Encipherment where RSA keys are permitted, so that clients negotiating RSA key transport still connect. |
| Extended Key Usage | Section 3, OID EKU | Server Authentication. Apple platforms reject a TLS server certificate that carries no Extended Key Usage at all, so omitting the extension is not a safe default even though Windows accepts it. |
| DNS Names SAN | Section 2, SAN Attributes | Present, and Mandatory for a server profile. Modern clients ignore the Common Name entirely and match the hostname against this field. |
| Validity In Days | Section 1 | Within the Signing CA’s remaining validity. A certificate cannot outlive the CA that signed it. |
Key Cert Sign and CRL Sign are deliberately absent from the Product Profile screen. An end entity certificate must never be able to sign another certificate, and CERTInext removes the possibility rather than trusting the operator to avoid it.
#### Hierarchy design
Use two tiers as the default and three only when a stated policy requires the separation. A two tier hierarchy gives you the property that matters most, which is that the Root CA key signs once and is then used only when a subordinate is renewed. A third tier adds a further CA to renew, distribute and monitor, and it buys nothing unless different Signing CAs genuinely fall under different policies.
Give each certificate purpose its own Signing CA where the purposes are operated by different teams or audited separately. A compromise or a misconfiguration is then contained to the certificates issued under that one CA, and the CA can be replaced without disturbing the rest of the estate. Where the purposes are operated by the same team, a single Signing CA carrying several Product Profiles is simpler and equally correct.
Keep the Root CA out of daily use. In CERTInext this means creating it, creating the subordinate beneath it, and then leaving it alone. Where the account supports key profiles, a Root CA whose key lives in a hardware security module is materially harder to misuse than one whose key lives in a software key store.
#### Naming
The Common Name is written permanently into the certificate and appears in every client trust store, so it should identify the CA to a person reading a chain years from now. A convention of organisation, tier and number, giving names such as Acme Corp Root CA 1 and Acme Corp Issuing CA 1, achieves that with no ambiguity.
Two failures are worth avoiding specifically. Names that differ only by a word buried in the middle force an operator to compare serial numbers to tell a root from an issuing CA. Names that carry a year or a project name age badly, because the CA outlives both.
Fill in Organization Unit, State and Locality on a production CA, where the distinguished name may be read in an audit. Skip them on a test hierarchy, where they add nothing.
#### Validity laddering
Each tier must expire comfortably after the tier below it, and the margin needs to be large enough that the lower CA can be renewed while the parent is still valid. The form enforces a ten day margin, which is the absolute floor.
| Tier | Production | Test hierarchy | Reasoning |
| ---------------------- | -------------- | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Root CA | 20 years | 2 years | Replacing a root means revisiting every trust store you have distributed to, so a root is given a lifetime that makes that a rare event. |
| Intermediate CA | 10 years | 1 year | Long enough to be stable, short enough that the algorithm choice is revisited within a decade. |
| Signing CA | 5 years | 721 days | The CA in daily use. A shorter life keeps the rotation habit alive and limits exposure if the key is compromised. |
| End entity certificate | 90 to 398 days | 10 days for a renewal test | Short lifetimes make automated renewal the normal path rather than an exception, and they cap the value of a stolen key. |
A very short leaf lifetime combined with a renewal window measured in days leaves no margin for a failed attempt to retry. Ten days is useful for exercising renewal behaviour during a test and is not a production setting.
#### Key algorithm
| Practice | Detail |
| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Treat RSA 2048 as the floor | It removes compatibility as a variable while a new hierarchy is being proven, and no current client refuses it. |
| Prefer ECC P256 for production | Smaller keys and faster handshakes at equivalent security, and support is universal on modern clients. |
| Use RSA 4096 with SHA 384 for a long lived Root CA | The root key has to outlast everything it signs, which for a 20 year root means outlasting two decades of advances in analysis. |
| Keep the parent at least as strong as the child | CERTInext restricts the child to the parent’s family. Within that family, a root weaker than the CA beneath it makes the stronger key pointless, because the chain is only as strong as its weakest signature. |
| Match the family exactly while proving a new chain | The child does not have to match the parent, but matching removes one variable from an early failure. |
| Select PQC only where the consuming application is known to support it | No shipping browser or operating system trust store validates a Dilithium, Falcon or SPHINCS+ chain today. A PQC hierarchy is a deliberate choice for a closed application, not a general upgrade. |
| Offer a narrow set on the Product Profile | Every algorithm selected in Section 1 becomes an option a requester may use. Two entries, typically RSA 2048 and ECC P256, give a genuine choice while keeping the estate predictable. |
#### Key protection
Where the key profile feature is enabled for the account, choose the profile deliberately rather than accepting the default.
| Key Profile | Appropriate use |
| ----------- | ----------------------------------------------------------------------------------------------------- |
| PKCS12 | Test hierarchies, and production hierarchies whose certificates protect low value internal services. |
| HSM | Production Root CAs and any Signing CA whose compromise would affect authentication or payment paths. |
| Crypto4A | Where the organisation already operates Crypto4A hardware and wants the CA key held there. |
Run Test Connection and confirm it succeeds before continuing. A failure at this point is a configuration problem that takes a minute to correct, and the same failure after the wizard has been submitted is a failed CA creation.
Record the Key Store Password before you leave the screen. CERTInext does not store it in a recoverable form, and there is no route back to it.
#### Extension discipline
| Setting | Root CA | Intermediate and Signing CA | Note |
| ------------------ | --------------------------------- | --------------------------------- | ------------------------------------------------------------------------------ |
| Key Usage | Key Cert Sign, CRL Sign, Critical | Key Cert Sign, CRL Sign, Critical | The only correct Key Usage on a CA at any tier. |
| Extended Key Usage | Not included | Not included | An EKU here caps every certificate beneath it. |
| CRL Distribution | Not required | Publish in production | A root is self signed, so its own CRL is never consulted when validating it. |
| AIA, OCSP | Not required | Publish in production | Real time revocation status for the certificates this CA issues. |
| CA Issuer | Not required | Publish in production | Lets a client repair an incomplete chain by downloading the issuing CA. |
| Certificate Policy | Optional | Recommended in production | Carries the policy OID and CPS pointer that an audit will look for. |
| Custom Extension | Avoid | Avoid unless mandated | Only where a named application requires the OID and is known to understand it. |
Never mark a custom extension Critical unless the receiving application explicitly requires it. A client that does not recognise a critical OID is obliged to reject the certificate, which turns an unrecognised field into a total failure rather than a harmless one.
#### Revocation
Publish a CRL URL and an OCSP URL on every CA that issues, and confirm that both are reachable from every network that will validate a certificate, including any segment behind a firewall and anything in a DMZ. An endpoint that is published but unreachable is worse than no endpoint at all, because it produces handshake delays and, under stricter client policies, outright failures.
The corollary applies to a test hierarchy. Leaving CRL, OCSP and CA Issuer off during a test removes a whole class of failure from the exercise and is a reasonable choice, provided the intermediate is distributed deliberately as described in Section \[8], since without a CA Issuer URL a client cannot repair a chain on its own.
Decide before you issue anything, not after. A CA created without these extensions cannot have them added later, and certificates already issued under it carry whatever the CA carried at the time.
#### Product Profile hygiene
| Practice | Reason |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| One profile per certificate purpose | A Server TLS profile and a Client TLS profile differ in their Extended Key Usage. Splitting them keeps each certificate limited to what it is actually for. |
| Trim the default Mandatory rows | The form adds six Subject Attribute rows and two SAN rows, all Mandatory. Automated requests normally carry only a domain name, so any other Mandatory attribute rejects the request. |
| Delete or relax the IP Address SAN row | A Mandatory IP Address SAN fails every request that carries only a hostname. |
| Set Fixed on the organisational fields | Organization Name, Country, State and Locality are the same on every certificate you issue. Fixing them guarantees a consistent identity and removes four fields the requester can get wrong. |
| Leave Common Name Dynamic, mapped to Domain Name | The host name is the one value that genuinely varies per request. |
| Use Regex where the name space is known | A pattern restricting Common Name to your own domain suffix stops a profile issuing for a name it was never intended to cover. Use the Test button to confirm the pattern before saving. |
| Select automatic approval for anything automated | ACME clients, SCEP devices and the Discovery and Provisioning flows cannot wait for a human. Manual approval belongs where issuance is a controlled, audited event. |
| Write a real Description | The field is not embedded in the certificate and exists purely so the next administrator can tell two similar profiles apart. |
| Export a proven profile | Export Profile produces JSON that Import Profile consumes, which is the reliable way to reproduce a profile in another account or environment. Check the Subordinate CA selection after importing, because the target account holds a different CA. |
#### Operational practice
Verify the chain before distributing anything. The check in Section \[7] takes a minute and surfaces every extension mistake described in this guide. Finding one there costs a rebuild of a CA that nothing yet depends on. Finding the same mistake after the Root CA has reached several hundred machines costs a redistribution.
Build the hierarchy once in a test account before building it in production. The wizards are unforgiving by design, and the cost of learning them on a hierarchy nobody trusts yet is zero.
Record what you created. Reporting Tags and Remarks are not written into the certificate and exist for exactly this purpose. A CA whose owner, scope and intended lifetime are recorded at creation is a CA that can be renewed confidently in five years by someone who was not there.
Plan the distribution of the Root CA before you create it. Group Policy, Intune or a configuration management tool covers the managed estate. Everything outside it, which usually means contractors, personal devices, appliances and anything not domain joined, needs a manual route, and the size of that population is a genuine input into whether a private PKI is the right answer for the service in question.
Review the Summary step in full. It is the last point at which a mistake costs nothing.
#### Common mistakes and what they cost
| Mistake | Symptom | Cost to correct |
| ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Digital Signature ticked on a CA instead of Key Cert Sign | The CA cannot sign. Chain validation fails with NotValidForUsage. | Reissue the CA and everything beneath it. |
| An Extended Key Usage set on a CA | Certificates below it are rejected for the purpose the EKU excludes, however correct the leaf. | Reissue the CA. Certificates already issued keep validating only if the CA is renewed with the same key pair. |
| Purpose saved as Intermediate CA on the issuing CA | The CA does not appear in the Subordinate CA list when creating a Product Profile. | Create a replacement Signing CA under the same parent. |
| Subordinate validity left at the parent’s remaining life minus ten days | No window in which to renew the subordinate while the parent is comfortably valid. | Reissue the subordinate. |
| All six Subject Attribute rows left Mandatory | Automated requests fail even though the profile looks correct. | Edit the profile. No certificate needs reissuing. |
| A CRL or OCSP URL published that clients cannot reach | Handshake delays, and failures under stricter client policies. | Reissue the CA, because CA extensions are fixed at creation. |
| Root CA installed on the server rather than on the clients | Everyone except the server operator still sees a warning. | Distribute the Root CA to the clients. Nothing needs reissuing. |
#### Pre creation checklists
Run through the relevant list immediately before clicking Create. Each item corresponds to a setting that cannot be changed afterwards.
**Root CA**
| Check | Confirmed |
| ----------------------------------------------------------------------------------- | --------- |
| Type is Root CA and no Parent CA is shown | |
| Common Name follows the naming convention and will still make sense in twenty years | |
| Organization Name and Country are correct and complete | |
| Key algorithm is at least RSA 2048, and is the family the whole hierarchy will use | |
| Validity exceeds the planned life of every CA that will sit beneath it | |
| Key Usage reads Key Cert Sign, CRL Sign, with Critical selected | |
| Include EKU is cleared | |
| Key Profile connection test has succeeded, where a key profile is used | |
| Key Store Password is recorded, where one was set | |
**Signing CA**
| Check | Confirmed |
| -------------------------------------------------------------------------------- | --------- |
| Type is Subordinate CA and the correct Parent CA is selected | |
| Purpose is Signing CA, not Intermediate CA | |
| CA Path Length Constraints shows 0 | |
| Validity leaves a comfortable renewal window before the parent expires | |
| Key algorithm sits within the parent’s family and is no stronger than the parent | |
| Key Usage reads Key Cert Sign, CRL Sign, with Critical selected | |
| Include EKU is cleared | |
| CRL, OCSP and CA Issuer URLs are set and reachable, for a production CA | |
**Product Profile**
| Check | Confirmed |
| ------------------------------------------------------------------------------------------- | --------- |
| Subordinate CA is the intended Signing CA | |
| Validity In Days is within the Signing CA’s remaining validity and matches the renewal plan | |
| Key Algorithm lists only the algorithms you intend to support | |
| Subject Attributes carry no Mandatory row that an automated request cannot supply | |
| Organisational fields are Fixed, and Common Name is Dynamic and mapped to Domain Name | |
| DNS Names SAN is present and Mandatory | |
| The IP Address SAN row is deleted or set to Optional | |
| KU row carries Digital Signature, and Key Encipherment where RSA is permitted | |
| EKU row carries Server Authentication for a TLS server profile | |
| Automatic approval matches how requests will actually arrive | |
| The profile has been exported once it is proven | |
