TLS/SSL Certificate Fundamentals to Certificate Lifecycle Management
The padlock icon and HTTPS displayed in the address bar when accessing a website are now familiar sights. What procedures pass between browser and server for that indicator to appear, and what an organization must manage to establish that procedure, are relatively less well known.TLS/SSL certificates are often described as protecting a single individual site. However, in enterprise environments, the points where certificates are used continue to expand beyond web servers to load balancers, network equipment, internal business systems, containers, and APIs. On top of this, as of March 15, 2026, the maximum validity period for public TLS/SSL certificates was reduced to 200 days, shortening renewal cycles as well. This is where a management burden that conceptual explanations alone don't reveal arises.This article organizes how TLS/SSL certificates are verified at the point of connection and what procedures govern their issuance, then examines what management challenges arise when the same conditions are applied at organization-wide scale. It then looks at how DigiCert's certificate lifecycle management product, Trust Lifecycle Manager, addresses these challenges. ☑️ What Is a TLS/SSL CertificateA TLS/SSL certificate is a digital certificate that encrypts data exchanged between a server and browser and authenticates the identity of the organization that owns the domain. A certificate includes a key pair consisting of a public key and a private key, and only certificates signed by a Certificate Authority (CA) trusted by the browser function as valid. In other words, a certificate performs both the function of protecting communication and the function of confirming who owns the website.The reason encryption is necessary is that, without a protective mechanism, communication passes in plaintext. Data between a browser and web server is transmitted as-is, and an attacker intercepting it in the middle can view and use the contents. This includes data such as credit card numbers, personal identification information, and login credentials, which cause harm as soon as they are exposed. A website address beginning with https rather than http is an indicator that the connection is protected by TLS/SSL.A certificate contains subject information along with the key pair. This is the item indicating who owns the certificate and website in question, and what information is contained here depends on what verification was performed prior to issuance.SSL and TLS are not separate technologies but protocols in the same family. Each time a new version of the SSL protocol was released, only the version number changed, but when the version following SSLv3.0 was named TLSv1.0 instead of SSLv4.0, the name changed, and TLSv1.3 is currently in use. However, the name SSL is still widely used, so certificates are often referred to jointly as TLS/SSL. Products purchased under the name SSL certificate are, in fact, TLS certificates. ☑️ How Is a Certificate Verified at Each ConnectionThe moment a certificate is actually used is when a user connects to a site. When a browser connects to a site protected by HTTPS, a procedure called the TLS/SSL handshake is executed. This process is invisible to the user and is performed instantly at every connection.The procedure proceeds as follows. When the browser connects to the server and requests proof of identity, the server transmits its TLS/SSL certificate and public key. The browser verifies whether the CA that issued the certificate is trustworthy, and checks whether the certificate has expired, whether it has been revoked, and whether the name recorded on the certificate matches the site being accessed. Once verification passes, the browser generates a symmetric session key, encrypts it with the server's public key, and sends it back, and the server decrypts this session key with its own private key. From then on, the server and browser encrypt all data exchanged using this session key.Three types of keys are used here. Data encrypted with a public key can only be decrypted with the private key, and the reverse also holds, but encryption and decryption using the public and private keys carries a heavy computational load. For this reason, the public and private keys are used only during the handshake stage where the session key is securely generated, and once the connection is established, the symmetric session key is used for actual data transmission.From an operational standpoint, the verification stage performed by the browser deserves attention. The browser checks the certificate's expiration and revocation status, whether the issuing CA is trusted, and whether the name recorded on the certificate matches the site being accessed. Even if an administrator has overlooked a single certificate, this verification is still carried out as usual. ☑️ Where Does a Certificate's Trust Come FromAmong the items the browser checks, as noted above, whether the issuing CA is trusted is directly tied to the process by which the certificate is created. To be issued a certificate, a server must generate a Certificate Signing Request (CSR). In this process, a private key and public key are generated on the server in question, and the CSR file, containing the public key, is transmitted to the CA. The CA uses the CSR to create a data structure that pairs with the private key, but does not verify the private key itself. The private key never leaves the server.The issued certificate is installed on the server, and at this time the intermediate certificate is installed along with it. The intermediate certificate serves to link the server certificate to the CA's root certificate, establishing the trust relationship. This structure, extending from the server certificate through the intermediate certificate to the root certificate, is called the certificate chain.The most important element of a certificate is the fact that it was digitally signed by a trusted CA. Anyone can create a certificate itself, but browsers only trust certificates issued by an authority included in their list of trusted CAs. Browsers come preloaded with a trusted root CA store, and to be listed in this store and recognized as a CA, an organization must comply with the security and authentication standards set by browsers and undergo audits for them.In summary, a certificate's trust is based not on the certificate file itself, but on which CA issued it and through what procedure. ☑️ What Is Verified Before a Certificate Is IssuedIf the chain of trust examined above concerns who issued the certificate, the certificate type concerns what was verified before issuance. TLS/SSL certificates are classified according to the scope of identity verification performed prior to issuance into Domain Validated (DV), Organization Validated (OV), and Extended Validation (EV). The names of the three types express what verification procedure was undergone before issuance.- A DV certificate is issued after confirming only that the applicant controls the domain in question. The procedure is short, so it can be obtained quickly, but organizational information is not included in the certificate. It has the lowest level of identity verification among the three types, and is presented as suitable for blogs or personal websites that do not conduct transactions or collect personal information.- An OV certificate verifies the business entity linked to the certificate in addition to confirming domain ownership. The CA verifies the business's name, type, status, and physical address, and also confirms whether the entity is properly maintained. It is intended for services with a login screen or corporate sites.- An EV certificate, in addition to the verification performed for DV and OV, confirms the business's actual operational status, physical address, publicly listed representative phone number, years in business, and registration and jurisdiction information. This includes checking for domain fraud, checking contact information against blacklists, and a phone call to confirm the applicant's employment. It is used for services such as financial institutions and e-commerce where a high level of identity verification matters.The period for which verification results can be reused has also shortened. Along with the validity period reduction mentioned above, as of March 15, 2026, the reuse period for Subject Identity Information contained in OV and EV certificates was reduced from 825 days to 398 days, and the reuse period for domain validation information was reduced from 398 days to 200 days. DV certificates, which do not contain organizational information, are not subject to the change in the organizational information reuse period.The difference among the three types is not encryption strength but the scope of identity verification prior to issuance. For a single site, one can decide which type to obtain as needed, but as the number of managed assets grows, deciding which verification level to apply to which service becomes a matter of organizational standards. Without a standard, the choice of certificate type is left to individual system administrators' judgment, and over time the certificate configuration across the organization loses consistency. ☑️ What Changes as the Number of Managed Assets GrowsThe explanation so far presupposes an individual certificate. A single browser and a single server perform a handshake, and a single administrator creates a CSR and installs a certificate. Actual enterprise environments differ in the number of managed assets. Points where certificates are used are scattered across public web services, internal business systems, load balancers and network equipment, user devices and VPN connections, and containers and APIs. As scale grows, the premises of the concepts explained above each turn into the following challenges.First, it becomes difficult to grasp which certificates exist where and in what quantity. Because private keys are generated individually on servers and never leave that location, certificates and keys exist scattered across multiple systems from the start. If an organization also uses both public and private CAs together, or mixes multiple CAs, the issuing entities and management consoles are further divided. A certificate not in the inventory is included in neither renewal targets nor inspection targets.Second, it becomes difficult for the organization to control items determined at issuance time. The DV, OV, EV verification levels discussed above, as well as the algorithm, key length, and validity period, are all determined at the time of issuance, and changing them afterward requires reissuance. Even if standards are set, if they are not applied at the issuance stage, the actual choice is left to individual administrators' judgment.Third, the limitations of tracking expiration schedules manually become apparent. Because the browser checks a certificate's expiration and revocation status at every connection, missing the expiration of even one certificate blocks access to that service. When the number of managed assets reaches into the hundreds, the premise that a single administrator will not miss a schedule becomes difficult to sustain.Fourth, the issuance and installation procedures are repeated as many times as there are systems. The process described above — CSR generation, issuance request, installation of the certificate and intermediate certificate, and verification — is short when considered for a single certificate, but as the number of targets grows, it becomes repetitive work as-is.On top of this, the shortening of validity periods compounds the problem. The CA/Browser Forum approved a proposal in 2025 to reduce the maximum validity period of public TLS/SSL certificates in stages. Starting with 200 days on March 15, 2026, it will shrink to 100 days on March 15, 2027, and to 47 days on March 15, 2029. DigiCert applies a standard one day shorter than the ceiling at each point in time, issuing public TLS/SSL certificates with a maximum validity of 199 days starting February 24, 2026. Even if the number of certificates managed stays the same, the number of renewal operations performed continues to increase.The operational approach that handles the four challenges outlined above under a single standard is called certificate lifecycle management. It is a method of managing the discovery, issuance, installation, renewal, and revocation processes of an organization's certificates at the organizational level rather than leaving them to individual administrators. DigiCert Trust Lifecycle Manager is a product that supports carrying out this management on a single platform. ☑️ Certificate Lifecycle Management Supported by DigiCert Trust Lifecycle ManagerDigiCert Trust Lifecycle Manager is a product that discovers, controls, and automates certificates distributed across cloud, hybrid, and on-premises environments, and is provided as a component of DigiCert ONE, a digital trust management platform. Below, we look in order at how it addresses the four challenges outlined above, the scope to which this management applies, and what configurations it is offered in. Securing Certificate VisibilityTrust Lifecycle Manager imports certificates regardless of CA or trust store to build an inventory. It scans networks, clouds, and endpoints to discover certificates and keys that are not registered as managed assets. In addition to cloud discovery scans, the inventory can also be built through Certificate Transparency (CT) logs, APIs, and CSV imports.In customer environments, this feature serves as the starting point for defining the scope of management. Certificates issued individually by departments, or certificates not properly handed over during personnel transitions, generally remain outside the inventory. This is the reason unidentified certificates, misconfigurations, and weak encryption methods remain in place.When certificates issued by multiple CAs are brought together into the inventory, the problem of divided issuing entities is also resolved at the same time. Regardless of which CA issued them, the current status can be checked from a single list, and policy application and expiration management can subsequently be carried out under the same standard. Defining and Applying Encryption PolicyStandards for algorithm, key length, and validity period are defined, and different policies can be applied by region, environment, and business unit. Role-based access permissions can be granted so that certificates are managed only within an assigned scope.As noted in the second challenge above, a certificate's verification level and cipher settings are determined at the time of issuance. Applying policy at the issuance stage keeps the choice of which type and settings to use for which service under organizational standards rather than leaving it to individual judgment, and makes it easier to present evidence during audits.Encryption policy is not something set once and left alone. When regulatory requirements change or an algorithm in use needs to be replaced, knowing which certificate was issued with which algorithm and key length is necessary to determine the scope and targets of the transition. Trust Lifecycle Manager supports standardizing policy to maintain audit readiness and adjusting standards as cryptography-related regulations change. Controlling Expiration and MisconfigurationIt proactively detects certificates nearing expiration and misconfigurations, and sends alerts along with policy violations. Alerts are delivered to the organization and system responsible for the certificate in question.Service outages due to certificate expiration are not unforeseen failures but failures that occur because a scheduled date was missed. When expiration information is consolidated in the inventory and automatically delivered to the responsible party, the pathway leading to missed renewals is itself reduced. Automating Renewal and IssuanceThe platform handles renewals and repetitive change work, and integrates with CA, ITSM, cloud, application delivery, and IAM tools. Standard protocols such as ACME and SCEP, Windows auto-enrollment, and APIs are provided as automation methods, which can be used to connect to existing workflows.The reason multiple automation methods are presented is that the environments where certificates are installed differ from one another. When the process from CSR generation through installation and verification, described as the fourth challenge above, is automated, it becomes possible to build a structure where operational headcount does not need to scale at the same rate even as managed assets grow or validity periods shorten. Conversely, any point where automation is not applied becomes a bottleneck at every renewal cycle. Environments Where Certificate Management AppliesTrust Lifecycle Manager is premised on applying certificate management to hybrid infrastructure, users and devices, and cloud workloads without reconfiguring existing infrastructure. It handles both certificates issued by public CAs and private certificates issued for internal use. This means the scope of management is not limited to public web servers.In the hybrid infrastructure and network domain, it targets certificates for servers, load balancers, and network equipment. It manages certificates scattered across multiple locations from a single place, and automates renewal for services where an outage would have significant impact. This is also an area where the problem of divided management consoles tends to surface first in environments using both data centers and cloud together.In the user and device authentication domain, it manages certificates used for devices, smart cards, and wireless and VPN connections. It integrates with UEM and identity solutions to handle certificate issuance and revocation at the time of hiring and departure, and applies authentication and encryption policy consistently according to organizational standards. This is an area where, because certificates are attached to people and endpoints, the responsible organization often differs from the infrastructure team.In the cloud-native and DevOps domain, it automates certificates for containers, clusters, and APIs. It integrates with DevOps pipelines, secrets managers, and IaC tools to ensure certificates are handled within the deployment flow. From an operational standpoint, the criterion for review is whether security policy can be maintained without slowing down the development organization's pace of work. Offerings by Scale of ManagementTrust Lifecycle Manager is offered in three configurations — Essentials, Advanced, and Premium — depending on the scale of management and level of requirements.Essentials targets small to mid-sized organizations managing DigiCert certificates in a single environment. It includes inventory building via cloud discovery scans, CT logs, APIs, and CSV imports; issuance and management of public and private DigiCert certificates; tags and alerts; custom reporting; and automation via ACME, SCEP, Windows auto-enrollment, and APIs. Advanced targets environments with a mix of multiple CAs, covering governance across hybrid environments overall and extended automation and integrations. Premium targets large-scale infrastructure, and includes Kubernetes and ServiceNow integration, PAM integration, post-quantum cryptography migration workflows, and SLA-based dedicated support.When reviewing adoption, first organizing how many CAs are currently in use and what tool integrations are needed makes it easier to determine which configuration fits. ☑️ Frequently Asked QuestionsAre SSL certificates and TLS certificates different?They are certificates in the same family. The name changed when the successor version to the SSL protocol was named TLS, and TLSv1.3 is currently in use. Certificates sold under the name SSL are, in fact, TLS certificates.What is the difference between DV, OV, and EV certificates?The scope of identity verification performed prior to issuance differs. DV only confirms whether the applicant controls the domain; OV additionally verifies the business's name, type, status, and physical address; and EV further confirms the business's operational substance and the applicant's employment status. The encryption strength of the three types is not different.What is certificate lifecycle management?Certificate lifecycle management is an operational approach that manages the discovery, issuance, installation, renewal, and revocation processes of an organization's TLS/SSL certificates under a single standard. It includes understanding where and how many certificates exist, applying organizational policy at the time of issuance, proactively controlling expiration, and automating repetitive procedures.What is DigiCert Trust Lifecycle Manager?DigiCert Trust Lifecycle Manager is a certificate lifecycle management product that discovers, controls, and automates certificates distributed across cloud, hybrid, and on-premises environments. It is provided as a component of the DigiCert ONE platform, and can import certificates to build an inventory regardless of the issuing CA or trust store. Since the detailed scope of support may vary by plan selected, confirmation is needed when reviewing adoption.How much does the management burden increase as certificate validity periods shorten?The number of renewal operations performed increases. The maximum validity period for public TLS/SSL certificates was reduced to 200 days as of March 15, 2026, and will shrink to 100 days on March 15, 2027, and to 47 days on March 15, 2029. DigiCert has been issuing with a maximum validity of 199 days since February 24, 2026. Even if the number of certificates managed remains the same, the annual number of renewals continues to increase, making manual management methods difficult to sustain.What problems arise from managing certificate expiration manually?The likelihood of missed renewals grows as the number of managed assets increases. Because browsers check a certificate's expiration status at the time of connection, a single expiration directly leads to blocked access to that service. Certificates not registered in the inventory are also excluded from expiration tracking, which is why securing visibility is a prerequisite for expiration management. ☑️ ConclusionThe operating principle of a TLS/SSL certificate is not conceptually complex in itself. A key pair securely opens a session, the signature of a trusted CA guarantees identity, and the browser checks expiration and revocation status. Management becomes difficult not because the principle is complex, but because the number of targets to which the same principle applies within an organization grows from hundreds to thousands, and renewal cycles keep shortening on top of that.For this reason, certificate management is less a question of where to purchase certificates and more a question of how to identify the certificates that exist within an organization, what policy governs issuance, how to avoid missing expirations, and how to automate repetitive procedures. DigiCert Trust Lifecycle Manager is a tool for handling these four items at the organizational level rather than leaving them to individual administrators' management capacity.However, introducing a tool alone does not immediately establish a management system. Judgments vary by environment, from confirming where and how extensively certificates are being used, to deciding what settings to adopt as organizational standards and which environments to automate first. CloudNetworks supports this entire process, from reviewing current certificate operations, to reviewing, building, and operating DigiCert Trust Lifecycle Manager adoption. For detailed product information and adoption inquiries, please contact CloudNetworks. ▶ Learn more about DigiCert Trust Lifecycle Manager (TLM) [Source : DigiCert, "How TLS/SSL Certificates Work", https://www.digicert.com/how-tls-ssl-certificates-work, DigiCert, "What is SSL, TLS and HTTPS?", https://www.digicert.com/what-is-ssl-tls-and-https, DigiCert, "What is an SSL Certificate?", https://www.digicert.com/what-is-an-ssl-certificate, DigiCert, "What's the Difference Between DV, OV & EV SSL Certificates?", https://www.digicert.com/difference-between-dv-ov-and-ev-ssl-certificates, DigiCert, "Trust Lifecycle Manager | PKI Management", https://www.digicert.com/trust-lifecycle-manager, DigiCert, "TLS/SSL Certificate Validity: Frequently Asked Questions", https://www.digicert.com/faq/tls-ssl-certificate-validity, DigiCert, "TLS Certificate Lifetimes Will Officially Reduce to 47 Days", https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days]
September 02, 2026
