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

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

Organization Name (O)

Legal name of the organisation that owns and operates this CA.

Acme Corporation

Required

Organization Unit (OU)

Department or unit responsible for the CA.

IT Security

Optional

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.

Key Encipherment

RSA key transport, used by older TLS cipher suites.

Data Encipherment

Encrypting data directly with the certificate key.

Key Agreement

Establishing a shared secret, for example ECDH.

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.

Decipher Only

Restricts Key Agreement to decryption only.

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

Extended Key Usage

Not included

CRL Distribution

Not required

Recommended in production

AIA, OCSP

Not required

Recommended in production

CA Issuer

Not required

Recommended in production

Certificate Policy

Optional

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.

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

Key Usage

Restricts the cryptographic operations the certificate key may perform.

Always include

EKU

Extended Key Usage

Specifies the application purposes for which the certificate may be used.

Always include

CRL

Certificate Revocation List

The URL from which the CRL can be downloaded. Clients use this to check revocation status.

Recommended

OCSP

Online Certificate Status Protocol

The URL of the OCSP responder, for real time revocation status checking.

Recommended

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.

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

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

Type

Root CA

Validity

2 Year(s), shown as 731 days

CA Common Name

EMUDHRA ROOT CA PKI

Organization Name

Emudhra

Country

India

Key Algorithm

RSA 2048 (SHA 256)

Include KU

Key Cert Sign and CRL Sign, Critical selected

Include EKU

Cleared

CRL Distribution, AIA, OCSP, CA Issuer, Certificate Policy, Custom Extension

All cleared

Additional Information

Optional, skip or add tags

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

Type

Subordinate CA

Parent CA

EMUDHRA ROOT CA PKI

Purpose

Signing CA

CA Path Length Constraints

0, set automatically

Validity

721 Day(s)

CA Common Name

EMUDHRA INT CA

Organization Name

Emudhra

Country

India

Key Algorithm

RSA 2048 (SHA 256)

Include KU

Key Cert Sign and CRL Sign, Critical selected

Include EKU

Cleared

Additional Information

Optional

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

Product Name

emudhra pki trust test

Subordinate CA

EMUDHRA INT CA

Validity In Days

10 for a renewal test, or 365 in practice

Key Algorithm

RSA 2048 (SHA 256)

Description

Internal TLS server certificates

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

SAN Attributes

Keep DNS Names, and delete the IP Address row. Request Field Domain Name, Presence Mandatory, Data Type PrintableString, Field Restriction Type Dynamic

Extensions, row 1

OID KU, values Digital Signature and Key Encipherment, Critical selected

Extensions, row 2

OID EKU, values Server Authentication and Client Authentication, Critical cleared

Extensions, rows 3 and 4

OID CP and OID CRL, Type Default, both optional

Custom Extension

Leave empty

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 $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

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.

# <IP address of the server> <hostname from the certificate SAN> 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 https://example.internal 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

CA Path Length Constraints

Hidden

Dropdown 1, 2 or 3

Fixed at 0

Key Generation

Not shown

System or Requester

Upload or Paste CSR

Not shown

Required when Key Generation is Requester

Key Store Password

Not shown

Required when Key Generation is System

Key Algorithm

All 28 options

Filtered by parent family

Filtered by parent family, hidden when a CSR is supplied

OCSP Signing EKU offered

Yes

Appears in Product Profile CA list

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

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

The only correct Key Usage on a CA at any tier.

Extended Key Usage

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

PreviousSupported Devices and Platforms

NextSupported Public Certifying Authorities

Last updated 1 month ago

[1] Introduction and Overview

What a private PKI is

CA Hierarchy

The single rule that prevents most failures

[2] Before You Begin

Permissions and access

Decisions to make first

Order of work

[3] Creating a Private Certificate Authority

Navigation Path

Step 1: Create Private CA

Step 2: Configure CA Information

Step 3: Key Information

Step 4: Extensions

Step 5: Additional Information (Optional)

Step 6: Summary and Payment

Viewing the CA Hierarchy

[4] Creating a Product Profile

Navigation Path

Section 1: Configure Product

Section 2: Setup Profile

Section 3: Extensions

Section 4: Custom Extension

Section 5: Advanced Settings (Optional)

Finishing and creating the profile

Viewing the Product Hierarchy

[5] Worked Example: A Two Tier Hierarchy for Internal TLS

Part 1: The Root CA

Part 2: The Signing CA

Part 3: The Product Profile

[6] Downloading the Certificate Files

The CA certificates

The issued server certificate

Which format to choose

[7] Verifying the Chain

[8] Distributing Trust

Windows clients and IIS servers

Linux servers

Reaching the server by the name in the certificate

[9] Where to Go Next

[10] Frequently Asked Questions

[11] Quick Reference

Field behaviour by CA purpose

Rules the forms enforce

Extension defaults on a certificate profile

[12] Best Practices and Minimum Requirements

The minimum a CA certificate must carry

The minimum an end entity certificate must carry

Hierarchy design

Naming

Validity laddering

Key algorithm

Key protection

Extension discipline

Revocation

Product Profile hygiene

Operational practice

Common mistakes and what they cost

Pre creation checklists