Solutions
By Industry
Banking & Finance Telecommunication Public Utilities Payment Industry-agnostic
By Category
AI Data Lake & DWH Customer 360 Digital Banking Content Services Security Billing Software Smart City and Traffic Management Enterprise Resource Planning (ERP) Customer Experience
Investor
Investor relations
Investor Relations Center Dividend Policy Shareholders Analysts Financial Calendar Closed Periods IR Contact
Financial Information
Financial Highlights – consolidated Recent Results Financial Reports Presentations Financial Press Releases FAQ
Governance
Regulatory Filing Legal Environment Auditor Corporate Governance IPO
Being Acquired Career Center
About
About the Group Governance Company Structure Group Policies Norms & Certificates ESG Become a Partner

Certificate Lifecycle Management

TLS/SSL certificates are digital certificates issued by a trusted Certificate Authority (CA) that serve two critical functions: they authenticate the identity of a server (proving that a website or service is genuinely who it claims to be) and they enable encrypted communication between the server and the client using the TLS (Transport Layer Security) protocol. When a browser connects to a website secured with a TLS certificate, it verifies the certificate's authenticity against the CA's trusted root, establishes an encrypted session, and displays the padlock icon and HTTPS prefix in the address bar. TLS certificates contain key information including the domain name they protect, the issuing CA, the certificate's validity period, and the server's public key. Despite being technically TLS certificates, they are still commonly referred to as SSL certificates, a legacy term from the now-deprecated Secure Sockets Layer protocol.

TLS/SSL certificates are fundamental to internet security for three core reasons. First, they encrypt all data transmitted between a user's browser and the server, protecting sensitive information, including credentials, payment card data, and personal details, from interception by third parties. Second, they authenticate the server's identity, ensuring users are communicating with the genuine website and not a fraudulent impersonator (a defense against phishing and man-in-the-middle attacks). Third, they are a baseline trust signal: browsers actively warn users when a site lacks a valid TLS certificate, and search engines such as Google use HTTPS as a ranking factor. For organizations, maintaining valid, properly configured TLS certificates is a compliance requirement under frameworks such as PCI DSS, GDPR, NIS2, and DORA, and a prerequisite for customer trust in any digital service.

When a user connects to an HTTPS website, a process called the TLS handshake takes place. During this handshake, the server presents its TLS certificate, the client verifies it agains a trusted Certificate Authority (CA), and both parties negotiate encryption parameters. This process relies on asymmetric encryption, using a public key and a private key, to securely exchange a session key, after which symmetric encryption takes over for the remainder of the session for performance efficiency. Algorithms such as RSA, ECC (Eliptic Curve Cryptography), and AES (Advanced Encryption Standard) are commonly used in this process.

TLS/SSL certificates differ in the level of identity verificiation performad by the Certificate Authority (CA) before issuance, making some types more appropriate for ceratin use cases than others.

Domain Validation (DV) certificates offer the most basic level of verification. The CA confirms only that the applicant controls the domain in question, no organizational identity is checked. Because the validation process is fully automated, DV certificates are issued within minutes. They are well suited for blogs, infomational webistes, and for internal toools where basic encrypted connection is sufficient, but they provide no assurance about the organization behind the website.

Certificate expiration occurs when a TLS/SSL digital certificate reaches the end of its predefined validity period. This is typically 1 year (398 days for publicly trusted certificates, as mandated by CA/Browser Forum baseline requirements). Once a certificate expires, browsers and clients no longer trust it, immediately triggering visible security warnings ( " Your connection is not private " ) that block users from accessing the service. Expired certificates cause service outages, damage customer trust, and can constitute a compliance violation. Certificate expiration is one of the most common and preventable causes of website downtime, making proactive expiration monitoring and automated renewal essential practices for any organization managing digital certificates.

Certificate renewal is the process of replacing an expiring or expired TLS/SSL certificate with a newly issued certificate from a Certificate Authority (CA) before the existing one becomes invalid. Renewal maintains the continuity of trusted encrypted communications and prevents the service outages and browser security warnings associated with expired certificates. Certificate renewal can be performed manually, by generating a new certificate signing request (CSR), submitting it to the CA, and deploying the new certificate, or automatically using protocols such as ACME (Automatic Certificate Management Environment), which enables zero-touch renewal without human intervention. Automated renewal is strongly recommended for organizations managing large numbers of certificates, as manual processes are error-prone and difficult to scale.

Certificate management is the systematic set of processes and tools used to discover, track, issue, deploy, monitor, renew, and revoke digital certificates across an organization's entire IT infrastructure. As organizations scale, deploying certificates across web servers, APIs, microservices, IoT devices, and internal systems, the volume and complexity of certificate management grows rapidly. Without a centralized certificate management platform, organizations face significant risks: missed expirations causing outages, shadow certificates issued outside of IT's visibility, and compliance gaps. Effective certificate management provides a complete inventory of all certificates, automated lifecycle workflows, expiration alerting, and audit trails to support compliance with regulatory requirements such as PCI DSS, NIS2, and DORA.

The certificate lifecycle is the complete sequence of stages that a digital certificate passes through from creation to retirement. The key stages are:

  1. Request - an entity generates a key pair and submits a Certificate Signing Request (CSR) to a Certificate Authority.
  2. Issuance - the CA validates the request and issues the signed certificate.
  3. Deployment - the certificate is installed and activated on the target server, device, or service.
  4. Monitoring - the certificate is tracked for validity, configuration correctness, and approaching expiration.
  5. Renewal - the certificate is renewed before it expires, maintaining continuity of service.
  6. Revocation - if the certificate is compromised or no longer needed, it is revoked and added to the CA's Certificate Revocation List (CRL) or OCSP records.
  7. Retirement - the expired or revoked certificate is decommissioned and removed from inventory. Managing the full certificate lifecycle, particularly at scale, requires automated tooling to prevent the operational and security risks associated with unmanaged certificates.

A wildcard certificate is a TLS/SSL certificate that secures a primary domain and all of its first-level subdomains under a single certificate, identified by an asterisk in the subject field (e.g., *.example.com). A single wildcard certificate for *.example.com will secure app.example.com, api.example.com, portal.example.com, and any other subdomain at that level, without needing separate certificates for each. This significantly simplifies certificate management for organizations with multiple subdomains. However, wildcard certificates carry a broader risk profile than single-domain certificates: if the private key associated with a wildcard certificate is compromised, all subdomains it covers are potentially exposed. Wildcard certificates do not cover second-level subdomains (e.g., dev.app.example.com) and are not suitable for all use cases.

A self-signed certificate is a TLS/SSL certificate that is signed by the same entity that created it, the certificate holder, rather than by a trusted, third-party Certificate Authority (CA). Because self-signed certificates are not issued by a recognized CA, browsers and operating systems do not trust them by default and display prominent security warnings when they are encountered. Self-signed certificates are appropriate for internal development environments, testing, internal-only services where the certificate can be manually distributed and trusted, and certain machine-to-machine communications where mutual trust is established out of band. They should never be used for public-facing websites, APIs, or any service where end-user trust and regulatory compliance are required, as the absence of third-party validation provides no assurance of the server's identity.

When a TLS/SSL certificate expires, the trust chain that browsers and clients rely on to verify a server's identity immediately breaks. The consequences are immediate and cascading:

  • Browser security warnings: Users are shown a prominent "Your connection is not private" or "Certificate expired" error page. Most users will not proceed past this warning, effectively taking the service offline from their perspective.
  • Service outages: APIs, mobile apps, IoT devices, and internal systems that perform certificate validation will refuse to connect, causing application failures and integration breakdowns across dependent services.
  • Loss of encryption: Without a valid certificate, encrypted HTTPS communication cannot be established, leaving data in transit unprotected.
  • Compliance violations: Expired certificates constitute a failure of security controls required under regulations such as PCI DSS, GDPR, NIS2, and DORA, potentially triggering audit findings and regulatory penalties.
  • Reputational damage: Visible security errors erode customer trust rapidly and can result in lasting brand damage, particularly for financial services and healthcare organizations.

The most effective prevention is automated certificate lifecycle management. Tools that continuously monitor certificate expiration dates, alert well in advance of expiry, and trigger automatic renewal via protocols such as ACME, eliminating the risk of human oversight causing a missed renewal.

The ACME (Automatic Certificate Management Environment) protocol is an open standar, defined in RFC 8555, that automates the issuance, renewal, and revocation of TLS/SSL certificates between a web server or client and a Certificate Authority (CA). ACME is the protocol that powers Let's Encrypt and is supported by a growing number of public and private CAs, making it the foundation of zero-touch certificate lifecycle management.

Here is how the ACME protocol works step by step:

  1. Account creation: The ACME client (running on the server) registers an account with the CA by generating a key pair and submitting the public key.
  2. Order submission: The client submits a certificate order specifying the domain name(s) to be covered.
  3. Domain validation (challenge): The CA issues a challenge to prove the client controls the domain. The two most common challenge types are HTTP-01 (the client places a specific token at a known URL on the domain) and DNS-01 (the client creates a specific DNS TXT record). Wildcard certificates require DNS-01 validation.
  4. Challenge verification: The CA verifies the challenge response. Once validated, the domain authorization is stored.
  5. Certificate issuance: The client submits a Certificate Signing Request (CSR), and the CA issues and returns the signed certificate.
  6. Automated renewal: The ACME client is configured to repeat this process automatically, typically 30 days before expiration, requiring zero human intervention.

ACME eliminates the manual steps that make certificate management error-prone at scale, and is the recommended approach for any organization seeking to implement automated, zero-touch certificate renewal.

Certificate sprawl is the uncontrolled proliferation of TLS/SSL certificates across an organization's IT infrastructure resulting from inconsistent issuance practices, lack of centralized visibility, decentralized ownership, and reliance on manual processes. In large enterprises, certificates are issued across cloud environments, on-premises servers, microservices, APIs, IoT devices, and internal applications. This is often done by different teams using different CAs, with no single system tracking them all.

Certificate sprawl creates several serious risks:

  • Invisible expirations: Certificates that are not tracked are not renewed, leading to unexpected outages when they expire silently.
  • Shadow certificates: Certificates issued outside of IT governance (by developers, third-party vendors, or automated tooling) are unknown to the security team, creating unmanaged attack surfaces.
  • Inconsistent security standards: Sprawled certificates may use outdated algorithms, weak key lengths, or inappropriate validity periods that do not meet current security standards.
  • Compliance gaps: Regulators and auditors require organizations to demonstrate control over all certificates in use — an impossible task without a centralized inventory.
  • Incident response delays: When a CA is compromised or a certificate must be urgently revoked, certificate sprawl makes it extremely difficult to identify all affected certificates quickly.

The solution to certificate sprawl is a centralized certificate management platform that provides automated discovery of all certificates across the environment, a unified inventory, lifecycle automation, and policy enforcement, regardless of which CA issued the certificate.

Multi-tenant TLS certificate management is the capability of a certificate management platform to manage digital certificates across multiple distinct organizational units, clients, business divisions, or customer environments — each with their own isolated policies, CA configurations, certificate inventories, and access controls — from a single, centralized platform instance.

This model is essential in several contexts:

  • Managed Security Service Providers (MSSPs) and managed PKI providers that manage certificates on behalf of multiple enterprise clients, each requiring strict data isolation and separate reporting.
  • Large enterprises with multiple subsidiaries, business units, or geographic regions that operate semi-independently but require centralized governance and visibility.
  • Cloud service providers and SaaS platforms that issue and manage TLS certificates for customer-facing endpoints across a large customer base.

Key capabilities of a multi-tenant certificate management solution include:

  • tenant-level isolation of certificate inventories, CA connections, and policies;
  • role-based access control scoped to individual tenants;
  • consolidated reporting and dashboards for administrators with cross-tenant visibility;
  • separate billing and quota management per tenant;
  • support for both shared and tenant-specific CA integrations.

Multi-tenant certificate management significantly reduces operational overhead while maintaining the governance, security, and compliance standards required by each individual tenant.

Zero-touch TLS certificate renewal is the fully automated process of renewing digital certificates before they expire without requiring any manual action from IT or security teams. In a zero-touch renewal model, the certificate management system or ACME client continuously monitors certificate expiration dates, automatically initiates the renewal process a configurable number of days before expiry, completes domain validation, obtains the new certificate from the CA, and deploys it to the target server or service, all without human intervention.

Zero-touch renewal is made possible by the ACME protocol (RFC 8555), which standardizes automated communication between certificate clients and Certificate Authorities. When combined with a certificate management platform, zero-touch renewal can extend across complex, hybrid environments covering cloud infrastructure, on-premises servers, load balancers, CDNs, and internal services.

The business case for zero-touch renewal: Certificate expiration is one of the most common and entirely preventable causes of service outages and security incidents. As organizations manage growing numbers of short-lived certificates (the CA/Browser Forum is progressively reducing maximum certificate validity periods, with 47-day certificates expected by 2027), manual renewal processes become operationally unsustainable. Zero-touch renewal eliminates expiration risk at scale, reduces operational overhead, and supports compliance with the continuous security monitoring requirements of frameworks such as NIS2, DORA, and PCI DSS.

Yes, for most enterprises, support for both public and private Certificate Authorities (CAs) is a fundamental requirement of any effective TLS certificate management platform.

Public CAs (such as DigiCert, Sectigo, Let's Encrypt, and GlobalSign) issue certificates that are trusted by default in browsers and operating systems worldwide. They are used for public-facing websites, customer-facing APIs, and any service that must be trusted by external users without additional configuration.

Private CAs (also called internal or enterprise CAs, such as Microsoft Active Directory Certificate Services or a self-hosted PKI) issue certificates that are trusted only within an organization's controlled environment. They are used for internal services, microservices communication, machine-to-machine (M2M) authentication, VPN gateways, internal APIs, IoT device identity, and DevOps infrastructure — environments where purchasing public CA certificates at scale would be impractical and where the organization maintains its own trust anchor.

A certificate management platform that supports only public CAs will leave a significant portion of the certificate estate unmanaged. This creates the exact visibility and governance gaps that lead to certificate sprawl, surprise expirations, and compliance failures. Also, a platform that only supports private CAs cannot manage the public-facing certificate estate. Enterprises typically operate both types simultaneously, and the management platform must provide a unified inventory, automated lifecycle workflows, and consistent policy enforcement across all CAs, public and private, from a single tool. Support for the ACME protocol, SCEP, EST, and CA-specific APIs ensures compatibility across the broadest range of CA providers.