Here's the blog formatted for Webflow without the section dividers:

What is a Digital Certificate?

Digital certificates are the credentials that establish trust in the digital world. They are electronic documents that bind a cryptographic public key to a verified identity—whether that identity belongs to a website, an application, a device, or a person. Every time you see the padlock icon in your browser, a digital certificate is at work. Every secure connection your organisation makes relies on certificates to verify identity and enable encryption.

A digital certificate is a digitally signed document issued by a Certificate Authority (CA) that validates the association between a public key and a specific identity. Certificates on the internet typically conform to the widely adopted X.509 standard, which defines the format and overall structure of those certificates as well as several important components.

These components include required and optional fields, encoding rules (DER/PEM), and the syntax of extensions. Each plays a role in the function of the certificate, including the subject's identity information, the subject's public key, the certificate's validity period, the issuing CA's identity, the issuing CA's digital signature, and any relevant extensions such as Key Usage or Subject Alternative Names.

The digital signature is what makes the certificate trustworthy by providing integrity and authenticity. Consuming entities can validate this signature and the certificate's placement within a trusted certification path to establish that the CA has authenticated the subject's identity and issued the certificate. For a broader understanding of how certificates fit within the wider trust framework, see our guide to What is PKI.

Types of Digital Certificates

Domain Validated (DV) Certificates

Domain Validated certificates verify only that the applicant can demonstrate control over a specified domain. The validation process is typically automated, and the challenge verification is usually completed within minutes, using one of several methods as defined by the CA/Browser Forum Baseline Requirements.

HTTP-based validation requires the Certificate Authority to provide the applicant with a unique text file containing a generated token. This file is placed into a designated location within the domain that is accessible via URL. The CA then interrogates that location to fetch the file and confirm ownership.

DNS-based validation involves the CA providing the applicant with a unique token which is then used to create a specific TXT or CNAME record within the domain's DNS Zone. The CA queries the domain's DNS for the record to validate ownership.

Email-based validation relies on the CA sending a verification email containing a unique code or link to a pre-approved email address such as admin@yourdomain.com or hostmaster@yourdomain.com. The applicant accesses that mailbox to use the link or code, proving administrative control over the domain.

Domain Validated certificates are suitable for basic encryption but provide no assurance about the organisation behind the domain. They are commonly used for smaller personal websites, blogs, internal services, or automated development environments.

Organisation Validated (OV) Certificates

Organisation Validated certificates attest to both domain control verification and verification of certain legally verifiable details about the organisation. In addition to DV verification controls, the CA conducts a manual review of business details such as registered legal names, physical address, and incorporation jurisdiction.

This process typically takes days to complete whilst the CA performs verification via government records, third-party business databases, or direct confirmation with the organisation. The CA also confirms that the individual requesting the certificate is authorised to do so on behalf of the organisation. OV certificates display the organisation's name in certificate details.

Organisation Validated certificates are commonly used for corporate websites, government or regulated industry sites, business-to-business portals, or any scenario where proving the organisation's legitimacy is required.

Extended Validation (EV) Certificates

Extended Validation certificates require rigorous verification of the legal entity, physical location, and operational or jurisdictional existence. An EV certificate attests that the CA has verified domain control at a stricter high-assurance level than DV and performed more rigorous legal identity verification than an OV certificate.

This process includes verification of the exact legal name, registration number, and legal status of the organisation using authoritative government sources. It also includes verification that the organisation is actively operating, evidencing verified contact details, financial verification such as active bank accounts, and confirmation of a minimum operational time period.

Only a named individual can request an EV certificate. The CA must verify their identity using authoritative identity sources and databases, and validate that the individual has explicit organisational authorisation to make the request. EV certificates must include additional EV-mandated extensions containing verified details of the organisation. This extensive review can take weeks but provides the highest level of identity assurance.

Extended Validation certificates are typically used for financial institutions, government portals, identity providers, payment processors, or any scenario requiring strong identity assurance.

Other Certificate Types

Beyond TLS/SSL certificates for websites, organisations rely on a range of other digital certificates for different trust and security purposes.

Code signing certificates verify the authenticity and integrity of software, ensuring that applications have not been tampered with and originate from a trusted publisher.

S/MIME certificates enable email encryption and digital signing, protecting message confidentiality and allowing recipients to verify the sender's identity.

Client certificates support strong user and device authentication, commonly used for VPN access, zero-trust architectures, and mutual TLS (mTLS).

Document signing certificates provide cryptographic proof of authorship and integrity for legally binding documents, helping to ensure they remain unaltered after signing.

The Certificate Lifecycle

Every digital certificate follows a defined lifecycle, from issuance through renewal, expiry, or revocation. Understanding this lifecycle is essential for effective certificate management and maintaining secure, uninterrupted services.

The process begins with the generation of a public-private key pair and creation of a Certificate Signing Request (CSR) that must be submitted to an appropriate CA. The Certificate Authority then validates the request, cryptographically signs the certificate, and issues it.

Once issued, the certificate is deployed to the appropriate systems—such as web servers, applications, devices, or end users—where it can be used to enable secure communication or authentication.

Before a certificate reaches its expiration date, defined by the validity period, it must be renewed to avoid service outages or security issues. If a certificate is compromised, mis-issued, or no longer required, it can be revoked by the CA, rendering it untrusted before its natural expiry date.

Finally, at the end of their lifecycle, certificates are retired and archived in accordance with organisational policies and governance compliance requirements. For a deeper exploration of this process, read our guide to What is Certificate Lifecycle Management.

Why Certificate Management Matters Now

The certificate landscape is evolving rapidly, driven by tightening industry standards and a growing emphasis on automation. Publicly trusted TLS certificates are now limited to a maximum validity of 397 days, a significant reduction from the multi-year lifespans that were once common. Many organisations are adopting 90-day certificates as best practice to reduce key compromise risk, along with a drive towards enabling automated issuance and renewal.

Looking ahead, proposed changes would further shorten the reuse window for domain control validation (DCV) to as little as 10 days by 2029. Though not yet enforced at the time of writing, this is a realistic and widely discussed proposal.

These changes improve security posture by narrowing the window of exposure if a private key is compromised or if a certificate is mis-issued. However, they also make manual certificate management increasingly impractical. Organisations that once relied on annual renewal reminders now face renewal cycles every few months, often across hundreds or thousands of certificates. Without automation and centralised visibility, this growing operational burden significantly increases the risk of outages and security failures.

Growing Certificate Complexity

Modern organisations manage a rapidly growing and increasingly diverse certificate estate that includes internal TLS and mutual TLS (mTLS) certificates, code signing certificates, S/MIME certificates, and certificates embedded in IoT devices and operational technology.

Each certificate use case typically has its own issuance workflows, validation requirements, lifespans, and revocation mechanisms. As these certificates proliferate across cloud platforms, development pipelines, devices, and users, visibility of that certificate estate can become increasingly fragmented.

Many organisations lack a complete inventory of where certificates are deployed, who owns them, and when they expire. This certificate sprawl increases operational complexity and expands the potential attack surface, making centralised governance and lifecycle management critical. Our blog on why traditional certificate management is no longer enough explores these challenges in detail.

The DevOps Challenge

The shift to cloud-native architectures and DevOps practices has dramatically increased certificate turnover in many organisations. Containers, microservices, short-lived workloads, and dynamic scaling models require certificates to be issued, rotated, and revoked at machine speed. In many environments, certificates may exist for mere hours or days, yet must still be trusted, tracked, and secured.

Traditional manual certificate processes were designed for static infrastructure and annual renewals. This does not practically scale to environments where services are created and destroyed continuously. Without automation tightly integrated into CI/CD pipelines and orchestration platforms, certificate management quickly becomes a bottleneck—or worse, a source of outages and security gaps. Understanding the four pillars of CLM can help organisations address these challenges effectively.

Certificate Transparency and Revocation

Certificate Transparency

Certificate Transparency (CT) provides an open framework of publicly accessible, append-only logs that record the issuance of publicly trusted TLS certificates. When CAs issue certificates, they are required to submit them to multiple independent CT logs. This transparency helps detect mis-issued or rogue certificates—if someone fraudulently obtains a certificate for your domain, monitoring CT logs can reveal its existence, even if it was never deployed.

Modern browser policies, notably those enforced by Google Chrome, require publicly trusted TLS certificates to include Signed Certificate Timestamps (SCTs) from multiple distinct CT logs. Requiring SCTs from multiple independent CT logs improves the overall resilience and trustworthiness of the CT ecosystem.

If a single CT log becomes unavailable, misbehaves, or is later disqualified, certificates that include SCTs from other trusted CT logs remain verifiable. This also reduces the risk that a compromised or malicious CT log could conceal a mis-issued certificate, as multiple independent CT logs would need to collude to avoid detection.

Browsers validate the presence and correctness of these SCTs during the TLS handshake or when examining the certificate chain. Certificates that fail to meet SCT requirements can be flagged as non-compliant and may be rejected completely or result in security warnings.

Revocation Mechanisms

Revocation mechanisms ensure that certificates can be invalidated before their scheduled expiration if they are compromised, mis-issued, or no longer trusted.

Certificate Revocation Lists (CRLs) are periodically published lists of revoked certificates maintained by the issuing CA. However, CRLs can be large and are increasingly impractical at internet scale.

Online Certificate Status Protocol (OCSP) allows near real-time validation checks by enabling clients to query the CA for the current status of a certificate.

OCSP Stapling allows the server to periodically fetch its own OCSP response and include it in the TLS handshake, eliminating the need for the client to contact the CA during connection establishment. This can be particularly beneficial when clients cannot reach the CA directly.

How Unsung Supports Certificate Management

Unsung helps organisations gain visibility and control over their certificate estates. Our discovery services identify certificates across your entire infrastructure—including those outside the visibility of central IT teams. We assess your current certificate practices against industry security best practices and governance compliance requirements.

Our managed certificate services handle the operational complexity of certificate lifecycle management. From automated issuance and renewal to continuous monitoring and proactive alerting, we help ensure your certificates remain valid and your critical services stay online.

When organisations prefer to build or extend automation in-house, our PKI consultancy experts provide design and implementation support to deploy scalable, future-proof certificate management solutions. For insights into what to look for when evaluating solutions, see our guide to key features in an enterprise CLM deployment.

Contact Unsung to learn how we can help you manage your digital certificates effectively and with confidence.

‍

‍