# Developer Platform Welcome to your team’s developer platform

Welcome to the CERTInext Support

Centralized hub for everything related to CERTInext – documentation, APIs, and release updates.

Sign up Log in

User GuideYour guide to using CERTInext
Explore documentation to set up, manage, and automate certificate lifecycle for public and private trust. Step-by-step guides help enterprises, resellers, and individuals streamline operations with confidence.		Read Documentation/spaces/NvYrWQTJxwzOAGkanyHW/files/LHIOZGoI6dPF36TuRaxH
API DocumentationAutomate with powerful APIs
Browse, test, and integrate CERTInext APIs to connect CLM with your applications. Includes endpoint details, request/response examples, and authentication steps using both REST and ACME API endpoints		Explore APIs/spaces/xBwAIBM7JEDMRQJSV2xo/pages/trLwwmumlaofzMKwR3fr/files/IaUMODRBBSBL8eUaPX09
ChangeLogsStay updated with the latest releases
Track new features, bug fixes, and enhancements in CERTInext. Stay current with release versions, updates to the Bot, integrations, and platform improvements.		View Changelogs/spaces/O1d18S4qAIBTLIwIojhn/pages/xSKACgaFjsHdWkvrL7EZ/files/ebMoLMpZFyLqpzByuzrk
Get started with CERTInext in 5 minutes

  • Quick start guides for new users.
  • Account setup, first certificate issuance, and Bot activation in minutes.
  • Configuring Certificate Templates for various use cases
Quick Start Guide/spaces/NvYrWQTJxwzOAGkanyHW/pages/qhGkXHZNNy2MvX78hZ2O
Deployment Guides for On-Prem Installation

  • Steps to deploy CERTInext in on-prem environments
  • Configuring it for running Public Trust and Private Trust Use cases
  • Using APIs in On-prem setup

Installation Guides/spaces/NvYrWQTJxwzOAGkanyHW/pages/oIDeyZE0bsqScafQUsy0
# CERTInext Overview CERTInext is eMudhra’s enterprise-grade Certificate Lifecycle Management (CLM) platform designed to centrally discover, issue, monitor, automate, and renew digital certificates across on-premises, cloud, and hybrid environments. It supports public and private PKI use cases, integrates with leading CAs and enterprise systems, and automates certificate workflows across applications, devices, users, and workloads to reduce outages and security risks caused by expired or unmanaged certificates. CERTInext provides real-time visibility, policy-based controls, role-based access, audit trails, and standards-based integrations, enabling organizations to maintain cryptographic hygiene, meet compliance requirements, and scale trust operations efficiently as part of their broader digital-trust strategy. ### Getting Started
What is CERTInextCERTInext is an enterprise certificate lifecycle management platform that centralizes discovery, issuance, renewal, automation, and governance of digital certificates across hybrid environmentshttps://docs.certinext.io/documentation/getting-started/what-is-certinext
Key Concepts and TerminologyCERTInext key concepts and terminology define the core components of certificate lifecycle management, including certificates, CAs, PKI, discovery, provisioning, renewal, automation, and governance across hybrid environments./pages/DXu8aHO4n52mgJCoKNQM
CERTInext Architecture OverviewCERTInext architecture outlines how Bots, APIs, CA connectors, and cloud services work together to centralize discovery, issuance, renewal, automation, and governance of digital certificates across hybrid environments./pages/EIdDhI6PB4uGA0P9DH0b
User Roles and Access ModelExplains role-based access control in CERTInext, defining permissions, approvals, and separation of duties for administrators, operators, and auditors./pages/PoFTR2G7t6YjpktymN33
Supported Use CasesOutlines common CERTInext use cases including TLS management, DevOps automation, cloud workloads, internal PKI, and certificate governance at scale/pages/yeyalr59c1fVChQnOepZ
Quick Start GuideGuides new users through initial setup steps to access CERTInext, discover certificates, configure alerts, and begin managing certificate lifecycles quickly./pages/qhGkXHZNNy2MvX78hZ2O
Capabilities OverviewProvides a summary of CERTInext capabilities including certificate discovery, inventory, issuance, renewal, policy enforcement, monitoring, reporting, and automation across enterprise environments./pages/8ktgzFuh8b8N5Hcu1SSv
Navigating the interfaceExplains the main navigation structure, menus, and workflows, enabling users to quickly locate features and perform common certificate management tasks./pages/Vq2wUwJRhjb7QaR0ljwm
Dashboard and WidgetsThe dashboard presents real-time visibility into certificate health, expirations, risks, and compliance using configurable widgets tailored to different operational roles./pages/mBVU3XpbCe55b7iTipwM
Global SettingsCovers system-wide configuration options such as notifications, integrations, security policies, and default behaviors that govern how CERTInext operates across the organization./pages/fpkW1oVWqIyik3OacIm6
### Platform
Certificate Lifecycle ManagementCovers end-to-end management of certificates including discovery, inventory, issuance, renewal, replacement, revocation, and retirement across on-premises, cloud, and hybrid environments./pages/aOjs4gC5WzIpifbjuGsn
Automation and DevOpsExplains how CERTInext automates certificate workflows using protocols, APIs, agents, and integrations with DevOps tools, CI/CD pipelines, containers, and cloud platforms.https://docs.certinext.io/documentation/automation-and-devops/automation-overview
Certificate Authorities and Trust StoresDescribes managing integrations with public and private certificate authorities, internal PKI, root and intermediate certificates, and enterprise trust store configurations.https://docs.certinext.io/documentation/certificate-authorities-and-trust-stores/supported-public-certifying-authorities
Policies, Governance and ComplianceDetails how CertiNext enforces certificate policies, cryptographic standards, ownership controls, audit trails, and governance requirements to support security and regulatory compliance.https://docs.certinext.io/documentation/policies-governance-and-compliance/policy-framework-overview
User Roles and Access ControlExplains how role-based access control defines permissions, approvals, and separation of duties across administrators, operators, DevOps teams, and auditors.https://docs.certinext.io/documentation/getting-started/user-roles-and-access-model
Monitoring, Alerts and ReportingProvides visibility into certificate health, expirations, and policy violations through dashboards, alerts, notifications, and reports to help prevent outages and security risks.https://docs.certinext.io/documentation/monitoring-alerts-and-reporting/monitoring-overview
Deployment and OperationsCovers deployment models, scalability, high availability, backup, upgrades, and operational best practices for running CertiNext reliably in enterprise environments.https://docs.certinext.io/documentation/deployment-and-operations/deployment-models-on-prem-cloud
Security ArchitectureOutlines CertiNext’s security design including data protection, encryption, secure communications, key handling, access controls, and vulnerability management practices.https://docs.certinext.io/documentation/security-architecture/certinext-security-model
Troubleshooting and FAQsOffers guidance on resolving common issues related to discovery, automation, integrations, alerts, and connectivity, along with frequently asked questions.https://docs.certinext.io/documentation/troubleshooting-and-faqs/general-troubleshooting-approach
Support and ResourcesExplains how to access support, raise tickets, understand SLAs, collect logs, and use documentation, training, and additional enablement resources.https://docs.certinext.io/documentation/support-and-resources/raising-a-support-ticket
# What is CERTInext Certificate sprawl is a real operational problem. As validity periods shorten industry-wide and as security models shift toward Zero Trust, the volume, diversity, and velocity of digital certificates has grown to a point where manual management simply breaks down. CERTInext is an enterprise Certificate Lifecycle Management (CLM) platform built to handle that scale - giving you centralized visibility, automation, and policy-driven control across your entire certificate estate. Worth noting: the pressure isn't just about volume. Shorter certificate validity periods mean issuance, renewal, and replacement happen far more frequently than they did even a few years ago. At the same time, certificates have moved well beyond web servers. You'll find them in cloud-native applications, APIs, microservices, IoT devices, connected vehicles, and electric mobility platforms. Trying to track all of that with spreadsheets, ad-hoc scripts, or disconnected tools is how outages happen - a forgotten Apache cert expires over a weekend, and suddenly a customer-facing service goes dark. CERTInext addresses this directly. It gives you a single place to discover certificates wherever they exist, automate issuance and renewal, enforce security and compliance standards, and extend consistent management across servers, applications, devices, IoT deployments, and emerging digital ecosystems. # Key Concepts and Terminology Before you can get the most out of CERTInext, it helps to have a solid grounding in the terminology the platform uses - not just the obvious terms like "certificate" and "CA," but the operational concepts that shape how things actually work day to day. This section covers the foundational vocabulary: digital certificates, Certificate Authorities (CAs), private and public PKI, Certificate Signing Requests (CSRs), domain validation, discovery, provisioning, renewal, revocation, and automation workflows. It also walks through the operational components you'll encounter in the platform - Bots, scan targets, CA connectors, key stores, and trust chains - and explains the distinction between discovery and provisioning, which trips up a lot of new users. Getting this vocabulary straight matters because it affects how you configure integrations, read dashboard metrics, apply lifecycle controls, and troubleshoot when something goes wrong. It also gives technical, operational, and compliance teams a shared language, which is often the first thing that breaks down when certificate incidents occur. Whether you're connecting to public CAs like emSign and DigiCert, working with private CAs such as emCA or AD CS, or managing cloud and container environments, consistent terminology is what keeps policy enforcement coherent across the board. # Public Key Infrastructure Public Key Infrastructure (PKI) is the foundational framework behind secure digital communication, identity validation, and trusted information exchange across systems, networks, and applications. At its core, PKI combines cryptographic key pairs (public and private), digital certificates, and a defined set of policies, procedures, hardware, and software to build and manage digital trust. A digital certificate, within this framework, binds a public key to a specific entity's identity - a server, device, application, or user - so that anyone communicating with that entity can verify who they're actually talking to and establish a secure session. In CERTInext, PKI isn't just theoretical background - it's the enterprise trust backbone that all certificate lifecycle operations are built on. It governs how certificates are created, stored, distributed, used, revoked, and validated within your organization. PKI supports secure authentication, encryption, and integrity for everything from HTTPS/TLS connections to machine identities in IoT, API ecosystems, mobile apps, and internal platforms. A solid PKI includes several components. CERTInext orchestrates all of them: * Certificate Authorities (CAs) - Trusted entities that issue and sign digital certificates after validating identity and policy requirements. * Registration Authorities (RAs) - Services that validate identities and bind them to cryptographic keys, verifying request data before passing it on to CAs. * Trust Anchors (Root CAs) - The top of the trust hierarchy, used to validate all certificate chains. These are typically pre-distributed to the target trust community or embedded in the OS or device firmware. * Certificate Repositories, CRLs, and OCSP - Data stores and services that track certificate status and handle revocation information. * Certificate Policies and Profiles - Rules that govern certificate formats, acceptable algorithms, permitted usage, and lifecycle standards. The tricky part here is that PKI isn't a single product you deploy once - it's an architecture that spans people, processes, and systems. CERTInext builds on these PKI elements to deliver enterprise-grade certificate lifecycle management, making secure, automated, and policy-driven operations practical across hybrid environments. # Certificate Lifecycle Management Certificate Lifecycle Management (CLM) covers the end-to-end management of digital certificates - from the moment they're requested or discovered, through issuance, deployment, renewal, replacement, revocation, and eventual retirement. Certificates are time-bound security assets. Failures at any stage of their lifecycle, especially expiration or misconfiguration, can cause outages, security incidents, or compliance gaps. The volume and velocity of certificates has increased significantly in recent years, driven by shorter validity periods, cloud adoption, DevOps automation, Zero Trust architectures, and the rapid growth of machine identities. Managing that at scale with spreadsheets, ticketing systems, or calendar reminders doesn't hold up - and it introduces real operational risk. CLM gives you a structured, automated approach to keeping certificates valid, trusted, and compliant throughout their lifecycle. #### CLM in the Context of CERTInext CERTInext provides centralized, policy-driven Certificate Lifecycle Management across both public and private trust environments. It acts as a single system of record for all certificates, regardless of where they were issued or deployed, and automates lifecycle operations to cut down on manual effort and human error. Key CLM capabilities in CERTInext include: * **Discovery and Inventory** - Automatically discover certificates across networks, cloud environments, applications, devices, and APIs, and maintain a continuously updated inventory with complete metadata. * **Issuance and Provisioning** - Standardize and automate certificate requests and issuance from integrated Certificate Authorities, ensuring certificates are provisioned according to defined profiles and policies. * **Deployment and Installation** - Track where certificates are deployed, and support automated or assisted provisioning to endpoints, applications, and devices. * **Monitoring and Alerting** - Continuously monitor certificate health, expiration timelines, trust chains, and cryptographic strength, with proactive alerts to prevent service disruption. * **Renewal and Replacement** - Automatically renew or replace certificates before expiry, including re-provisioning to endpoints, to keep operations running without interruption. * **Revocation and Decommissioning** - Revoke certificates that are compromised, no longer needed, or out of policy, and ensure clean lifecycle closure. * **Governance and Audit** - Enforce cryptographic policies, approval workflows, and role-based access, with full audit trails and reports to support compliance and security reviews. For instance, if a TLS certificate on a load balancer is 30 days from expiry, CERTInext can trigger an automated renewal workflow, re-provision the new certificate to the endpoint, and log the entire process - no calendar reminder, no manual ticket, no last-minute scramble. #### Why CLM Matters Effective CLM is critical to maintaining service availability, security posture, and compliance wherever certificates are used - servers, applications, users, devices, IoT platforms, and machine-to-machine communication. Automating and governing the full lifecycle shifts you from reactive firefighting to proactive, scalable, resilient trust operations. # Certificate Types Not all certificates are interchangeable. Each type carries distinct usage requirements, validation standards, and lifecycle characteristics - and CERTInext tracks and automates all of them. Here's what the platform manages: * **TLS/SSL Certificates** - Secure transport for web applications, APIs, microservices, load balancers, and internal services. These are probably the most common type you'll encounter, and they're subject to the industry-wide validity period reductions that have driven much of the urgency around CLM. * **Client and Device Certificates** - Identify and authenticate users, machines, servers, and network devices for secure access and mutual TLS communication. For instance, a device certificate on a corporate laptop can be used to enforce network access policy without relying on username/password alone. * **Code Signing Certificates** - Ensure software integrity and verify publisher identity for applications, scripts, drivers, and software updates. Without these, there's no reliable way to confirm that the binary a user is running hasn't been tampered with after the developer shipped it. * **Document Signing Certificates** - Support digital signing of PDFs, contracts, invoices, and official records, providing authenticity, integrity, and non-repudiation. * **IoT and Embedded Certificates** - Provide secure identity for internet-connected devices, sensors, gateways, and industrial endpoints. These typically require high-volume, low-touch issuance workflows, since you're often provisioning thousands of devices at a time. * **Private Certificates (Any Profile)** - Support internally issued certificates for enterprise applications, internal domains, DevOps environments, VPNs, and custom trust models under private PKI policies. * **Private CA Hierarchies** - Manage full private PKI hierarchies, including Root and Intermediate CAs. This gives you controlled issuance, policy enforcement, key management, and trust chain administration across internal environments. Each of these types has its own lifecycle requirements. A TLS certificate might have a 90-day validity window today, while a code signing certificate or device certificate operates on a very different schedule. CERTInext tracks those differences and applies the appropriate automation and governance to each. # Key Management (Cryptographic Key Lifecycle) Key Lifecycle Management (KLM) is the end-to-end management of cryptographic keys throughout their entire lifespan - from secure generation and storage through usage, rotation, archival, and destruction. Cryptographic keys are the actual security assets underneath digital certificates, encryption, authentication, and digital signatures. If those keys are weak, over-exposed, or poorly managed, the security guarantees that certificates and PKI are supposed to provide collapse at the foundation. As enterprises scale up Zero Trust architectures, cloud platforms, DevOps automation, and machine identities, the number of cryptographic keys in active use has grown rapidly. Fragmented or manual key handling creates risk: key compromise, compliance failures, and operational breakdowns. KLM gives you a structured, auditable way to maintain cryptographic hygiene across environments. #### Key Lifecycle Stages Key Lifecycle Management typically covers these stages: * **Key Generation** - Keys are generated using approved algorithms and key lengths, often inside secure environments such as Hardware Security Modules (HSMs) or cloud key management services, specifically to prevent exposure during generation. * **Key Storage and Protection** - Private keys must be stored securely, protected against unauthorized access, extraction, or tampering. That typically means HSMs, secure enclaves, or encrypted key stores, depending on your environment. * **Key Usage** - Keys are used for defined purposes: certificate signing, TLS handshakes, data encryption, digital signatures, or device authentication. Usage restrictions exist so keys aren't repurposed beyond their intended scope. * **Key Rotation and Renewal** - Keys are periodically rotated based on policy, cryptographic best practices, or compliance requirements. Rotating keys limits the blast radius if a key is ever compromised. * **Key Backup and Recovery** - Secure backup mechanisms ensure keys can be recovered after a system failure, without sacrificing confidentiality or integrity. * **Key Revocation and Destruction** - Keys that are compromised, expired, or no longer needed are revoked and securely destroyed to prevent future misuse. #### Key Lifecycle Management in CERTInext In CERTInext, KLM is closely aligned with Certificate Lifecycle Management and PKI governance. The platform gives you visibility and control over cryptographic keys associated with certificates across public and private trust environments. You can track key metadata - including age, algorithm, size, and usage - and use that data to identify weak, non-compliant, or long-lived keys. CERTInext also lets you enforce key rotation and cryptographic policies, align key usage with certificate profiles and trust models, and support audits with traceable key lifecycle records.
#### Common Uses of Cryptographic Keys Cryptographic keys managed through KLM appear across a wide range of enterprise and emerging use cases: * **TLS and Secure Communications** - Keys underpin encrypted communication between servers, applications, APIs, and services. * **Digital Certificates and PKI** - Keys are what make certificate issuance, validation, and trust chains actually work for users, devices, and services. * **Machine and Device Identity** - Keys authenticate devices, IoT endpoints, industrial systems, and connected vehicles. * **Data Encryption** - Keys protect sensitive data at rest and in transit across databases, storage systems, and cloud platforms. * **Digital Signatures and Code Signing** - Keys provide integrity, authenticity, and non-repudiation for software, documents, and transactions. * **Zero Trust Security Models** - Keys supply the strong cryptographic identity that continuous authentication and authorization of users and machines depends on. # Certificate Profiles and Metadata Certificate profiles and certificate metadata define how digital certificates are created, interpreted, governed, and managed throughout their lifecycle. Together, they provide the structure and context that make automated issuance, policy enforcement, and operational visibility possible at scale. When certificates are issued manually or inconsistently - different key sizes here, different algorithms there, validity periods all over the place - you end up with security gaps and a support burden that compounds over time. Profiles and metadata address that by standardizing how certificates are requested, issued, and governed across the organization. #### Certificate Profiles A certificate profile is a predefined template that specifies how a certificate should be configured and used. It ensures consistent issuance that aligns with your organization's security and compliance requirements. In CERTInext, certificate profiles typically define: * Certificate type (e.g., TLS, client authentication, device, code signing) * Key algorithm and key size (e.g., RSA 2048, ECC P-256, or post-quantum algorithms such as CRYSTALS-Dilithium or Kyber) * Validity period aligned to policy and CA constraints * Allowed key usage and extended key usage (e.g., server authentication, client authentication) * Subject and Subject Alternative Name (SAN) rules - for instance, the domain name protected by a TLS certificate or the email address on an S/MIME certificate * Issuing CA and trust model (public or private) * Approval and workflow requirements Using profiles means certificates are issued correctly the first time. That cuts down on manual rework and reduces misconfiguration - both of which are common sources of certificate-related incidents. #### Certificate Metadata Certificate metadata is the descriptive and operational information attached to a certificate once it's been issued or discovered. This is what gives you visibility into where a certificate lives, how it was issued, and what state it's in right now. In CERTInext, certificate metadata commonly includes: * Certificate subject and SANs * Issuer, trust anchor, and certificate chain * Validity period and expiration date * Associated private key attributes (algorithm, size, age) * Deployment location (server, application, device, endpoint) * Lifecycle status (active, expiring, revoked, replaced) * Policy compliance indicators * Ownership and responsibility (team, application, business unit) This metadata is what powers accurate inventory management, proactive monitoring, and informed decision-making across security, operations, and compliance teams. Without it, you're flying blind. #### Why Profiles and Metadata Matter * Standardization - Profiles enforce consistent cryptographic and usage standards across teams and environments. * Automation - Metadata makes automated monitoring, renewal, replacement, and reporting possible. * Governance - Profiles align certificates with organizational policies; metadata supports audits and compliance reviews. * Risk Reduction - Visibility into certificate attributes helps you spot weak algorithms, long-lived certificates, or misconfigured deployments before they become incidents. #### Certificate Profiles and Metadata in CERTInext CERTInext uses certificate profiles as the policy backbone for automated issuance and renewal, while metadata provides continuous visibility across the certificate estate. Together, they shift certificate management from ad-hoc handling to controlled, policy-driven, auditable operations - supporting modern use cases across servers, applications, devices, IoT platforms, and Zero Trust architectures. # Public Trust and Private Trust Digital certificates don't operate in a vacuum - they operate within defined trust models that determine where and how a certificate is actually trusted. The two primary trust models you'll encounter in enterprise environments are public trust and private trust. Getting this distinction right is foundational to designing a certificate strategy that's both secure and scalable. #### Public Trust Public trust covers certificates issued by Certificate Authorities whose root certificates are embedded in major browsers, operating systems, and devices. Because of that pre-distribution, certificates issued under public trust are automatically recognized by external users and systems - no additional configuration required on the relying party's side. Publicly trusted certificates are typically used for internet-facing websites and applications (HTTPS/TLS), public APIs and services, and external customer- or partner-facing platforms. CERTInext supports public trust certificates through integrations with public CAs and through its own public trust infrastructure. Specifically, CERTInext uses the emSign public trust anchor, which is owned and operated by CERTInext's group entities and is trusted across major global browsers and operating systems. This means you can issue and manage publicly trusted certificates within CERTInext while maintaining consistent lifecycle governance and automation - rather than treating public certificates as a separate, disconnected concern. #### Private Trust Private trust refers to certificates issued by internal or enterprise-controlled Certificate Authorities. These certificates are trusted only within environments where the corresponding root or intermediate certificates have been explicitly installed. They're not visible or trusted by the public internet. Private trust certificates are commonly used for internal applications and services, machine-to-machine and service-to-service communication, device and workload authentication, and IoT or industrial closed-network environments. The tricky part here is distribution. Private trust gives you greater control over certificate policies, lifecycles, and trust boundaries - but it requires careful management to ensure trust anchors are properly deployed and maintained. A private CA root that isn't distributed to all the right endpoints creates trust failures that can be surprisingly hard to diagnose. #### Managing Public and Private Trust in CERTInext CERTInext manages both public and private trust models from a single platform. It provides centralized visibility into certificates issued under different trust anchors, applies consistent policies across trust domains, and automates lifecycle operations regardless of where certificates were issued or deployed. By supporting public trust (including the emSign trust anchor) alongside private trust, you can align certificate usage with security and exposure requirements, reduce operational complexity across mixed trust environments, and enforce consistent governance and auditability - without having to run separate tooling for each trust model. # Certificate Authorities and Trust Anchors Certificate Authorities (CAs) are the foundational entities within PKI that issue digital certificates. A certificate binds a public key to an identity - a server, user, or device - and is digitally signed by the CA to assert that binding. In CERTInext, integrating with one or more CAs, whether public or private, is what makes automated issuance, renewal, and lifecycle enforcement possible across your certificate estate. CAs operate under defined standards, primarily X.509 v3, and follow industry guidelines from bodies like the CA/Browser Forum. Those guidelines govern the requirements for TLS, code signing, S/MIME, and machine identity certificates, ensuring relying parties can actually trust what they receive. A **Trust Anchor** is the root of trust in a PKI - the point from which all certificate validation begins. Technically, it's a trusted certificate, usually a self-signed root CA certificate, that has been pre-installed or explicitly trusted by a system. When a client (a browser, operating system, or application) receives a digital certificate, it validates it by constructing a chain from the presented certificate through one or more intermediate CA certificates up to a trust anchor. If that chain terminates at a root the system already trusts, the certificate is accepted. If it doesn't, trust fails - and from the end user's perspective, that usually means a hard error. In CERTInext, trust anchors play a key role in validating certificates from both external public CAs and internal private CAs. Public trust anchors are distributed through operating systems and browsers, covering internet-facing services. Private trust anchors - internal root CAs - are explicitly defined within an organization to establish trust within controlled environments. CERTInext lets administrators import, manage, and govern trust anchors and their associated intermediate CA certificates, ensuring certificate validation and policy enforcement align with organizational governance and compliance requirements. **Why This Matters in CERTInext** • Validation Foundation - Trust anchors underpin every certificate validation process. Without a trusted root in the chain, a correctly issued certificate still won't be trusted. • Automated Trust Path Management - CERTInext automates the assembly and validation of certificate chains up to configured trust anchors, reducing the kind of manual configuration errors that create hard-to-diagnose trust failures. • Governance and Compliance - Centralized trust anchor management ensures that only authorized roots and intermediates are in use, which is what makes policy enforcement and audit requirements enforceable in practice. This architecture supports robust, scalable trust management - whether certificates are used for public HTTPS services, internal service authentication, IoT device identity, or machine-to-machine communications. # Discovery and Inventory Discovery and Inventory are the starting point for effective Certificate Lifecycle Management - and they're often where organizations realize just how much they didn't know about their own certificate estate. You can't secure or govern what you can't see. Certificates get deployed across servers, cloud services, load balancers, containers, applications, devices, APIs, and code repositories, frequently without centralized oversight. Unknown, unmanaged, or forgotten certificates are where operational and security risk accumulates. A cert issued three years ago by a developer who has since left the company, sitting on a forgotten load balancer - that's a real scenario, and it's why discovery matters. CERTInext addresses this with automated discovery mechanisms and a centralized certificate inventory that delivers continuous visibility across the entire certificate landscape. #### Certificate Discovery Discovery is the process of identifying certificates and associated keys wherever they exist, regardless of how or when they were issued. CERTInext performs discovery across heterogeneous environments to locate certificates that may have been provisioned manually, by legacy systems, or entirely outside standard workflows. CERTInext discovery capabilities include: • Network-based discovery of TLS certificates on servers, endpoints, and load balancers • Discovery across cloud and hybrid environments • Identification of certificates deployed in applications, middleware, and APIs • Detection of certificates on devices, appliances, and IoT environments • Correlation of discovered certificates with their issuing Certificate Authorities Discovery can run continuously or on-demand, so visibility stays accurate as environments change rather than becoming a stale snapshot. #### Certificate Inventory The inventory is the centralized, authoritative record of all certificates known to CERTInext. Each discovered or issued certificate is cataloged with complete contextual and operational metadata, creating a single system of record for certificate management. The inventory typically includes: • Certificate type and usage • Issuer, trust anchor, and certificate chain • Validity period and expiration timelines • Key algorithm, size, and age • Deployment location and associated endpoints • Lifecycle status (active, expiring, expired, revoked) • Ownership and responsible team or application • Policy and compliance indicators This unified inventory replaces spreadsheets and fragmented tools with consistent, actionable data that actually stays current. #### Why Discovery and Inventory Matter • Risk Reduction - Identify unknown or unmanaged certificates before they expire or become vulnerable. • Operational Efficiency - Accurate inventory data is what makes automated renewal, replacement, and remediation workflows reliable. • Governance and Compliance - Support audits and policy enforcement with complete, accurate records rather than best-guess estimates. • Scalability - Manage certificates across thousands of endpoints and multiple trust models without relying on manual tracking. In CERTInext, discovery continuously feeds the centralized inventory, keeping certificate data current and actionable. For instance, if a new server is spun up with a self-signed certificate that was never registered in any tool, continuous network-based discovery will surface it - giving your team a chance to remediate before it becomes a compliance finding or an expiry incident. # Protocols for Enrolment and Automation Standardized protocols sit at the heart of any serious certificate operation. Manual certificate requests and installations simply don't hold up at the speed, reliability, or security level that cloud-native, DevOps, Zero Trust, and machine-identity environments demand. Enrollment and automation protocols give systems, applications, and devices a consistent, interoperable path to obtain and maintain certificates - no human in the loop required. CERTInext supports the industry-standard enrollment and automation protocols that make policy-driven, scalable certificate lifecycle operations possible across diverse environments. #### **Certificate Enrollment Protocols** **Enrollment protocols** define how a system or device requests a certificate and how a Certificate Authority validates and issues it. **ACME (Automated Certificate Management Environment)** ACME is the go-to protocol for automated TLS certificate issuance and renewal. It lets systems request, validate, and renew certificates automatically - no manual approval needed - which makes it a natural fit for web servers, cloud workloads, and DevOps pipelines. For instance, if your Apache cert expires at 2 a.m., an ACME-enabled workflow can renew and deploy it without waking anyone up. CERTInext extends standard ACME support with ACME Renewal Information (ARI), which lets clients receive CA-provided renewal timing guidance. That means more intelligent, CA-aligned renewal scheduling, fewer renewal spikes, and better operational resilience at scale. **SCEP (Simple Certificate Enrollment Protocol)** SCEP is widely used for device and network equipment enrollment - routers, switches, VPN devices, enterprise-managed endpoints. It's been around a long time, and it's still the protocol most network gear speaks natively. **EST (Enrollment over Secure Transport)** EST improves on SCEP with stronger authentication and secure transport. You'll typically see it in enterprise and IoT environments where higher identity assurance is required, and where SCEP's older design leaves gaps. **CMP / CMPv2 (Certificate Management Protocol)** CMP provides a comprehensive framework covering enrollment, renewal, and revocation. It's commonly chosen for large-scale enterprise PKI deployments where a full-featured, standards-based management protocol is needed. **CSR-Based Enrollment** Certificate Signing Request (CSR) workflows let systems generate key pairs locally and submit CSRs for approval and issuance. This supports both fully automated pipelines and approval-driven scenarios where a human review is required before issuance. #### **Automation and Lifecycle Protocols** Beyond initial enrollment, automation protocols keep certificates valid and compliant throughout their lives. CERTInext uses these protocols and interfaces to automatically renew certificates before expiration, replace certificates when policies change, re-provision certificates to endpoints without service disruption, and handle revocation and re-issuance when a compromise occurs. Worth noting: this isn't just about convenience. Reducing manual intervention is a security improvement - fewer humans touching cryptographic material means fewer opportunities for error or mishandling. #### Why Protocol-Based Automation Matters Using standardized protocols for enrollment and automation gives you real operational advantages. Scalability means you can support thousands or millions of certificates without manual handling. Interoperability means the same protocols work across vendors, platforms, and environments. Security comes from enforcing consistent cryptographic practices sand eliminating the human error that manual processes introduce. Operational resilience comes from not getting caught off guard by an expired cert that takes down a service. #### Protocols in the Context of CERTInext CERTInext acts as the orchestration layer - managing enrollment protocols, applying certificate profiles and policies, and integrating with Certificate Authorities and endpoints. By supporting open, widely adopted standards, you're not locked into proprietary mechanisms. Certificate operations remain consistent whether you're managing servers, applications, devices, IoT platforms, or DevOps workflows. # Policy and Governance Policy and governance provide the structural and assurance framework that ensures certificates and cryptographic keys are issued, managed, and used in a secure, compliant, and auditable way. As certificates become central to identity, access control, and Zero Trust security models, strong governance isn't optional - it defines *who can issue trust, under what conditions, and with what level of assurance*. #### Certificate Policies (CP) and Certification Practice Statements (CPS) Two foundational documents underpin certificate governance: **Certificate Policy (CP)** A CP defines *what* assurance level a certificate provides and *for what purpose* it may be used. It sets out requirements like identity validation strength, key protection expectations, certificate usage constraints, and lifecycle rules. Think of it as the contract that tells relying parties what they're trusting. **Certification Practice Statement (CPS)** A CPS describes *how* a Certificate Authority implements and enforces the requirements in the CP. It documents operational practices including identity verification, key management, certificate issuance, revocation, audits, and incident handling. Together, CP and CPS create transparency and trust by clearly stating the rules under which certificates are issued and managed. #### Governance in WebTrust and Audited Environments Publicly trusted Certificate Authorities operate within independently audited environments to ensure compliance with global trust standards. WebTrust Audits cover: • WebTrust for Certification Authorities • WebTrust for CA – Extended Validation • WebTrust for TLS Baseline Requirements • WebTrust for S/MIME Baseline Requirements • WebTrust for Code Signing • WebTrust for Network Security These audits verify that the CA's operations align with its CP/CPS, CA/Browser Forum requirements, and strong security controls across issuance, revocation, and infrastructure management. ETSI Audits are particularly relevant for CAs operating in European and regulated environments: • ETSI EN 319 411-1 (General Policy Requirements for Trust Service Providers) • ETSI EN 319 411-2 (Qualified Certificates) • ETSI EN 319 401 (General Policy Requirements for Trust Service Providers) ETSI audits matter especially for Qualified Trust Service Providers (QTSPs) operating under eIDAS frameworks, and they serve as an alternative or complementary assurance model to WebTrust. Completing these audits is typically required for inclusion in major browser and operating system trust stores. The tricky part here is that governance in audited environments extends well beyond technology - it reaches into documented processes, role separation, incident response, infrastructure security, logging, and continuous compliance monitoring. That's a significant operational commitment. \#### Policy and Governance in CERTInext CERTInext operationalizes certificate governance by translating policy requirements into enforceable, automated controls across the certificate lifecycle. Key governance capabilities include: Policy Enforcement - Certificate profiles aligned with CP/CPS requirements control allowed algorithms, key sizes, validity periods, and usage constraints. For instance, if your CP prohibits 1024-bit RSA keys, the profile simply won't issue them. Role-Based Access and Approval Workflows - Separation of duties is enforced through role-based access control (RBAC) and configurable approval flows for certificate requests and lifecycle actions. Not everyone who can view a certificate can revoke one. Audit Trails and Accountability - Detailed logs capture certificate issuance, renewal, revocation, approvals, and administrative actions. This supports both internal investigations and external audits. Trust Domain Governance - You can manage and govern certificates across public trust (including WebTrust-audited public CAs) and private trust environments from a single platform. Compliance Readiness - Centralized visibility, reporting, and evidence aligned with security and compliance frameworks means you're not scrambling to collect evidence when an audit arrives. \#### Why Policy and Governance Matter Without strong governance, certificate environments fragment. Inconsistency creeps in. Trust failures, outages, and regulatory non-compliance follow. Policy-driven governance ensures that certificates are issued only for approved purposes, cryptographic standards stay current, trust anchors and CAs are used appropriately, and every action leaves an auditable trail. # Automation and Integration **Automation and integration** are critical to managing certificates at scale. As certificate lifecycles shorten and usage expands across cloud, DevOps, Zero Trust, and machine identity environments, manual certificate operations become error-prone and operationally unsustainable. Automation ensures certificates are issued, deployed, renewed, and replaced reliably, while integrations connect certificate management to the systems where certificates are actually consumed. CertiNext is designed as an orchestration layer that automates certificate lifecycle operations and integrates seamlessly with enterprise platforms, infrastructure, and development toolchains. #### Automation in CertiNext CertiNext automates the full certificate lifecycle to reduce manual intervention and prevent service disruptions. Automation is policy-driven, ensuring that all actions comply with defined security and governance standards. Key automation capabilities include: * **Automated issuance and renewal** based on certificate profiles and expiry thresholds * **Automated replacement and re-provisioning** when certificates expire, are revoked, or fall out of policy * **Scheduled and event-based workflows** that respond to lifecycle triggers * **Zero-touch operations** for high-volume and short-lived certificate environments Automation minimizes human error, improves operational resilience, and ensures continuous trust across environments. #### Integration with Certificate Authorities CertiNext integrates with both **public and private Certificate Authorities** to standardize certificate issuance and lifecycle control. These integrations allow CertiNext to: * Route certificate requests to the appropriate CA * Apply consistent policies regardless of issuer * Support multiple trust domains from a single platform This enables organizations to manage diverse CA ecosystems without fragmented tooling or inconsistent processes. #### Integration with Infrastructure and Platforms Certificates are consumed by infrastructure, not by management tools. CertiNext integrates with the systems where certificates are deployed and used, including: * Web servers, application servers, and load balancers * Cloud platforms and hybrid environments * Network devices and appliances * Containers, orchestration platforms, and service meshes * Endpoints, devices, and IoT environments These integrations ensure certificates are deployed correctly and updated without manual installation steps. #### DevOps and CI/CD Integration Modern development environments rely on automation and infrastructure as code. CertiNext integrates with DevOps and CI/CD pipelines to enable: * Automated certificate provisioning during build and deployment * Secure injection of certificates and keys into applications * Certificate rotation without redeploying applications * Support for ephemeral and short-lived workloads This allows security controls to align with development velocity rather than becoming a bottleneck. #### API and Event-Driven Integration CertiNext exposes APIs and event mechanisms that allow organizations to integrate certificate lifecycle operations into custom workflows and enterprise systems. These interfaces support: * Programmatic certificate requests and lifecycle actions * Integration with ITSM, IAM, CMDB, and monitoring tools * Event-driven responses to certificate state changes APIs enable CertiNext to function as part of a broader security and automation ecosystem rather than a standalone tool. #### Why Automation and Integration Matter Automation and integration ensure that certificate management keeps pace with modern infrastructure and security models: * **Scalability** – Manage thousands or millions of certificates without manual effort * **Reliability** – Prevent outages caused by expired or misconfigured certificates * **Consistency** – Enforce uniform policies across environments and teams * **Security** – Reduce human error and improve cryptographic hygiene #### Automation as a Core Principle in CertiNext In CertiNext, automation and integration are not optional enhancements - they are foundational design principles. By embedding certificate lifecycle automation into enterprise platforms, infrastructure, and DevOps workflows, CertiNext enables organizations to operate secure, resilient, and future-ready trust environments at enterprise scale. # Machine Identities and IoT **Machine identities** are digital identities assigned to non-human entities such as servers, applications, workloads, devices, sensors, and embedded systems. These identities are typically established using digital certificates and cryptographic keys, enabling machines to authenticate themselves, establish secure communication, and participate in trusted transactions without human involvement. As enterprises adopt cloud-native architectures, Zero Trust security models, and connected systems, machine identities now vastly outnumber human identities. Managing these identities securely and at scale is a critical requirement, particularly in **IoT, industrial, and embedded environments**, where devices are long-lived, distributed, and often resource-constrained. #### Machine Identities in Modern Architectures Machine identities are foundational to: * **Service-to-service authentication** in microservices and APIs * **Workload identity** in cloud, container, and Kubernetes environments * **Device authentication** for endpoints, appliances, and infrastructure * **Zero Trust architectures**, where every interaction must be authenticated Certificates provide strong, cryptographically verifiable identity for machines, enabling mutual authentication, encrypted communication, and policy-based access control. #### IoT and Embedded Environments IoT and embedded systems introduce unique challenges for identity and trust: * Large volumes of devices deployed across geographies * Long device lifecycles with limited ability for manual intervention * Constrained compute, memory, and connectivity * High impact of compromise in industrial, automotive, and critical infrastructure use cases Certificates are increasingly used to establish identity for: * IoT sensors and gateways * Industrial control systems and OT environments * Connected and electric vehicles (EV ecosystems) * Smart infrastructure and edge computing platforms In these environments, secure provisioning, automated rotation, and strong key protection are essential. #### Machine Identity and IoT Management in CertiNext CertiNext extends Certificate Lifecycle Management beyond traditional servers to support **machine identities at scale**, including IoT and embedded use cases. The platform enables organizations to manage certificates and keys consistently across heterogeneous machine environments. Key capabilities include: * Automated certificate enrollment for devices using standard protocols * Centralized visibility into device and machine certificates * Policy-driven issuance, rotation, and revocation * Tracking of certificate and key age, strength, and compliance * Support for private trust models commonly used in IoT deployments By integrating certificate lifecycle automation with device and infrastructure workflows, CertiNext reduces operational complexity while maintaining strong security controls. #### Why Machine Identity Management Matters Unmanaged or weakly protected machine identities can lead to unauthorized access, lateral movement, and large-scale compromise. In IoT and industrial environments, the impact can extend beyond IT systems into physical operations and safety. Effective management of machine identities ensures: * Secure onboarding and authentication of devices * Continuous trust throughout the device lifecycle * Rapid response to compromise or decommissioning * Alignment with Zero Trust and modern security architectures #### A Scalable Trust Foundation With the growth of IoT, edge computing, and connected ecosystems, machine identities are becoming the dominant form of digital identity. CertiNext provides the automation, visibility, and governance needed to manage these identities securely and consistently - supporting enterprise, industrial, and future digital ecosystems with a unified trust foundation. # Crypto agility and Post Quantum Crypto **Crypto-agility** is the ability of an organization to rapidly adapt its cryptographic systems in response to evolving threats, standards, or regulatory requirements. As cryptographic algorithms age, vulnerabilities are discovered, or new computing capabilities emerge, organizations must be able to replace or upgrade cryptography without disrupting services or rebuilding systems from scratch. The need for crypto-agility has become more urgent with the advancement of quantum computing, which poses a material and present-day strategic risk to widely used public-key algorithms such as RSA and ECC. While large-scale, fault-tolerant quantum computers are not yet mainstream, the threat is not purely future-oriented. Adversaries may already be engaging in **Harvest Now, Decrypt Later (HNDL)** strategies - collecting encrypted data today with the intent to decrypt it once quantum capabilities mature. Similarly, **Threat Now, Forge Later (TNFL)** highlights the risk that digital signatures and authentication artifacts created today could be forged in the future if quantum-resistant protections are not adopted. For data and systems with long confidentiality or integrity requirements, preparation must begin now rather than waiting for full-scale quantum deployment. #### Post-Quantum Cryptography (PQC) **Post-quantum cryptography** refers to cryptographic algorithms designed to remain secure even in the presence of quantum computers. These algorithms are being standardized by bodies such as NIST and are expected to gradually replace or complement existing public-key algorithms. Key challenges with PQC adoption include: * Inventorying where vulnerable algorithms are currently used * Managing coexistence of classical and post-quantum algorithms * Handling larger key sizes and performance considerations * Coordinating large-scale certificate and key replacement across environments Preparing for PQC is not a single migration event - it is a multi-year transition that requires visibility, planning, and controlled execution. #### Crypto-Agility in the Context of CertiNext CertiNext enables crypto-agility by providing centralized visibility and control over cryptographic assets across the enterprise. By managing certificates, keys, profiles, and policies from a single platform, organizations can assess impact and execute cryptographic changes systematically rather than reactively. CertiNext supports crypto-agility through: * **Comprehensive inventory** of certificates and keys, including algorithms, key sizes, and usage * **Policy-driven controls** to enforce approved cryptographic standards * **Bulk renewal and replacement workflows** to rotate certificates and keys at scale * **Separation of profiles and policies** from applications, reducing dependency on hard-coded cryptography * **Automation and orchestration** to minimize service disruption during cryptographic transitions * CertiNext supports the generation and management of **approved PQC algorithms** This foundation allows organizations to respond quickly to deprecations, compliance mandates, or emerging threats. #### Preparing for a Post-Quantum Future While post-quantum algorithms will be introduced gradually, organizations must act now to ensure readiness. This includes understanding where cryptography is used, minimizing cryptographic sprawl, and ensuring lifecycle automation is in place. CertiNext helps organizations prepare for post-quantum cryptography by: * Identifying cryptographic exposure across servers, applications, devices, and IoT environments * Enabling staged transitions using updated certificate profiles and policies * Supporting hybrid environments where classical and post-quantum cryptography coexist * Providing governance and auditability throughout the transition #### Why Crypto-Agility Matters Without crypto-agility, organizations risk being locked into outdated or vulnerable cryptographic algorithms, leading to rushed migrations, outages, or long-term data exposure. With increasing regulatory focus on quantum readiness, crypto-agility is becoming a strategic requirement rather than a technical preference. By embedding crypto-agility into certificate and key lifecycle operations, CertiNext enables organizations to remain secure, compliant, and future-ready - supporting both today’s cryptographic standards and tomorrow’s post-quantum trust models. # Security and Compliance controls **Security and compliance controls** ensure that certificates, cryptographic keys, and trust operations are protected against misuse, compromise, and operational failure while remaining aligned with internal security standards and external regulatory requirements. As certificates underpin authentication, encryption, and machine identity across critical systems, strong controls are essential to maintain trust and accountability. CERTInext embeds security and compliance controls directly into certificate and key lifecycle operations, ensuring that trust is not only automated but also governed, auditable, and defensible. #### Core Security Controls CERTInext enforces security controls across the entire certificate ecosystem, including: * **Role-Based Access Control (RBAC)**\ Fine-grained roles and permissions ensure that users can only perform actions appropriate to their responsibilities, supporting separation of duties and least-privilege access. * **Approval and Authorization Workflows**\ Configurable approval workflows ensure that certificate issuance, renewal, and revocation actions are reviewed and authorized in accordance with organizational policies. * **Secure Key Handling**\ Visibility into key attributes such as algorithm strength, age, and usage helps enforce cryptographic hygiene and reduces the risk of weak or overexposed keys. * **Trust Anchor and CA Governance**\ Controlled management of trusted Certificate Authorities and trust anchors ensures that certificates are issued only from approved and audited sources. #### Compliance and Audit Readiness CERTInext supports compliance by maintaining transparency and traceability across all lifecycle activities. The platform records detailed audit trails that capture: • Certificate requests, approvals, and issuance events\ • Renewals, replacements, and revocations\ • Administrative changes to policies, profiles, and trust settings\ • User and system actions across the platform In addition to audit logging, CERTInext provides comprehensive reporting capabilities to support compliance and audit evidence generation. Administrators can generate filtered, exportable reports covering certificate inventory, issuance history, expiry forecasts, vulnerability posture, CA usage, and user activity. Reports can be exported in formats such as CSV, Excel, and PDF, enabling streamlined submission during internal audits, WebTrust reviews, ETSI assessments, and regulatory inspections. These records and reports support internal audits and external compliance requirements across industries and geographies. #### Alignment with Standards and Regulatory Frameworks CERTInext is designed to align with widely recognized security and compliance frameworks, including: • Public CA environments operating under WebTrust-audited controls\ • CA/Browser Forum requirements for publicly trusted certificates\ • WebTrust audit regimes including TLS Baseline Requirements, Extended Validation, S/MIME, Code Signing, and Network Security\ • ETSI audit frameworks, including support for environments operating under ETSI EN 319 standards and Qualified Certificate regimes (e.g., eIDAS Qualified Trust Service Providers)\ • Enterprise security frameworks such as ISO 27001, SOC 2, and PCI DSS\ • Regulatory and industry-specific compliance requirements where certificates play a role in identity and trust By enforcing policy-driven controls, supporting Qualified Certificate environments under ETSI audit regimes, and maintaining auditable records with structured reporting, CERTInext helps organizations demonstrate compliance without manual evidence collection. #### Monitoring and Risk Management Continuous monitoring identifies security and compliance risks before they lead to incidents. CERTInext surfaces: * Certificates nearing expiration * Misconfigured or non-compliant certificates * Weak or deprecated cryptographic algorithms * Unapproved trust paths or issuers Alerts and reports enable timely remediation and support proactive risk management. #### Security and Compliance as a Built-in Capability In CERTInext, security and compliance are not separate layers added after deployment - they are built into how certificates and keys are managed every day. By combining automation with enforceable controls, audit-ready reporting, and alignment with WebTrust and ETSI-regulated environments, CERTInext enables organizations to scale certificate operations securely while meeting governance, audit, and regulatory expectations across modern, distributed environments. # Architecture Overview The CERTInext Architecture Overview illustrates how the platform enables centralized certificate lifecycle management across on-premises systems, cloud environments, and third-party platforms while integrating with public and private Certification Authorities (CAs). At the infrastructure layer, CERTInext Bots are deployed within enterprise environments. These bots connect to internal assets such as HSMs, LDAP directories, certificate stores, SSH keys, file systems, and application servers (Server A). They also support agentless discovery and provisioning for remote systems like Windows (via SMB) and Linux (via SSH) servers. Additionally, bots integrate with third-party platforms including F5, Cloudflare, AWS ACM, Kubernetes, Palo Alto, FortiGate, and Akamai through secure API-based communication. All bots communicate securely with the CERTInext platform hosted in AWS Cloud over HTTPS (Port 443). Within the cloud layer, CERTInext exposes multiple APIs and protocol endpoints including REST, SCEP, EST, WAEP, and ACME, enabling automation and DevOps integration. Core functional modules include Discovery, Provisioning, Managed PKI, Secure Key Management, Vulnerability Assessment, Certificate/Key Compliance, Scheduling, and CT Log discovery. The platform is multi-tenant, with a Master Database and logically separated tenant environments. On the CA integration side, CERTInext connects to eMudhra’s data center for emSign (public CA) and emCA (private PKI) via dedicated APIs. It also integrates with external public CAs such as DigiCert and Sectigo through CA APIs. This allows automated certificate issuance, renewal, revocation, and trust validation. Overall, the architecture demonstrates a secure, scalable, API-driven, and multi-tenant design that bridges enterprise infrastructure, cloud platforms, and certification authorities into a unified certificate lifecycle management ecosystem.
# Capabilities Overview CertiNext delivers a comprehensive, end-to-end set of capabilities for managing digital certificates, cryptographic keys, and trust at enterprise scale. The platform is designed to address modern certificate challenges - shorter lifecycles, automation-first environments, Zero Trust architectures, and the rapid growth of machine identities - while remaining simple to operate and govern. CertiNext combines deep lifecycle automation with strong governance, broad protocol support, and native public and private trust capabilities, enabling organizations to manage trust consistently across cloud, on-premises, hybrid, and emerging environments. #### Centralized Visibility and Control CertiNext provides a unified, real-time view of certificates, keys, trust anchors, and issuing authorities across the enterprise. Discovery and inventory capabilities ensure that all certificates - regardless of origin or deployment location - are visible and managed from a single platform. This eliminates blind spots, reduces operational risk, and enables proactive lifecycle management. #### End-to-End Lifecycle Automation CertiNext automates the full certificate lifecycle, including discovery, issuance, deployment, renewal, replacement, revocation, and decommissioning. Automation is policy-driven and supports both long-lived and short-lived certificate models. This reduces manual effort, prevents outages caused by expired certificates, and ensures consistent execution across environments. #### Native Support for Public and Private Trust CertiNext manages both publicly trusted and privately trusted certificates through a unified control plane. The platform supports enterprise PKI as well as publicly trusted certificates, including native use of a globally trusted public trust anchor operated by CertiNext’s group entities. This dual-trust capability simplifies operations in environments that span external-facing services and internal workloads. #### Policy-Driven Governance and Compliance CertiNext embeds governance directly into certificate operations through certificate profiles, cryptographic policies, approval workflows, and role-based access control. These controls ensure that certificates are issued and used in accordance with organizational standards and audited trust practices, while maintaining full audit trails for compliance and reporting. #### Broad Protocol and Integration Support CertiNext supports industry-standard enrollment and automation protocols and integrates seamlessly with infrastructure platforms, cloud environments, DevOps pipelines, and enterprise systems. Open APIs and event-driven workflows allow CertiNext to fit naturally into existing operational and security toolchains, reducing friction and avoiding proprietary lock-in. #### Machine Identity and IoT Readiness CertiNext extends certificate management beyond traditional servers to support machine identities across devices, workloads, IoT platforms, industrial systems, and connected ecosystems. Automated enrollment, lifecycle management, and policy enforcement enable secure identity at scale, even in highly distributed or resource-constrained environments. #### Crypto-Agility and Future Readiness CertiNext is designed with crypto-agility at its core. By decoupling cryptographic policies from applications and automating bulk replacement workflows, the platform enables rapid response to algorithm deprecations, regulatory changes, and future post-quantum transitions - without service disruption. #### Operational Simplicity with Enterprise Scale CertiNext balances deep technical capability with operational simplicity. A clear user interface, actionable dashboards, and role-based views allow security, infrastructure, and DevOps teams to collaborate effectively without increasing complexity. The platform scales from small deployments to large, multi-region environments with high certificate volumes. #### Built for Trust-Critical Environments CertiNext is designed for environments where trust, availability, and compliance are non-negotiable. By combining automation, governance, native trust capabilities, and future-ready design, CertiNext enables organizations to operate resilient, secure, and scalable trust infrastructures - without the operational overhead traditionally associated with certificate management. # Multiple Login Options CERTInext provides multiple secure authentication methods to support diverse enterprise environments, user preferences, and security policies. Users can log in using password-based authentication, OTP verification, digital certificates, enterprise identity providers (Active Directory, SAML, OIDC), and social/enterprise SSO providers such as Microsoft and Google. This flexibility enables organizations to align authentication with Zero Trust principles, identity governance, and enterprise security standards. ### **Available Login Methods** CERTInext supports the following login options: #### **1. Password-Based Login** * Users authenticate using registered email ID and password * Supports password policies and reset mechanisms **Best suited for:**\ General users and standalone environments
#### **2. OTP-Based Login** * Users enter their registered email ID * A One-Time Password (OTP) is sent to email * OTP is used for authentication **Best suited for:**\ Passwordless and secure access scenarios
#### **3. Digital Certificate Login** * Authentication using client certificates installed on device * Certificate must be pre-mapped to user account **Path:**\ **My Profile → Add Certificate** **Best suited for:**\ High-security and regulated environments
#### **4. Active Directory (AD) Login** * Login using enterprise AD credentials * Supports: * UPN () * DOMAIN\username **Best suited for:**\ On-prem enterprise identity environments
#### **5. Single Sign-On (SSO – SAML / OpenID Connect)** CERTInext supports enterprise SSO using: * **SAML 2.0** * **OpenID Connect (OIDC)** Common providers: * Azure AD * Okta * Custom enterprise IdPs **Best suited for:**\ Federated identity and enterprise authentication #### **6. Microsoft SSO Login** * Users can authenticate directly using their **Microsoft account (Azure AD / Entra ID)** * Available as a one-click login option on the login screen **How it works:** * Redirects user to Microsoft identity platform * Authenticates via corporate or personal Microsoft account * Returns authenticated identity to CERTInext **Best suited for:**\ Organizations using Microsoft 365 / Azure AD #### **7. Google SSO Login** * Users can log in using their **Google account (Google Workspace or personal Gmail)** * Available directly on the login screen **How it works:** * Redirects to Google authentication * User signs in and grants access * CERTInext maps authenticated identity **Best suited for:**\ Organizations using Google Workspace or cloud-first environments ### **How to Enable Login Methods** Navigate to: **Settings → Account Configuration → Authentication Settings** #### **Step 1: Enable Authentication Controls** * Enable **Single Sign-On (SSO)** * Enable **2FA (optional but recommended)** ### **Microsoft SSO Configuration** Microsoft login is typically enabled via **OpenID Connect (OIDC)**. #### **Steps:** 1. Navigate to:\ **Settings → Account Configuration → OpenID Connect** 2. Register an application in **Azure Portal (Entra ID)** 3. Configure: * Client ID * Client Secret * Redirect URL (from CERTInext) 4. Provide OIDC details in CERTInext: * Discovery URL:\ `https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration` * Scopes: `openid email profile` 5. Save configuration Once configured, **Microsoft login button is activated on login screen**
### **Google SSO Configuration** Google login is also enabled using **OpenID Connect (OIDC)**. #### **Steps:** 1. Navigate to:\ **Settings → Account Configuration → OpenID Connect** 2. Create OAuth credentials in **Google Cloud Console** 3. Configure: * Client ID * Client Secret * Authorized Redirect URI 4. Use Google endpoints: * Authorization URL: `https://accounts.google.com/o/oauth2/v2/auth` * Token URL: `https://oauth2.googleapis.com/token` * User Info URL: `https://openidconnect.googleapis.com/v1/userinfo` 5. Set scopes: * `openid email profile` 6. Save configuration Once configured, **Google login button is enabled** ### **Active Directory (AD) Setup** #### **Enable AD Login** * Select **Active Directory** in Authentication Settings * Configure default role
#### **Configure LDAP Connectors** Navigate to: **Integrations → LDAP Connectors** Provide: * Host, Port * Base DN * Bind credentials * Search filter Test and save connection #### **Attribute Mapping** Map: * Email → `mail` * Username → `userPrincipalName` #### **Role Mapping** Map AD groups to CERTInext roles #### **User Sync** * Enable periodic sync * Configure activation/deactivation behavior ### **SAML 2.0 Setup** 1. Copy SP details from CERTInext 2. Configure in IdP 3. Upload metadata 4. Save
### **OpenID Connect Setup** Provide: * Client ID / Secret * Discovery URL * Token & UserInfo endpoints * Scopes Enable PKCE if required ### **Login Experience** * Users see multiple login options on the login page: * Password * OTP * Digital Certificate * Active Directory * Microsoft * Google * SSO * Available options depend on configuration ### **Security Best Practices** * Prefer SSO (Microsoft/Google/IdP) with MFA * Use certificate-based login for critical roles * Restrict password login where possible * Enable user sync for AD environments * Regularly review access and role mappings CERTInext supports a comprehensive set of authentication methods including enterprise SSO, Active Directory, Microsoft, and Google login. This ensures seamless user access while maintaining strong identity security, compliance, and centralized control. # Navigating the CERTInext Interface CERTInext is organized around a left-hand navigation menu that provides structured access to all certificate lifecycle, key management, integration, and governance capabilities. The interface is designed to support both operational users and administrators, allowing quick movement between day-to-day tasks and strategic oversight functions. The primary navigation sections include: * **Dashboard** – Provides a consolidated, real-time view of certificate health, risks, and operational status across the organization.
* **Certificates** – Central workspace for managing certificate orders, Certificate Authorities, discovery of existing certificates, and automated provisioning.
* **Keys** – Visibility and governance of cryptographic keys, including key aging and strength indicators.
* **Integrations** – Configuration of automation endpoints, bots, and integrations with external systems, platforms, and environments.
* **Billing & Payments** – Access to subscription, balance, and usage-related information where applicable.
* **Reports** – Detailed operational, compliance, and audit reports for certificates, keys, and lifecycle activities.
* **Settings** – Platform-wide configuration including global settings, security controls, roles, access policies, and organizational preferences.
This structure ensures users can quickly locate relevant functions while maintaining a clear separation between operational actions and administrative configuration. # Dashboard and Widgets The CERTInext dashboard provides a unified, real-time snapshot of certificate and key posture across the selected group or organizational context. Each widget highlights actionable information, enabling teams to proactively manage risk and operational workload. #### User Statistics This widget summarizes user access and onboarding status within the selected group: * **Total Users** – Number of active users with access to CERTInext. * **Pending Invites** – Users who have been invited but not yet onboarded. * **Pending Admin Approval** – Requests awaiting administrative approval. This helps administrators maintain visibility into access governance and onboarding workflows.
#### Domain & Organization Pending Approval This widget highlights validation tasks that require attention before certificates can be issued: * **Domains** – Domains awaiting ownership or control validation. * **Organizations** – Organizations pending verification or approval. It ensures that validation bottlenecks are identified early, helping avoid delays in certificate issuance. #### Certificate Statistics This widget provides insight into certificate lifecycle status and potential risks: * **Orders Pending Issuance** – Certificate requests awaiting CA issuance. * **Certificates Pending Provisioning** – Issued certificates that are yet to be deployed to endpoints. * **Expiring Within 30 Days** – Certificates approaching expiry, requiring renewal or replacement. * **Chaining Issues** – Certificates with incomplete or incorrect trust chains. These indicators help teams prioritize remediation and prevent service disruptions. #### Bot Statistics Bot statistics reflect the health and readiness of automation components: * **Bots with Issues** – Automation bots experiencing errors or failures. * **Bots with Updates Available** – Bots requiring updates for compatibility or enhancements. This widget helps ensure that automation pipelines remain reliable and up to date. #### End Point Statistics This widget focuses on endpoint-level exposure: * **Unprotected Endpoints** – Systems or applications without valid certificate coverage. * **Certificates with Vulnerabilities** – Certificates identified with weak algorithms or configurations. It provides early warning signals for security gaps at the infrastructure level. #### Key Statistics Key statistics offer cryptographic hygiene indicators: * **Keys with Aging >180 Days** – Keys that may require rotation based on policy. * **Weak Keys** – Keys that do not meet defined strength or algorithm requirements. This supports proactive cryptographic governance and compliance alignment. #### Certificates Issued (Public / Private) This chart visualizes certificate issuance trends over time, segmented by: * **Public Certificates** * **Private Certificates** It helps teams understand issuance patterns, growth trends, and dependency on public versus internal PKI. #### Expiring Certificates Timeline This widget presents a time-based view of upcoming certificate expirations across multiple horizons: * 1 Day * 1 Week * 15 Days * 1 Month * 6 Months * Max The timeline enables forward-looking planning, ensuring renewals are automated or scheduled well in advance.
#### **Interactive Graphs and Analytical Views** At the bottom of the Dashboard, CertiNext provides multiple interactive graphical views that offer visual insight into certificate distribution, security posture, and cryptographic lifecycle trends. These graphs are dynamic and allow filtering, time-range selection, and contextual drill-down. #### Certificates Issued (Public / Private) This bar chart displays certificate issuance trends by month. • Toggle between **Public** and **Private** certificates.\ • View issuance volume across selected months.\ • Identify spikes in certificate generation (e.g., bulk provisioning or renewals). This helps teams analyze growth patterns and CA dependency trends over time. #### Expiring Certificates This bar graph visualizes certificate expiration distribution across selectable time horizons: • 1 Day\ • 1 Week\ • 15 Days\ • 1 Month\ • 6 Months\ • Max The **View All** option navigates to the full certificate list filtered by expiration window. This enables forward planning for renewal campaigns and workload balancing. #### Expiring Certificates (Discovery) This pie chart displays discovered certificates grouped by source: • SSL/TLS\ • LDAP\ • File System\ • AWS\ • Others Time filters (1D, 1W, 15D, 1M, 6M, MAX) allow viewing expirations within specific ranges. This helps determine which discovery sources contribute most to upcoming expiry risks.
#### Certificates by Source (Discovery) This interactive pie chart categorizes discovered certificates by source. Available controls: • **Filter By Source**\ • **Filter By CA** Source categories shown: • SSL/TLS\ • LDAP\ • File System\ • AWS\ • Others This visualization helps validate discovery coverage across infrastructure, cloud platforms, and repositories. #### Certificates by Security Rating This bar chart categorizes certificates by security posture: • Excellent\ • Best\ • Good\ • Poor\ • Fail Security ratings are derived from: • Key size strength\ • Algorithm compliance\ • Certificate configuration\ • Trust chain validation The **Learn More** option provides further rating methodology details. This graph helps identify weak or non-compliant certificates requiring remediation.
#### Key Ageing The Key Ageing section combines summary indicators with a time-series trend graph. Top metrics displayed: • **No. of Keys** – Total keys in inventory\ • **Keys Used** – Keys currently in active use\ • **Keys Rotated** – Keys that have undergone rotation The line graph shows key activity trends over time with selectable ranges: • 1D\ • 1W\ • 15D\ • 1M\ • 6M\ • MAX This supports enforcement of key rotation policies and long-term cryptographic hygiene monitoring. #### Keys by Tags This section provides tab-based categorization of keys: Tabs available: • Key by Source\ • Key by Type\ • Key by Size The “Key by Source” view displays keys grouped by: • SSH\ • HSM\ • PKCS12\ • Database The horizontal bar chart shows count distribution by key origin. This enables governance teams to analyze key storage patterns and ensure secure key handling practices across environments.
### Summary Together, the CertiNext navigation and dashboard widgets provide: * **Operational clarity** for daily certificate management * **Risk visibility** for expiring, weak, or misconfigured assets * **Governance oversight** for users, domains, organizations, and keys * **Automation health monitoring** for large-scale environments This design ensures CertiNext remains effective for both tactical execution and strategic certificate governance at enterprise scale. # Global Settings The **Global Settings** page allows administrators to configure account-wide behaviors that apply across all users, certificates, and workflows in CERTInext. You will be on the "Account Configuration" menu. These settings help enforce security controls, standardize communication, and ensure consistent notification and alerting across the organization. Proper configuration of global settings is essential for secure operations and predictable certificate lifecycle management. This page is typically accessed by account administrators and governs authentication, language preferences, notifications, and operational contact details. ## Authentication Settings Global authentication settings define how users access CERTInext and help enforce organizational security policies.
### Enforce Two-Factor Authentication (2FA) Enables mandatory two-factor authentication for all users using T-OTP based authentication. This adds an additional security layer beyond passwords and helps protect administrative and operational access. ### Enable Single Sign-On (SSO) Allows users to authenticate using the organization’s identity provider. SSO simplifies user access management, supports centralized identity governance, and aligns CERTInext access with enterprise IAM policies. The updated CERTInext UI supports multiple SSO and federated authentication methods, including: * **SAML 2.0** * **OpenID Connect (OIDC)** * **Active Directory (AD/LDAP)** * **Microsoft Login** * **Google Login** These authentication methods can be configured centrally under the **Authentication Settings** section. #### SAML 2.0 Authentication The **SAML 2.0** configuration allows CERTInext to integrate with enterprise Identity Providers (IdPs) such as: * Okta * Azure AD * Ping Identity * OneLogin * Google Workspace * ADFS Administrators can configure: * ACS URL * Entity ID / Audience * Name ID Format * IdP Metadata XML * SSO Login URL * Signing Certificates This enables federated login using enterprise credentials while supporting centralized identity governance and MFA enforcement. #### OpenID Connect (OIDC) The **OpenID Connect** configuration supports modern OAuth-based identity providers and cloud authentication platforms. Supported providers include: * Azure AD / Microsoft Entra ID * Google Workspace * Auth0 * Okta * Custom OIDC providers Administrators can configure: * Client ID * Client Secret * Discovery URL * Authorization URL * Token URL * UserInfo URL * PKCE settings * Scopes (openid, email, profile) OIDC enables secure token-based authentication and simplified integration with cloud-native identity platforms. #### Active Directory (AD) Authentication The **Active Directory** authentication option allows users to log in using enterprise AD credentials. CERTInext supports: * LDAP / LDAPS integration * Multiple AD connectors * Cross-domain and cross-forest authentication * User synchronization * Group-to-role mapping Administrators can configure: * LDAP Connectors * Search Filters * Email Domain Mapping * Default User Roles * User Sync Intervals * Automatic User Activation / Deactivation This integration aligns CERTInext authentication with enterprise Windows identity infrastructure. #### Microsoft Login CERTInext supports direct authentication using Microsoft accounts through integrated SSO workflows. Users can authenticate using: * Microsoft 365 accounts * Azure AD / Entra ID accounts * Corporate Microsoft credentials This option simplifies user onboarding and enables seamless enterprise login experiences for Microsoft-based environments. #### Google Login CERTInext also supports authentication using Google accounts. Users can log in using: * Google Workspace accounts * Corporate Gmail identities * Standard Google accounts (where permitted) This option is particularly useful for organizations using cloud-first collaboration and identity environments. These authentication settings help ensure that access to certificate and trust operations is protected, centralized, and auditable across enterprise environments. ### Language Preferences Language settings control the default language used across the platform and in system communications. * **Default Language**\ Sets the primary language for the CERTInext user interface. * **Email Notification Language**\ Defines the language used for all system-generated email notifications, including certificate and order-related communications. Configuring language preferences ensures consistency in user experience and external communications, especially in global or multi-region deployments. ### Notifications and Alerts Notification settings control how CERTInext communicates important lifecycle events, operational alerts, and account-level information. **Support Contact Information** Administrators can configure: * **Support Email** * **Support Contact Number** * **Support Display Name** These details are included in customer-facing notifications to provide clear points of contact for certificate-related queries or issues. ### Certificate Renewal Notifications CERTInext allows fine-grained control over certificate renewal messaging to help prevent expirations and service disruption. * **Account-wide Certificate Renewal Message**\ A customizable message included in renewal notifications. * **Send Certificate Renewal Notification Emails**\ Enables automated renewal reminders to configured recipients. * **Renewal Notification Schedule**\ Notifications can be sent at multiple intervals before expiry (for example, 90, 60, 30, 15, 10, 5, 3, and 1 day) and after expiry.\ This ensures stakeholders receive timely reminders aligned with operational processes. #### Order and Provisioning Notifications Global settings also control who receives certificate order and provisioning-related emails, including: * Order confirmation * CSR-related notifications * Certificate download notifications Additional options include: * **Copy Technical Point of Contact (TPOC)** on order emails * **Exclude Organization Representatives** from receiving certain order notifications * **Configure account-level email addresses for provisioning alerts** These controls help route notifications to the right operational teams while reducing unnecessary noise. #### Domain Validation and Provisioning Options * **Generate Interim DV**\ Enables interim Domain Validation handling as part of the certificate issuance process, supporting faster provisioning workflows where applicable. This setting helps align certificate issuance behavior with organizational validation practices. #### Account Balance Alerts For accounts using prepaid or balance-based models, CERTInext provides: * **Low Account Balance Alerts**\ Automated notifications when account balance drops below configured thresholds. This ensures uninterrupted certificate issuance and avoids operational delays due to insufficient balance. # User Roles and Access Model ### User Roles and Access Management **User Roles and Access Management** in CERTInext is designed to enforce strong security controls, clear separation of duties, and operational accountability across certificate, key, and trust management activities. Given the sensitive nature of certificate authorities, cryptographic keys, and trust anchors, access to CERTInext is governed through a granular, role-based access control (RBAC) model. This approach ensures users can perform only those actions that are appropriate to their responsibilities, while all actions remain auditable and policy-aligned. ### Role-Based Access Control (RBAC) CERTInext uses **role-based access control** to define what actions a user can view or perform within the platform. Roles are assigned to users and determine access across functional areas such as certificate management, CA operations, discovery, provisioning, reporting, and administrative settings. RBAC supports the principle of **least privilege**, ensuring: * Administrative privileges are restricted to authorized users * Operational users can perform lifecycle actions without overreach * Sensitive CA and key operations are tightly controlled
The following standard roles are available within CERTInext: #### Administrator Provides unrestricted access across the entire CERTInext platform, including certificates, keys, discovery, integrations, reporting, billing, user management, and global settings. Administrators can configure platform-wide policies, authentication methods, CA integrations, and operational controls. #### Approver Provides read access across the platform with the ability to approve certificate requests and lifecycle actions submitted by other users. Approvers cannot approve their own requests, ensuring separation of duties and governance compliance. #### Basic User Provides access limited to the user’s own certificate orders, certificates, and related lifecycle activities. Users can request, view, renew, and manage only their own assigned certificates. #### Finance Manager Provides full access to billing, payments, invoices, and financial operations within CERTInext. Includes read-only visibility into certificate orders, certificates, organizations, domains, and related operational data. #### Manager Provides broader operational access across certificate orders, certificates, organizations, domains, groups, users, and selected settings. Includes approval capabilities and partial access to Discovery and CA operations, while preventing self-approval actions. #### Standard User Extends Basic User permissions by allowing read-only visibility into all account-level certificate orders, certificates, organizations, and domains. Operational modification rights remain limited to the user’s own assets. #### Discovery User Provides access exclusively to the Discovery module, including certificate scanning, inventory visibility, scan configurations, bots, and discovery-related reporting. No certificate issuance or administrative access is granted. #### Sub Account User Provides Basic User capabilities along with visibility into sub-account pricing and related delegated account structures. Commonly used in reseller, partner, or multi-tenant operational environments. ### Custom Roles In addition to default roles, CERTInext allows administrators to create **custom roles** tailored to organizational needs. Custom roles are built by selecting fine-grained permissions across platform modules, enabling precise alignment with internal teams and workflows.
Permissions can be defined across areas such as: * **Certificate Authorities** – Creating, managing, suspending, or revoking CAs and CA certificates * **Certificates and Orders** – Requesting, approving, renewing, reissuing, suspending, or revoking certificates * **Discovery** – Running discovery bots, managing discovered certificates, and CT log monitoring * **Provisioning** – Managing automated provisioning workflows, bots, and certificate rotation * **Keys and Key Stores** – Creating and managing keys, key profiles, and key stores * **APIs and Integrations** – Creating and managing API credentials and connectors * **Domains and Organizations** – Managing validation objects and organizational entities * **Reports and Audit Logs** – Accessing audit trails and operational reports * **Settings and Configuration** – Managing global account settings, custom fields, IP restrictions, and reporting tags This flexibility allows CERTInext to support diverse roles such as security administrators, PKI operators, DevOps engineers, auditors, finance teams, and application owners. ### Separation of Duties and Approvals CERTInext supports **separation of duties** by allowing organizations to distribute responsibilities across different roles. For example: * One role may request certificates while another approves them * CA management can be restricted to a small, trusted group * Audit and reporting access can be read-only Approval permissions can be configured to ensure sensitive actions - such as certificate issuance, revocation, or CA changes - are reviewed and authorized in line with governance policies. ### User and Group Management Users can be organized into **groups**, and roles can be applied at the group level to simplify administration. This is especially useful in large enterprises where access needs to align with business units, environments, or geographic regions. CERTInext also supports: * User invitations and approval workflows * Role activation and deactivation * Assignment of multiple roles where required #### Auditability and Compliance All role assignments, permission changes, and user actions are logged and available through audit reports. This provides: * Full traceability of who performed what action and when * Evidence for internal audits and external compliance reviews * Support for regulated and trust-critical environments #### Why User Roles and Access Management Matter In certificate and trust management, unauthorized or accidental actions can have wide-reaching impact. Strong access controls help: * Protect CA and key material * Reduce operational risk and misconfiguration * Enforce governance and compliance requirements * Support secure collaboration across teams #### Access Management as a Trust Control In CERTInext, user roles and access management are treated as a core trust control, not just an administrative feature. By combining granular permissions, custom roles, approval workflows, and auditability, CERTInext enables organizations to manage certificates and cryptographic assets securely, responsibly, and at enterprise scale. # Group Management **Groups** in CERTInext provide a structured way to organize users, certificate requests, products, and financial controls within a single account. They act as logical boundaries that help enterprises delegate responsibility, apply scoped access, and manage certificate operations at scale - without fragmenting governance or visibility. Groups are especially useful in multi-team, multi-application, or multi-entity environments where different users should be able to request and manage certificates only within defined limits.
#### Purpose of Groups Groups are used to: * Segment certificate operations by team, project, application, or business unit * Control which users can access and operate within a specific scope * Restrict which organizations, domains, and products can be used for certificate requests * Apply financial controls such as balance usage and cost attribution * Route notifications and renewal communications appropriately This allows decentralized operations while maintaining centralized governance. #### Group Configuration Each group in CERTInext has clearly defined configuration attributes: **Group Information** Defines the identity and ownership of the group, including: * Group name and description * Group logo (optional) * Creator details and creation timestamp * Source IP used during creation This information helps with traceability and administrative oversight. #### User Access Control Groups can be configured to: * **Allow specific users** to access the group * Assign users specific **roles** within the group Only authorized users can view, request, or manage certificates within that group’s scope, supporting least-privilege access and separation of duties. #### Certificate Request Scope Groups define *what certificates can be requested* and *for whom*: * **Organizations**\ Restrict certificate requests to specific validated organizations. * **Domains**\ Limit certificate issuance to approved domains associated with the group. * **Products**\ Control which certificate products or profiles are available to users in the group. This prevents accidental or unauthorized certificate issuance outside approved boundaries. #### Financial Controls Groups can be linked to specific financial handling rules, such as: * Deducting certificate costs from the account balance * Supporting cost segregation across teams or projects * Enabling internal chargeback or cost tracking models These controls are especially valuable in large organizations with shared certificate budgets. #### Notifications and Renewal Communication Groups support configuration of: * Certificate renewal notification email addresses * Group-specific communication for lifecycle events This ensures renewal alerts and operational messages reach the right stakeholders without over-notifying unrelated teams. #### User Membership and Roles Each group maintains a list of assigned users, including: * User identity and contact details * Role within the group (e.g., administrator, operator) * Account status and creation date This provides transparency into who is responsible for certificate operations within the group. #### Why Groups Matter Without grouping, certificate platforms can quickly become difficult to govern in large or distributed organizations. Groups enable: * Controlled decentralization of certificate requests * Reduced operational risk through scoped access * Clear ownership and accountability * Simplified administration at enterprise scale #### Groups as an Operational Boundary In CertiNext, groups function as **operational trust boundaries**. They allow organizations to scale certificate management across teams and use cases while preserving strong governance, auditability, and financial control - making groups a foundational construct for enterprise deployments. # Using Tags ### Reporting Tags **Reporting Tags** in CertiNext provide a flexible way to categorize, organize, and govern certificates, orders, discoveries, and related records across the platform. Tags help add business and operational context to technical certificate data, making it easier to filter, report, and control certificate usage at scale. Tags are commonly used to represent environments, departments, applications, projects, or any other logical classification relevant to an organization.
#### Purpose of Reporting Tags Reporting tags allow organizations to: * Categorize certificates and orders for better visibility and reporting * Filter dashboards, inventories, and reports by business or operational context * Track certificate usage across environments such as production, pre-production, and test * Support cost allocation, governance, and audit requirements By using tags consistently, organizations can gain clearer insights into how certificates are used across teams and environments. #### Creating and Managing Tags Administrators can create and manage tags from the Reporting Tags section in Settings. Each tag includes: * **Tag Name** – A human-readable identifier (e.g., *Production*, *Preproduction*, *Test*) * **Tag Value** – A standardized value used for filtering and reporting (e.g., *PROD*, *TEST*, *EVAL*) * **Status** – Indicates whether the tag is active and available for use Tags can be enabled or disabled as requirements evolve, without affecting existing certificate records. #### Tags for Environment Isolation Beyond reporting, CertiNext uses tags as a powerful mechanism for **environment isolation**. Tags can be applied to certificates discovered through scanning and monitoring activities, allowing environments to be clearly separated within a shared account. For example: * Certificates discovered in production systems can be tagged as **PROD** * Certificates discovered in test or evaluation systems can be tagged as **TEST** or **EVAL** This separation helps ensure that actions intended for one environment do not accidentally affect another. #### Tags and Access Control Tags can also be used in conjunction with **user and group access controls**. Users or groups associated with a specific tag can be granted visibility and management rights only over certificates and discoveries carrying the same tag. This enables: * Delegated certificate management by environment or team * Reduced operational risk through scoped access * Clear ownership and accountability for certificate lifecycles For example, a team responsible for test environments can manage only certificates tagged as *TEST*, while production certificates remain restricted to authorized users. #### Tags in Discovery and Inventory During certificate discovery, CertiNext allows discovered certificates to be automatically associated with tags. This ensures: * Immediate classification of discovered certificates * Faster triage and remediation based on environment or usage * Consistent tagging even for certificates not originally issued through CertiNext Tagging discovered certificates helps bring unmanaged or legacy certificates into governed workflows without losing contextual information. #### Reporting and Export Reporting tags can be used to: * Filter certificate and order reports * Generate environment-specific or department-specific views * Export filtered data to Excel or PDF for audits, reviews, or internal reporting This makes tags a key tool for both operational management and compliance reporting. #### Why Reporting Tags Matter As certificate estates grow, raw technical data alone is not enough. Tags provide the contextual layer that allows organizations to: * Scale certificate operations safely * Enforce environment separation * Improve reporting clarity * Align certificate management with business structures #### Tags as a Governance and Visibility Tool In CertiNext, tags are more than labels—they are a governance and isolation mechanism. By combining tagging with discovery, access control, and reporting, CertiNext enables organizations to manage certificates across environments and teams with precision, clarity, and reduced risk. # Supported Use Cases CERTInext supports a wide range of enterprise and industry use cases where digital certificates, cryptographic keys, and trust automation are foundational. The platform is designed to address both traditional certificate needs and modern, large-scale machine identity requirements, enabling organizations to manage trust consistently across IT, cloud, DevOps, and operational environments. Below are the most commonly adopted and high-impact use cases supported by CERTInext. #### 1. TLS Certificate Management for Servers and Devices One of the most common use cases for CERTInext is the ordering, deployment, and lifecycle management of **TLS certificates** for servers, applications, network devices, and endpoints. This includes both internet-facing and internal services. CERTInext enables: * Centralized ordering of TLS certificates from public and private Certificate Authorities * Domain and organization validation management * Automated renewal and replacement to prevent service outages * Visibility into certificate deployment across servers, load balancers, appliances, and devices This use case addresses the operational challenge of managing increasing certificate volumes and shorter validity periods across distributed environments. #### 2. Private PKI for Machine Identities and IoT CERTInext is widely used to establish and operate **private PKI** environments for machine identities, particularly in IoT, industrial, and embedded systems. Common scenarios include: * Device authentication for IoT sensors, gateways, and edge devices * Machine-to-machine authentication in closed or controlled networks * Identity for industrial systems, OT environments, and connected infrastructure * Secure identity for connected and electric vehicle ecosystems CertiNext supports automated enrollment, lifecycle management, and policy enforcement for device certificates, enabling secure and scalable machine identity management. #### 3. Certificate Automation Across Hybrid and Cloud Environments Automation is a core CertiNext use case, enabling organizations to eliminate manual certificate handling across dynamic environments. CertiNext supports: * Automated certificate issuance and renewal using standard protocols * Zero-touch provisioning and rotation across servers, cloud workloads, and containers * Integration with DevOps pipelines and infrastructure automation tools * Event-driven lifecycle workflows that respond to certificate state changes This use case is critical for cloud-native, CI/CD, and Zero Trust architectures where certificates must be created and rotated continuously without human intervention. #### 4. Key Management for Encryption and Cryptographic Operations CertiNext supports **key lifecycle management** for cryptographic keys used beyond certificates, including data encryption and digital security controls. Common key management use cases include: * Managing keys used for data-at-rest and data-in-transit encryption * Enforcing key rotation and cryptographic policies * Tracking key strength, age, and usage across systems * Supporting secure key usage for signing, encryption, and authentication This capability helps organizations maintain cryptographic hygiene and align with security and compliance requirements. #### 5. Discovery and Risk Reduction for Existing Certificates CertiNext is used to discover and inventory certificates that already exist across enterprise environments, including those issued outside standard workflows. This use case enables: * Identification of unknown or unmanaged certificates * Early detection of expiring or weak certificates * Reduction of outage and security risk caused by blind spots Discovery is often the first step organizations take when adopting CertiNext. #### 6. Zero Trust and Service-to-Service Authentication Certificates are a key enabler of Zero Trust security models. CertiNext supports certificate-based identity for: * Service-to-service authentication in microservices architectures * Mutual TLS (mTLS) for internal APIs and workloads * Continuous authentication of machines and applications This use case enables strong, cryptographic identity without reliance on static credentials. #### 7. Crypto-Agility and Large-Scale Certificate Rotation CertiNext is used to support crypto-agility initiatives, including algorithm upgrades and mass certificate replacement. Typical scenarios include: * Responding to algorithm deprecations or policy changes * Preparing for post-quantum cryptography transitions * Executing bulk certificate and key rotations with minimal disruption This use case reduces operational risk during large-scale cryptographic changes. #### 8. Governance, Compliance, and Audit Support CertiNext supports organizations operating in regulated and trust-critical environments by enabling: * Policy-driven certificate issuance and usage * Role-based access and approval workflows * Comprehensive audit trails and reporting This use case is critical for enterprises that must demonstrate compliance and accountability. #### Summary CertiNext supports both foundational and advanced certificate and key management use cases - from TLS certificate ordering to large-scale IoT machine identity and cryptographic governance. By combining automation, visibility, and policy enforcement, CertiNext enables organizations to manage trust securely and efficiently across modern, distributed digital ecosystems. # Quick Start Guide The CERTInext Quick Start Guide helps you get up and running with certificate lifecycle management in minutes. It provides a guided flow to onboard your environment, discover certificates, automate issuance, and enable deployment - all from a centralized platform. This guide follows the same structure as the CERTInext portal, allowing you to navigate seamlessly between documentation and the product UI. ### **Step 1: Access CERTInext** **Navigation:** `Login → Dashboard` * Log in to the CERTInext portal using your credentials * Ensure your organization and user roles are correctly configured * Verify access to required modules such as Certificates, Integrations, and Templates ### **Step 2: Configure Prerequisites** **Navigation:** `Settings → Global Settings / Integrations` Before starting, ensure: * Network access (Port 443 outbound enabled) * Required credentials for endpoints (IIS, Tomcat, F5, etc.) * Administrative privileges for Bot installation * CA integration (Public CA or Private CA such as emCA) These prerequisites ensure smooth discovery, issuance, and deployment workflows ### **Step 3: Install and Configure Bot** **Navigation:** `Integrations → Tools → Bots` * Download the CERTInext Bot * Install on a target system (Windows/Linux) * Launch with administrator privileges * Activate using Account ID and Bot Token The Bot acts as the execution engine for discovery and deployment across your infrastructure ### **Step 4: Discover Certificates** **Navigation:** `Certificates → Discovery / Bots` * Create a new Bot configuration * Define scan targets: * IP ranges * Domains * Ports / Port ranges * Select sources: * SSL/TLS, LDAP, AWS, File System, HSM, F5 * Run scan All discovered certificates will be visible in the centralized inventory ### **Step 5: Create Templates (CSR & Provisioning)** **Navigation:** `Certificates → Templates` * Create **CSR Template** * Define key algorithm, size, subject details * Create **Provisioning Template** * Define deployment type (Tomcat, IIS, F5, etc.) * Configure automation settings Templates standardize issuance and ensure policy-driven automation ### **Step 6: Issue & Rotate Certificates** **Navigation:** `Certificates → Inventory` * Select a discovered certificate * Apply CSR + Provisioning templates * Initiate **Certificate Issuance / Rotation** CERTInext automates: * Key generation * CSR creation * Certificate issuance (Public/Private CA) * Renewal workflows ### **Step 7: Auto Deploy Certificates** **Navigation:** `Certificates → Provisioning` * Select deployment type: * **Tomcat** (server.xml update + restart) * **IIS** (Windows store + binding update) * **F5** (SSL profile update via API) * Apply provisioning template Certificates are automatically deployed to endpoints without manual intervention ### **Step 8: Monitor Dashboard & Alerts** **Navigation:** `Dashboard` Track: * Expiring certificates * Weak keys / vulnerabilities * Discovery coverage * Automation health Configure alerts: * Expiry notifications * Policy violations * Security risks ### **Step 9: Enable Notifications & Reporting** **Navigation:** `Settings → Integrations (SMTP) / Reports` * Configure SMTP for alerts * Enable expiry notifications * Generate reports for: * Inventory * Compliance * Risk posture ### **Quick Navigation Map (UI Alignment)** | Step | Action | CERTInext Navigation | | ---- | ---------------- | ------------------------------- | | 1 | Login & Access | Dashboard | | 2 | Prerequisites | Settings / Integrations | | 3 | Bot Setup | Integrations → Tools | | 4 | Discovery | Certificates → Bots / Discovery | | 5 | Templates | Certificates → Templates | | 6 | Issuance | Certificates → Inventory | | 7 | Deployment | Certificates → Provisioning | | 8 | Monitoring | Dashboard | | 9 | Alerts & Reports | Settings / Reports | ### **Outcome** By completing this Quick Start Guide, you will: * Discover all certificates across your environment * Centralize certificate inventory and visibility * Automate issuance, renewal, and deployment * Eliminate downtime caused by expired certificates * Strengthen security and compliance posture # Enterprise Customer Signup Enterprise accounts in CERTInext are intended for organizations that manage internal and external certificate environments and require centralized governance, automation, and integration capabilities. These accounts are optimized for enterprise operations and do not include reseller-specific features such as sub-account creation or downstream price list management. #### Enterprise Sign-Up Process Follow the steps below to create an Enterprise account: 1. **Access the Sign-Up Page**\ Open [https://us.certinext.io/](https://hub.emsign.com/) and click **Sign Up**. 2. **Select Enterprise Registration**\ Choose **Sign up as an Enterprise**.
3. **Provide Required Details**\ Enter the following information: * Full Name * Email Address * Mobile Number * Organization Name * Country 4. **Accept Terms and Conditions**\ Review and accept the Terms and Conditions to proceed. 5. **Account Activation** * A confirmation message is displayed after submission. * An activation email is sent to the registered email address. * Click the activation link and set a password as per platform policy. Once activated, the Enterprise account is ready for use, allowing organizations to begin managing certificates, configuring automation, and integrating CERTInext into enterprise workflows. # Plans and Pricing CERTInext offers a comprehensive portfolio of SSL/TLS digital certificates designed for individuals, SMBs, and enterprise organizations. Certificates are available across three validation levels - **Domain Validation (DV)**, **Organization Validation (OV)**, and **Extended Validation (EV)** - with flexible coverage options including single domain, wildcard, multi-domain, and multi-domain wildcard. All plans include: * Strongest SHA-2 & ECC encryption (up to 256-bit) * Unlimited server licenses * Major browser and mobile device compatibility > **Note:** Pricing shown below reflects the **1-year** subscription tier. Multi-year plans (2-year and 3-year) are available at discounted annual rates. Prices are in **USD**. ### **Certificate Types & Pricing** #### **1. Domain Validation (DV) SSL Certificates** DV certificates are the fastest and most affordable option. Domain ownership is verified in minutes with no organization documents required. Best suited for personal websites, blogs, internal tools, and development environments. | Certificate Type | 1-Year Price | 2-Year Price | 3-Year Price | Coverage | | -------------------------------- | ------------ | ------------ | ------------ | ---------------------------------------------------- | | Single Domain DV SSL | $69/year | $62.10/year | $58/year | 1 FQDN or subdomain | | Wildcard DV SSL *(Most Popular)* | $99/year | $89.10/year | $83/year | Main domain + unlimited subdomains | | Multi-Domain DV SSL | $173/year | $155.70/year | $144/year | Up to 4 domains (extra SAN: $35/year) | | Multi-Domain Wildcard DV SSL | $298/year | $268.20/year | $248/year | Multiple domains + subdomains (extra SAN: $280/year) | **Key Features:** * Issued in minutes * Secures one or more FQDNs or subdomains * Ideal for low-risk websites #### **2. Organization Validation (OV) SSL Certificates** OV certificates verify both domain ownership and organizational identity, providing enhanced trust for business and customer-facing applications. | Certificate Type | Coverage | | ---------------------------- | ----------------------------- | | Single Domain OV SSL | 1 domain | | Wildcard OV SSL | Domain + subdomains | | Multi-Domain OV SSL | Up to 250 domains | | Multi-Domain Wildcard OV SSL | Multiple domains + subdomains | **Key Features:** * Organization-validated trust * Strong encryption (SHA-2 & ECC) * Supports up to 250 SANs * Ideal for enterprises and regulated environments > **Pricing:** Contact or visit\ > #### **3. Extended Validation (EV) SSL Certificates** EV certificates provide the highest level of trust with rigorous validation of business identity. | Certificate Type | Coverage | | -------------------- | ---------------- | | Single Domain EV SSL | Primary domain | | Multi-Domain EV SSL | Multiple domains | **Key Features:** * Highest authentication level * 256-bit encryption (2048/4096 RSA) * Trusted across browsers/devices * Supports compliance (PCI, HIPAA, GDPR) > **Pricing:** Contact or visit\ > #### **4. Additional Certificate Types** | Certificate Type | Description | | ------------------------------- | -------------------------- | | **S/MIME Certificate** | Secure email communication | | **Document Signer Certificate** | Digital document integrity | | **Wildcard SSL** | Covers domain + subdomains | | **Multi-Domain SSL (SAN)** | Covers multiple domains | ### **Choosing the Right Plan** | Use Case | Recommended Certificate | | ----------------------- | ----------------------- | | Personal website | DV SSL | | Small business | OV SSL | | Multiple subdomains | Wildcard SSL | | E-commerce / finance | OV or EV SSL | | Enterprise multi-domain | Multi-Domain SSL | | Email security | S/MIME | | Document signing | Document Signer | *** ### **Enterprise & Volume Licensing** CERTInext offers CertiNext+ (Enterprise CLM): * Automated certificate lifecycle management * Private PKI hierarchies * ACME & API automation * RBAC and governance controls * Monitoring, alerts, audit trails * PQC readiness * On-prem, cloud, hybrid deployment * Compliance support (WebTrust, GDPR, etc.) ### **Billing & Subscription** * Annual billing (1, 2, 3-year plans) * Multi-year discounts available * SAN expansion supported * $500,000 warranty (DV) * Renewal alerts before expiry ### **How to Purchase** 1. Visit 2. Select certificate type and duration 3. Complete payment 4. Perform validation (DV/OV/EV) 5. Receive certificate 6. Install and activate HTTPS # Topping up your wallet CERTInext uses a prepaid, wallet-based model for Enterprise customers to enable immediate certificate ordering and clear financial control. Enterprise users can add credits from Billing & Payments → Add Credits. The current account balance is always displayed at the top of the page to provide real-time visibility before proceeding. #### Adding Credits (Online Payment) To add credits using online payment: * Select Add/Withdraw Credits * Choose Credit to Account (or Group, if applicable) * Enter the amount and click Pay * Complete the payment on the secure payment gateway
Once successful, credits are instantly reflected in the wallet. If the payment status remains pending, users can verify it using the Recheck Payment Status option by entering the transaction number. #### Adding Credits via Wire Transfer (Offline Payment) CERTInext also supports Wire Transfer / Remittance for organizations that prefer offline or bank-based payments.
To add credits using Wire Transfer: * Navigate to Add Credits → Wire Transfer * Enter the payment amount, transaction number, and transaction date * Submit the request using Submit Offline Payment Wire transfer payments are processed offline and require approval from the CERTInext finance team. Once approved, the credited amount is updated in the wallet balance. #### Viewing Transaction History All credit activities are recorded under Recent Transactions, showing: * Transaction number * Date and amount * Payment mode (Online or Offline) * Approval and payment status This section provides a complete audit trail for wallet funding activities. #### Wallet Usage Wallet balance is automatically debited at the time of certificate order placement, ensuring immediate processing and avoiding post-order billing delays. This approach enables predictable spending, uninterrupted certificate issuance, and transparent financial tracking for Enterprise certificate operations. # Product Price Lists The Product Price List provides a consolidated view of pricing for all certificate products available on the CERTInext platform. It helps customers quickly review pricing options and plan purchases based on validity duration and internal budget requirements. You can access the Product Price List from\ Billing & Payments → Product Price List. #### Viewing Pricing Information The Product Price List displays certificate pricing in a tabular format, organized by different validity periods. This allows users to easily compare pricing options and make informed purchasing decisions without placing an order. The price list shown in the portal is the authoritative and up-to-date reference for all certificate pricing. #### Filtering and Exporting Users can: * Filter the list to narrow down specific certificate categories * Export to Excel for internal review or analysis * Export to PDF for sharing or offline reference These options make it easy to work with pricing data outside the portal. #### Generating a Proforma Invoice Users can generate a Proforma Invoice directly from the Product Price List page for budgeting or approval purposes. The proforma invoice is for reference only and does not initiate an order. The Product Price List ensures pricing transparency, supports budgeting workflows, and enables customers to plan certificate purchases efficiently within CERTInext. # Partner Signup Partner accounts in CERTInext are intended for resellers, distributors, and service providers who manage certificate sales for end customers and require pricing control, wallet-based billing, and commission tracking. These accounts are optimized for partner operations and support onboarding of sub-partners and customer referral workflows. #### Partner Sign-Up Process Follow the steps below to create a Partner account: 1. **Access the Sign-Up Page**\ Open [https://us.certinext.io/](https://hub.emsign.com/) and click Sign Up. 2. **Select Partner Registration**\ Choose Sign up as a Partner.
3. **Provide Required Details**\ Enter the following information: * Full Name * Email Address * Mobile Number * Organization Name * Organization Type * Country 4. **Accept Terms and Conditions**\ Review and accept the Terms and Conditions to proceed. 5. **Account Activation** * A confirmation message is displayed after submission. * An activation email is sent to the registered email address. * Click the activation link and set a password as per platform policy. Once activated, the Partner account is ready for use, allowing partners to configure pricing, manage wallet credits, onboard sub-partners, and begin certificate sales through the CERTInext platform. # Partnership Models CERTInext supports a structured Partner and Sub-Partner engagement framework designed to enable resellers, distributors, and channel partners to scale certificate sales while maintaining strong governance, pricing discipline, and financial transparency. The framework is optimized for high-volume, multi-customer environments where operational control, commission accuracy, and minimal financial risk are essential. To support different business and investment preferences, CERTInext enables two distinct Partner–Sub-Partner operating models, both governed through the Partner account. Under this framework: A Partner signs up directly with CERTInext and acts as the primary commercial and operational entity. The Partner owns the relationship with the platform and defines how Sub-Partners are onboarded, priced, and operationally governed. In the **Independent Sub-Partner (Commission-Based) Model**, the Partner enrolls Sub-Partners as independent entities and assigns them a predefined price list. Sub-Partners maintain and top up their own wallets and place certificate orders directly. When certificates are issued, the price difference between the Partner’s base price and the Sub-Partner’s price is automatically credited to the Partner as commission. This model allows Partners to earn commission without maintaining wallet balances, handling collections, or managing Sub-Partner finances. In the **Partner Group (Wallet-Based) Model**, Sub-Partners operate within the Partner’s own group. All certificate orders placed by Sub-Partners are settled directly from the Partner’s wallet at Partner pricing, which is not visible to Sub-Partners. Commercial arrangements between the Partner and Sub-Partners occur outside the platform. In this model, no platform-level commission is calculated, but the Partner retains full pricing flexibility and margin control while funding usage on a just-in-time basis. Across both models, pricing rules, wallet usage, and order settlement are enforced centrally at the Partner level, ensuring consistency and governance regardless of how Sub-Partners are structured. This dual-model approach enables decentralized sales execution, where Sub-Partners independently acquire customers and generate orders, while preserving centralized control, financial clarity, and operational transparency. Partners can choose the model that best aligns with their risk appetite and business strategy - achieving scale and revenue visibility without long-term capital lock-in or manual reconciliation. # Referring end customers CERTInext allows Partners to onboard and refer end customers either directly or through Sub-Partners, providing flexibility in how customer relationships and sales channels are structured. This approach supports both direct resale models and multi-tier partner ecosystems without compromising governance or traceability. The referral flow operates as follows: * The Partner signs up and completes account activation on CERTInext, establishing the primary reseller account that governs pricing, wallet funding, and commission settlement. * The Partner may optionally create Sub-Partner accounts and assign predefined price lists to them, ensuring that all downstream orders adhere to approved commercial terms. * Once activated, Sub-Partners are authorized to generate certificate orders on behalf of end customers, using the products and pricing made available through the mapped price list. * End customers receive certificates strictly in accordance with the selected product type, validity, and pricing configuration, ensuring consistency and compliance across all orders. All certificate orders placed by Sub-Partners are logically and financially linked to the Partner account, enabling automatic tracking of revenue, order activity, and commissions. This eliminates the need for manual attribution while providing Partners with full visibility and financial control as they expand their customer reach. # Topping up your wallet CERTInext operates on a prepaid, wallet-based financial model for Partners to ensure predictable transactions, real-time order processing, and transparent financial governance across partner ecosystems. Partners are required to add credits to their account wallet before placing certificate orders or enabling Sub-Partners to transact. This ensures that sufficient balance is always available to support uninterrupted order activity and immediate certificate processing. Credits can be added by navigating to Billing & Payments → Add Credits, where Partners can choose between Online Payment and Offline Payment modes. In both cases, the current wallet balance is displayed before proceeding. Online payments redirect users to a secure payment gateway for instant crediting, while offline payments are processed after finance approval. The platform also provides a payment status recheck mechanism to track submitted transactions. The wallet balance is used to settle certificate order values at the time an order is generated, eliminating post-order billing or reconciliation delays and enabling instant fulfillment. When a Sub-Partner places a certificate order**:** * The certificate cost is automatically calculated based on the price list mapped to the Sub-Partner * The corresponding amount is debited from the Partner’s wallet balance during order processing * Commission is calculated independently and credited to the Partner after successful certificate issuance CERTInext also allows credit withdrawal, enabling Partners to submit a withdrawal request from the Add Credits section. Upon approval by the CERTInext back office, the requested amount is credited to the Partner’s registered bank account, ensuring flexibility and financial liquidity. This wallet-based approach ensures uninterrupted order fulfillment, accurate financial settlement, and a clear separation between certificate cost and commission earnings - supporting reliable reconciliation, audit readiness, and scalable partner operations. # Setting a customer price list CERTInext requires price list configuration as a mandatory prerequisite for onboarding and enabling Sub-Partners. This ensures that all certificate transactions follow predefined commercial terms and eliminates ambiguity in pricing and commission calculations. The pricing workflow operates as follows: * The Partner creates a custom price list that defines product-wise pricing for certificates, including applicable product types, validity periods, and pricing structures. * During Sub-Partner account creation, the Partner maps the predefined price list to the Sub-Partner, establishing the commercial framework under which the Sub-Partner can operate. * Once mapped, Sub-Partners are restricted to placing orders only using the assigned price list, preventing deviations from approved pricing. This controlled pricing mechanism provides several operational benefits: * Ensures consistent and governed pricing across all sales channels * Prevents unauthorized discounting or ad-hoc pricing changes * Enables Partner-specific margin management without manual intervention * Simplifies and standardizes commission calculation and reporting After mapping, the price list becomes the authoritative pricing reference for all certificate orders generated by the Sub-Partner, ensuring predictable revenue, accurate commission attribution, and scalable partner operations. # How commission is paid out? CERTInext uses an automated, event-driven commission settlement mechanism to ensure accuracy, transparency, and scalability across partner ecosystems. Commission calculation and crediting are fully system-controlled, removing dependency on manual processes or post-transaction reconciliation. The commission workflow operates as follows: * A Sub-Partner generates a certificate order after completing account activation and using an assigned price list. * Once the certificate is successfully issued, the platform automatically triggers commission processing. * The Partner’s commission is calculated based on the predefined commercial model associated with the order. * The calculated commission amount is credited directly to the Partner account without requiring manual approval or intervention. At no stage is manual reconciliation required, ensuring that commission payouts remain timely, consistent, and error-free. #### Commission Visibility and Tracking Credited commissions are immediately visible to Partners through: * **Commission Reports**, providing detailed transaction-level breakdowns * **Account Balance and Financial Views**, reflecting updated earnings in real time This automated approach ensures: * **Real-time visibility** into commission earnings * **Accurate tracking** of Partner revenue across all Sub-Partner orders * **Transparent revenue sharing** aligned with pricing and order activity * **Audit-ready financial records** suitable for compliance and reporting By eliminating manual commission processing, CERTInext significantly reduces operational overhead, minimizes financial disputes, and strengthens trust between the platform and its Partner network - enabling scalable and reliable channel growth. # Placing an order as a Retail Customer Retail customers are individuals or small and medium businesses that place certificate orders directly through the public CERTInext portal. Any customer placing orders via [https://emsign.com/](https://emsign.com/index) is treated as a Retail customer within CERTInext. Retail accounts are designed to provide a simplified yet powerful ordering experience, allowing customers to procure and manage certificates without the complexity of reseller or enterprise pricing models. #### Placing a Certificate Order To place a certificate order as a Retail customer, follow these steps: 1. **Sign In to the Portal**\ Log in to the CERTInext portal () using your registered Retail account credentials.
2. **Select the Certificate Product**\ Choose the required certificate type from the available products.
3. **Provide Certificate Details**\ Enter domain, organization, and technical details as prompted. 4. **Confirm Pricing and Submit Order**\ Review the product price and submit the order using available wallet balance or payment options. 5. **Order Processing and Issuance**\ Once submitted, the order is processed and the certificate is issued upon successful validation. #### Pricing and Payment * Retail certificate orders follow standard product pricing defined by CERTInext. * Pricing details can be viewed under Billing & Payments → Product Price List. * Orders are processed using the account wallet balance or supported payment methods. This structured approach allows Retail customers to quickly purchase and manage certificates while maintaining visibility into pricing, billing, and certificate lifecycle events. # Trusted Agent Trusted Agent accounts in CERTInext are intended for authorized individuals who are responsible for validating, approving, and managing digital signature certificate requests. Trusted Agents act as verification authorities and play a critical role in ensuring identity assurance and compliance during certificate issuance and revocation processes. Trusted Agents typically include qualified professionals and authorized third parties, such as accountants, lawyers, government officials, or other approved entities. #### Trusted Agent Sign-Up Process Follow the steps below to create a Trusted Agent account: **Access the Trusted Agent Portal**\ Open the Trusted Agent portal URL provided by eMudhra in a supported web browser. **Provide Registration Details**\ Enter the required registration information as communicated during onboarding, including personal and professional identification details. **Account Verification and Approval**\ Trusted Agent accounts are subject to verification and approval by eMudhra. Once approved, login credentials and access instructions are shared with the registered user. **Login and Certificate Association**\ To access the portal, the Trusted Agent must log in using the registered username and select the assigned Class 3 Organization Certificate for authentication. Once activated, the Trusted Agent account is ready for use, enabling the user to process issuance and revocation requests, track certificate status, and perform validation activities through the Trusted Agent portal. # Ordering a Certificate CERTInext provides a guided, step-by-step workflow for ordering digital certificates. The ordering process is designed to collect all technical, organizational, and identity-related information required for certificate validation and issuance in a structured manner. The workflow is consistent across account types and ensures that certificate requests are accurate, compliant, and ready for automated validation. Each stage of the order captures specific information and allows users to review details before proceeding to the next step. # As a Partner Partners use CERTInext to place certificate orders on behalf of end customers. This enables resellers and service providers to manage customer certificates while maintaining pricing control and centralized billing. When placing an order as a Partner: * Orders follow partner-configured price lists * Payment is settled from the Partner wallet * Orders are automatically linked for reporting and commission tracking Partners can place orders directly for customers or through Sub-Partner workflows, depending on their account configuration. All partner-initiated orders follow the same validation and issuance standards enforced by CERTInext. # As a customer Customers (Enterprise or Retail) place certificate orders directly for their own organizational use. This model is designed for customers managing certificates for internal systems, applications, or public-facing services. Customer orders: * Follow standard platform pricing * Are paid using the customer wallet balance * Are issued directly into the customer account Customers manage their own organizations, domains, and certificate lifecycle without reseller-specific pricing or commission constructs. # Ordering DV Public Trust Certificates Although SSL is still commonly used interchangeably in the industry, it should not be. SSL (Secure Sockets Layer) is an insecure deprecated predecessor protocol to TLS (Transport Layer Security). Although our public trust TLS certificates could be used to support the SSL protocol, eMudhra advocates for secure protocol usage, and our certificates are designed and intended to support secure versions of TLS for secure authentication and privacy over the internet. ### What Is a DV SSL Certificate? A Domain Validation (DV) certificate is the quickest and most affordable type of SSL/TLS certificate. The Certificate Authority (emSign) simply confirms that you control the domain name - it does not check who you are or what organization you represent. When to use a DV certificate: • Personal websites, blogs, or hobby sites • Development or staging environments • Short-term projects • Any site where speed and low cost matter more than showing your organization name in the certificate What a DV certificate does NOT provide: • It does not verify your organization's identity • Visitors cannot see your company name in the certificate - only your domain name is shown ### The Four DV SSL Certificate Variants DV certificates verify only that you control the domain being secured - no company identity check is required. This makes them fast to issue (often within minutes) and the most popular choice for websites, blogs, applications, and internal services. CERTInext offers four variants: **DV SSL Certificate** You need to secure a single specific domain, such as [www.mybusiness.com](http://www.mybusiness.com) or shop.mybusiness.com. **DV Wildcard SSL Certificate** You need to secure your main domain and ALL its subdomains (\*.mybusiness.com). One certificate covers mail, portal, api, shop - any subdomain you create now or in future. **DV UCC SSL Certificate (Multi-Domain)** You need to secure several completely different domains or subdomains under a single certificate, e.g., mybusiness.com, mybusiness.net, and shop.mybusiness.com. **DV Wildcard UCC SSL Certificate** You need to protect multiple wildcard domains together, e.g., \*.mybusiness.com and \*.mybusiness.net - ideal for organizations managing several brands or regions. Choose the one applicable to your scenario based on the above description. ⚠️ **IMPORTANT** A DV certificate proves only that you control the domain - it does NOT show your organization's name in the certificate. If your website needs to display a verified company name in the certificate details, you need an OV (Organization Validated) or EV (Extended Validation) certificate, available separately on CERTInext. ### How to Use This Guide The guide is divided into two phases that apply to all four variants: • Phase 1 - Applying for the Certificate in CERTInext: A 6-step wizard you complete online. • Phase 2 - Post-Submission: What Happens After You Pay: Actions you take via email and the emSign Subscriber Portal to validate your domain and download your certificate. Where a step or field differs between variants, a clearly marked 'Variant Difference' section explains exactly what changes. Everything else is identical across all four variants. 📌 **InCommon Note** If your institution is part of the InCommon Certificate Service (a programme for US universities and research institutions operated by Internet2), your CERTInext login and group assignment may be pre-configured by your IT administrator. The application steps in this guide are identical for InCommon users. Your subscription cost may be covered under your institutional InCommon agreement - certificates may appear at $0.00 or a flat negotiated rate. Check with your IT/PKI administrator before placing an order. ## Before You Start - What You Will Need Please gather the following before beginning your certificate application. Having these ready will allow you to complete the entire process in one session. CERTInext Login **What It Is** *Your username and password for the CERTInext platform (certinext.io).* **What To Do** *Log in before starting. If you do not have an account, contact your IT administrator or eMudhra support.* #### Your Domain Name **What It Is** The website address you want to secure. * DV SSL: e.g., [www.mybusiness.com](http://www.mybusiness.com) * DV Wildcard SSL: e.g., \*.mybusiness.com * DV UCC SSL: e.g., mybusiness.com + mybusiness.net * DV Wildcard UCC SSL: e.g., \*.mybusiness.com + \*.mybusiness.net **What To Do** Write this down before starting. Make sure it exactly matches what your web server uses. #### CSR File **What It Is** A Certificate Signing Request - a block of encoded text generated by your web server or IT team. It contains your domain name and a public key that the CA uses to create your certificate. **What To Do** If you do not have a CSR, ask your IT team or hosting provider to generate one. Alternatively, you can skip CSR at application time and provide it later. See Step 2 for full guidance. #### DNS or Server Access **What It Is** After paying, you must prove you control your domain - either by adding a TXT record to your DNS settings or uploading a small file to your web server. **What To Do** Contact your DNS provider (e.g., GoDaddy, Cloudflare) or your IT administrator. For Wildcard variants, DNS TXT record is the only recommended method. #### Payment Method **What It Is** Either a CERTInext credit balance (pre-loaded by your organization) or a credit/debit card for online payment. **What To Do** Confirm with your accounts or IT team which method to use. # Phase 1 Steps ## Applying DV Certificate in a nutshell involves below steps **Step 1: Choose Product & Validity** * Select the DV SSL/TLS certificate variant you require (Single Domain, Wildcard, Multi-Domain/UCC, etc.). * Choose the validity period or subscription coverage as applicable. **Step 2: Certificate Signing Request (CSR)** * Upload the CSR file. * Paste the CSR content manually. * Or skip the CSR and submit it later. **Step 3: Requestor Information** * Enter the certificate requestor's details: * Name * Email Address * Mobile Number * Designation * These details will be used for order-related communications. **Step 4: Certificate Information** * Enter the domain name(s) to be secured. * Add SANs (Subject Alternative Names) if required. * Review the certificate details before proceeding. **Step 5: Additional Information (Optional)** * Add reporting tags for tracking and reporting. * Enter order remarks or internal references. * Configure auto-renewal preferences. * Add technical contact information if required. * Add additional email recipients for notifications. * Complete any custom fields configured by the administrator. **Step 6: Order Summary & Payment** * Review all order details. * Verify certificate information and payment details. * Submit payment. * The order is successfully created and submitted for processing. # Step 1 - Choose Product & Validity **Important Documentation Conventions:** Normal text below provides feature descriptions and explanatory information. *Italicized text* indicates navigation paths, procedures, and actions to be performed within the CERTInext platform. *Click on the 'New Certificate' button at left top corner of Navigation menu.* This is the first screen of the certificate application wizard. It is where you tell CERTInext which type of certificate you want and for how long. #### How to Get Here *1. Log in to CERTInext (certinext.io).* *2. Click the NEW CERTIFICATE button in the dark sidebar on the left.* *3. The screen titled 'Certificates :: New Request' opens.* *4. The left panel shows all 6 steps. You begin at Step 1: Choose Product & Validity.*
#### Fields on This Screen #### Group * Represents the account and organization in CERTInext that will own the certificate and be billed for it. * *The field is automatically populated based on your account configuration.* * *Verify that the correct organization or group is displayed.* * This field cannot be modified by the user. #### CA Source * Specifies the Certificate Authority (CA) that will issue the certificate. * *Select emSign from the CA Source dropdown.* * emSign is the publicly trusted CA operated by eMudhra. #### Certificate Type * Defines the broad category of certificate being requested. * *Select SSL/TLS Certificates from the Certificate Type dropdown.* #### Product * Determines the specific SSL/TLS certificate variant. * *Choose the product that best matches your requirement, such as:* * *DV Single Domain* * *DV Wildcard* * *DV Multi-Domain (UCC)* * *DV Wildcard Multi-Domain (UCC)* * Refer to the product comparison section if needed before making a selection. #### Subscription For * Defines the coverage period for the certificate subscription. * *Select one of the available options:* * *1 Year* * *2 Years* * *3 Years* * Most customers choose a 1-year subscription. * Publicly trusted SSL/TLS certificates can only be issued with a maximum certificate validity of 1 year. * If a 2-year or 3-year subscription is selected, the certificate will be reissued annually while the subscription remains active. * The subscription payment covers the entire selected period. #### Number of Domains (Applicable for UCC Products Only) * Displayed only when a UCC (Multi-Domain) or Wildcard UCC product is selected. * Determines how many domain names or SANs (Subject Alternative Names) will be included in the certificate. * *Select the total number of domains required.* * The base product typically includes up to 4 domains. * Additional domains can be added at an extra cost. * Plan SAN requirements in advance to simplify certificate management. #### Cost * Displays the calculated certificate price based on the selected options. * Pricing updates automatically when products, validity periods, or domain counts are changed. * *Review the displayed amount before proceeding.* * Any applicable taxes (such as Local Tax) will be calculated and shown during the Order Summary and Payment stage. #### Variant Differences - What to Select as 'Product'
Your SituationSelect This Product
Securing one specific domain only (e.g., www.mybusiness.com)DV SSL Certificate
Securing all subdomains of one domain (e.g., *.mybusiness.com)DV SSL Certificate Wildcard
Securing multiple different domains in one certificateDV SSL Certificate UCC
Securing multiple wildcard domains in one certificateDV SSL Certificate Wildcard UCC
Choose the one applicable to your scenario based on the above description. #### The Blue Information Box When you select any DV product, a blue information panel appears at the bottom of the screen. It summarises what the product covers. Key details shown for all DV variants: • Domain Validation - automated and fast (no company identity check required) • Fully Automated & Instant Approval - issuance typically within minutes • Unlimited Server Licences - install on as many servers as you need • Strongest SHA2 & ECC Encryption supported • Major Browser & Mobile Device Compatibility • Automatic renewal reminders and early renewal options **📌 InCommon Note** Under 'Subscription For', you will see the same 1/2/3 year options. InCommon institutional agreements typically issue DV certificates for 30 days / 90 days / 199 days at a time, in line with CA/Browser Forum rules. Even if your InCommon contract runs for multiple years, each individual certificate is issued for a maximum of 30 days / 90 days / 199 days respectively and must be renewed accordingly. The auto-renew feature (set in Step 5) handles this automatically. *When done, click the Next button at the bottom right.* # Step 2 - Certificate Signing Request (CSR) This screen is where you provide the CSR - a technical file from your web server that the Certificate Authority uses to create your certificate.
#### What Is a CSR? A CSR (Certificate Signing Request) is a block of text generated by your web server. It contains your domain name (called the Common Name) and a public key. The CA reads this information to create your certificate. Your IT team, hosting provider, or server administrator can generate a CSR for you. **📌 NOTE** The public key and signature algorithm from your CSR are used for certificate generation. Subject details such as Organization, Country, and State are pre-filled from your CSR for convenience but can be edited on screen. The values you submit in the form will be the final values in the issued certificate - not necessarily what was in the CSR. #### Variant Differences - CSR Requirements
VariantCSR Common Name (CN) Format & Key Size
DV SSL CertificateCN = yourdomain.com (e.g., www.mybusiness.com). Key size: 2048-bit RSA minimum.
DV Wildcard SSL CertificateCN = *.yourdomain.com - the asterisk and dot are REQUIRED (e.g., *.mybusiness.com). Key size: 4096-bit RSA recommended for stronger security.
DV UCC SSL CertificateCN = your primary domain (e.g., mybusiness.com). Additional domains are added as Subject Alternative Names (SANs). Key size: 2048-bit RSA minimum.
DV Wildcard UCC SSL CertificateCN = your primary wildcard domain (e.g., *.mybusiness.com). Additional wildcard domains are SANs. Key size: 4096-bit RSA recommended.
**⚠️ IMPORTANT** Wildcard certificates MUST have the asterisk in the Common Name: \*.yourdomain.com - NOT yourdomain.com. A CSR generated without the asterisk will NOT work for a Wildcard certificate and the order will be rejected by the CA. If your CSR was generated for the wrong domain, ask your IT team to generate a new CSR with the correct Common Name before proceeding. #### Your Three Options on This Screen ***Option A - Upload CSR File*** *1. Click the Choose File button next to 'Upload CSR'.* *2. A file browser opens. Navigate to your .csr or .pem file on your computer.* *3. Select the file. The filename appears next to the button once selected.* ***Option B - Paste CSR Text*** *4. Open your CSR file in any text editor (Notepad on Windows, TextEdit on Mac).* *5. Copy the entire block - starting with -----BEGIN CERTIFICATE REQUEST----- and ending with -----END CERTIFICATE REQUEST-----, including those header and footer lines.* *6. Paste the copied text into the 'Paste CSR' text box on screen.* ***Option C - Skip CSR*** *7. Tick the 'Skip CSR' checkbox at the top of the screen.* *8. You can complete the order and pay now, then provide the CSR later.* *9. Use this if your IT team has not generated the CSR yet but you need to start the order.* **💡 TIP** If you use a shared hosting service such as cPanel or Plesk: Log in to your hosting control panel, go to SSL/TLS settings, and generate a CSR from there. For standard DV SSL, enter your domain as the Common Name. For Wildcard variants, enter \*.yourdomain.com with the asterisk. Copy the CSR text from your hosting panel and paste it into the Paste CSR box on this screen. *Click Back to go back, or Next to proceed.* # Step 3 - Certificate Requestor Information This screen captures the details of the person placing this certificate order. This is the same for all four DV variants.
#### Fields on This Screen #### Name *(Required)* * *Enter the full name of the certificate requestor.* * This is the individual responsible for submitting the certificate request. * The requestor does not necessarily have to be the person who will install the certificate. * *The field is automatically populated from the CERTInext account profile.* * *Verify that the displayed name is correct.* * *Avoid using initials, abbreviations, or nicknames.* #### Requestor Email ID *(Required)* * This is the primary email address associated with the certificate request. * All important communications are sent to this email address, including: * Order confirmation emails * Domain validation requests * Certificate issuance notifications * Certificate download instructions * Renewal reminders * *The field is automatically populated from the account profile.* * Ensure the email address is monitored regularly. * Do not use distribution lists, shared mailboxes, or unattended inboxes. #### Mobile Number * Used for important notifications and communication related to the certificate request. * *The country code is selected from the dropdown list.* * *Verify and update the number if required.* * Example: * United States: +1 * India: +91 #### Certificate Download Delegation *(Optional)* * Allows certificate download responsibility to be delegated to another person. * Useful when the requestor is different from the system administrator or technical team responsible for installation. * *Enable this option only if someone else will download and install the certificate.* * *Leave it disabled if the requestor will handle certificate download and installation.* #### Contact Name (Delegation - Optional) * *Enter the full name of the person authorized to download the certificate.* * Typically this is a server administrator, application owner, or infrastructure engineer. * *Leave blank if download delegation is not required.* #### Email ID (Delegation - Optional) * *Enter the email address of the delegated certificate downloader.* * The delegated contact will receive: * Certificate issuance notifications * Certificate download emails * Download instructions and access information * *Leave blank if download delegation is not required* **💡 TIP** If you are applying on behalf of a client or colleague, enter your own details as the Requestor (so you receive all notifications). Use the Certificate Download Delegation fields to ensure the person who will actually install the certificate also receives the download email. *Click Back to go back, or Next to proceed.* # Step 4 - Certificate Information This screen is where you enter the domain name(s) that the certificate will protect. This step has significant differences between variants.
*Screenshot: Step 4 - Certificate Information (DV SSL Certificate - single domain)*
*Screenshot: Step 4 - Certificate Information (DV Wildcard SSL Certificate - wildcard domain)*
*Screenshot: Step 4 - Certificate Information (DV UCC / Wildcard UCC - multiple domains)* ### Fields on This Screen - All Variants #### Domain Name *(Required – All Variants)* * *Enter the primary domain name that the certificate will secure.* * This is the main website or service address that users will access. * The exact format depends on the certificate variant selected. * Examples: * Single Domain: `example.com` * Wildcard: `*.example.com` * Multi-Domain (UCC): `example.com` * *Ensure the domain name matches the information provided in the CSR (if applicable).* #### Automatically Secure the “www” Variant *(DV SSL & DV UCC Only)* * *When enabled, the certificate will automatically include the corresponding **www** version of the primary domain.* * Example: * If the primary domain is `example.com`, the certificate will also secure `www.example.com`. * *This option is enabled by default for DV SSL and DV UCC certificates.* * It is recommended to leave this option enabled unless the **www** version is not required. * Wildcard certificates do not require this option because subdomains are already covered. #### Additional Domain Names *(UCC & Wildcard UCC Only)* * Allows multiple domains or SANs (Subject Alternative Names) to be secured under a single certificate. * *Each additional domain is entered separately.* * Examples: * `mail.example.com` * `portal.example.net` * `shop.example.org` * *Click the **+** button to add more domain entries.* * *This feature is available only for UCC (Multi-Domain) and Wildcard UCC certificates.* #### Import Additional Domains *(UCC & Wildcard UCC Only)* * Useful when a large number of domains need to be included in the certificate. * *Upload a CSV or text file containing the list of domains.* * This eliminates the need to manually enter each domain individually. * Particularly helpful when securing dozens or hundreds of SANs. #### Clear *(UCC & Wildcard UCC Only)* * *Removes all additional domain names currently entered on the screen.* * Use this option carefully. * *Once cleared, the entered domains cannot be restored automatically and must be re-entered or re-imported.* * *Recommended only when you need to completely restart the SAN configuration.* #### Variant Differences - What to Enter as the Domain Name
VariantDomain Format to Enter
DV SSL CertificateEnter your specific domain name only - no asterisk. The www checkbox will handle both www and non-www if ticked.
DV Wildcard SSL CertificateEnter the wildcard format: *.yourdomain.com - the asterisk (*) and dot (.) prefix are REQUIRED. Do not enter without the asterisk.
DV UCC SSL CertificateEnter your primary domain in the Domain Name field, then add all additional domains in the Additional Domain Name fields below.
DV Wildcard UCC SSL CertificateEnter your primary wildcard domain (*.yourdomain.com) in the Domain Name field, then add additional wildcard or standard domains below.
**⚠️ IMPORTANT** Critical - The domain name entered here MUST match the Common Name (CN) in your CSR. If they do not match, the Certificate Authority will reject the request. If you are unsure what domain name was used in the CSR, check with your IT team before proceeding. Example mismatch to avoid: If your CSR was generated for \*.mybusiness.com but you enter mybusiness.com here (without the asterisk), the CA will reject it. **📌 NOTE** UCC Multi-Domain Rule: For DV UCC certificates, if you prove ownership of a base domain (e.g., mybusiness.com), all subdomains of that same base domain (e.g., mail.mybusiness.com, blog.mybusiness.com) will be validated automatically. However, completely different domains (e.g., anotherbusiness.com) each require separate domain verification. Validating a subdomain does NOT prove ownership of the parent domain. *Click Back to go back, or Next to proceed.* # Step 5 - Additional Information (Optional) This screen contains optional fields that help with managing and administering the certificate. None of these are required to get the certificate issued - but several are very useful and are recommended. This step is the same for all four DV variants.
#### Fields on This Screen #### Tags *(with “+ Add Tag” Button)* * *Tags are labels that help categorize and organize certificate orders for easier tracking and reporting.* * Common examples include: * Project Name (e.g., "ProdApp") * Environment (e.g., "Production", "UAT", "Development") * Server Name * Department or Business Unit * Cost Center * Tags are used internally within CERTInext and are not included in the certificate itself. * *Click **+ Add Tag** to create a new tag.* * *Multiple tags can be added to a single order.* * Using tags is highly recommended to simplify searching, filtering, and reporting. #### Order Remarks * *Allows you to add internal notes related to the certificate request.* * Remarks are visible only within CERTInext and are not included in the certificate. * Useful for recording: * Business justification * Change request numbers * Ticket references * Renewal notes * Deployment instructions * Example: * "Replacing certificate for production web server." * "Renewal of expiring VPN certificate." * *Leave blank if no additional comments are required.* #### Technical Point of Contact (Technical POC) * Allows you to specify the individual responsible for the technical management of the certificate. * Typically used to identify: * Server administrators * Infrastructure teams * Network administrators * Application owners * The Technical POC may be different from the requestor who submits the order. * *Enable this option if technical ownership needs to be formally recorded.* * Particularly useful in enterprise environments with multiple teams and administrators. * *Leave disabled if not required.* #### KYC Documents *(Optional)* * *Allows supporting identity or business verification documents to be uploaded.* * Some certificate types or account configurations may require document verification. * Typical examples include: * Business registration documents * Organization verification documents * Government-issued identification * For most standard DV SSL/TLS certificates, KYC documents are not required. * *Upload documents only when specifically requested during the certificate validation process.* #### Additional Email Recipients * Allows additional stakeholders to receive certificate-related notifications. * Useful when multiple people need visibility into the certificate lifecycle. * Typical recipients include: * IT Administrators * Security Teams * Application Owners * Operations Teams * Project Managers * These recipients can receive notifications such as: * Order confirmations * Domain validation requests * Certificate issuance alerts * Renewal reminders * Revocation notifications * *Enable the option and enter the required email addresses.* #### Auto-Renew Certificates Until Coverage *(Enabled by Default)* * Automatically renews and reissues certificates throughout the selected subscription coverage period. * Helps ensure certificates do not expire unexpectedly. * *Recommended for most production environments.* * *When enabled:* * *CERTInext automatically initiates the renewal process before certificate expiry.* * *Renewal notifications are sent according to configured policies.* * When disabled: * Renewals must be performed manually. * There is a higher risk of certificate expiry if renewal is overlooked. * It is recommended to leave this option enabled unless there is a specific operational requirement for manual renewals. #### Set Renew Criteria: Before \_\_ Days of Expiry * *Defines how many days before certificate expiration the automatic renewal process should begin.* * The default value is 15 days before expiry. * Organizations can increase this value to provide additional time for: * Validation activities * Approval workflows * Deployment planning * Change management processes * Example: * 15 Days: Renewal starts 15 days before expiration. * 30 Days: Renewal starts 30 days before expiration. * 60 Days: Renewal starts 60 days before expiration. * For large enterprises, a longer renewal window is often recommended to accommodate internal processes and avoid service disruption. **💡 TIP** Even though all fields on this screen are optional, it is good practice to: (1) add at least a Tag such as 'Production Web Server' or 'Wildcard - All Subdomains' to make the certificate easy to find later, and (2) leave Auto-renew turned ON to avoid your website showing a security warning due to an expired certificate. **📌 InCommon Note** The Auto-renew feature works the same way for InCommon certificates. Since InCommon DV certificates are issued for 30 days/ 90 days / 199 days at a time, auto-renewal will trigger 15 days (or your set number of days) before each expiry. Make sure your institutional InCommon agreement is still active at renewal time so the renewed certificate is also covered under the agreement. Click Back to go back, or Next to proceed to the Order Summary. # Step 6 - Order Summary & Payment This is the final screen before submitting your order. It shows a complete summary of everything you have entered, along with the payment breakdown. Review all details carefully before paying - once payment is made, changes require going through the order management tools.
**📌 NOTE** An orange "Payment Pending" badge appears in the top-right corner of this screen. This confirms that the order has NOT yet been paid. ### What Is Shown on This Screen #### Product Information Section * **Certificate Type:** SSL/TLS Certificates * **Product Name:** The DV variant you selected (e.g., DV SSL Certificate, DV SSL Certificate Wildcard, etc.) * **Validity Period:** 1 Year, 2 Years, or 3 Years, as selected in Step 1 * **Domain Count:** Number of domains covered (1 for standard/Wildcard certificates; your selected number for UCC variants) #### Certificate Information Section * Displays the domain name(s) entered in Step 4. * Confirm that all domain names are correct before proceeding with payment. * For UCC variants, all additional domains (SANs) are listed in this section. #### Payment Information Section * **Current Balance:** Your account's pre-loaded credit balance in USD. This represents your organisation's available credit within CERTInext. * **Certificate Price:** Base price of the selected DV certificate product in USD. * **Additional SAN Cost:** Applicable only for UCC variants. This is the charge for each domain beyond the base 4 included domains * **Grand Total:** The total amount payable in USD (Certificate Price plus any Additional SAN Cost). Tax is included where applicable. ### Subscriber Agreement Checkbox **⚠️ IMPORTANT** *You must tick this checkbox before the payment buttons become active.* The checkbox text reads: *"The Subscriber/Requestor hereby agrees to have read, understood and agree to Subscriber Agreement of emSign."* By selecting this checkbox, you are legally agreeing to the terms and conditions of the emSign Certificate Authority for issuing this certificate. * *Click the **Subscriber Agreement** link to review the complete terms and conditions before accepting.* * *Payment options remain disabled until the checkbox is selected.* ### Payment Options #### Save and Exit * *Saves your order as a draft.* * No payment is made. * Order status remains **"Payment Pending"**. * You can return later to complete payment. **Use this option if:** * *You are not ready to pay.* * Additional approvals are required. * *You want to save your progress and continue later.* #### Pay Online * *Opens the online payment gateway.* * *Supports payment methods such as:* * *Credit Card* * *Debit Card* * *Net Banking* * *Bank Transfer (where available)* * *Payment is processed immediately.* **Use this option if:** * Your organisation does not have a pre-loaded credit balance. #### Use Credit * *Instantly deducts the Grand Total from your organisation's pre-loaded CERTInext credit balance.* * No card or banking details are required. * Commonly used by enterprise customers. **Use this option if:** * Your organisation has sufficient credits available. * You have already accepted the Subscriber Agreement. ### 📌 InCommon Note If your InCommon certificate is covered under an institutional subscription: * The displayed cost may be **$0.00** or a nominal flat-rate amount. * Click **Use Credit** to proceed. * If the displayed cost appears unexpectedly high, contact your IT administrator before proceeding. * Pricing configuration may need to be verified with your InCommon account manager. ### 📌 Final Note Once you click **Use Credit** or **Pay Online** and payment is successfully processed: * Your order is officially submitted. * You are redirected to the **Order Confirmation** screen. * A confirmation email is sent to the requestor. * The certificate request enters the validation and approval workflow. **Important:** * Do not close the browser immediately after payment. * Wait for the Order Confirmation screen to load successfully. * Ensure that the confirmation email has been received before leaving the process. # Phase 2 Steps (via email & emSign) ## Immediately After Payment – The Order View Screen The **Certificates :: Orders > View Order** page opens automatically after payment. This page serves as the central location for tracking and managing the certificate order within CERTInext.
### The Order Header Bar At the top of the page, a summary section displays the key details of the order. #### Order ID * A unique identifier assigned to the certificate order (for example: 1184216685). * This number is required when contacting support or searching for the order later. * Record the Order ID or take a screenshot of the page for future reference. #### Ordered Date * Displays the date and time when the order was submitted. * Confirms that the order was successfully created. #### Product * Displays the SSL/TLS certificate variant selected during the ordering process. * Verify that the displayed product matches the intended certificate type. #### Group * Displays the organization or account under which the certificate was ordered. * Confirms the billing and ownership account. #### CA Source * Displays the issuing Certificate Authority. * For emSign certificates, this field shows **emSign**. * Verify that the expected CA is displayed. #### Certificate Price * Displays the total amount charged for the certificate order in USD. * This amount should match the Grand Total shown during the Order Summary & Payment step. #### Order Status * Displays **Order Accepted** in an orange status badge. * This indicates that payment has been successfully received and the order has been recorded in CERTInext. * The certificate request has not yet been forwarded to the Certificate Authority for processing. * No action is required from the requestor at this stage. #### Certificate Status * Displays **Pending for Approver** in an orange status badge. * Indicates that the certificate request is awaiting approval from the organization's CERTInext Account Administrator. * The request cannot proceed until administrator approval has been completed. **If you are an Administrator:** * Use the 3-dot menu located in the upper-right corner of the page to approve the request. **If you are not an Administrator:** * Contact your IT department or CERTInext account administrator and provide the Order ID for approval. ### ⚠️ Important – Pending for Approver In enterprise CERTInext accounts, every new certificate order must be approved by an Account Administrator before it is forwarded to emSign for processing. * If you are the designated Administrator, approve the request using the 3-dot menu available on this page. * If you are not the Administrator, contact the responsible administrator or CERTInext account manager and request approval. * Include the Order ID when requesting approval to help locate the order quickly. ### What the Rest of the Order View Page Shows #### SSL Subscription Information Displays information about the certificate subscription. * **Subscription For:** Displays the selected subscription period (for example, 1 Year, 2 Years, or 3 Years). * **Subscription Start Date:** Displays as a dash (-) until the certificate is issued. * **Subscription End Date:** Displays as a dash (-) until the certificate is issued. * **Subscription Status:** Displays **Pending** in an orange status badge until issuance is completed. #### Auto-Renewal Configuration Displays the renewal settings selected during the order process. * Confirms whether automatic renewal is enabled. * Displays the configured number of days before certificate expiry when the renewal process should begin. #### Certificate Information Displays the certificate details entered during ordering. * Primary domain name. * Additional domains (SANs), if applicable. * Confirms the exact domains that will be included in the certificate. #### Certificate Requestor Information Displays the details of the user who submitted the certificate request. * Requestor Name. * Requestor Email Address. #### CSR Information Displays information extracted from the submitted Certificate Signing Request (CSR). * **Common Name (CN):** The primary domain name. * **Key Size:** Typically: * 2048-bit RSA for DV SSL and DV UCC certificates. * 4096-bit RSA for Wildcard certificate variants. * **Key Algorithm:** RSA. #### Ordered By Displays details of the individual who submitted the order. * User Name. * User Role. #### Renewal Notifications Displays the notification configuration for certificate renewal. * **Send Email Notifications:** Yes. * Renewal reminder emails will be sent before certificate expiration. #### Reissue History Displays the history of certificate reissues. * For a newly created order, the section displays: * **No records found** * This is expected because no certificate reissues have occurred yet. ### 📌 Note - Three Dot Menu Options *The 3-dot menu located in the upper-right corner of the Order View page provides access to additional order management functions.* Depending on the order status and user permissions, the menu may include: * Track Order (generate a public tracking URL) * Download Invoice * Replace CSR * Recall Request * Cancel Order * Download Certificate (available after issuance) * Reissue Certificate (available after issuance) These options allow administrators and authorized users to manage the certificate throughout its lifecycle. ## PHASE 2 will have below steps in a nutshell #### Order Confirmation After the order is submitted and payment is successfully processed: * A confirmation email is sent to the Requestor's registered email address. * The email contains a Track Order link. * Use this link to monitor the progress of the certificate request throughout the validation and issuance process. #### Domain Verification For all DV (Domain Validation) SSL/TLS certificates, domain ownership or control must be verified before certificate issuance. * Open the **emSign Subscriber Portal** using the link provided in the order emails. * Complete the Domain Control Validation (DCV) process using one of the available verification methods. * Domain verification confirms that you are authorized to request a certificate for the domain. * Certificate issuance cannot proceed until domain validation is successfully completed. #### Administrator Approval Applicable for enterprise accounts where approval workflows are enabled. * The certificate request is routed to the designated CERTInext Administrator. * The administrator reviews the request details, including: * Certificate product * Domain names * Requestor information * Organizational policies * The administrator can approve or reject the request. * Processing continues only after approval is granted. #### Certificate Issued Once all required validations and approvals have been completed: * emSign issues the SSL/TLS certificate. * Certificate issuance notifications are sent via email. * The certificate becomes available for download through CERTInext and the associated certificate management workflows. #### Download & Install After issuance: * Download the certificate files from CERTInext. * Download any required intermediate or CA chain certificates if applicable. * Install the certificate on the target server, application, load balancer, appliance, or device. * Verify that HTTPS/TLS services are functioning correctly after installation. * Perform post-installation validation to confirm successful deployment and secure connectivity. # DV Order Confirmation ## Email 1 - Order Confirmation: 'Your Order is Successful' *Shortly after payment, you receive an email at the Requestor Email ID you provided in Step 3.*
#### Email Details * **Subject Line:** ORDER #\[your order ID] - Your Order is Successful * **Greeting:** Dear \[Your Name], Your order is placed successfully. * **Order ID:** Your unique order number - save this. * **Ordered Date:** Date and time of the order in UTC. * **Product & Validity:** The DV variant and duration you selected. * **Identifier:** Your domain name (or primary domain for UCC variants). * **Subscription For:** 1 Year (or your selected period). * **Track Order Button:** The orange button in the email. Clicking it opens the emSign Subscriber Portal - where you complete domain verification and download your certificate. ⚠️ **IMPORTANT** Do not ignore this email. *The Track Order link is how you complete the domain validation step. Without completing domain validation, your certificate cannot be issued.* 💡 **TIP** Check your spam or junk folder if you do not see this email within a few minutes of payment. The email is sent from the emSign / eMudhra domain. Add the sender to your safe senders list to avoid future emails going to spam. *If you provided a Certificate Download Delegation email address in Step 3, that person will also receive a copy of relevant notifications.* # DV Order Tracking *Clicking the Track Order button in the confirmation email opens the emSign Subscriber Portal - a separate, public-facing web page that guides you through the remaining steps to get your certificate issued. You do not need to log in to CERTInext to access this page.*
#### Page Header The page displays: *"Hello \[Your Name], Please follow the instructions and complete the below verification steps to speed up your certificate issuance process."* ## The Four Order Actions This page shows four steps in the Order Actions section. Steps 1 and 2 are automatically completed when you paid: #### 1. Submit CSR * Completed (green tick) - automatically done when you submitted your CSR in Step 2. #### 2. Subscriber Agreement * Completed (green tick) - automatically confirmed when you ticked the agreement in Step 6. #### 3. Domain Verification * Awaiting Customer Action (orange) - YOU must complete this step. #### 4. Certificate Download * Issuance Pending (orange) - becomes available once Step 3 is completed. ## The Order Details Sidebar (Right Side of the Page) * **Date Ordered:** Date you placed the order. * **Order ID:** Your unique reference number. * **Product & Validity:** Your DV variant and duration. * **Domain Name:** The domain (or primary domain) being secured. * **Order Status:** Order Accepted. * **Certificate Status:** Pending for Approver - awaiting Administrator approval in CERTInext. 📌 **InCommon Note** The emSign Subscriber Portal is the same for all users, including InCommon members. Domain verification is required for ALL DV certificates regardless of your InCommon membership - you must always prove domain control. *You can always return to this page by clicking the Track Order button in the confirmation email, or by generating the tracking URL from within CERTInext using the 3-dot menu on your order.* # Domain Verification Domain verification is the most important step after payment. The Certificate Authority must confirm that you control the domain before it can issue the certificate. This section explains how to complete it.
### What You See When You Expand Domain Verification *Click on the **'3. Domain Verification'** row (or the + expand icon on the left).* The section expands to show: * Total Domains: the number of domains that need to be verified (1 for DV SSL and Wildcard; your selected count for UCC variants). * Under Domain Control Validation (DCV): your domain name(s) listed, each with a Verify button and a CAA button. * The CAA button is for advanced DNS checks - typically for IT teams only. Use the Verify button. ### How to Start - Click the Verify Button *Click the orange Verify button next to your domain name. A popup window titled:* ***'Domain Control Validation (\[your domain]) - #\[Order ID]'*** *opens.* ⚠️ **IMPORTANT** Note shown in the popup: *"This is technical in nature (if you are not the right person, please contact your IT / Domain administrator)."* If you are not the person who manages your domain's DNS settings or web server, stop here. Copy the portal URL from your browser address bar and forward it to your IT or domain administrator. Ask them to complete the domain verification step on your behalf. ## Choosing a Domain Control Validation (DCV) Method The popup shows a DCV Method dropdown. Two methods are available: ### Method 1 - DNS TXT Record (Most Preferred - Recommended for All Variants) This method proves you control the domain by adding a special text record to your domain's DNS settings. It is recommended for all DV variants and is the only suitable method for Wildcard certificates.
*Select **'DNS TXT Record (Most Preferred)'** from the DCV Method dropdown.* *The popup shows:* * ***Record Type:** TXT* * ***Host:** Your domain name (or a specific validation subdomain). Use the Copy button to copy the exact value.* * ***Value:** A unique alphanumeric token generated for your order (e.g., 5A27BFFF4R95F80945F8D5491A8FFC98). Use the Copy button - even a single character difference will cause verification to fail.* ### Step-by-Step Instructions for DNS TXT Record 1. *Log in to your domain registrar or DNS provider (e.g., GoDaddy, Cloudflare, Namecheap, Google Domains, AWS Route 53).* 2. *Navigate to the DNS Management section for your domain.* 3. *Add a new TXT record:* * *Host/Name: Paste the Host value copied from the popup.* * *Value/Content: Paste the long alphanumeric token copied from the popup.* * *TTL: Set to the minimum available (e.g., 300 seconds / 5 minutes) for fastest propagation.* 4. *Save the DNS record.* 5. *Wait 5–30 minutes for the DNS record to propagate. In rare cases, propagation can take up to 48 hours.* 6. *Return to the DCV popup in the emSign Subscriber Portal and click the orange **'Verify Now'** button.* 7. *If successful, a green confirmation popup appears.* 💡 **TIP** You can check if your DNS record has propagated using a free tool such as dnschecker.org. Search for your domain and the TXT record type. Once the value appears worldwide, click Verify Now. ## Method 2 - HTTP/HTTPS File-Based Validation (For DV SSL and DV UCC Only) This method proves domain control by uploading a small text file to your web server at a specific URL. The CA then checks that the file exists and contains the correct token. ⚠️ **IMPORTANT** File-based validation is **NOT suitable for Wildcard certificates** (DV Wildcard SSL and DV Wildcard UCC). For Wildcard domains, use the DNS TXT Record method only. Note shown in the popup: *"File-based (HTTP/HTTPS URL) DCV method can only be used to prove domain ownership over Fully Qualified Domain Names (FQDNs), exactly as named."*
The popup shows: * **File Name:** A specific filename (e.g., 084984170207f94FB0482A1A70BF9A82.txt). Use the Copy button. * **File Content:** A unique token string (e.g., 30924A299885503882D10144825CD4F5). Use the Copy button. * **Download File link:** Click this to download the ready-made .txt file - saves you creating it manually. * **Full Path:** The exact URL where the file must be accessible (e.g., ). ### Step-by-Step Instructions for File-Based Validation 1. *Click **Download File** in the popup to download the ready-made file.* 2. *Upload the file to your web server at exactly this path:* *`http://[yourdomain.com]/.well-known/pki-validation/[filename].txt`* 3. *Do not change the filename or its contents.* 4. *Verify the file is accessible:* * *Open the URL in a browser.* * *If you see the token text displayed or the file downloads, it is accessible.* * *A 404 error means the file is not in the correct location.* 5. *Once the file is accessible at the correct URL, click **Verify Now** in the popup.* 💡 **TIP** To upload the file, use: * Your hosting control panel's File Manager (cPanel, Plesk) * An FTP client such as FileZilla * Your hosting provider's file upload service ***Choose the one applicable to your scenario based on the above description*** ## Variant Differences - Domain Verification #### DV SSL Certificate * DNS TXT Record (recommended) * HTTP/HTTPS File-Based #### DV Wildcard SSL Certificate * DNS TXT Record ONLY #### DV UCC SSL Certificate * DNS TXT Record (recommended) * HTTP/HTTPS File-Based #### DV Wildcard UCC SSL Certificate * DNS TXT Record ONLY for each wildcard domain 📌 **InCommon Note** The DNS TXT Record method is recommended for all InCommon institutional certificates. If your domain DNS is managed by your institution's IT department: * Provide them with the Host and Value shown in the popup. * Ask them to add the TXT record. For UCC variants with multiple domains from different departments, each domain administrator may need to be contacted separately. ## After Domain Verification Succeeds *Once you click **Verify Now** and the CA confirms your domain control, a green success popup appears:* 📌 **NOTE** *"Thank you for proving the domain ownership for \[your domain]. Domain Verification is completed successfully. Please track your order and complete your pending actions to speed up the certificate issuance process."* *Click **OK**.* *The Order Actions list updates:* * *Domain Verification now shows a green **Completed** status.* * *Steps 1, 2, and 3 will all display green Completed indicators.* ⚠️ **IMPORTANT** **Reminder about Administrator Approval** Even after domain verification is complete, the certificate will **NOT** be issued until the CERTInext Account Administrator approves the order. If the Certificate Status remains **Pending for Approver** for an extended period after domain verification: * Contact your IT department. * Request that the order be approved in CERTInext. # DV Certificate Download ## Certificate Issued Once both domain verification is complete AND the Administrator has approved the order, emSign issues the certificate. *The Order Actions list on the emSign Subscriber Portal updates to show all four steps as Completed (green), and Step 4 - Certificate Download becomes active.*
The Order Details sidebar on the right updates to show: * Order Status: Order Accepted (orange - this is normal at this stage) * Certificate Status: Certificate Generated (green) - this is the key status confirming your certificate exists and is ready to download ### Downloading the Certificate *You can download the issued certificate in two ways: via the emSign Subscriber Portal (Step 4) or directly from CERTInext.* Both methods give you the same certificate files. ### Method A - Download via the emSign Subscriber Portal
*Expanding the '4. Certificate Download' row shows a green 'Certificate Issued' badge and the following message:* **📌 NOTE** Your certificate has been issued and ready for download. An email containing certificate download instructions has been sent to your email address. If you have not received an email, please click Resend Email to resend it. Your certificate is based on the CSR submitted by you. Please ensure to import / use the certificate against the same key-pair from where the CSR was generated. #### Resend Email *Resends the certificate download notification email to your registered email address. Use this if you did not receive Email 2.* #### Download Certificate *Directly downloads the certificate from this page - without needing the email link.* ### Method B - Email 2: 'Your Certificate is ready for download' *A second email arrives at your Requestor Email ID (and delegated email, if set).*
#### Email Details * Subject Line: ORDER #\[your order ID] - Your Certificate is ready for download * Download Certificate button: Orange button - click to go directly to the certificate download page. * Download URL: A URL you can copy and paste into your browser if the button does not work. **💡 TIP** Save this email. *The download link allows you to access the certificate directly at any time. If you miss it, use the Resend Email button in the emSign Subscriber Portal, or download directly from CERTInext via the 3-dot menu on your order.* ### Choosing the Download Format *Clicking the Download Certificate button (from the email or the emSign portal) takes you to the emSign download page. Click the orange Download Certificate button on that page. A popup titled 'Select the Format to download' appears with four options:*
#### DER Encoded Binary X.509 (.CER) * A binary (machine-readable) format. * The file is not human-readable text. * Suitable for: * Java applications * Some enterprise systems * Older Microsoft environments #### Base-64 Encoded X.509 (.CER) * A text-based format with a .CER file extension. * Human-readable text containing the certificate. * Suitable for: * Windows systems * IIS (Internet Information Services) web server #### Base-64 Encoded X.509 (.CRT) * A text-based format with a .CRT file extension. * Same content as .CER - just a different file extension recognised by Linux servers. * Suitable for: * Apache * Nginx * Other Linux-based web servers * The most commonly used format. #### Zip (Recommended if Unsure) * A compressed ZIP archive containing multiple certificate files: * Your server certificate * The intermediate CA chain certificate * The root CA certificate * Recommended if you are unsure which format to choose. * Provides all certificate files in one download. **💡 TIP** **Which format should I choose?** * Apache or Nginx (Linux): choose Base-64 encoded X.509 (.CRT) * Windows IIS or Microsoft environments: choose Base-64 encoded X.509 (.CER) * cPanel or Plesk (shared hosting): choose Base-64 encoded X.509 (.CRT) * If you are unsure: choose Zip - it contains everything and you can use whichever file you need *Choose the one applicable to your scenario based on the above description* **⚠️ IMPORTANT** Your certificate file does NOT contain your private key. Your private key was created on your server when you generated the CSR - it never left your server. The certificate file and the private key must BOTH be present on your server to enable HTTPS. Never share your private key with anyone. Wildcard and Wildcard UCC certificates: if you install the certificate on multiple servers (e.g., web server, mail server, API server), each server needs a copy of both the certificate file AND the matching private key. ### Method C - Download Directly from CERTInext 1. *Log in to CERTInext.* 2. *Go to Certificates > Orders in the left sidebar.* 3. *Find your certificate order in the list (Certificate Status should show 'Certificate Generated' in green).* 4. *Click View to open the order details.* 5. *Click the 3-dot menu in the top-right corner.* 6. *Select 'Download Certificate' from the menu.* *Choose the one applicable to your scenario based on the above description* **📌 NOTE** *The 3-dot menu also shows 'Reissue Certificate' - this allows you to reissue the certificate (for example, if you need to provide a new CSR due to a key compromise) within the same validity period. The reissued certificate will have the same expiry date as the original. Contact your administrator before reissuing.* ### Final Order Status - The Order is Complete *After you download the certificate, return to CERTInext and check **Certificates > Orders**. Click **View** on your order. The status has now fully updated.* **Order Status** Order Fulfilled (green badge) **Certificate Status** Certificate Downloaded (green badge) **Subscription Start Date** The date and time the certificate was issued (e.g., 27 May 2026, 10:30 UTC) **Subscription End Date** Exactly 1 year later (e.g., 27 May 2027, 10:30 UTC) - or the end of your selected validity period **Subscription Status** Active (green) **Issuer CA Information - Root CA** emSign QA SSL RSA CA - G1 (or similar emSign root CA name) **CA Type** Public **📌 NOTE** These details confirm your certificate was successfully issued by emSign and is now active. Your website is ready to be secured with HTTPS once the certificate is installed on your server. # Ordering OV Public Trust Certificates ## What Is an OV Certificate? An Organization Validation (OV) SSL/TLS certificate does two things simultaneously: it encrypts all data flowing between your web server and visitors' browsers, and it proves to those visitors that your organization has been independently verified by a trusted Certificate Authority (the CA). Unlike a basic Domain Validation (DV) certificate, which only checks that you control a domain name, OV certificates require the CA to confirm that your company or organization legally exists. This makes OV certificates the standard choice for corporate websites, customer portals, e-commerce stores, and any site where organizational identity matters. The issuance timeline is typically 3-5 business days because the CA must complete the organization verification step. Once your organization is validated and stored in the system, subsequent OV certificate orders for the same organization can be processed faster. ### The Four OV Product Variants - At a Glance CERTInext offers four variants of the OV certificate, each designed for a different hosting scenario: **OV SSL Certificate** Domains Included (base): 1 Extra SAN/Domain Cost: N/A Domain Format: domain.com Covers All Subdomains: No (only www if enabled) www Variant Option: Yes (checkbox) DCV Verifications: 1 Add/Remove SANs post-issuance: No Consent Confirmation Dialog: Not required **OV Wildcard SSL** Domains Included (base): 1 wildcard Extra SAN/Domain Cost: N/A Domain Format: \*.domain.com Covers All Subdomains: Yes - all subdomains www Variant Option: No (disabled) DCV Verifications: 1 Add/Remove SANs post-issuance: No Consent Confirmation Dialog: Required **OV UCC SSL** Domains Included (base): Up to 4 Extra SAN/Domain Cost: $84 per domain Domain Format: Multiple domains Covers All Subdomains: No - each listed separately www Variant Option: Yes (checkbox) DCV Verifications: One per domain Add/Remove SANs post-issuance: Yes Consent Confirmation Dialog: Required **OV Wildcard UCC SSL** Domains Included (base): Up to 4 wildcards Extra SAN/Domain Cost: $490 per domain Domain Format: Multiple \*.domain.com Covers All Subdomains: Yes - all subdomains per wildcard www Variant Option: No (disabled) DCV Verifications: One per domain Add/Remove SANs post-issuance: Yes Consent Confirmation Dialog: Required #### **Choosing the Right Product** **Use OV SSL Certificate** if you need to secure one specific domain (e.g., [www.example.com](http://www.example.com)). **Use OV Wildcard SSL** if you need to secure a domain and ALL its sub-domains (e.g., \*.example.com covers mail.example.com, shop.example.com, etc.). **Use OV UCC SSL** if you need to secure several different domain names under one certificate (e.g., example.com + example.net + another-domain.com). **Use OV Wildcard UCC SSL** if you need to secure multiple wildcard domains under one certificate (e.g., \*.example.com + \*.example.net). ### Prerequisites - Before You Begin Have the following ready before starting an application: **CERTInext account**: Log in at your organization's CERTInext portal URL. Your administrator provides login credentials. **Certificate Signing Request (CSR)**: A CSR is a block of encrypted text generated on your web server. It contains your public key and basic organizational details. Generate it using your web server software (e.g., OpenSSL, IIS, cPanel) before starting the application. **Domain name(s) to secure:** Know the exact domain(s) you want the certificate to protect. For Wildcard, the format is \*.yourdomain.com. For UCC/Wildcard UCC, list all domains upfront. **Organization details**: Legal organization name, registered address, country, state/province, and locality - as they appear in official records. These must match what the CA verifies. **Organization representative info**: Full name and contact details (email, phone) of the person who will act as the certificate subscriber. **Account credit or payment method**: Sufficient account credit balance or a payment card for the Pay Online option. **Access to DNS provider (for DCV)**: After payment you must prove domain ownership via DNS. You (or your IT/domain administrator) will need to create a DNS TXT record at your domain's DNS provider. # Phase 1 Steps This phase covers the seven-step application wizard inside CERTInext. Click New Certificate in the left navigation panel to begin. A side progress bar tracks your position through all seven steps. **Important - Progress Bar** The left-side steps panel shows all seven steps. Steps with a tick mark are completed. You can click Back at any step to return and edit without losing later data, except where explicitly noted. **The seven steps in Phase 1 are:** Step 1 - Choose Product & Validity Step 2 - Certificate Signing Request (CSR) Step 3 - Organization Information Step 4 - Organization Representative Information Step 5 - Certificate Information Step 6 - Additional Information Step 7 - Order Summary & Payment # Step 1 - Choose Product & Validity **Important Documentation Conventions:** Normal text below provides feature descriptions and explanatory information. *Italicized text* indicates navigation paths, procedures, and actions to be performed within the CERTInext platform. *This is the first screen you see after clicking New Certificate. You select which OV product to purchase and for how long.*
#### Common Fields (all four products) **Group**: Your organization account name in CERTInext (e.g., ABC limited). *This is pre-assigned and cannot be changed here. No action needed - confirm this is your correct account.* **CA Source**: The Certificate Authority that will issue the certificate. *emSign (eMudhra's trusted CA) is pre-selected. Leave as emSign unless your administrator has configured an alternative.* **Certificate Type**: The category of certificate. *SSL/TLS Certificates is pre-selected. Leave as SSL/TLS Certificates.* **Product**: The specific certificate product you wish to purchase. *Click the dropdown and select the desired OV product.* **Subscription For**: The validity period of the certificate: 1 Year, 2 Years, or 3 Years. *Select the appropriate validity period*. Longer subscriptions lock in pricing and reduce renewal effort. Note: industry standard maximum is 1 year for public trust, but multi-year subscriptions provide continuous coverage through automatic renewal. **Cost**: The price for the selected product and validity period (in USD). Auto-calculated. Review before clicking Next. #### 1b. Product-Specific Fields **Product Difference** *The 'No. of Domains' dropdown appears ONLY for OV UCC SSL and OV Wildcard UCC SSL.* It is not present for OV SSL Certificate or OV Wildcard SSL. **No. of Domains (UCC & Wildcard UCC only)**: Sets how many domains the certificate will cover. *The default and minimum included in the base price is 'Upto 4'. You may add more during Step 5 at an extra per-domain cost. Leave at 'Upto 4' if you need four or fewer domains. If you already know you need more, you can add them individually in Step 5 (Certificate Information).* **Extra SAN note (UCC & Wildcard UCC only)**: A note displayed beneath the Cost field informing you of the per-domain cost for SANs beyond the included base. Take note of this cost before proceeding. Each extra domain added in Step 5 will increase the Grand Total accordingly. #### 1c. Certificate Features Panel A blue information panel at the bottom of the screen describes what all OV SSL/TLS certificates include: Secures Single, Wildcard, Multiple Domains & Sub Domains Domain & Organization Validation Average Issuance Timeframe: 1-5 Business Days Unlimited Server Licenses Strongest SHA2 & ECC Encryption Major Browser & Mobile Device Compatibility Free Expert Support Automatic Renewal Reminders and Early Renewal Options **Action** *After reviewing all fields and the cost, click Next to proceed to Step 2.* # Step 2 - Certificate Signing Request (CSR) A Certificate Signing Request (CSR) is a file you generate on your web server before applying for the certificate. It contains your public key and basic identity information. The CA uses the public key in your CSR to create your certificate - the corresponding private key remains securely on your server and is never sent to anyone.
**Important** The public key and signature algorithm from your CSR are used for certificate generation. Subject details such as Organization, Country, and State are pre-filled from your CSR for convenience but can be edited. The values you submit in the form will be the final values in the issued certificate. ***Skip CSR**: An option to bypass CSR submission at this stage if you do not yet have one prepared. The CSR will then need to be provided before the certificate can be issued. Only use Skip CSR if specifically instructed by your administrator. In most cases, have your CSR ready before starting the application.* ***Upload CSR (Choose File button)**: Upload a CSR file (.csr or .txt) directly from your computer. Click Choose File, navigate to your saved CSR file, and select it. The CSR text will be loaded automatically.* ***Paste CSR (text area)**: An alternative to file upload - paste the raw CSR text directly into this box. Copy the full CSR text from your server (including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines) and paste it into this field.* **CSR Format - What It Looks Like** A valid CSR begins with: -----BEGIN CERTIFICATE REQUEST----- Followed by several lines of base64-encoded text. Ends with: -----END CERTIFICATE REQUEST----- *Ensure you copy the entire block including the BEGIN and END lines.* **Key Size Recommendation** *When generating your CSR, use a minimum key size of 2048 bits (RSA) or 256 bits (ECC/ECDSA).* CERTInext shows the key size and algorithm from your CSR on the final order view. The screenshots in this guide show RSA 4096-bit keys. **Action** *After uploading or pasting your CSR, click Next to proceed.* # Step 3 - Organization Information This step links your certificate order to a legally verified organization. The CA will validate your organization's details before issuing the certificate.
**Instant Issuance - Pre-validated Organizations** *If your organization has been previously validated by the CA, you will see an 'Instant' badge next to it and a green notice: 'You have 1 validated organization(s) - Instant issuance available.'* *Selecting a pre-validated organization skips the organization re-validation wait, significantly speeding up certificate issuance.* New organizations require validation, which typically takes 1-3 business days. #### Selecting Your Organization *The screen shows a list of your account's organizations. Use the tabs to filter: All, Validated, or Pending. Click the row of your organization to select it. The fields below will auto-populate.* **Organization selector**: A searchable list of organizations linked to your CERTInext account. Each entry shows the organization name, ID number, location, and validation status. *Click on your organization's row to select it. If you have only one organization, it will appear pre-selected*. **+ Add a new organization**: Button to register an organization that is not yet in the system. *Click only if your organization does not appear in the list*. New organizations must complete a validation process (1-3 business days) before certificates can be issued. *Fill in all required details carefully - they must match official legal records.* **Organization Name (\*)**: The full legal name of your organization. *Automatically filled from the selected organization. Verify it matches your official registration exactly*. **Organization Unit**: The department or division within the organization (optional). *Leave blank if not applicable, or enter a relevant department name (e.g., 'IT Security', 'Operations').* **Street Address 1 (\*)**: The first line of the organization's registered street address. *Automatically filled. Verify accuracy.* **Street Address 2**: Second address line (optional, e.g., Suite or Floor number). *Fill in if applicable.* **Country (\*)**: The country where the organization is registered. *Automatically filled from the validated organization record.* **State / Province (\*)**: The state or province of the organization's address. *Automatically filled. Select from dropdown if required.* **Locality (\*)**: The city or locality of the organization's address. *Automatically filled. Verify it is correct.* **Postal Code / Post Office Box Number (\*)**: The postal/ZIP code of the organization's address. *Automatically filled. Verify accuracy.* **Note - Organization Details Accuracy** *The organization details entered here must exactly match the information on official government or business registration documents (e.g., company registration certificate, articles of incorporation).* The CA will verify these details during the validation process. Discrepancies will cause delays or rejection of your application. **Action** *After selecting your organization and confirming the details are accurate, click Next.* # Step 4 - Organization Representative This step identifies the person who will act as the certificate subscriber - the individual who is responsible for the certificate on behalf of the organization. This person will receive all certificate-related emails including order confirmation, verification requests, and the download notification.
**Choose User (New / Existing)**: *Toggle between creating a new user profile or selecting an existing one from your account.* **New**: *Enter the representative's details manually.* **Existing**: *Select from a pre-existing list of users in the system. If this is your first certificate order or the representative is not yet in the system, choose New. Otherwise, choose Existing and select the appropriate user.* Name (\*): Full name of the organization representative. *Enter the person's legal first and last name. Avoid abbreviations.* Email ID (\*): The email address of the representative. This is where all certificate notifications will be sent. *Enter a valid, monitored business email address. All post-submission actions (consent, DCV, download) are triggered via this email. Do not use a shared or unmonitored mailbox unless someone actively reads it.* Mobile Number (\*): The representative's mobile/phone number (including country code). *Select the country dial code from the dropdown, then enter the number.* This may be used for identity verification by the CA. Certificate Download Delegation: An optional section to designate a different person who is authorized to download the issued certificate on behalf of the representative. *Only fill in if the person who applied is not the same person who will download and install the certificate.* *Leave blank if the representative will handle the download themselves.* Contact name (Delegation): Name of the person delegated to download the certificate. *Enter only if using Certificate Download Delegation.* Email ID (Delegation): Email address of the delegated downloader. *Enter only if using Certificate Download Delegation. This person will receive the download notification email.* **Note - Representative Email** The email address entered here is the most critical field in this step. *Every post-payment action - consent requests, domain verification instructions, and the final certificate download link - is sent to this address.* *Ensure it belongs to someone who will monitor it actively until the certificate is issued.* **Action** *After completing the representative's details, click Next.* # Step 5 - Certificate Information This step shows a summary of your organization's details (auto-filled, read-only) and collects the domain name(s) the certificate will protect. This is where the four products differ most significantly.
#### 5a. Organization Summary (Read-Only - All Products) *The top portion of this screen displays the organization details you confirmed in Step 3. These fields are informational only and cannot be edited here. If you notice an error, click Back to return to Step 3.* Organization Name - Your organization's legal name (e.g., ABC limited) Organization Unit - Department name or blank if not specified Street Address 1 - Registered street address Street Address 2 - Additional address details or blank Country - Country of registration (e.g., United States of America (USA)) State / Province - State or province (e.g., California) Locality - City (e.g., California) Postal Code / Post Office Box Number - ZIP/postal code (e.g., 8765678) #### 5b. Domain Name Fields - Differences by Product **Product Difference** The domain entry section below the organization summary is the key difference between the four OV products. Read the sub-section for your chosen product carefully. **OV SSL Certificate - Single Domain**
**Automatically secure 'www' variant of websites**: *A checkbox that, when ticked, instructs the system to also secure the [www.yourdomain.com](http://www.yourdomain.com) version of your domain automatically, at no extra cost. Tick this box if your website is accessed both with and without 'www' (which is the case for most websites). Leave unticked only if your domain is exclusively accessed without [www](http://www).* **Domain Name (\*)**: *The single fully-qualified domain name (FQDN) the certificate will protect (e.g., shop.example.com). Type the domain name exactly as it should appear in the certificate. Do not include 'http\://' or 'https\://'. Example: example.com or portal.example.com* **Note - OV SSL Domain** Enter only the base domain or subdomain you want to protect. A single OV SSL certificate covers exactly one domain. The 'Automatically secure www variant' checkbox adds [www.yourdomain.com](http://www.yourdomain.com) as an additional SAN (Subject Alternative Name) at no extra cost - tick it unless you have a specific reason not to. **OV Wildcard SSL Certificate - Single Wildcard Domain**
**Domain Name (\*)**: The wildcard domain in \*.yourdomain.com format. The asterisk (\*) represents any single subdomain label. *Enter the wildcard domain using the \*.yourdomain.com format. Example: \*.example.com - this will cover mail.example.com, shop.example.com, portal.example.com, etc. Do NOT include the asterisk if you want the root domain only; use OV SSL for that.* **Note - OV Wildcard SSL Domain** The 'www variant' checkbox is not available for Wildcard certificates because \*.domain.com already covers [www.domain.com](http://www.domain.com) (www is itself a subdomain). **Note**: a Wildcard certificate covers only ONE level of subdomain depth. \*.example.com covers shop.example.com but does NOT cover deep.shop.example.com. **OV UCC SSL Certificate - Multiple Domains**
**Automatically secure 'www' variant of websites**: *Tick to also secure the [www.yourdomain.com](http://www.yourdomain.com) version of the primary domain automatically. Tick if applicable for your primary domain.* **Domain Name (\*)**: The primary (main) domain name the certificate will protect. *Enter your primary domain name (e.g., example.com).* **Additional Domain Names (\*)**: A multi-entry field where you add all extra domain names beyond the primary domain. *Each domain appears as a removable tag. The included base is up to 4 domains total (primary + additional).* Beyond 4, each domain is charged at $XXX USD. *Click inside the 'Select' dropdown/input box and type each additional domain, pressing Enter or clicking the '+' button after each one. You can also click 'Import additional domain' to paste or upload a list of domains in bulk. Click the X next to any domain to remove it.* **Import additional domain (button)**: Allows bulk import of multiple domain names at once instead of adding them one by one. *Click to open an import dialog. Paste a list of domain names (one per line) and confirm.* **Clear (button)**: Removes all entries from the Additional Domain Names list. Use only if you want to start the domain list from scratch. **Note - OV UCC SSL Domains & Pricing** The base price covers up to 4 domains (1 primary + up to 3 additional). Each domain beyond 4 costs extra. *The Order Summary in Step 7 will display a separate line item: 'Additional SAN Cost' so you can verify the total before paying.* Plan your domain list carefully - domains can be added/removed after issuance using the 'Add / Remove SANs' action, but each change may require additional domain verification. **OV Wildcard UCC SSL Certificate - Multiple Wildcard Domains**
**Domain Name (\*)**: The primary wildcard domain in \*.yourdomain.com format. *Enter the primary wildcard domain (e.g., \*.example.com).* **Additional Domain Names (\*)**: Additional wildcard or regular domain names beyond the primary. Base price covers up to 4 entries total. Each additional domain beyond 4 costs extra. *Add each additional wildcard domain (e.g., \*.example.net, \*.another-domain.com) using the same method as OV UCC SSL described above.* **Import additional domain (button)**: Bulk import of additional domains. *Same as OV UCC SSL - paste a list for bulk entry.* **Note - OV Wildcard UCC SSL Domains & Pricing** The base price covers up to 4 wildcard domains. Each additional wildcard domain beyond 4 costs extra. This is significantly higher than the UCC SAN cost because each wildcard entry covers an entire subdomain namespace. The 'www variant' option is not available here - wildcard domains already cover www as a subdomain. **Action** *After entering all domain name(s), click Next to proceed to Step 6.* # Step 6 - Additional Information (Optional) This step is the same for all four OV products. All fields are optional but some, such as auto-renewal, are pre-configured with sensible defaults.
**Tags**: Custom labels you can attach to this order for internal tracking and reporting within CERTInext (e.g., 'Production', 'Project-Alpha', '2026-Q2'). Click '+ Add Tag', type your tag text, and press Enter. Add multiple tags as needed. Tags are for your internal use only and do not appear on the certificate. **Order Remarks**: A free-text notes field for any special instructions or internal references related to this order. Type any notes relevant to your team or to support if you need to raise a query. This text is visible to the CA and CERTInext administrators. **Technical Point of Contact Information**: Checkbox - expands to collect the name, email, and phone number of the technical person responsible for managing this certificate (e.g., the system administrator who will install it). *Tick and fill in only if the technical contact is different from the Organization Representative entered in Step 4*. Useful for larger organizations where the certificate requester and the server administrator are different people. **KYC Documents**: Checkbox - expands to allow you to upload Know Your Customer (KYC) verification documents (e.g., company registration certificate, utility bill, government ID). *Tick and upload documents if the CA requests them for your organization or if this is a new organization requiring validation*. Providing these upfront can speed up the validation process. **Additional email recipients**: Checkbox - expands to add extra email addresses that should receive certificate-related notifications. Tick and add email addresses if others in your organization (e.g., a manager, security team) should also receive order status updates and the download notification. **Auto-renew certificates until coverage**: *Checkbox (ticked by default) - instructs CERTInext to automatically initiate certificate renewal before expiry, ensuring continuous HTTPS coverage without manual intervention. Leave ticked (recommended).* Only untick if you want to manage renewals manually. **Set renew criteria - Before \[N] days of certificate expiry**: Configures how many days before expiry the auto-renewal process begins. Default is 15 days. *Click the dropdown to adjust the lead time (e.g., 30 days gives more time for any renewal complications). 15 days is the standard minimum recommended.* **Action** *Review and adjust any optional settings, then click Next to proceed to the Order Summary.* # Step 7 - Order Summary & Payment The final step before payment. Review everything carefully. *A 'Payment Pending' badge appears in the top-right corner.*
#### 7a. Product Information Panel **Certificate** Type: The category of certificate (SSL/TLS Certificates). Verify this matches your intended purchase. **Product Name:** The specific OV product selected (e.g., OV SSL Certificate, OV SSL Certificate Wildcard, OV SSL Certificate UCC, OV SSL Certificate Wildcard UCC). Confirm this is the correct product variant. **Validity Period:** The subscription duration selected in Step 1 (e.g., 1 Year). Confirm the correct duration. **Domain Count**: The total number of domains the certificate will cover. For OV SSL and Wildcard SSL: 1. For UCC/Wildcard UCC: reflects the total number of domains entered in Step 5. #### 7b. Certificate Information Panel A summary of all organization details and domain name(s) entered across previous steps. Scroll through to verify all values are correct. If anything is wrong, click Back to return to the relevant step. #### 7c. Payment Information Panel **Credit Usage Note** A banner on screen states: 'On click of Use Credits button, amount will be deducted from \[Your Organization] balance.' Confirm your account balance is sufficient before choosing Use Credit. **Current Balance**: Your organization's current pre-paid credit balance in USD. Verify you have sufficient balance if paying by credit. If the balance is less than the Grand Total, use Pay Online instead. **Certificate Price (upto 4) (UCC/Wildcard UCC only)**: The base certificate price covering the included number of domains (up to 4). Informational - auto-calculated. **Additional SAN Cost (UCC/Wildcard UCC only):** The additional cost for any domains beyond the included base quantity. Informational. Verify this matches the number of extra domains you added in Step 5. **Grand Total**: The final total amount in USD payable for this order. Verify this matches your expectation before proceeding to payment. **Subscriber Agreement checkbox:** A mandatory checkbox confirming you have read and agreed to eMudhra emSign's Subscriber Agreement. You MUST tick this checkbox before payment. Click the 'Subscriber Agreement' hyperlink to read the full terms if you have not done so. **Note - Subscriber Agreement** Ticking the Subscriber Agreement checkbox is a legal acknowledgement that you agree to eMudhra emSign's terms and conditions for certificate issuance and usage. Read the agreement before ticking. The checkbox is mandatory - you cannot proceed to payment without it. #### 7d. Payment Buttons **Save and Exit**: Saves your application as a draft and exits the wizard. You can return to complete payment later from the Orders list. **Pay Online**: Opens a payment gateway to pay the Grand Total using a credit/debit card or other supported online payment method. **Use Credit**: Deducts the Grand Total from your organization's pre-paid credit balance in CERTInext immediately. Order is submitted upon confirmation. **Action** *Tick the Subscriber Agreement checkbox, then click either Pay Online or Use Credit to submit your order.* *After successful payment, you will be taken to the Order View page.* # Phase 2 Steps (via email & emSign) After payment, your order enters a multi-step verification and issuance workflow. Most steps happen automatically or require brief actions from you via email links. This section explains every stage in sequence. **The Phase 2 steps are:** Order Confirmation - receive email and view order in CERTInext Order Tracking - access the emSign Subscriber Portal and review Order Actions Organization Re-use Consent - provide consent if re-using a validated organization Subscriber Agreement - confirm agreement for this specific order Domain Verification - complete Domain Control Validation (DCV) for each domain Certificate Download - download your issued certificate in the preferred format Order Fulfilled - certificate active and installed on your server # OV Order Confirmation #### 2.1 CERTInext Order View - Immediately After Payment You are automatically redirected to the Order View page in CERTInext. Bookmark or note the Order ID displayed at the top - you will need it for any support queries.
**Order ID**: Unique reference number for your certificate order. Keep this safe. **Ordered Date**: Date and time the order was placed. **Product**: The OV certificate product ordered. **Group**: Your organization account name. **CA Source**: Certificate Authority: emSign. **Certificate Price**: Total amount charged for this order (USD). **Order Status:** 'Order Accepted' (orange badge) - the order has been received and accepted for processing. **Certificate Status**: 'Pending for Approval' (orange badge) - the certificate is awaiting CA validation and issuance steps. The lower portion of the Order View page shows detailed panels: SSL Subscription Information, Auto-Renewal Configuration, Organization Representative Information, Certificate Signing Request (CSR) Information, Organization Information, Certificate Information, Additional Information, and Renewal Notifications. **Note - Subscription Dates** Subscription Start Date and Subscription End Date will be blank at this stage. They are populated once the certificate is issued and the subscription becomes Active. #### 2.2 Order Confirmation Email *Within minutes of payment, the Organization Representative receives an email notification confirming the order was placed successfully.*
Subject: ORDER #\[Order ID] - Your Order is Successful Order ID: Your unique order reference number Ordered Date: Date and time (UTC) Product & Validity: Product name and subscription period Identifier: The primary domain name secured by this certificate Subscription Per: e.g., 1 Year(s) Track Order button: Orange button linking to the emSign Subscriber Portal for your order **Action** *Click 'Track Order' to open the emSign Subscriber Portal where you will complete the remaining verification actions.* *You can also access this portal via the link in subsequent notification emails.* # OV Order Tracking #### 2.3 emSign Subscriber Portal - Order Actions Overview The emSign Subscriber Portal is eMudhra's certificate management interface for subscribers. *It shows the status of all five verification actions that must be completed before your certificate is issued.*
The portal header shows your name and the Certificate Requester Information. The Order Details panel on the right shows Order ID, Product & Validity, primary Domain Name, Order Status, and Certificate Status. #### The Five Order Actions 1\. **Organization Verification**: Confirms the organization details are accurate and the organization is validated by the CA. This is typically auto-completed if you selected a pre-validated organization in Step 3 of the application. 2\. **Submit CSR**: Confirms your CSR was accepted. Auto-completed if you submitted a CSR in Step 2. 3\. **Subscriber Agreement**: You must formally agree to the emSign Subscriber Agreement for this specific order. Status will show 'Awaiting Customer Action' until you complete it. 4\. **Domain Verification**: You must prove you control each domain on the certificate. Status shows 'Awaiting Customer Action'. Covered in detail in Section 2.6. 5\. **Certificate Download**: Available once all other steps are complete. Status progresses from 'Issuance Pending' to 'Certificate Issued'. Covered in Section 2.7. **Note - Action Status Colors** *Green = Completed.* *Orange = Awaiting Customer Action (you must do something).* *'Issuance Pending' (orange) on step 5 means the CA is still processing - no action needed yet.* *Certificate Status in the right panel shows the overall progress: 'Pending for Approval' - 'Approved' - 'Certificate Generated'.* # Organization Reuse Consent #### 2.4 Organization Re-use Consent (If Applicable) When your order re-uses a previously validated organization (which is the standard case when selecting a pre-validated organization in Step 3), the system requires the Organization Representative to formally consent to this re-use. This is a security measure to prevent unauthorized use of an organization's validated identity. **When Does This Apply?** Consent is required whenever a new certificate order re-uses an organization's existing validated details and subscriber agreement. If this is your very first order for an organization that is being validated fresh, you will not see a consent request at this stage - the CA will contact you separately for validation. #### 2.4a Consent Required Email
*The Organization Representative receives an email with the subject: 'ORDER #\[ID] - Consent Required to re-use \[Organization] Organization'.* The email contains the order details (Order ID, Ordered Date, Product & Validity, Identifier/domain, Ordered By, Organization Name, Organization Country) and a 'Click here' hyperlink to open the consent page. **Action** *Click the 'Click here' link in the email to open the emSign Consent page.* #### 2.4b emSign Consent Page
**The consent page displays:** *A notification message identifying the order, the organization being re-used, and the person who placed the order.* Order details: Order ID, Date Ordered, Ordered By Organization details: Organization ID, Organization Name, Country Consent statement: 'Accepting this consent means that you allow this order to re-use your organization information & subscriber agreement.' Two buttons: Accept (orange) and Decline (red) **Important** *If you recognize this order and authorize it, click Accept.* *If you did NOT authorize this order or do not recognize it, click Decline immediately and contact your CERTInext administrator.* Declining will halt the certificate issuance for this order. #### 2.4c Consent Confirmation Dialog (OV Wildcard SSL, OV UCC SSL, OV Wildcard UCC SSL only) **Product Difference** *For OV Wildcard SSL, OV UCC SSL, and OV Wildcard UCC SSL orders, clicking Accept on the consent page triggers an additional Consent Confirmation dialog.* This extra step does NOT appear for OV SSL Certificate orders.
*A modal dialog appears asking: 'Are you sure you want to accept the consent?'* *Click Yes to confirm your consent.* *Click No to cancel and return to the consent page.* #### 2.4d Consent Accepted Confirmation
*After clicking Accept (and Yes in the confirmation dialog where applicable), a confirmation screen displays: 'Thank you for providing your consent to re-use \[Organization Name].' This confirms the consent has been recorded.* **Note - Subscriber Agreement** *Once consent is provided, the Subscriber Agreement step (Step 3 in the Order Actions) is typically auto-completed as part of the consent process.* *Return to the emSign Subscriber Portal to verify the status.* # Subscriber Agreement #### 2.5 Subscriber Agreement The Subscriber Agreement step confirms that the certificate subscriber has formally read and agreed to eMudhra emSign's terms and conditions for this specific certificate order.
*In most scenarios where you re-use a validated organization and provide consent (Section 2.4), the Subscriber Agreement step is auto-completed as part of the consent workflow. If it still shows 'Awaiting Customer Action', click the '+' expand icon next to Step 3 to view and accept the agreement directly in the portal.* **Note** *Once all of Steps 1, 2, and 3 show 'Completed' (green), the system proceeds to Step 4: Domain Verification.* *You may receive an email notification prompting you to complete domain verification.* # Domain Verification #### 2.6 Domain Control Validation (DCV) Domain Control Validation is the process by which you prove to the Certificate Authority that you genuinely control each domain name listed on the certificate. No certificate can be issued until DCV is complete for all domains.
#### 2.6a Domain List *When you expand Step 4 (Domain Verification), you see:* *'Total Domains: \[N]' - the count of domains requiring verification.* *Each domain listed with a status icon (orange warning = pending, green = verified) and a 'Verify' button.* *For OV SSL and OV Wildcard SSL: 1 domain to verify.* *For OV UCC SSL and OV Wildcard UCC SSL: one entry per domain - you must verify each domain individually.* **Product Difference** OV UCC SSL and OV Wildcard UCC SSL require domain verification for EVERY domain listed on the certificate. If you have 5 domains, you must complete 5 DCV processes. For efficiency, work through them in sequence. The DCV Instructions at the bottom of the page provide general guidance applicable to all domains. **The DCV Instructions panel reads:** A Domain Control Validation or DCV must be completed before issuing an SSL/TLS certificate. *Please click Verify Domain against each domain name to select a DCV method and prove control over each domain.* *In case of Multi-Domain SSL Certificates, if the authorized domain name (base domain) ownership is proven then all the sub domains that have the same base domain name will be proven automatically. For example, if xyz.com domain control is proven then the entire sub domains like blog.xyz.com and mail.xyz.com will be proven automatically. Please note that, vice versa is not allowed.* #### 2.6b DCV Method - DNS TXT Record (Recommended) *Click the 'Verify' button next to a domain. A modal dialog appears.*
**Technical Note** *The DCV modal includes a note: 'This is technical in nature. If you are not the right person, please contact your IT / Domain administrator.'* If you do not manage your DNS records yourself, forward the TXT record details (Host and Value) to your DNS administrator and ask them to create the record. **DCV Method dropdown**: The method used to prove domain ownership. *'DNS TXT Record (Most Preferred)' is the recommended and pre-selected method. Leave as 'DNS TXT Record (Most Preferred)' unless your DNS provider does not support TXT records*, in which case consult your IT administrator. **Record Type:** The type of DNS record to create: TXT. Always TXT for this method. **Host**: The hostname for the DNS TXT record. This is the domain name itself (Copy button available). Copy this value exactly. Log in to your DNS provider's management panel, navigate to DNS settings for this domain, and use this as the Host/Name field when creating the TXT record. **Value**: The unique verification token that must be entered as the TXT record's value (Copy button available). Copy this token exactly. Enter it as the Value/Content of the new TXT record at your DNS provider. Do not add any extra spaces or characters. **Verify Now button**: Triggers the CA's system to check your DNS for the TXT record. ONLY click Verify Now after you have saved the DNS TXT record at your DNS provider AND allowed sufficient time for DNS propagation (see note below). **Close button**: Closes the modal without verifying. Click Close if you need to set up the DNS record first and return to verify later. **Note - DNS Propagation** After creating the DNS TXT record at your DNS provider, changes may take anywhere from a few minutes to 48 hours to propagate globally (depending on your DNS TTL settings). It is best practice to wait at least 15-30 minutes before clicking 'Verify Now'. If verification fails, wait longer and try again. Do not delete the TXT record until verification succeeds. #### 2.6c Domain Verification Success
*After successful verification, a success popup appears: 'Thank you for proving the domain ownership for \[domain]. Domain Verification is completed successfully. Please track your order and complete your pending actions to speed up the certificate issuance process.'* *Click OK to dismiss.* *The domain's status icon turns green.* *Certificate Status in the right panel updates to 'Approved'.* For UCC and Wildcard UCC products: repeat the Verify process for each remaining domain until all show green / Completed. # Interim DV Certificate No action is required from you. *Once all domain verifications (Action 1) are complete, the system automatically processes and issues the Interim DV Certificate. Monitor this step's status in the portal. It will move from "Issuance Pending" to "Completed" automatically*.
An **Interim Domain Validated (DV) Certificate** is a temporary, basic certificate issued once domain verification is complete, before the full EV organization validation is finalized. It provides DV-level HTTPS coverage for your domains while the CA completes the Extended Validation checks (organization verification, approver confirmation, etc.).
**What happens next:** \ *• Once the Interim DV Certificate is issued, you may optionally install it on your server for immediate basic HTTPS coverage.* \ *• The full OV Certificate will be issued after all remaining OV-specific verifications are approved.*
# OV Certificate Download #### 2.7 Certificate Issuance Once all Order Actions (Steps 1-4) are marked Completed, the CA processes and issues the certificate. This typically happens within minutes of the final verification step being approved, but may take up to 1-5 business days depending on CA processing.
All Steps 1-4: Completed (green): All required actions are done - the CA has everything it needs. Step 5 Certificate Download: Certificate Issued (green): The certificate has been generated and is ready to download. Certificate Status: Certificate Generated (green): Confirmed - your certificate exists and is waiting for you. Order Status: Order Accepted (orange): The order is still in the 'Accepted' state; it moves to 'Order Fulfilled' after download. #### 2.8 Certificate Download There are three ways to download your issued certificate: via the email notification, via the emSign Subscriber Portal, or directly from CERTInext. **2.8a Download Notification Email**
The Organization Representative receives an email with the subject: 'ORDER #\[ID] - Your Certificate is ready for download'. The email contains Order ID, Ordered Date, Product & Validity, and the Identifier (domain). It includes an orange 'Download Certificate' button and an alternative URL to paste into a browser. **Action** *Click the 'Download Certificate' button in the email. This opens the emSign Subscriber download page.* **2.8b emSign Subscriber Portal - Certificate Download Page**
**The download confirmation page shows:** A green tick with: 'Thanks for completing the necessary steps.' 'Your certificate has been issued and ready for download. To continue further, please click Download Certificate.' Order ID, Product & Validity, and Domain Name details. Orange 'Download Certificate' button. **2.8c Step 5 - Expanded Download Panel in Order Actions** Expanding Step 5 in the Order Actions list reveals the following download instructions and options: Step 5 Expanded - Text on Screen Your certificate has been issued and ready for download. An email containing certificate download instructions has been sent to your email ID. In case you have not received an email, please click Resend Email to resend the email. Your certificate is based on the CSR submitted by you. Please ensure to import / use the certificate against the same key-pair, from where the CSR was generated. Please follow the necessary instructions in your download notification email to download your certificate. ***Resend Email**: Re-sends the download notification email to the Organization Representative's email address. Use this if the original email was not received.* ***Download Certificate**: Initiates the certificate download directly from the portal, bypassing the email.* **Important** Your certificate is generated from the CSR you submitted. You MUST install and use the certificate on the same server and with the same private key that was used to generate the CSR. If you generate a new key pair, you must re-issue the certificate with a new CSR. **2.8d Selecting the Download Format**
When initiating a download from CERTInext, a 'Select the Format to download' dialog appears with four options: **DER encoded binary X.509 (.CER)**: Binary format of the certificate. Compact and widely supported by Windows systems and Java keystores. Choose this for Windows Server (IIS) or Java-based servers. Double-click the downloaded file to view/install in Windows Certificate Manager. **Base-64 encoded X.509 (.CER)**: Text-based (PEM) format of the certificate, saved with the .CER extension. Readable in a text editor. Choose this for most Linux/Unix-based servers (Apache, Nginx), or when your server software requests a .CER file. **Base-64 encoded X.509 (.CRT)**: Identical content to the Base-64 .CER above but saved with the .CRT file extension. Choose this when your server software (e.g., Apache, Nginx) expects a .crt file extension. **Zip:** A ZIP archive containing the certificate along with any intermediate/chain certificates. Recommended for most installations. Choose Zip if you are unsure, or if your server requires the full certificate chain. Extract the ZIP and follow your server's installation guide for the certificate and chain files. **Note - Which Format to Choose** If in doubt, choose Zip - it includes all necessary certificate files (end-entity certificate + intermediate certificates/chain). Your web server administrator will know how to handle the extracted files. For quick Windows inspection, choose DER or Base-64 .CER. *Choose the one applicable to your scenario based on the above description* **Action** *Select your preferred format and click Download.* *Save the file(s) to a secure location.* Follow your web server platform's documentation to install the certificate. # OV Order Fulfilled #### 2.9 CERTInext Order View - Final State After the certificate is downloaded, the Order View in CERTInext updates to its final state. Navigate to Certificates - Orders and click your order to view it. Order Status: Order Fulfilled (green) Certificate Status: Certificate Downloaded (green) Subscription Status: Active (green) Subscription Start Date: Date the certificate was issued Subscription End Date: Expiry date (Start Date + validity period, e.g., 1 year) #### 2.9a Order Action Menu *In the top-right corner of the Order View, a three-dot menu icon provides additional actions depending on the certificate type:*
Download Invoice: Available for all products. Track Order: Available for all products. Download Certificate: Available for all products. Reissue Certificate: Available for all products. Add / Remove SANs: OV UCC SSL and OV Wildcard UCC SSL only. Revoke Certificate: OV UCC SSL only (as shown). **Note - Reissue vs. Revoke** Reissue creates a replacement certificate (useful when you change your server or CSR). The old certificate is revoked as part of reissuance. Revoke permanently deactivates the certificate without replacement - only use Revoke if you are decommissioning the service or the key has been compromised and you will not replace it. # Ordering EV Public Trust Certificates ### What Is an EV Certificate? An Extended Validation (EV) SSL/TLS certificate provides the highest level of identity assurance available for websites. It encrypts all data flowing between a visitor's browser and your server and prominently displays your organization's verified identity to visitors. Unlike Domain Validation (DV) or Organization Validation (OV) certificates, EV certificates require the Certificate Authority (CA) to perform rigorous, multi-step verification of your organization's legal existence, physical address, operational status, and the authority of the individuals signing and approving the certificate request. This process is governed by strict CA/Browser Forum EV Guidelines. EV certificates require two authorized individuals from your organization: a Contract Signer (who signs the legal Subscriber Agreement) and a Certificate Approver (who formally authorizes certificate issuance). These can be the same person if they hold the appropriate authority. The issuance timeline is typically 5-7 business days because the CA must complete full Extended Validation. Once issued, your certificate provides the strongest available browser trust indicators. ### The Two EV Product Variants CERTInext offers two variants of the EV certificate, each designed for a different hosting scenario. **EV SSL Certificate** Secures a single primary domain (e.g., yourcompany.com + optionally [www.yourcompany.com](http://www.yourcompany.com)). Ideal for organizations that need the highest trust level on one website. Requires 1 DCV verification. Has 7 Order Actions in Phase 2. **EV SSL Certificate UCC** Secures multiple domain names (up to 4 included, expandable) under one certificate. Ideal for organizations with several websites or portals that all require EV-level trust. Requires one DCV verification per domain. Has 8 Order Actions in Phase 2 (includes Interim DV Certificate action). **Wildcard Domains:** Not supported on EV certificates (CA/Browser Forum policy). **ℹ INFO - Choosing the right EV product** Use EV SSL Certificate if you need the highest identity assurance on exactly one domain. Use EV SSL Certificate UCC if you need EV-level trust across multiple distinct domains (e.g., companyportal.com + companyshop.com + companyintranet.com). **Note**: Wildcard domains (\*.domain.com) are NOT permitted on EV certificates under CA/Browser Forum rules. ### Prerequisites - Before You Begin Have the following ready before starting an application. **CERTInext account** Log in at your organization's CERTInext portal URL. Your administrator provides login credentials. Log in before starting and confirm you have permission to place certificate orders. **Certificate Signing Request (CSR)** A CSR is a block of encrypted text generated on your web server. It contains your public key and basic organizational details. Generate it using your web server software (e.g., OpenSSL, IIS, cPanel) before starting. Generate using a minimum 2048-bit RSA or 256-bit ECDSA key. Ensure the domain in the CSR matches the domain you will enter in Step 5. **Domain name(s) to secure** Know the exact domain(s) you want the certificate to protect. For EV SSL UCC, list all domains upfront. Confirm you own and control the domain(s) as the CA will verify domain ownership during validation. **Organization details** Full legal organization name, registered address, country, state/province, locality, and postal code - exactly as they appear in official government or business registration records. Gather from official company registration documents. Mismatches with registry data are the most common cause of EV validation delays. **DUNS Number or Company Registration Number** A 9-digit DUNS number (from Dun & Bradstreet) or local government-issued company registration number. Used for EV organization identity verification. Find your DUNS number at dnb.com. If your organization does not have one, DUNS registration is free for businesses. **Contract Signer** An authorized individual (e.g., Director, VP, IT Director) with legal authority to sign the Subscriber Agreement on behalf of your organization. Identify this person before starting. They will receive a signing link by email. Can be the same person as the Certificate Approver. **Certificate Approver** An authorized individual (e.g., CISO, IT Director) with authority to approve EV certificate issuance for your organization. Identify this person before starting. They will receive an approval link by email. Can be the same person as the Contract Signer. **Account credit or payment method** Sufficient account credit balance or a payment card for the Pay Online option. Confirm balance or have a payment card ready before proceeding to Step 8. **Access to DNS provider (for DCV)** After payment you must prove domain ownership via DNS. You or your IT/domain administrator will need to create a DNS TXT record at your domain's DNS provider. Coordinate with your DNS administrator in advance. For EV SSL UCC, each domain requires its own TXT record. # Phase 1 Steps This phase covers the eight-step application wizard inside CERTInext. Click New Certificate in the left navigation panel to begin. A progress bar on the left side tracks your position through all eight steps. Steps with a tick mark are completed. You can click Back at any step to return and edit without losing later data. Use the sub-pages below to follow each step in sequence. # Step 1 - Choose Product & Validity **Important Documentation Conventions:** Normal text below provides feature descriptions and explanatory information. *Italicized text* indicates navigation paths, procedures, and actions to be performed within the CERTInext platform. *This is the first screen you see after clicking New Certificate. You select which EV product to purchase and for how long.*
### Common Fields (both product variants) **Group** Your organization account name in CERTInext. Pre-assigned and cannot be changed here. No action needed - confirm this is your correct account. **CA Source** The Certificate Authority that will issue the certificate. emsign (eMudhra's trusted CA) is pre-selected. Leave as emsign unless your administrator has configured an alternative. **Certificate Type** The category of certificate. SSL/TLS Certificates is pre-selected. Leave as SSL/TLS Certificates. **Product** The specific EV certificate product you wish to purchase. Click the dropdown and select the desired EV product: 'EV SSL Certificate' for single domain, or 'EV SSL Certificate UCC' for multi-domain. See the main page for guidance on which to choose. **Subscription For** The validity period: 1 Year, 2 Years, or 3 Years. Select the appropriate validity period. Note: EV certificates cannot exceed 1 year under CA/Browser Forum rules, but multi-year subscriptions provide continuous coverage through automatic renewal. **Cost** The price for the selected product and validity period (in USD). Auto-calculated. Review before clicking Next. ### Product-Specific Fields

ℹ INFO

Product Difference - No. of Domains field

The 'No. of Domains' dropdown appears only for EV SSL Certificate UCC. It is not present for EV SSL Certificate.

**No. of Domains \*(EV SSL Certificate UCC only)\*** Sets how many domains the certificate will cover. The default and minimum included in the base price is 'Upto 4'. Leave at 'Upto 4' if you need four or fewer domains. Additional domains beyond 4 can be added in Step 5 **Extra SAN note \*(EV SSL Certificate UCC only)\*** A note displayed beneath the Cost field informing you of the per-domain cost for SANs beyond the included base. Note this cost before proceeding. Each extra domain added in Step 5 increases the Grand Total accordingly. ### Certificate Features Panel A blue information panel at the bottom of the screen describes what all EV SSL/TLS certificates include: • Secures Single, Multiple Domains & Sub Domains • Domain & Extended Organization Validation • Average Issuance Timeframe: 1-5 Business Days • Unlimited Server Licenses • Strongest SHA2 & ECC Encryption • Major Browser & Mobile Device Compatibility • Priority Support • Automatic Renewal Reminders and Early Renewal Options

⚠ IMPORTANT

EV certificates take 1-5 business days to issue due to rigorous identity verification by the CA. Plan ahead if you have a launch deadline.

EV certificates cannot exceed 1 year of validity per CA/Browser Forum rules.

*After reviewing all fields and the cost, click Next to proceed to Step 2.* # Step 2 - Certificate Signing Request (CSR) A Certificate Signing Request (CSR) is a file you generate on your web server before applying for the certificate. It contains your domain name, organization details, and your public key. The CA uses your CSR to generate your certificate.

⚠ IMPORTANT

Important note displayed on screen

The public key and signature algorithm from your CSR are used for certificate generation. Subject details such as Organization, Country, and State are pre-filled from your CSR for convenience but can be edited. The values you submit in the form will be the final values in the issued certificate.

### Screen Fields ***Skip CSR*** *An option to bypass CSR submission at this stage if you do not yet have one prepared. The CSR will then need to be provided before the certificate can be issued. Only use Skip CSR if specifically instructed by your administrator. In most cases, have your CSR ready before starting the application.* ***Upload CSR (Choose File button)*** *Upload a CSR file (.csr or .pem) directly from your computer. Click Choose File, navigate to your saved CSR file, and select it. The CSR text will be loaded automatically.* ***Paste CSR (text area)*** *An alternative to file upload - paste the raw CSR text directly into this box. Copy the full CSR text from your server (including the \`-----BEGIN CERTIFICATE REQUEST-----\` and \`-----END CERTIFICATE REQUEST-----\` lines) and paste it into this field.* ### CSR Format A valid CSR looks like this: \-----BEGIN CERTIFICATE REQUEST----- \[several lines of base64-encoded text] \-----END CERTIFICATE REQUEST----- Ensure you copy the entire block including the BEGIN and END lines. ### Key Size Requirement Your CSR must be generated using a minimum 2048-bit RSA key or 256-bit ECDSA key. Never share your private key - only the CSR (public portion) should be uploaded. Ensure the domain in your CSR matches the domain you will enter in Step 5. After uploading or pasting your CSR, click Next to proceed to Step 3. # Step 3 - Organization Information This step collects the legal details of your organization. For EV certificates, these details are verified against official government business registries and must match exactly. They will appear in your issued certificate, visible to your website visitors.
### Entering Your Organization Details *Enter the legal details of your organization exactly as they appear in official government records and business registries. These details are used for Extended Validation.* **Organization Name \*(required)\*** The full legal name of your registered business or institution. Enter your organization's exact legal name as registered with the government (e.g., "ABC Corporation Inc."). Do not use abbreviations. **Organization Unit** The department or division within your organization responsible for this certificate (optional). Enter a department name (e.g., "Information Technology", "Web Services"), or leave blank. **Business Category \*(required)\*** The legal classification of your organization. Select the option that best matches: Private Organization (most companies), Government Entity, Business Entity, or Non-Commercial Entity. **Street Address 1 \*(required)\*** The first line of your organization's official registered address. Enter the building number and street name of your registered office. **Street Address 2 \*(required)\*** The second line of your organization's address. Enter the suite, floor, or additional address detail (e.g., "Suite 400", "Time Square Building"). **Country \*(required)\*** The country where your organization is legally registered. Select from the dropdown. Defaults to United States of America (USA). **State / Province \*(required)\*** The state or province of your registered address. Select from the dropdown list. **Locality \*(required)\*** The city or town of your registered address. Enter the city name. **Postal Code \*(required)\*** The ZIP code or postal code of your registered address. Enter your 5-digit ZIP code or full postal code.

⚠ IMPORTANT

All organization information must match your official legal registration documents exactly - including capitalization and punctuation.

Use your registered office address, not a P.O. Box or mailing address.

Discrepancies between entered information and registry data are the most common cause of EV validation delays or rejections.

For EV certificates, the Organization Name is verified against official business registries and will appear in your certificate.

### Pre-validated Organizations If your organization has been previously validated by the CA, it may appear at the top of the selection list. Selecting it will pre-fill all fields and may allow the CA to skip re-validation, speeding up issuance significantly. New organizations require full Extended Validation. *After entering all organization details and confirming accuracy, click Next to proceed to Step 4.* # Step 4 - Organization Representative Info *This step identifies the person who will act as the certificate subscriber - the individual within your organization who is formally requesting this certificate. They will receive a consent email during the verification phase (Phase 2, Action 2).*
### Screen Fields **Choose User (New / Existing)** *Toggle between creating a new user profile or selecting an existing one from your account. Choose New to enter details manually or Existing to select from a pre-existing list. If this is your first certificate order or the representative is not yet in the system, choose New. Otherwise, choose Existing and select the appropriate user.* **Name \*(required)\*** Full name of the organization representative. *Enter the person's legal first and last name. Do not use nicknames or abbreviations.* **Email ID \*(required)\*** The work email address of the representative. A verification consent email will be sent here during Phase 2. *Enter a valid, monitored organizational email address. Must be a work email - not a personal email (Gmail, Yahoo, etc.). Do not use a shared or unmonitored mailbox. The consent link is individual and time-sensitive.* **Mobile Number** The representative's mobile/phone number (optional). *Select the country dial code from the dropdown, then enter the number.*

⚠ IMPORTANT

Use official organizational email addresses only. Personal emails are not acceptable for EV certificates.

The Organization Representative's email will receive the certificate requester consent email. Ensure this person is available to respond promptly.

The consent email is addressed to the individual - it should not be forwarded.

### Certificate Download Delegation (Optional) *Use this section if a different person (other than the Organization Representative) should receive notifications when the certificate is ready to download* - for example, your web server administrator. **Contact name (Delegation)** Name of the person delegated to download the certificate. *Enter only if using Certificate Download Delegation.* **Email ID (Delegation)** Email address of the delegated downloader. *Enter only if using Certificate Download Delegation.* This person will receive the download notification email. *After completing the representative's details, click Next to proceed to Step 5.* # Step 5 - Certificate Information This step shows a summary of your organization's details (auto-filled, read-only) and collects the domain name(s) the certificate will protect, along with your company registration number.
### Organization Summary (Read-Only - All Products) *The top portion of this screen displays the organization details you confirmed in Step 3. These fields are informational only. If any detail is incorrect, click Back to return to Step 3 and correct it before proceeding.* The fields displayed are: • Organization Name - your organization's legal name (e.g., ABC Corporation Inc.) • Organization Unit - department name or blank if not specified • Business Category - Private Organization / Government Entity / Business Entity / Non-Commercial Entity • Street Address 1 - registered street address • Street Address 2 - additional address details or blank • Country - country of registration (e.g., United States of America (USA)) • State / Province - state or province (e.g., New York) • Locality - city (e.g., New York) • Postal Code - ZIP/postal code (e.g., 11697) ### Domain Name Fields - Differences by Product

ℹ INFO

Product Difference - Domain Fields

The domain entry section below the organization summary is the key difference between the two EV products. Read the section for your chosen product carefully.

#### EV SSL Certificate - Single Domain
**Automatically secure 'www' variant of websites** *A checkbox that, when ticked, instructs the system to also secure the [www.yourdomain.com](http://www.yourdomain.com) version of your domain automatically, at no extra cost. Tick this box if your website is accessed both with and without 'www' (which is the case for most websites). Leave unticked only if your domain is exclusively accessed without [www](http://www).* **Domain Name \*(required)\*** The single fully-qualified domain name (FQDN) the certificate will protect (e.g., yourcompany.com). *Type the domain name exactly as it should appear in the certificate. Do not include 'http\://' or 'https\://'. Example: \`yourcompany.com\` or \`portal.yourcompany.com\`.* **Company DUNS / Company Registration Number \*(required)\*** A 9-digit DUNS number (Dun & Bradstreet) or local government-issued company registration number. Used for EV organization identity verification. *Enter your 9-digit DUNS number. If you do not have a DUNS number, enter your local government-issued company registration/incorporation number. Find your DUNS at dnb.com - registration is free for businesses.* #### EV SSL Certificate UCC - Multiple Domains
**Automatically secure 'www' variant of websites** *Tick to also secure the www variant of the PRIMARY domain automatically. Tick if applicable for your primary domain. Note: this applies to the primary domain ONLY. Additional domain names do not automatically include their www variant.* **Domain Name \*(required)\*** The primary (main) domain name the certificate will protect (domain #1 of your total). *Enter your primary domain name (e.g., yourcompany.com). Do not include 'https\://' or '[www](http://www).'.* **Additional Domain Names \*(required)\*** A multi-entry field where you add all extra domain names beyond the primary domain (domains #2, #3, #4, etc.). *Each domain appears as a removable tag. Click inside the input box and type each additional domain, pressing Enter or clicking the '+' button after each one. You can also click 'Import additional domain' to paste or upload a list in bulk. Click 'x' on any domain tag to remove it.* **Import additional domain (button)** Allows bulk import of multiple domain names at once instead of adding them one by one. *Click to open an import dialog, paste a list of domain names (one per line), and confirm.* **Clear (button)** Removes all entries from the Additional Domain Names list. *Use only if you want to start the domain list from scratch.* **Company DUNS / Company Registration Number \*(required)\*** A 9-digit DUNS number or local company registration number. *Enter your DUNS number or company registration number. Same as EV SSL Certificate.*

⚠ IMPORTANT

List ALL domains you need secured in a single order. Adding domains post-issuance requires a reissue of the certificate.

Wildcard domains (e.g., *.yoursite.com) are NOT supported on EV certificates per CA/Browser Forum policy.

IP addresses cannot be added as SANs for EV certificates.

The www variant auto-secure option applies to the PRIMARY domain only.

The total domain count (primary + additional) must not exceed your purchased 'No. of Domains' without paying the extra SAN fee.

*After entering all domain name(s) and the registration number, click Next to proceed to Step 6.* # Step 6 - Authorized Signatory Information This step is unique to EV certificates. EV certificates require two specifically authorized individuals from your organization: a Contract Signer (who signs the legal Subscriber Agreement) and a Certificate Approver (who authorizes certificate issuance). These can be the same person if they hold appropriate authority.
### Contract Signer Information The Contract Signer is the individual with authority to enter into legal agreements on behalf of your organization (e.g., Director, VP, authorized officer). They will receive and must electronically sign the eMudhra emSign Subscriber Agreement. **Same as Organization Representative (checkbox)** *Copies the Organization Representative's details from Step 4 into this section. Check this box if the same person from Step 4 is also your Contract Signer. The fields will auto-fill.* **Choose User \*(required)\*** 'New' or 'Existing' contact. *Select 'New' to enter new details, or 'Existing' to pick from saved contacts.* **Name \*(required)\*** Full legal name of the Contract Signer. *Enter their full name exactly as it appears on official documents.* **Email ID \*(required)\*** *Work email of the Contract Signer. The Subscriber Agreement signing link will be sent here. Enter a valid organizational work email. The agreement link is sent to this address. The Subscriber Agreement is a legally binding document - ensure this email reaches the correct authorized person.* **Telephone** Contact phone number (optional). *Select country code and enter the full telephone number.* ### Certificate Approver Information The Certificate Approver is the individual who gives final authorization for the EV certificate to be issued (e.g., CISO, IT Director, delegated manager). This is an EV-specific requirement under CA/Browser Forum guidelines. **Same as Contract Signer (checkbox)** *Copies the Contract Signer's details into the Certificate Approver section. Check this if the same person is both Contract Signer and Certificate Approver (common in smaller organizations).* **Choose User \*(required)\*** *'New' or 'Existing' contact. Select 'New' to enter new details, or 'Existing' to pick from saved contacts.* **Name \*(required)\*** *Full legal name of the Certificate Approver.* *Enter their full name.* **Email ID \*(required)\*** *Work email of the Approver. The EV Certificate Request Approval link will be sent here. Enter a valid organizational work email. Ensure the Approver is available and watching their email.* **Telephone** Contact phone number (optional). *Select country code and enter the full number.*

⚠ IMPORTANT

The Contract Signer must have legal authority to bind your organization to contractual agreements (e.g., Director, VP, authorized officer).

The Certificate Approver must have authority to authorize security certificate issuance (e.g., CISO, IT Director, or delegated manager).

Both roles can be fulfilled by the same person if they hold appropriate authority.

Do not use external consultants or vendors in these roles.

*After completing the authorized signatory details, click Next to proceed to Step 7.* # Step 7 - Additional Information (Optional) This step is the same for both EV products. All fields are optional but some, such as auto-renewal, are pre-configured with sensible defaults.
### Screen Fields **Tags** Custom labels you can attach to this order for internal tracking and reporting within CERTInext (e.g., 'Production', 'Project-Alpha', '2026-Q2'). *Click '+ Add Tag', type your tag text, and press Enter. Add multiple tags as needed.* Tags are for your internal use only and do not appear on the certificate. **Order Remarks** A free-text notes field for any special instructions or internal references related to this order. *Type any notes relevant to your team or to support if you need to raise a query.* This text is visible to the CA and CERTInext administrators. **Technical Point of Contact Information** Checkbox - expands to collect the name, email, and phone number of the technical person responsible for managing this certificate (e.g., the system administrator who will install it). *Tick and fill in only if the technical contact is different from the Organization Representative entered in Step 4. Useful for larger organizations.* **KYC Documents** Checkbox - expands to allow you to upload Know Your Customer (KYC) verification documents (e.g., company registration certificate, utility bill, government ID). *Tick and upload documents if the CA requests them or if you want to proactively provide them to speed up the EV verification process.* **Additional email recipients** Checkbox - expands to add extra email addresses that should receive certificate-related notifications. *Tick and add email addresses if others in your organization (e.g., a manager, security team) should also receive order status updates and the download notification.* **Auto-renew certificates until coverage** Checkbox (ticked by default) - instructs CERTInext to automatically initiate certificate renewal before expiry. *Leave ticked (recommended). Only untick if you want to manage renewals manually. Without auto-renewal, your certificate may expire without notice, causing browsers to show security warnings.* **Set renew criteria - Before \[N] days of certificate expiry** *Configures how many days before expiry the auto-renewal process begins. Default is 15 days. Click the dropdown to adjust the lead time (e.g., 30 days gives more time for any renewal complications). 15 days is the standard minimum recommended.* *Review and adjust any optional settings, then click Next to proceed to the Order Summary.* # Step 8 - Order Summary & Payment The final step before payment. Review everything carefully. A 'Payment Pending' badge appears in the top-right corner.
### Product Information Panel **Certificate Type** The category of certificate (SSL/TLS Certificates). Verify this matches your intended purchase. **Product Name** The specific EV product selected (e.g., EV SSL Certificate or EV SSL Certificate UCC). Confirm this is the correct product variant. **Validity Period** The subscription duration selected in Step 1 (e.g., 1 Year). Confirm the correct duration. **Domain Count** The total number of domains the certificate will cover. For EV SSL Certificate: 1. For EV SSL Certificate UCC: reflects the total number of domains entered in Step 5.

ℹ INFO

Product Difference - Order Summary for EV SSL Certificate UCC

The Order Summary in Step 8 shows all the following for UCC:

Domain Count: 4 (or your selected number)

domain name: [primary domain]

additional domain names: [all additional domains listed, comma-separated]

### Certificate Information Panel A summary of all organization details and domain name(s) entered across previous steps. Scroll through to verify all values are correct. ### Payment Information Panel **Current Balance** Your organization's current pre-paid credit balance in USD. Verify you have sufficient balance if paying by credit. If the balance is less than the Grand Total, use Pay Online instead. **Certificate Price (upto 4) \*(EV SSL Certificate UCC only)\*** The base certificate price covering the included number of domains (up to 4). Informational - auto-calculated. **Additional SAN Cost \*(EV SSL Certificate UCC only)\*** The additional cost for any domains beyond the included base quantity. Format shown: '$\[rate] per \[count]'. Verify this matches the number of extra domains you added in Step 5. **Grand Total** The final total amount in USD payable for this order. Verify this matches your expectation before proceeding to payment. **Subscriber Agreement checkbox** A mandatory checkbox confirming you have read and agreed to eMudhra emSign's Subscriber Agreement. You MUST tick this checkbox before payment. *Click the 'Subscriber Agreement' hyperlink to read the full terms if you have not done so.* ### Payment Buttons ***Save and Exit*** *Saves your application as a draft and exits the wizard. You can return to complete payment later from the Orders list.* ***Pay Online*** *Opens a payment gateway to pay the Grand Total using a credit/debit card or other supported online payment method.* ***Use Credit*** *Deducts the Grand Total from your organization's pre-paid credit balance in CERTInext immediately. Order is submitted upon confirmation.*

⚠ IMPORTANT

Review ALL information carefully before payment. Once payment is made, changes to domain name or key organization details require a certificate reissue.

Ensure your domain name and organization name are correct - these appear in the certificate and are visible to your website visitors.

*Tick the Subscriber Agreement checkbox, then click either Pay Online or Use Credit to submit your order. After successful payment, you will be taken to the Order View page.* # Phase 2 Steps (via email & emSign) After payment, your order enters a multi-step verification and issuance workflow. For EV certificates, the CA must verify your identity, organization, domain ownership, and organizational authority before issuing the certificate. Most steps require action from you or your authorized signatories.

ℹ INFO

Two portals are involved

1. CERTInext (certinext.io) - where you placed your order. Use it to track order status.

2. emSign Subscriber Portal - where you and your authorized signatories complete all verification steps.

The emSign portal link is sent to you in the order confirmation email and is also accessible via CERTInext > Certificates > Orders > your order > Track Order Status.

Use the sub-pages below to follow each verification step in sequence: • Order Confirmation - what you see in CERTInext immediately after payment and the confirmation email you receive. • Order Tracking - how to access and read the emSign Subscriber Portal and its Order Actions. • Submit CSR - how to submit your CSR if you skipped it during application. • Certificate Requester Verification - how the Organization Representative confirms their certificate request. • Subscriber Agreement - how the Contract Signer electronically signs the Subscriber Agreement. • EV Certificate Request Approval - how the Certificate Approver gives formal authorization. • Organization Verification - how the CA verifies your organization's legal existence. • Domain Verification - how to prove domain control via DNS TXT record. • Interim DV Certificate - the temporary certificate issued for EV SSL Certificate UCC after domain verification. • Certificate Download - how to download your issued certificate in the right format. • Order Fulfilled - the final state of your order in CERTInext. # Order Confirmation *You are automatically redirected to the Order View page in CERTInext. Bookmark or note the Order ID displayed at the top - you will need it if you contact support.*
The Order View shows the following key fields: • Order ID - unique reference number for your certificate order. Keep this safe. • Ordered Date - date and time the order was placed. • Product - the EV certificate product ordered. • Group - your organization account name. • CA Source - Certificate Authority: emSign. • Certificate Price - total amount charged for this order (USD). • Order Status - 'Order Accepted' (orange badge) - the order has been received and accepted for processing. • Certificate Status - 'Pending for Approver' (orange badge) - the certificate is awaiting verification and issuance steps.

ℹ INFO

Note - Subscription Dates

Subscription Start Date and Subscription End Date will be blank at this stage. They are populated once the certificate is issued and the subscription becomes Active.

### Order Confirmation Email *Within minutes of payment, the Organization Representative receives an email notification confirming the order was placed successfully.*
The email contains the following: • Subject: ORDER #\[Order ID] - Your Order is Successful • Order ID - your unique order reference number • Ordered Date - date and time (UTC) • Product & Validity - product name and subscription period • Identifier - the primary domain name secured by this certificate • Subscription Per - e.g., 1 Year(s) • Track Order button - orange button linking to the emSign Subscriber Portal for your order *Click Track Order to open the emSign Subscriber Portal where you will complete the remaining verification actions. You can also access this portal via the link in subsequent notification emails.* ### Tracking Order Status in CERTInext In CERTInext, *navigate to Certificates > Orders and click your order to view its full details.* *Click the three-dot menu (top-right of the order) to open the "Track Order Status" popup. This popup shows a unique Order Status Tracking URL.* • *"Open URL": Opens the emSign Subscriber Portal in your browser.* • *"Share URL": Sends the tracking link via email to the Organization Representative.* # Order Tracking The emSign Subscriber Portal is the central place where all post-payment verification steps are tracked and completed. *Access it via the "Track Order" link in your confirmation email.* **The portal displays:** • Request Information: Certificate Requester, Contract Signer, and Certificate Approver details • Order Details panel (right side): Date, Order ID, Product, Domain, Order Status, Certificate Status • Order Actions: A numbered list of all verification steps required for certificate issuance
### The Order Actions

ℹ INFO

Product Difference - Number of Order Actions by Product

EV SSL Certificate has 7 Order Actions.

EV SSL Certificate UCC has 8 Order Actions (adds Action 7: Interim DV Certificate).

**Action 1 - Submit CSR** Confirms your CSR was accepted. Auto-completed if you submitted a CSR in Step 2. Only pending if you selected "Skip CSR". **Action 2 - Certificate Requester Verification** The Organization Representative confirms they authorized this certificate request. A consent email is sent to their email address. **Action 3 - Subscriber Agreement** The Contract Signer electronically signs the emSign Subscriber Agreement - the legal contract between your organization and the CA. **Action 4 - EV Certificate Request Approval** The Certificate Approver gives formal institutional authorization for EV certificate issuance. Mandatory for all EV certificates. **Action 5 - Organization Verification** The CA verifies that your organization is a real, legally registered entity. May be automatic or require a Verified Professional Letter (VPL). **Action 6 - Domain Verification (DCV)** You prove to the CA that your organization controls the domain(s) on the certificate. Required before certificate issuance. **Action 7 (EV SSL Certificate UCC only) - Interim DV Certificate** A temporary DV-level certificate is automatically issued after domain verification, while EV organization checks are finalized. **Action 7 (EV SSL Certificate) / Action 8 (EV SSL Certificate UCC) - Certificate Download** Available once all other steps are complete. The CA issues your certificate and it becomes available for download.

ℹ INFO

Action Status Colors

Green = Completed.

Orange = Awaiting Customer Action (you must do something).

'Issuance Pending' (orange) on the final certificate action means the CA is still processing - no action needed yet.

Certificate Status in the right panel shows the overall progress: 'Pending for Approver' > 'Approved' > 'Certificate Generated'.

Use the Resync button (circular arrow icon) next to any action to refresh its status or resend notification emails.

# Submit CSR ### Action 1 - Submit CSR *If you uploaded or pasted your CSR in Step 2 of the application, this action is automatically marked completed. No action is needed.* If you selected "Skip CSR" during application, this step shows as pending. You must submit your CSR here before the certificate can be issued. • *Click the "+" to expand Action 1.* • *Paste or upload your CSR in the provided field.* • *Click Submit.* # Certificate Requester Information ### Action 2 - Certificate Requester Verification *The Organization Representative (Certificate Requester from Step 4) must confirm they authorized this certificate request. This is a consent step required for all EV SSL certificates.* ### Consent Required Email *The Organization Representative receives an email with the subject: 'ORDER #\[ID] - Certificate Requester consent required for SSL EV request'.*
• *Click the orange "Click here to provide consent" button in the email.* ### emSign Consent Page
• *Review the Order Details and Organization Details on the page.* *• Read the consent statement: "Accepting this consent means that you confirm your certificate request."* *• Click "Approve" to confirm, or "Reject" to decline.* *• A confirmation popup appears: "Are you sure you want to accept the consent?" - Click "Yes".* ### Consent Accepted Confirmation Success: "Thank you for completing the pending actions. This would help us to speed up the certificate issuance process." • *Click "Proceed for Verification" to return to the full Order Actions list.*

⚠ IMPORTANT

The consent email may land in the spam/junk folder. Check there if not received within 15 minutes.

If the consent link has expired, use the Resync button (circular arrow) next to Action 2 in the portal to send a new consent email.

The consent email is addressed to the individual - it should not be forwarded.

# Subscriber Agreement ### Action 3 - Subscriber Agreement The Contract Signer (from Step 6) must electronically sign the eMudhra emSign Subscriber Agreement - the legal contract between your organization and the Certificate Authority. ### Agreement Email *The Contract Signer receives an email with the subject: 'ORDER #\[ID] - Sign Subscriber Agreement for EV SSL Request'.*
• *Click the orange "Agreement Link" button in the email.* ### emSign Subscriber Portal - Subscriber Agreement Page
• *Review the full Subscriber Agreement document (10 pages) displayed on screen.* *• On the right panel, complete the Accept Agreement form:* *◦ Your Name: Pre-filled with the Contract Signer's name. Verify it is correct.* *◦ Place: Enter the city/location where you are signing (e.g., "New York").* *◦ Email ID: Pre-filled and masked for privacy. Verify the masked email is correct.* *◦ Check box: "I am the authorized person to sign this agreement."* *◦ Check box: "I agree to all the terms & conditions of this agreement."* *◦ Click "Accept Agreement" (both checkboxes must be ticked first).* *Success: "Thank you for providing your consent and completing the Subscriber Agreement step successfully."*

⚠ IMPORTANT

Read the Subscriber Agreement carefully - it is a legally binding document.

The Place field should reflect your actual current location, not your company's registered address.

Both checkboxes are mandatory. The "Accept Agreement" button remains inactive until both are checked.

Once signed, the agreement cannot be revoked without cancelling the order.

# EV Certificate Request Approval ### Action 4 - EV Certificate Request Approval The Certificate Approver (from Step 6) must give final authorization for the EV certificate issuance. This step is mandatory for all EV certificates under CA/Browser Forum rules. ### Approval Email *The Certificate Approver receives an email with the subject: 'ORDER #\[ID] - Approve SSL EV Certificate request'.*
• *Click the orange "Approve EV Certificate request" button in the email.* ### emSign Subscriber Portal - EV Certificate Approval Page
*• Review Order Details (Order ID, Date, Ordered By, Domain, Certificate Requester Name/Email).* *• Review Organization Details (Organization Name, Domain).* *• Under "Approve SSL EV request", click the orange "Approve" button (or "Reject" if there is an issue).* *• A confirmation popup asks: "Are you sure you want to approve the SSL EV certificate request?" - Click "Yes".* Success: "Thank you for approving the SSL EV certificate request successfully."

⚠ IMPORTANT

The Approver's action is a formal institutional authorization. Ensure the Approver reviews the domain and organization details before approving.

If the Approver has not received the email, use the Resync button next to Action 4 in the portal.

# Organization Verification ### Action 5 - Organization Verification The CA verifies that your organization is a real, legally registered entity. This is the most detailed verification step for EV certificates. The CA first attempts automatic verification using public business registries. ### Automatic Verification If the CA can verify your organization automatically through public business registries, *this step completes without any action from you - it will simply move to "Completed". Only if automatic verification cannot confirm your organization will a Verified Professional Letter (VPL) be requested.* ### Verified Professional Letter (VPL) *If automatic verification fails, the CA will request a Verified Professional Letter.* **Step A - Email requesting VPL:**
• Subject: ORDER #\[ID] - Submit Verified Professional Letter for SSL EV request *• The email explains that the CA could not verify your organization through public sources and requests a VPL.* *• Click the orange "Submit Verified Professional Letter" button.* **Step B - VPL Upload Form in emSign Portal:** The VPL is an official letter on your organization's letterhead (or from a legal authority) that establishes your organization's identity. It should confirm: Legal name, DBA name (if applicable), Physical address, Contract Signer authority, and Certificate Approver authority.
**Organization Name** Auto-filled with your organization's name. Read-only. No action needed. Verify it displays your correct organization name. **Document Source \*(required)\*** Describes the origin or type of the letter. *Enter a brief description of the document source (e.g., "Company Official Letterhead", "Notarized Business Registration Document").* **Document (PDF only) \*(required)\*** The actual VPL file to upload. Platform accepts PDF files only. *Click "Choose File", select your VPL PDF file, and confirm the upload. Ensure the file is not password-protected.* **Document Description \*(required)\*** A brief description of what the document contains. *Enter a short description (e.g., "Professional letter verifying ABC Inc legal registration and authorized signatories").* **Issuer Name \*(required)\*** Full name of the person who prepared or signed this letter. *Enter the full name of the attorney, notary, company officer, or authorized professional who issued the letter.* **Issuer Email ID \*(required)\*** Email address of the person who issued the letter. *Enter a valid work email address for the Issuer. The CA validation agent may contact them to verify the letter.* **Issuer Contact No. \*(required)\*** Phone number of the Issuer. Select the country code and enter the full phone number. The CA may call to verify the letter. • *Click "Submit For Verification" to submit the VPL.* Success: "Thank you for submitting the Legal Option Letter for \[organization] successfully." ### Organization Authentication Code After the VPL is reviewed, the CA sends an Organization Authentication Code to the email address publicly listed for your organization (from public registries such as WHOIS or business databases). **Two emails are sent simultaneously:** • An email to the publicly listed organizational contact containing the 6-digit Authentication Code. • An email to the Organization Representative containing a Verification Link to the emSign portal where the code must be entered.
**Step C - Entering the Authentication Code:**
*• Click the link in the Verification Link email.* *• On the emSign portal page, enter:* *◦ Organization Authentication Code: Enter the 6-digit code received by the public registry contact.* *◦ Designation: Enter your job title at the organization (e.g., "IT Manager", "Systems Administrator").* *• Click "Submit".* Success: "Thank you for submitting the organization authentication code for \[organization] and completing the verification successfully."

⚠ IMPORTANT

The authentication code is sent to the publicly listed organizational contact - not necessarily to you. Coordinate internally with whoever receives that email to obtain the code.

The code expires in 24 hours. If it expires, use the Resync button next to Action 5 in the portal to trigger a new code.

Your Designation must reflect your actual role at the organization.

# Domain Verification ### Action 6 - Domain Control Validation (DCV) Domain Control Validation is the process by which you prove to the Certificate Authority that you genuinely control each domain on your certificate. This is mandatory for ALL SSL/TLS certificates before issuance. ### Domain List When you expand Action 6 (Domain Verification), you see: • 'Total Domains: \[N]' - the count of domains requiring verification. • Each domain listed with a status icon (orange warning = pending, green = verified) and a 'Verify' button. • For EV SSL Certificate: 1 domain to verify. • For EV SSL Certificate UCC: one entry per domain - you must verify each domain individually.

ℹ INFO

Product Difference - Multiple DCV for EV SSL Certificate UCC

EV SSL Certificate UCC requires domain verification for EVERY domain listed on the certificate.

Total Domains: Shows the total count (e.g., "Total Domains: 4").

Each domain is listed individually with its own status icon, "CAA" button, and "Verify" button.

DCV must be initiated and completed for each domain separately by clicking "Verify" next to each one.

If the authorized domain name (base domain) ownership is proven, all sub-domains that have the same base domain name will be proven automatically (e.g., proving xyz.com automatically proves blog.xyz.com). Note: the reverse is NOT allowed.

### DCV Method - DNS TXT Record (Recommended) *Click the 'Verify' button next to a domain. A modal dialog appears.*

ℹ INFO

Technical Note

The DCV modal includes a note: "This is technical in nature. If you are not the right person, please contact your IT / Domain administrator." If you do not manage your DNS records yourself, forward the TXT record details (Host and Value) to your DNS administrator and ask them to create the record.

**DCV Method dropdown** The method used to prove domain ownership. 'DNS TXT Record (Most Preferred)' is the recommended and pre-selected method. Leave as 'DNS TXT Record (Most Preferred)' unless your DNS provider does not support TXT records. **Record Type** The type of DNS record to create: TXT. Always TXT for this method. **Host** The hostname for the DNS TXT record. This is the domain name itself (Copy button available). Copy this value exactly. Log in to your DNS provider's management panel, navigate to DNS settings for this domain, and use this as the Host/Name field when creating the TXT record. **Value** The unique verification token that must be entered as the TXT record's value (Copy button available). Copy this token exactly. Enter it as the Value/Content of the new TXT record at your DNS provider. Do not add any extra spaces or characters. For UCC: each domain gets its own unique Host and Value - do not reuse values between domains. **Verify Now button** Triggers the CA's system to check your DNS for the TXT record. ONLY click Verify Now after you have saved the DNS TXT record at your DNS provider AND allowed sufficient time for DNS propagation (15-30 minutes minimum, up to 48 hours). **Close button** Closes the modal without verifying. Click Close if you need to set up the DNS record first and return to verify later.

⚠ IMPORTANT

DNS Propagation

After creating the DNS TXT record at your DNS provider, changes may take anywhere from a few minutes to 48 hours to propagate globally (depending on your DNS TTL settings). It is best practice to wait at least 15-30 minutes before clicking 'Verify Now'. If verification fails, wait longer and try again. Do not delete the TXT record until verification succeeds.

### Domain Verification Success
After successful verification, a success popup appears: "Thank you for proving the domain ownership for \[domain]. Domain Verification is completed successfully." *Click OK to dismiss. The domain's status icon turns green.* *For EV SSL Certificate UCC: repeat the Verify process for each remaining domain until all show green / Completed.* # Interim DV Certificate ### Action 7 - Interim DV Certificate (EV SSL Certificate UCC Only)

ℹ INFO

Product Difference - Action 7 is unique to EV SSL Certificate UCC

This action does NOT appear for the standard EV SSL Certificate.

No action is required from you. *Once all domain verifications (Action 6) are complete, the system automatically processes and issues the Interim DV Certificate. Monitor this step's status in the portal. It will move from "Issuance Pending" to "Completed" automatically.*
An Interim Domain Validated (DV) Certificate is a temporary, basic certificate issued once domain verification is complete, before the full EV organization validation is finalized. It provides DV-level HTTPS coverage for your domains while the CA completes the Extended Validation checks (organization verification, approver confirmation, etc.).
**What happens next:** • Once the Interim DV Certificate is issued, you may optionally install it on your server for immediate basic HTTPS coverage. • The full EV Certificate (Action 8) will be issued after all remaining EV-specific verifications are approved. • When the full EV Certificate is issued, replace the Interim DV Certificate on your server with the EV certificate.

⚠ IMPORTANT

The Interim DV Certificate is NOT the final EV Certificate. Do not consider your EV order complete until the full EV Certificate (Action 8) is issued.

The EV Certificate provides the highest browser trust indicators. The Interim DV Certificate does not.

Replace the Interim DV Certificate with the full EV Certificate promptly once it is issued.

# EV Certificate Download ### Certificate Issuance and Download Once all Order Actions are marked Completed, the CA processes and issues the certificate. This typically happens automatically within minutes to a few hours of the final action being completed. No action is required from you at this stage. ### Download Notification Email The Organization Representative receives an email with the subject: 'ORDER #\[ID] - Your Certificate is ready for download'. • The email contains Order ID, Ordered Date, Product & Validity, and the Identifier (domain). • It includes an orange "Download Certificate" button linking to the emSign Subscriber download page. • Click the "Download Certificate" button in the email. This opens the emSign Subscriber download page. ### emSign Subscriber Portal - Certificate Download Page
The download confirmation page shows: • A green tick with: "Thanks for completing the necessary steps." • "Your certificate has been issued and ready for download. To continue further, please click Download Certificate." • Order ID, Product & Validity, and Domain Name details. • Orange "Download Certificate" button. ### Certificate Download in Order Actions Expanding the final Certificate Download action in the Order Actions list reveals the following: **Text shown in the expanded panel:** \> Your certificate has been issued and ready for download. An email containing certificate download instructions has been sent to your email ID. In case you have not received an email, please click Resend Email to resend the email. Your certificate is based on the CSR submitted by you. Please ensure to import / use the certificate against the same key-pair, from where the CSR was generated. ***Resend Email*** *Re-sends the download notification email to the Organization Representative's email address. Use this if the original email was not received.* ***Download Certificate*** *Initiates the certificate download directly from the portal, bypassing the email.*

🚨 CRITICAL

CRITICAL: Your certificate MUST be installed with the matching private key. If you have lost your private key, you will need to generate a new CSR and request a reissue.

After installation, verify your certificate using SSL Labs (ssllabs.com/ssltest) to confirm it is correctly installed and trusted by major browsers.

EV certificates display the organization's name in the browser address bar - confirm this appears correctly after installation.

For EV SSL Certificate UCC: the issued certificate file contains Subject Alternative Name (SAN) entries for ALL your domains. You install ONE certificate file that covers all domains simultaneously.

### Selecting the Download Format When initiating a download from CERTInext, a 'Select the Format to download' dialog appears with four options:
**DER encoded binary X.509 (.CER)** Binary format of the certificate. Compact and widely supported by Windows systems and Java keystores. Choose this for Windows Server (IIS) or Java-based servers. **Base-64 encoded X.509 (.CER)** Text-based (PEM) format of the certificate, saved with the .CER extension. Readable in a text editor. Choose this for most Linux/Unix-based servers (Apache, Nginx), or when your server software requests a .CER file. **Base-64 encoded X.509 (.CRT)** Identical content to the Base-64 .CER above but saved with the .CRT file extension. Choose this when your server software (e.g., Apache, Nginx) expects a .crt file extension. **Zip** A ZIP archive containing the certificate along with any intermediate/chain certificates. Recommended for most installations. Choose Zip if you are unsure, or if your server requires the full certificate chain. Extract the ZIP and follow your server's installation guide. *Choose the one applicable to your scenario based on the above description*

ℹ INFO

Which Format to Choose

If in doubt, choose Zip - it includes all necessary certificate files (end-entity certificate + intermediate certificates/chain). Your web server administrator will know how to handle the extracted files. For quick Windows inspection, choose DER or Base-64 .CER.

# EV Order Fulfilled ### CERTInext Order View - Final State After the certificate is downloaded, the Order View in CERTInext updates to its final state. Navigate to Certificates > Orders and click your order to view this screen. The final state shows: • Order Status: Order Fulfilled (green) • Certificate Status: Certificate Downloaded (green) • Subscription Status: Active (green) • Subscription Start Date: Date the certificate was issued • Subscription End Date: Expiry date (Start Date + validity period, e.g., 1 year) ### Order Action Menu In the top-right corner of the Order View, a three-dot menu icon provides additional actions depending on the certificate type. **Available actions:** • Download Invoice - available for all products • Track Order - available for all products • Download Certificate - available for all products • Reissue Certificate - available for all products • Add / Remove SANs - EV SSL Certificate UCC only • Revoke Certificate - available for all products

ℹ INFO

Reissue vs. Revoke

Reissue creates a replacement certificate - useful when you change your server or CSR. The old certificate is revoked as part of reissuance.

Revoke permanently deactivates the certificate without replacement - only use Revoke if you are decommissioning the service or the key has been compromised and you will not replace it.

# Ordering SMIME Certificates #### What is an S/MIME Certificate? An S/MIME certificate is a digital security credential that is attached to your email account. Once installed in your email application, it does two important things: • Digitally signs your outgoing emails so recipients can verify that the email truly came from you (not an impersonator). • Encrypts emails between you and other S/MIME users, so no one else can read them in transit. # Phase 1 Steps This phase covers everything you do inside the CERTInext portal - from selecting your product to making payment. There are six steps. # Step 1 - Choose Product & Validity This is the first screen you see after clicking New Certificate in the CERTInext portal. You choose which type of certificate you want and for how long.
#### Field Reference • Group: The name of your organisation as registered in CERTInext. This is set by your administrator. This field is auto-filled. No action needed. • CA Source (\*): The Certificate Authority that will issue your certificate. 'eSign' is eMudhra's CA for S/MIME certificates. Select 'eSign' from the dropdown. • Certificate Type (\*): The category of certificate you are applying for. Select 'S/MIME Certificates' from the dropdown. • Product (\*): The specific S/MIME product variant and its validity period. Select 'eSign - SMIME - Simple MV-S 1 Year' (or the product your administrator has assigned to your group). • Cost: The price of the selected product in USD, as charged to your organisation's credit balance. This updates automatically when you select a product. No action needed. Verify the amount is correct. • Product Info Box: A summary of what S/MIME certificates provide: email validation, digital signing, and encryption. Read this to confirm S/MIME is the certificate type you need. **NOTE:** Fields marked with an asterisk (\*) are mandatory. You cannot proceed to the next step without filling them in. **TIP:** If you do not see the product you need in the dropdown, contact your CERTInext administrator; they control which products are available to your group. #### What to Do • Click New Certificate in the left sidebar (or top menu) to begin. • Confirm that Group shows your correct organisation name. • Set CA Source to eSign. • Set Certificate Type to S/MIME Certificates. • Select the correct Product from the dropdown. The cost will appear automatically. • Review the feature list in the blue information box to confirm your selection. • Click Next to proceed to Step 2. --- [Next Page](/llms-full.txt/1)