Electronic signatures are virtual marks that confirm that individuals have agreed to details or stipulations outlined in specific documents. These resemble traditional, handwritten signatures because they're designed to show acceptance or authorization — but with a key distinction: they rely on electronic actions rather than physical marks. Options include typing names, drawing signatures via touchscreen, or uploading images of handwritten signatures.

Electronic signatures can range from basic visual signatures to more secure digital signatures. Basic ones are easy to add, but these visual indicators can be copied or reused. Digital signatures add stronger protection through cryptographic validation, helping confirm the signer’s identity, support document integrity, and show whether the file has been altered after signing.

Three methods for adding a signature to a PDF document

With so many ways to sign documents, it’s tough to know where to start. Ultimately, the preferred signature method comes down to document-specific risk levels. In some situations, straightforward electronic signatures may be sufficient: internal documents, sales quotes, permission slips, or acknowledgments of document receipt. As security needs increase, cryptographic options become more important, especially for documents that require identity assurance or tamper-evident protection.

How to digitally sign a PDF with a digital certificate (most secure)?

If security is a priority, use certificate-based solutions to sign PDFs with confidence. This process is generally straightforward but calls for verified document signing certificates, along with software that supports cryptographic signing.

• Purchase a digital signature certificate. Obtain a document signing certificate from a trusted certificate authority (CA). Look for a certificate solution that offers tamper-evident protection and compatibility with timestamping mechanisms. Install or connect the certificate so your signing software can detect it.
• Open the PDF. Use a tool that supports certificate-based signatures to open the PDF and view the file (Adobe Acrobat is an option). You can also digitally sign PDF forms via Adobe Acrobat Reader.
• Select the certificate or digital signature option. Look through the program menu to find a prompt for applying a digital signature. If selected, this feature allows you to protect the PDF with a document signing certificate, rather than using an electronic signature. This should not be confused with other electronic options such as Fill & Sign.
• Find a location for the signature. Select the prompt to digitally sign the document. You will see directions to click and drag the area in which you want the signature to appear.
• Choose your certificate or digital ID. With the location designated, you will see another prompt to configure a digital signature identity. You can use a signature creation device to configure a token or import an existing digital ID as a file. If you still need to purchase a certificate, select the option to order a signature device from a partner. For Adobe workflows, look for providers supported through the Adobe Approved Trust List (AATL), which includes Sectigo. Be sure to download necessary drivers and confirm that a signature device is properly linked to your computer. You may also be able to apply a timestamp.
• Sign and save the PDF. Review all signature details and check that the right certificate has been selected. Be prepared to enter a password or PIN if prompted. Finally, save the document. Consider validating the signature by re-opening the document and viewing the signature status.

How to electronically sign a PDF with a basic signature?

Built-in PDF apps (such as Adobe Acrobat) provide opportunities to electronically sign PDFs. This streamlined approach can get documents signed quickly, but without the cryptographic protection that makes digital signatures so compelling. 

To electronically sign a PDF, follow these steps:

• Open the PDF. Use a software solution such as Adobe Acrobat to open the PDF.
• Choose a signing tool. Different programs may use different tools to add signatures. Adobe Acrobat's Fill & Sign function provides a straightforward option for adding basic electronic signatures to PDFs.
• Provide your signature. Choose options like typing or drawing your signature. Adobe even allows you to select a preferred font. If preferred, upload an image of your handwritten signature.
• Add the signature to the document. Indicate where you want the signature to appear. Typically, this will be placed on a designated signature line. Your PDF app or program may allow you to adjust the placement or even the size.
• Save or download the signed PDF. After the signature is placed, save the signed PDF. Adobe provides an option to save the document via cloud storage. The signed file will function as a new version of the document. If you need an audit trail, use a service that records signing activity, timestamps, and signer details. A basic typed, drawn, or uploaded signature may not provide the same level of evidence.

How to sign a PDF using an online tool?

Online tools make it easy to sign PDF documents on the go. The process is fast and doesn't require you to download or own a particular program or app. Some online services also offer features that can reduce editing or restrict access, such as flattening a PDF or adding password protection. These options can be useful, but they do not provide the same security as certificate-based digital signatures.

Browser-based tools are typically free to use, but with a caveat: you may need to pay extra to invite other people to sign. These online services also provide tools designed to compress PDFs (reducing their file size) or to convert them (to Microsoft Word or PowerPoint, for example). If you're focused on getting PDFs signed, however, you'll want to follow these steps:

• Upload the PDF. Look in the website's list of tools or features for options labeled 'Sign' or 'Sign PDF.' Select a tool that allows you to sign and then upload a document. Note which formats are accepted; you may be able to upload a Word document, convert it, and then sign as a PDF.
• Select the preferred signing feature. Many online e-signature tools make it easy to type electronic signatures or even 'handwrite' them using a touchscreen or mouse. Choose a preferred method before completing and accepting the signature.
• Place the signature on the PDF. Most online services provide drag-and-drop tools, so you can place your signature field in a preferred location. A sizing tool should let you shrink or expand your signature.
• Export or download the file. The online service will provide a prompt or button so you can download the signed file to your device. Click this, or if preferred, select a similar option for saving to Google Drive or saving to Dropbox. 

How do you know the right way to sign a PDF?

There is no 'right' approach to signing a PDF. This comes down to personal preferences and risk tolerance. For simple forms or low-risk approvals, basic electronic signatures (completed in PDF programs or through online tools) may be sufficient, depending on the document, organization, and legal or compliance requirements. Online tools expedite this signing process while programs such as Adobe Acrobat are familiar to many recipients and widely used for PDF signing workflows.

When documents demand strong identity verification and tamper evidence, opt for certificate-based digital signatures. These use cryptographic validation to help confirm the signer’s identity and show whether the file has been altered after signing.

When should you use a digital signature certificate?

Many documents require strong proof of signer identity or robust protection against tampering. These elevated needs are most common when documents contain sensitive information: financial data, legal obligations, or proprietary business information.

Businesses and independent professionals across many sectors rely on certificate-based digital signatures to safeguard clients and customers while also meeting strict compliance requirements. These can be valuable in industries ranging from healthcare to real estate. They're also valued for government contracts because they support strict chains of custody.

These situations demand greater protection; without added assurance, businesses and individuals are vulnerable to document tampering. Certificate-based digital signatures limit these risks by binding verified identities to sensitive documents.

Digital signatures also support strict governance frameworks. For example: the European Union's electronic IDentification, Authentication and trust Services (eIDAS) sets standards for electronic signatures. Under eIDAS, qualified electronic signatures have the legal effect equivalent to handwritten signatures in the EU.

Secure PDFs with digital signature certificates from Sectigo

Digital signatures provide peace of mind through tamper-evident protection and identity verification. By building cryptographic validation directly into PDFs, certificates go above and beyond basic electronic signatures to secure sensitive documents. 

Sectigo offers document signing options for independent professionals who need trusted PDF signatures, as well as enterprise teams managing higher-volume signing workflows. Use Sectigo’s document signing solutions to protect documents, verify trust, and sign with confidence.

Manual certificate management is already slowing teams down. But certificate automation alone is no longer enough to support modern infrastructure.

Certificates are core infrastructure to online businesses. They're deployed across hybrid, multi-cloud, and distributed environments, securing everything from servers and load balancers to CDNs, WAFs, and access systems. As that footprint grows, so does the burden of keeping it all valid, visible, and compliant.

At the same time, shorter certificate lifecycles and rising certificate volumes are pushing automation to its limits. The 47-day validity mandate means renewal cycles that used to happen a few times a year will soon need to happen 12x more per year, across every environment a business operates in.

Yet most enterprises are still relying on fragmented connectors, and manual workflows to keep up. That approach creates risk and limits scalability, when neither can be afforded.

Sectigo Orchestration Gateway (SOG) replaces fragmented automation with a single lightweight automation layer for the entire certificate lifecycle across servers, load balancers, CDNs, WAFs, and access systems, enabling secure, policy-driven execution at scale.

The bottom line? Manual management alone will never scale. Automation with fragmented connectors won't either. A unified orchestration gateway is required to deliver predictable, secure certificate operations.

The operational gap: Why fragmented automation doesn't scale

Most enterprises today operate with a patchwork of tools rather than a coherent system:

• Multiple connectors per platform
• Fragmented integrations
• Inconsistent workflows across environments

Individually, each of these might work. Together, they create certificate blind spots, configuration drift, and high operational overhead. Every new platform means another connector to build, another script to maintain, another team that must learn a different process. The result is an automation strategy that looks comprehensive on paper but breaks down in practice, usually at the worst possible time, like an unexpected outage caused by a certificate nobody knew was about to expire. 

The shift: From connector sprawl to a single orchestration gateway

Modern certificate lifecycle management requires one consistent automation model and centralized control, not a growing pile of point solutions stitched together after the fact.

Sectigo Orchestration Gateway delivers this by replacing point integrations with a single gateway, enabling consistent automation across hybrid, and multi-cloud and multi-vendor infrastructures. Instead of managing automation platform by platform, teams manage it once, centrally, with the same policies and processes applied everywhere, all while maintaining a low infrastructure footprint. 

How SOG enables scalable certificate lifecycle orchestration

1. Replace fragmented connectors with a single automation gateway

SOG connects to multiple endpoints through one gateway, eliminating the need for separate agents and integrations for every platform. That consolidation directly reduces infrastructure footprint and operational overhead. Fewer moving parts means fewer things that can break, and fewer teams needed to maintain them.

2. Automate the full certificate lifecycle end-to-end

SOG automates discovery, issuance, renewal, installation, and revocation as a single continuous process, not a series of disconnected steps. That enables genuinely hands-free lifecycle management at scale, rather than automation that still requires manual coordination between stages.

3. Secure certificate operations without expanding risk

SOG retrieves credentials just-in-time via PAM and local vault integrations, avoiding local credential storage altogether. Combined with policy-based access control, this means certificate operations can scale without expanding the attack surface.

4. Scale with lightweight, modular deployment

SOG's architecture is lightweight and built for fast deployment. Its modular design means new platforms can be supported without reworking the entire system — critical for enterprises whose infrastructure is constantly evolving.

5. Eliminate blind spots with full certificate visibility

You can't manage what you can't see. SOG's network discovery identifies certificates across environments, and central tracking within SCM significantly reduces the risk of outages caused by expired or forgotten certificates.

6. Future-proof operations with crypto agility

SOG supports evolving standards and PQC readiness, enabling parallel certificate operations at scale, a capability that will matter increasingly as organizations begin transitioning to post-quantum cryptography. And because SOG's capabilities continue to grow through its modular architecture, it's built to adapt quickly to evolving enterprise needs rather than requiring a platform overhaul down the line. 

From automation chaos to unified certificate lifecycle control

When organizations move from fragmented automation to a unified gateway, the benefits compound: reduced risk, lower operational overhead, and improved compliance. What used to require constant firefighting across disconnected tools becomes a single, predictable system. 

The foundation for modern certificate lifecycle management

Organizations need more than automation. They need orchestration, delivered through a single gateway that governs the entire certificate lifecycle, not just pieces of it.

Sectigo Orchestration Gateway enables end-to-end lifecycle automation, secure execution, and scalable operations across any environment.

The future of certificate lifecycle management is one orchestration layer that drives consistency, speed, and control at scale. 

Certificate management is becoming too important to treat as a back-office IT task. Several industry shifts are making it a business risk SMBs can’t afford to ignore:

Proliferation of certificates: Five years ago, most SMBs had one website and one certificate. Today they may have:

• A marketing website
• A customer portal
• SaaS applications
• APIs
• Cloud services
• Multi-domain environments

Each may be using different certificates, different hosting providers, and different management workflows. When certificates are spread across different domains, services, providers, and owners, teams first have to figure out which certificate expired, where it lives, and who can fix it.
The bigger problem is the disruption that follows: lost transactions, support calls, confused customers, and time spent figuring out what went wrong. If visibility is a challenge for you, it may be time to automate certificate discovery and inventory management.

Shrinking certificate lifespans. In early 2026, TLS certificate lifespans decreased from one year to 200 days. Lifespans will further decrease to 100 days in early 2027. By 2029, certificate renewals will become a monthly event when the maximum certificate lifespan drops to 47 days. 
This is not just an enterprise problem. Even the smallest organizations managing a handful of certs will experience an increase in the amount of renewals they will have to manage each year. By 2029, one cert is no longer one cert. One certificate will be equal to 8-12 certs when you factor in renewals. But let’s take a look at what will be happening a few months from now, when certificate lifespans drop to 100 days.

As renewal volume increases, spreadsheets, scattered reminders, and disconnected tools become harder to trust. If shorter certificate lifespans are already adding pressure to your IT lead, a domain subscription model can help simplify the work. Instead of purchasing and managing each certificate one at a time, you pay per fully qualified domain name (FQDN) or wildcard domain and can issue unlimited certificates during the subscription period. That gives SMBs a simpler way to align renewal dates, reduce one-off procurement, and keep certificate management from becoming a constant scramble.

Browser-driven trust expectations. Browser expectations are getting stricter, and SMBs are held to the same standard as everyone else. It is not only expired certificates that can create problems. Misconfigured certificates, incomplete trust chains, outdated roots, or certificates issued for the wrong domain can all affect whether a browser treats your site as trustworthy. For customers, the technical reason does not matter. The experience is simple: the site feels unsafe, unreliable, or not worth the risk.

How can SMBs reduce certificate risk before it disrupts the business?

For many SMBs, the issue is not that they lack ways to issue certificates. It is that those tools often do not show the full picture of certificate risk across the business. A hosting provider may cover one site, a renewal email may catch one deadline, and a spreadsheet may track what someone remembered to enter. But as certificates spread across domains, portals, cloud services, and providers, businesses need more than individual issuance or renewal tools. They need visibility into what exists, control over how certificates are managed, and automation that helps reduce risk before it reaches customers.

That is the role Sectigo Certificate Manager (SCM) Pro is designed to play: a more complete way to discover, manage, and automate certificates across the business so SMBs can address certificate risk as a whole, not one certificate at a time.

You can see firsthand how SCM Pro helps uncover certificate risk across your business so you can identify what exists, understand where exposure is building, and take action before it causes disruption. Try it for free for 30 days – no strings and no credit card needed.

The takeaway is simple: if your business depends on websites, portals, apps, or cloud services, certificate visibility is part of keeping those experiences reliable.

Start by understanding what certificates you have, where they live, and who owns them—then look for ways to manage that risk before it reaches your customers.

The World Wide Web is deeply embedded in modern life: work, communication, entertainment, and so much more. Today's users generally assume that online interactions will be secure, but they often struggle to understand the layered technologies that make secure online navigation possible.

It all comes down to trust. This is the confidence that users experience when browsing the web; the expectation that digital experiences will feel seamless and are better protected. It's what stops us from second-guessing every digital interaction. It often feels natural, but in reality, trust emerges as many carefully orchestrated tools and technologies work together to verify identities and encrypt sensitive information.

What makes the World Wide Web trustworthy?

No single technology secures every part of the Web. SSL/TLS, PKI, S/MIME, code signing, and automated CLM are just a few of the technologies that support digital trust, alongside controls such as access management, threat detection, and web application protection.
Each plays a distinct role in protecting digital identities, communications, and interactions:

• SSL/TLS certificates encrypt communications by safeguarding data exchanged between servers and browsers.
• PKI (public key infrastructure) establishes digital trust at scale by providing reliable infrastructure to verify identities and support encryption across digital environments.
• S/MIME supports sender authentication, message integrity, and email encryption.
• Code signing verifies software integrity, confirming that applications have not been tampered with or changed.
• Automated CLM keeps certificates up to date by streamlining discovery, issuance, and renewal, improving certificate visibility and reliability. 

Together, these technologies support everyday activities such as logging into online banking, purchasing products, downloading software, receiving authenticated business email, and accessing corporate applications.

Encrypting communications with SSL/TLS

Every time you visit an HTTPS website, SSL/TLS certificates help authenticate the connection and protect information exchanged between your browser and the server. Although HTTPS does not guarantee that a website is trustworthy, it helps prevent data from being intercepted or altered in transit.

SSL/TLS certificates are issued by trusted certificate authorities (CAs), which verify domain control and, depending on the certificate type, may also validate information about the organization. Together, encryption and authentication help protect data in transit and give users greater confidence that they are connecting to the intended website.

Building trust through PKI

Digital certificates rely on public key infrastructure (PKI) to establish verifiable chains of trust. Certificate authorities, public and private keys, and trusted root and intermediate certificates work together to authenticate identities and support encryption and digital signatures.

PKI provides the foundation for SSL/TLS, S/MIME, code signing, and other certificate-based security technologies. It also supports certificate issuance, renewal, and revocation. Without effective PKI management, organizations risk expired, unknown, compromised, or misconfigured certificates that can disrupt services and weaken digital trust.

Extending trust beyond websites

The digital ecosystem surrounding the World Wide Web extends far beyond the websites people browse. Email, software, APIs, connected devices, and corporate applications also depend on trusted identities and secure communications. Many depend on public key infrastructure and on digital certificates.

While SSL/TLS certificates improve website security, other digital certificates address the unique challenges that can emerge in different digital contexts. If these systems or virtual settings are not explicitly addressed, businesses and individuals may face risks such as email interception, software tampering, and unauthorized connections between systems.

Securing email with S/MIME and Mark Certificates

The protocol S/MIME (Secure/Multipurpose Internet Mail Extensions) helps secure email communication. Issued by CAs and installed in email clients, S/MIME certificates can verify sender identity, confirm that a message has not been altered, and protect sensitive content from unauthorized access.

S/MIME offers a crucial safeguard against some of the web's most persistent and dangerous threats: social engineering attacks that play on human trust. These include phishing (tricking email recipients into sharing sensitive information) and spoofing (adjusting email headers to make messages appear to come from reputable senders). 

Mark Certificates, including VMCs, add another email trust signal by validating an organization’s right to use its logo for display in supported inboxes through BIMI. Used alongside enforced DMARC, they help recipients more easily recognize authenticated branded messages.

Verifying software with Code Signing

Attackers may attempt to insert malicious code into software or updates. For this reason, developers rely on code signing certificates to identify the software publisher and show whether the code has been altered since it was signed.

Code signing certificates attach digital signatures to software, allowing operating systems and users to verify the publisher and determine whether the code has changed since it was signed. These certificates therefore give users stronger information for evaluating the origin and integrity of software downloads and updates.
 

Maintaining trust through automated certificate lifecycle management

Every digital certificate (whether intended to protect browsing, email, or software) navigates a distinct lifecycle that includes several critical phases: discovery, issuance, renewal, and in some cases, revocation. All certificates must eventually expire or be renewed. Expiration limits how long a certificate remains valid, while revocation allows compromised or incorrectly issued certificates to be invalidated before their scheduled expiration. If these functions are manually managed, they become prone to misconfigurations or missed renewals, leaving websites, emails, and applications at risk.

Automated certificate lifecycle management addresses these challenges by limiting operational overhead: automated systems continuously discover certificates and add them to comprehensive inventories while also providing an expedited method to issue certificates and renew them before they expire. As these phases are automated, certificate management becomes more proactive and reliable, creating a stronger framework for managing certificates at scale.

This reliability is especially valuable as growing numbers of machine identities increase certificate volumes. Larger certificate inventories become increasingly difficult to manage manually, but automation allows organizations to manage digital trust at scale. 

The need for automation will continue to grow as the maximum validity for publicly trusted SSL/TLS certificates falls from 200 days today to 100 days in March 2027 and 47 days in March 2029.

Why digital trust matters more than ever

The demands of securing the World Wide Web shift alongside the introduction of innovative technologies. 

Cloud services, AI systems, connected devices, APIs, and machine identities are increasing the number of digital identities and certificates organizations must manage. Digital certificates are one important way organizations authenticate these identities and protect communications between them. However, the very process of issuing and renewing those certificates can also introduce risks. If certificate lifecycle tasks are delayed or mismanaged, missed renewals can cause downtime, while compromised or poorly controlled certificates can create additional security risks.

Trust is what ultimately allows for technological innovation at scale. With a backbone of trust (supported by data encryption and validation), platforms and applications can be introduced with confidence, even as certificate volumes increase and lifespans shrink. This is what makes the modern Web and its connected services resilient and scalable enough to support tomorrow's technological breakthroughs.

Technologies powering a safer World Wide Web

The secure Web depends on many technologies working together. SSL/TLS protects connections, PKI establishes trusted identities, S/MIME protects email, code signing verifies software publishers and integrity, and automated CLM keeps certificates visible and current at scale. World Wide Web Day offers a timely reminder that these largely unseen systems support the trusted digital experiences people use every day.

Sectigo provides digital certificates and Sectigo Certificate Manager, an automated CLM platform, to help organizations secure connections, authenticate identities, and manage digital trust at scale.

We have automation to thank for the tools and systems that make online activities feel effortless.  Even though it may seem like a newer concept, automation has supported web operations for decades. However, its role has recently become far more important as digital environments have grown larger and more complex. 

Automation capabilities now play a central role in shaping trust mechanisms and security strategies. Today, organizations may manage certificates across websites, applications, APIs, cloud platforms, devices, and other machine identities. Manual solutions were never truly sufficient, but at this point, they cannot reliably maintain the never-ending series of operational or security-focused tasks that help power the web.

Certificate lifecycle management (CLM) offers an example of how automation works behind the scenes to protect users and businesses alike. When CLM is automated, every digital certificate-related process becomes more efficient and less prone to error: certificates are continuously discovered while issuance is streamlined and renewals are completed on time.

This is especially critical given the current changes impacting certificate validity periods — they're shrinking rapidly. We've reached the first milestone established by the CA/Browser Forum: public SSL/TLS certificates now have a maximum validity of 200 days. Their lifespan will see another drop to 100 days in 2027, and, by 2029, they will span just 47 days.

How does digital certificate automation work behind the scenes?

Automation takes many forms, but digital certificate automation is fundamental to the modern web. This type coordinates how certificates are discovered, requested, issued, deployed, monitored, renewed, and revoked at scale. The exact processes vary by certificate type. For public SSL/TLS certificates, automation can integrate with domain control validation and issuance protocols. Other certificate types, including S/MIME and Code Signing certificates, follow their own validation and policy requirements.

CLM platforms orchestrate these processes across certificate authorities (CAs), infrastructure, applications, and security tools, reducing the manual work required throughout the certificate lifecycle.

At this point, CLM automation is indispensable. It's what allows businesses to keep up as certificate inventories continue to expand and especially as validity periods shrink. Users who never actually observe CLM processes still benefit from these solutions as they browse securely, explore cloud applications, or complete transactions online without worrying about their personal data.

PKI is the foundation of certificate automation

Certificate automation operates within public key infrastructure (PKI), the framework of technologies, policies, processes, and trusted entities used to issue, manage, validate, and revoke digital certificates. While certificates provide credentials for websites, applications, devices, and other digital identities, PKI establishes the trust framework that allows systems to verify those credentials.

Trusted certificate authorities support PKI by performing validation checks and issuing certificates. They also provide revocation information that allows systems to identify certificates that should no longer be trusted before their scheduled expiration, such as after a private key compromise. 

Root and intermediate certificates create chains of trust that allow browsers, applications, APIs, and other systems to verify certificates and establish trusted connections. Although these PKI processes can be performed manually, automation is increasingly necessary to enforce policies consistently and manage certificates at enterprise scale. 

Without sufficient automation, large PKI environments are more likely to develop visibility gaps, inconsistent processes, missed renewals, and fragmented certificate management.

Why do certificate outages happen?

Certificate expiration is built into the trust model that supports the modern web. Without expiration, compromised certificates could appear valid indefinitely. Renewal allows organizations to replace certificates before they expire, maintaining trusted connections without disrupting service.

When digital certificates are allowed to expire without being renewed, outages can follow. Without valid certificates, systems can no longer authenticate identities and establish secure connections. As a result, browsers may display security warnings or block website access, while applications and APIs may reject connections or fail to exchange data. These certificate-related outages tend to happen more often when manual strategies are in place, such as tracking renewals in spreadsheets where expiration dates can be missed.

These issues are becoming more common as certificates are issued at scale and as validity periods shrink, prompting quarterly (and eventually, near-monthly) renewals. Under these new realities, proactive solutions become a matter of necessity. Depending on the organization, industry, and duration of the disruption, a certificate-related outage can result in significant revenue loss, recovery costs, operational disruption, and reputational damage.

How automation keeps the modern web running

A reliable World Wide Web becomes possible through automated solutions safeguarding connections and increasing confidence in every digital interaction. Automated certificate lifecycle management helps organizations manage certificates consistently across websites, applications, APIs, and other digital systems. It reduces manual work, improves visibility, and helps teams address certificate risks before they disrupt services.

An effective certificate management system builds automation into all lifecycle tasks and processes:

Automated discovery eliminates blind spots

Certificates are best managed when they're known: when organizations can easily discern where these certificates exist and what they secure. These days, it's difficult to maintain full inventories due to the sheer volume of certificates and the many systems and environments they support.

Automated discovery closes gaps in visibility through continuous scanning and cataloging. Discovered certificates are built into centralized inventories that provide instant access to certificate details, including ownership, location, and expiration dates.

Automated renewal prevents outages

Certificate expirations and renewals can seem inconvenient, but they're an important part of a well-rounded security ecosystem. Shorter validity periods limit how long a certificate remains trusted and reduce the potential exposure window if its private key is compromised.

Through protocols such as ACME (Automated Certificate Management Environment), organizations can automate domain control validation and certificate issuance. When properly integrated with the target infrastructure, ACME clients can also support automated deployment and renewal with minimal manual intervention, helping maximize uptime.

Centralized management improves visibility

Certificate management ties together the many elements of the certificate lifecycle. Inventories built through discovery provide valuable insight into certificate status, consolidated into a single view through centralized dashboards.

This unified approach supports consistent policy enforcement by showing when certificates are compliant and when they pose risks. Centralized systems also support machine identity management by applying consistent certificate, encryption, and authentication policies across devices, applications, and APIs. Solutions such as Sectigo Certificate Manager (SCM) bring these capabilities together to simplify oversight and reduce certificate-related risk.

Building a resilient certificate lifecycle management strategy

Automation is vital to today’s World Wide Web, and already, it's built into many of the processes that keep digital infrastructure working reliably. The role of automation will continue to expand as digital services, certificate inventories, and machine identities expand.

Organizations keep up by making automated certificate lifecycle management part of their core technology and security infrastructure. Integrating it into processes such as DevOps pipelines helps make certificate management an ongoing security practice rather than a separate renewal task. 

This visibility and control also support crypto agility, helping organizations identify and update certificates, keys, and algorithms as requirements change. That capability will become increasingly important as organizations assess post-quantum cryptography and prepare affected systems for future transitions.

By embedding automation into their infrastructure, organizations can reduce outages, apply policies more consistently, and maintain digital trust as technology and cryptographic requirements evolve.

Automation is the backbone of a trusted web

Automation has become a core part of maintaining trust, availability, and business continuity across the modern web. PKI provides the trust framework, while automated CLM helps organizations discover certificates, enforce policies, complete renewals, and respond to risks before they disrupt digital services.

World Wide Web Day is an opportunity to recognize not only what the web makes possible, but also the infrastructure that keeps it functioning securely. Every time someone browses a website, accesses a cloud application, or completes an online transaction, digital certificates help authenticate services and protect communications. Automated CLM helps organizations maintain that trust at scale as certificate inventories grow and validity periods continue to shrink.

Explore Sectigo’s digital certificates and Sectigo Certificate Manager to help protect communications, automate certificate management, and maintain trust across the modern web.

Public key infrastructure (PKI) is used to manage identity and security in internet communications and computer networking. The core technology behind PKI is public key cryptography, an encryption method that relies on the use of two related keys, a public key, and a private key, to protect data and verify identity.

This public and private key pair works together to encrypt and decrypt messages. Pairing two cryptographic keys in this manner is also known as asymmetric encryption, which is different from symmetric encryption, in which a single key is used for both encryption and decryption.

Advantages of asymmetric encryption include:

• The public key can be safely shared for key exchange and data encryption.
• The private key remains protected on the user’s device for secure key operations.
• It offers stronger protection against attacks than symmetric encryption.

This system supports SSL certificates, digital signatures, and other encryption protocols that keep sensitive data safe. The separation of public and private keys makes RSA encryption a foundation of trust in modern secure communications.

How public key cryptography relies on encryption

Public key cryptography relies on mathematical algorithms to generate key pairs. The public key consists of a string of random numbers used to encrypt data, while the private key is used to decrypt it. Only the intended recipient, who possesses the private key, can read the encrypted data.

Public keys are created using a complex cryptographic algorithm that mathematically binds them to their private keys, making them highly resistant to brute force attacks or guessing.

The key size or bit length of public keys determines the strength of protection. For example, 2048-bit RSA keys are often employed in SSL certificates, digital signatures, and other digital certificates. This key length offers sufficient cryptographic security to keep hackers from cracking the algorithm. Standards organizations like the CA/Browser Forum define baseline requirements for supported key sizes and algorithms to maintain trust and interoperability across systems.

PKI enables the digital certificates that we encounter daily, unobtrusively and ubiquitously, when using websites, mobile apps, online documents, and connected devices. One of the most common use cases of PKI is X.509-based Transport Layer Security (TLS)/Secure Socket Layer (SSL). This is the basis of the HTTPS protocol, which enables secure web browsing. But digital certificates are also applied to a wide range of use cases including application code signing, digital signatures, and other aspects of digital identity and security.

RSA vs DSA vs and ECC algorithms

There are three primary algorithms used for PKI key generation, each based on a different mathematical problem that defines its strength and efficiency:

• Rivest–Shamir–Adleman (RSA): Based on the difficulty of factoring large prime numbers, RSA encryption is the most established and widely used algorithm for SSL certificates and digital signatures.
• Digital signature algorithm (DSA): Relies on the discrete logarithm problem to generate digital signatures and verify authenticity. DSA is endorsed by the U.S. Federal Government and used for secure document validation.
• Elliptic curve cryptography (ECC): Uses the algebraic structure of elliptic curves to provide security with much shorter key lengths, improving performance and reducing memory usage and bandwidth requirements.

What is RSA?

The RSA algorithm was developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman. It relies on the fact that factorization of large prime numbers requires significant computing power., It was the first algorithm to use the public key/private key model and remains widely trusted today. There are varying key lengths associated with RSA, with 2048-bit RSA key lengths being the standard for most websites today.

What is ECC?

ECC encryption, or Elliptic Curve Cryptography, is based on mathematical algorithms governing the algebraic structure of elliptic curves over finite fields. It provides equivalent levels of cryptographic strength as RSA and DSA, with much shorter key lengths, reducing memory usage and bandwidth demands. Because of this, ECC vs RSA is a common comparison. ECC offers faster performance, especially on mobile and IoT devices. ECC became standardized after the Elliptic Curve Digital Signature Algorithm (ECDSA) was accredited in 1999 and is also endorsed by the NSA.

What is DSA?

DSA encryption (Digital Signature Algorithm) uses a different algorithm than RSA to create public key/private keys, based on modular exponentiation and the discrete logarithm mathematical problem. It provides the same levels of security as RSA for equivalent-sized keys. DSA vs RSA often comes down to signing speed and verification efficiency. DSA was proposed by the National Institute of Standards and Technology (NIST) in 1991 and was adopted by the Federal Information Processing Standard (FIPS) in 1993.
Note that it's possible to support multiple encryption algorithms at the same time. For example, Apache servers can support both RSA- and DSA-generated keys on the same server, offering flexibility and stronger enterprise security.

How do RSA and DSA compare?

While RSA and DSA use different types of mathematical algorithms to generate their key pairs. The key difference between RSA vs DSA keys lies in performance and speed, not cryptographic strength.

Performance and speed

RSA encryption is faster than DSA when it comes to encrypting and signing, but is slower than DSA for decrypting and verifying. However, since authentication requires both key operations, the real-world performance difference is minimal for most applications.

RSA is also slower than DSA when it comes to key generation, but since keys are generated once and used for months or years, this is often not an important consideration.

SSH protocol support

Another difference appears in Secure Shell (SSH) protocol support. RSA is compatible with both the original SSH, as well as the newer, second edition SSH2, while DSA only supports SSH2. Because SSH2 is more secure, this distinction can influence validation choices between DSA vs RSA in certain environments.

Federal endorsement

Another difference between DSA and RSA is that DSA is endorsed by the U.S. Federal Government. For businesses providing services to federal agencies, maintaining alignment with government standards may be a reason to select DSA.

The bottom line is: for most use cases, industries, and regulatory environments, RSA and DSA are very similar, offering equivalent cryptographic strength, and there is relatively little difference between the two. The two algorithms are also equally compatible with leading internet protocols including Nettle, OpenSSL, wolfCrypt, Crypto++, and cryptlib.

How does ECC compare to RSA and DSA?

The biggest difference between ECC vs RSA and DSA is the greater cryptographic strength that ECC offers for equivalent key size. An ECC key is more secure than an RSA or DSA key of the same size, offering equivalent security with far less computational demand.

Key size comparison:

Recommended Key Sizes According to NIST

ECC is more efficient

As the figure shows, with ECC you achieve equivalent cryptographic strength as RSA or DSA with significantly smaller key sizes - about an order of magnitude smaller. For example, to achieve the equivalent cryptographic strength of encrypting using a 112 bit symmetric key would require an RSA 2048 bit key, but only an ECC 224 bit key. The reduced size leads to faster key operations, lower memory usage, and improved performance for SSL certificates and secure key exchange processes.

The shorter key lengths mean devices require less processing power to encrypt and decrypt data, making ECC a good fit for mobile devices, Internet of Things, and other use cases with more limited computing power.

Security and speed

There are also some advantages to ECC compared to RSA or DSA in more traditional use cases like web servers, as smaller key sizes enable stronger security with faster SSL handshakes, which translates to faster web page load times. Smaller ECC keys enable stronger protection while maintaining efficiency, which is a major benefit in large-scale deployments.

It’s worth noting that ECDSA, the original version of ECC, is a variant of DSA. ECDSA offers equivalent levels of cryptographic strength per number of bits as ECC.

Why is elliptic curve cryptography not widely used?

While RSA is the most widely used algorithm, ECC has been gaining popularity over the years. One of the simpler reasons for RSA’s dominance is that it has been around longer. That being said, there are some cons to ECC that could further explain why people avoid it:

• Complexity: Learning and adopting ECC takes more time and is a more complex process than RSA. This can increase the risk of errors, which will have a negative impact on cybersecurity.
• Vulnerabilities: ECC can be vulnerable to side-channel attacks (SCA), which can lead to brute force attacks. They can also be vulnerable to twist security attacks, though there are countermeasures to help prevent these attacks.
• Compatibility: Older infrastructure and legacy software were built primarily around RSA and DSA, limiting ECC support in some environments. However, as standards evolve and ECC implementations mature, more organizations are moving toward ECC for its efficiency and long-term strength.

What does quantum computing mean for the future of encryption algorithms?

Quantum computing poses a serious threat to traditional cryptography methods like RSA, DSA, and ECC. These algorithms rely on mathematical problems, such as large prime factorization and discrete logarithms, that would become solvable almost instantly with a quantum computer. Once that happens, the encryption used in most SSL certificates, digital signatures, and secure communications could be broken in seconds.

Real-World impact when quantum computers arrive

Real-World impact when quantum computers arrive
If organizations fail to adopt quantum-safe cryptography before large-scale quantum computers become available, the following scenarios become highly probable:

• “Harvest now, decrypt later” attacks: Adversaries harvest encrypted communications today that rely on systems using RSA, ECC or DSA keys, store them, then decrypt them once quantum resources become available.
• Compromised confidentiality: Websites, email systems, virtual private networks and other secure channels secured with classical public-key cryptography could be broken in minutes rather than years.
• Undermined authentication and digital signatures: Trust frameworks reliant on digital signature algorithms (e.g., DSA and ECC versions) can be forged or invalidated, putting software distribution, financial transactions, identity verification and e-documents at risk.
• Critical infrastructure risk: Systems in finance, healthcare, energy, transportation, and government that depend on public-key cryptography may face operational disruption, data exposure, or false data injection if encryption is broken.
• Regulatory and compliance exposure: Organizations may find they are non-compliant with emerging mandates requiring migration to quantum-safe cryptographic standards, exposing them to legal, reputational or financial penalties.

What are NIST’s new post-quantum encryption standards?

To prepare for this shift, the National Institute of Standards and Technology (NIST) evaluated current post-quantum cryptography (PQC) and has introduced new post-quantum encryption standards under the Federal Information Processing Standards (FIPS) framework. These new algorithms are designed to resist attacks from both classical and quantum computers.

• FIPS 203 – ML-KEM (CRYSTALS-Kyber): The primary standard for encryption, using lattice-based math for small, fast keys and low memory usage.
• FIPS 204 – ML-DSA (CRYSTALS-Dilithium): The main standard for digital signatures, balancing high speed with strong cryptographic protection.
• FIPS 205 – SLH-DSA (SPHINCS+): A stateless hash-based backup for FIPS 204, it’s slower and larger but uses a different mathematical structure for added resilience.
• FIPS 206 – FN-DSA (FALCON): A new standard, not finalized yet, will be called FN-DSA, short for FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm.

Next steps: Building a quantum-resilient security strategy

Preparing for the quantum era begins with awareness and proactive planning. Organizations should start by identifying where RSA, DSA, and ECC algorithms are currently used, including in SSL certificates, VPNs, internal authentication systems, and application code signing. From there, security teams can prioritize migration to quantum-safe algorithms.

Sectigo’s Q.U.A.N.T. strategy provides a clear framework to guide this process, helping businesses quantify their cryptographic footprint, uncover risks, and assess and strategize for a secure transition. Through this approach, teams can navigate implementation with automated, quantum-safe solutions and track ongoing progress to maintain crypto agility as standards evolve.

Organizations can stay ahead by partnering with a trusted certificate authority like Sectigo, a leader at the forefront of post-quantum cryptography development. 

Protect your future with Sectigo’s PQC-ready security solutions

Now that you understand how RSA, DSA, and ECC encryption algorithms compare, and how quantum computing will soon reshape encryption standards, it’s time to prepare your organization for what’s next. Sectigo offers trusted digital certificates and advanced post-quantum cryptography solutions designed to help businesses transition smoothly to next-generation encryption.

Contact us today to learn more about how our products can protect your website from security threats. We also recommend exploring Sectigo’s PQC solutions.

While quantum-resistant algorithms solve the cryptographic problem, they introduce a practical one: much larger keys and signatures. If deployed through today's public key infrastructure (PKI), they would inflate every secure connection, driving up bandwidth, processing, and storage costs across the internet. Mobile users and high-latency networks would feel it most, but some systems like legacy web servers and load balancers might break completely.

Recognizing these limits, cryptographers from across the industry, including teams at Google, Cloudflare, with contributions from Sectigo, have been developing a new approach. Merkle Tree Certificates (MTCs) do not force large post-quantum signatures into an infrastructure that wasn't designed for them, they instead rethink how certificates are built and delivered for the post-quantum era. 

What is a Merkle Tree Certificate?

An MTC is a new approach to digital certificates that dramatically reduces the amount of data exchanged during a secure connection. Instead of signing every certificate individually and sending a full chain with every handshake, a certificate authority batches the certificates it issues into a single structure called a Merkle tree. The authority signs the tree rather than each certificate, and browsers receive the trusted tree heads ahead of time through transparency infrastructure. The elements of the tree that are signed are hash summaries, which in themselves are quantum-resistant.

When a browser connects to a website, the site presents a short proof, just a handful of hashes, showing that its certificate belongs to a tree the browser already trusts. The heavy chain of signatures never crosses the wire. That difference matters at post-quantum scale. A single ML-DSA signature weighs roughly 2.4 kilobytes, and a conventional chain would carry several of them plus transparency artifacts. The Merkle proof that replaces them typically comes in under a kilobyte.

MTCs will likely coexist with the certificates we use today.  Anticipate a future where quantum-resistant methods stay efficient, transparent, and compatible with the web as it exists right now. 

Why do Merkle Tree Certificates matter for the internet?

PKI is ubiquitous in all of our technology stacks. Cloud applications, AI-driven workloads, and billions of connected devices all depend on fast, constant TLS handshakes. If post-quantum authentication slows those handshakes down, everyone feels it. MTCs matter because they remove that tradeoff in two important ways.

1. Merkle Tree Certificates help keep the internet fast

Forcing traditional post-quantum signatures onto public websites would balloon handshake sizes and degrade the user experience, especially on mobile and high-latency connections. MTCs sidestep the problem by replacing multiple large signatures with one compact inclusion proof, holding overhead close to what users experience today. We get to keep using the internet exactly the way we do now, fast and uninterrupted, with quantum resistance underneath.

2. Merkle Tree Certificates make transparency part of the design

In today's PKI, Certificate Transparency (CT) logging is bolted onto the side of issuance as a separate step. When logging fails, a certificate can sit out in the wild unnoticed, creating a security blind spot.

MTCs invert that relationship. The act of creating a certificate is the act of logging it. If a certificate is not in the tree, it simply does not exist. That matters because authentication in a post-quantum world cannot be truly secure without total visibility, and MTCs make the two inseparable. 

Our vision: Sectigo and Merkle Tree Certificates

The momentum behind this shift is real and measurable. Browsers have signaled that MTCs are their preferred path for bringing post-quantum certificates to the public web, and feasibility experiments are already running against live internet traffic. Sectigo believes MTCs represent the most promising route to post-quantum authentication that preserves the performance and scalability organizations depend on today.

At the same time, we continue to track the broader post-quantum ecosystem, from NIST-standardized algorithms such as ML-DSA to evolving IETF specifications, browser roadmap decisions, and enterprise adoption requirements. The full scope of what MTCs can do is still coming into focus. What is already clear is that organizations need visibility, automation, and crypto agility to adapt as standards mature. Sectigo remains committed to helping customers prepare for that future, whatever shape the underlying certificate architecture takes. 

These certificates link a public key to a verified identity, enabling systems to confirm a digital entity’s legitimacy. They form the foundation of online security, protecting communications across websites, applications, documents, and devices.

Each X.509 certificate includes a public key, identifying details, and a digital signature from a trusted Certificate Authority (CA). The digital signature confirms the certificate’s integrity and origin, forming part of a certificate chain that leads back to a trusted root CA. This structure supports trust and helps prevent impersonation.

A core strength of an X.509 certificate is that it uses a key pair consisting of a related public key and a private key. In cryptography, the public and private key pair is used to establish secure session keys, verify identities, and enable encrypted communication.

The most common application of X.509-based PKI is Secure Sockets Layer (SSL) / Transport Layer Security (TLS), the foundation of the HTTPS protocol that enables secure web browsing. Beyond HTTPS, the X.509 standard is also used for code signing for application security, digital signatures, and other critical internet protocols.

X.509 version history

The first version of the X.509 standard was published in 1988. To formalize the rules for certificate issuance, the Telecommunication Standardization Sector of the ITU (ITU-T) developed a hierarchical system for distinguished names that followed the electronic directory service rules for X.500 and was inspired by the systems used to assign telephone numbers globally but applied to the more flexible organizational requirements of the Internet.

Version 3 introduced a major update with support for multiple extensions. Subsequent revisions have refined the v3 standard to support modern internet use cases and evolving security needs.

Additionally, the Internet Engineering Task Force (IETF), through its public-key infrastructure working group known as PKIX, adapted the X.509 v3 certificate standard to create the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL), known as RFC 5280. This profile is now widely used to define how certificates and revocation lists are handled across internet systems.

The benefits of X.509 certificates

As X.509 certificates facilitate secure messaging and web browsing, there are significant benefits for organizations to use them. They are used to authenticate websites, encrypt data in transit, and validate users and devices in both public and private networks. Their structure, which includes a trusted digital signature from a Certificate Authority (CA), makes them integral to the functionality of secure communication protocols like SSL/TLS, and S/MIME.

By binding a verified identity to a public key, X.509 certificates establish digital trust that supports security and data privacy in every interaction. These benefits extend across web traffic, internal systems, APIs, email communications, and beyond.

Establish trust

Digital certificates, also known as public key certificates, allow individuals, organizations, and even devices to prove their identity in a digital context. As the foundation for all digital identities, X.509 certificates are everywhere and are essential to every connected process from websites to applications to endpoint devices and online documents. For example, without these, we wouldn't be able to trust that www.amazon.com is actually Amazon's website.

This level of trust  is built not only through cryptographic architecture, but also through the certificate issuance process. The X.509 format supports identity validation by confirming that:

1. The public key belongs to the domain, organization, or individual contained within the certificate
2. The certificate has been signed by a trusted Certificate Authority (CA), such as Sectigo, or self-signed
3. The certificate follows defined certificate policies and has not been revoked or altered

When a certificate is signed by a trusted CA, the certificate user can be confident that the certificate owner or hostname/domain has been validated, while self-signed certificates can be trusted to a lesser extent as the owner doesn't go through any additional validation before issuance.

Enable scalability

The public key infrastructure (PKI) architecture behind X.509 certificates supports massive scalability. Organizations can protect billions of daily data exchanges using certificates that require no manual intervention to verify or decrypt. This is possible because public keys can be distributed openly, without revealing the private key needed to unlock the encrypted data.

This makes X.509 certificates uniquely effective at scaling secure identity and encryption across cloud services, enterprise networks, connected devices, and cross-border systems.

Help achieve crypto agility

The X.509 standard supports multiple cryptographic algorithms, including RSA, ECC, and DSA, and is being extended to support emerging post-quantum algorithms. This flexibility allows organizations to adopt stronger cryptography over time without rebuilding their entire PKI infrastructure. As algorithms evolve and threats increase, this crypto agility ensures that systems remain protected with up-to-date, standards-based encryption.

Promote interoperability

The X.509 standard is universally supported across browsers, operating systems, mobile platforms, network devices, and cloud providers. This broad compatibility allows certificates to function consistently across different environments and vendors. 

Support automation and lifecycle management

Digital certificate lifecycles can be managed automatically using protocols like ACME, EST, and SCEP. Organizations can issue, renew, and revoke X.509 certificates at scale without manual involvement. This automation reduces the risk of expired certificates, outages, or human error, and helps maintain uptime across critical systems.

How do X.509 certificates work?

X.509 certificates operate by binding a public key to a verified identity using a digital signature from a trusted Certificate Authority (CA). The certificate follows a defined structure that enables secure data encryption, authentication, and trust validation across systems.

The X.509 standard is based on an interface description language known as Abstract Syntax Notation One (ASN.1), which defines data structures that can be serialized and deserialized in a cross-platform way. Using the key pair associated with the certificate, systems can establish secure sessions, verify digital signatures, and protect communications.

The basis of public key infrastructure

The public key consists of a string of random numbers and can be used to encrypt a message. Only the intended recipient can decipher and read this encrypted message and it can only be deciphered and read by using the associated private key, which is also made of a long string of random numbers. The private key remains secret and is never shared.

As the public key is published for all the world to see, public keys are created using a complex cryptographic algorithm to pair them with an associated private key by generating random numeric combinations of varying lengths so that they cannot be exploited through a brute force attack.

The most common algorithms used to generate public keys are:

• Rivest–Shamir–Adleman (RSA): A widely used algorithm that relies on the difficulty of factoring large prime numbers.
• Elliptic curve cryptography (ECC): Uses elliptic curves over finite fields to provide strong security with shorter key lengths.
• Digital signature algorithm (DSA): Based on modular exponentiation and the discrete logarithm problem.

The key size or bit length of public keys determines the strength of protection. For example, 2048-bit RSA keys are  widely used in SSL certificates, digital signatures, and other digital certificates. This key length offers sufficient cryptographic security to keep hackers from cracking the algorithm. Standards groups like the CA/Browser Forum define minimum key sizes and cryptographic requirements to maintain trust and compatibility across browsers and systems.

Figure: X.509 certificates use a related public and private key pair for identity authentication and security for internet communications and computer networking

Issuance fields

X.509 certificate fields contain information about the identity that the certificate is issued to as well as the identity of the issuer CA. The standard fields include:

• Version: The X.509 version used, which determines the structure and available extensions.
• Serial number: The unique serial number identifier provided by the CA that distinguishes the certificate from others.
• Signature algorithm: The specific hashing and encryption method used to generate the digital signature.
• Signature value: The digital signature itself, created by the CA’s private key to authenticate the certificate contents.
• Issuer distinguished name: The name of the CA issuing the certificate
• Validity period of the certificate: The start/end date and time it's valid and can be trusted
• Subject distinguished name: The name of the identity the certificate is issued to
• Subject public key information: – the public key associated with the identity

Figure: X.509 certificates use a related public and private key pair for identity authentication and security for internet communications and computer networking

 Common digital certificate extensions

In addition to its standard information fields, X.509 version 3 introduced extensions that expand certificate functionality for modern internet use. Two common X.509 certificate extensions in use today include:

• Subject Alternative Name extension (SAN): Allows a certificate to bind multiple identities to the same public key. This can include additional domains, DNS names, IP addresses, or email addresses. Because of this extension, a single certificate can cover multiple endpoints, reducing complexity and cost. SAN-enabled certificates are often referred to as multi-domain certificates.
• Key Usage: Defines how the public key may be used, such as for digital signatures, key encipherment, or certificate signing. For example, a certificate with “signing-only” usage cannot be used for encryption. This prevents misuse and ensures that certificates are applied as intended.

Other commonly used extensions include Extended Key Usage, Basic Constraints, and CRL Distribution Points, depending on the certificate’s role and environment.

Digital certificates apply hierarchical trust chains

To further establish the trust of an identity, multiple digital certificates are often combined to build a hierarchical chain of trust that provides a series of verification layers. Each must be signed by an issuer CA as part of the X.509 verification process. The CA is named and stored in the root of the certificate. Additional intermediate certificates can be included in the trust chain and must be validated.

The full certificate chain typically includes:
Root certificate
Intermediate certificate
Leaf certificate

For example, when a web browser client reads the certificate, it must be able to follow the hierarchical path of certification including any intermediates required for validation that are recursively linked back to the root CA listed in the client's trust store, resulting in a complete chain of trust.

Figure: SSL/TLS certificates often combine intermediate CA certificates to create a hierarchical trust chain

Certificate Revocation Lists (CRLs)

The X.509 standard also defines the use of a certificate revocation list, which identifies all of the digital certificates that have been revoked by the issuing CA prior to the scheduled expiration date. Revocation typically occurs when a private key is compromised, the certificate was issued improperly, or the certificate holder's status changes.

These revoked certificates should no longer be trusted.

CRLs offer a simple way to distribute information about these invalid certificates. However, CRLs are increasingly deprecated by modern web browsers and applications in favor of more efficient methods like the Online Certificate Status Protocol (OCSP) and OCSP stapling, which offer complete revocation features.

PKI certificate encoding

One notable element not defined in the X.509 standard is how the certificate contents should be encoded to be stored in files.

There are two encoding schemas commonly used to store digital certificates in files:

• Distinguished Encoding Rules (DER) is most common, as the schema addresses most data objects. Certificates encoded by DER are binary files and cannot be read by text editors but can be processed by web browsers and many client applications.
• Privacy Enhanced Mail (PEM) is an encrypted email encoding schema that can be used to convert DER-encoded certificates into text files.

Common applications of X.509 public key infrastructure

Many internet protocols rely on X.509, and there are many applications of the PKI technology that are used every day, including web server security, digital signatures and document signing, and digital identities.

Web server security with SSL/TLS certificates

PKI is the basis for the SSL/TLS protocols that support HTTPS connections in modern web browsers. Without SSL certificates or TLS to establish secure connections, cybercriminals could exploit the Internet or other IP networks using a variety of attack vectors, such as man-in-the-middle attacks, to intercept messages and access their contents.

Digital signatures and document signing

In addition to being used to secure messages, PKI-based certificates enable tamper-proof digital signatures and verified document signing.

Digital signatures are a specific type of electronic signature that leverages PKI to authenticate the identity of the signer and the integrity of the signature and the document. Digital signatures cannot be altered or duplicated in any way, as the signature is created by generating a hash, which is encrypted using a sender's private key. This cryptographic verification mathematically binds the signature to the original message to ensure that the sender is authenticated and the message itself has not been altered.

Code signing

Code Signing enables developers to add a layer of assurance by digitally signing applications, drivers, and software programs so that end users can verify that a third party has not altered or compromised the code they receive. To verify the code is safe and trusted, these digital certificates include the software developer's signature, the company name, and timestamping.

Email certificates

S/MIME certificates are used to validate email senders and encrypt the content of messages and attachments. This prevents attackers from spoofing identities or reading messages in transit.

S/MIME leverages X.509 certificates to secure both personal and organizational email communications, protecting against spear phishing, data loss, and sophisticated social engineering attacks.

Many industries rely on S/MIME to meet regulatory or compliance requirements.

Digital identities

X.509 certificates also provide effective digital identity authentication. As data and applications expand beyond traditional networks to mobile devices, public clouds, private clouds, and Internet of Things devices, securing identities becomes more important than ever. And digital identities don't have to be restricted to devices; they can also be used to authenticate people, data, or applications. Digital identity certificates based on this standard enable organizations to improve security by replacing passwords, which attackers have become increasingly adept at stealing.

How do I get an X.509 certificate?

A critical component of deploying X.509 certificates is a trusted certificate authority or agent to issue certificates and publish the public keys associated with individuals' private keys. Without this trusted CA, it would be impossible for senders to know they are in fact using the correct public key associated with the recipient's private key and not the key associated with a malicious actor intending to intercept sensitive information and use it for nefarious purposes.

You have a few options when obtaining X.509 certificates:

• Use a trusted third-party Certificate Authority (CA): Providers like Sectigo validate the identity of the requester and issue certificates backed by a public trust hierarchy.
• Run your own internal CA: Many enterprises and tech providers choose to operate their own CA to issue certificates for internal systems, devices, or users.
• Use self-signed certificates: These are created and signed by the organization itself. While easy to generate, they are not publicly trusted and require manual trust configuration.

Regardless of which method you choose, the Certificate Authority must:

• Validate the identity of the requester before issuing the certificate.
• Confirm that the published public key is correctly associated with the requester’s private key.
• Maintain strong internal security practices to protect against compromise or abuse.

Manage X.509 certificates with Sectigo

One of the most critical aspects of X.509 certificates is effectively managing them at scale using automation. Without great people, processes, and technology in place, companies are leaving themselves open to cybersecurity breaches, outages, damage to their brand, and critical infrastructure failures.

Sectigo Certificate Manager (SCM) Pro provides centralized control over the full lifecycle of public and private certificates. From issuance to renewal and revocation, SCM Pro supports automation, policy enforcement, and seamless integration into your existing tech stack.

SCM Enterprise extends this capability to every human and machine identity across your organization, delivering complete certificate lifecycle management from a single platform.

An SSL certificate is a type of digital certificate that authenticates the identity of a website and establishes encrypted communications between two endpoints. This small data file leverage the TLS (Transport Layer Security) protocol, which is the successor to the SSL (Secure Sockets Layer) protocol. Commonly referred to as SSL/TLS certificates, they serve two functions:

1. Authentication: SSL certificates serve as credentials to authenticate the identity of a website. They are issued to a specific domain name and web server after a Certificate Authority, also known as a Certification Authority (CA), performs a vetting process on the organization requesting the certificate. Depending on the certificate type, it may include verified information about the business or organization behind the website.
2. Secure data communication: When an SSL certificate is installed on a web server, it enables a padlock or tune icon to appear in the web browser(depending on the browser). It activates the HTTPS protocol and creates a secure connection between the server and a browser. It enables use of encryption algorithms to scramble the data in transit into an indecipherable format that can only be read with the proper decryption key. This means sensitive data, like financial information, can be transmitted in a secure manner.

Web browsers show secure indicators when a site presents a certificate issued by a trusted Certificate Authority, like Sectigo. To become a trusted CA, a company must comply with and perform regular audits for the security and authentication process standards established by the leading browsers and the industry standards body called the CA/Browser Forum.

When a trusted CA issues a certificate to an organization, the browser will recognize the certificate as legitimate. The browser lets the user know that the web address is secure, and the user can safely browse the site and enter personal information.

How do SSL certificates work?

When a person visits a site with an SSL/TLS certificate, a "handshake" occurs to create a secure channel between the user and the organization and protect any data submitted on the website from being compromised. Here's how the handshake process works in real-time:

1. A client system such as a popular web browser connects to a server secured with an SSL/TLS certificate.
2. The browser initiates a TLS handshake with the server.
3. The server sends back a copy of its SSL certificate, including type, validity period, and organizational details.
4. The browser checks whether the certificate is valid. If the certificate is not installed, not up-to-date with the proper security protocols (has been allowed to expire), or not issued by a CA trusted by the browser, the user will see a warning message.
5. The server and browser complete key exchange and handshake messages, then begin a TLS encrypted session.
6. Any data shared between the browser and the server is now secure. If a hacker intercepts the communication, it will remain encrypted and unreadable.

Digital certificates are components of Public Key Infrastructure (PKI), which uses public key cryptography to establish trust. This process uses public and private keys to help establish encryption keys that protect data in transit.

What is the difference between SSL vs TLS?

TLS is an updated version of SSL that provides advanced encryption options, however the two acronyms are often referred to as having the same meaning.

Secure Sockets Layer, or SSL, was the name of the first cryptographic protocol established to ensure the identity of a server connected across the open internet. This protocol was created in 1995 to enable e-commerce on the web. SSL 2.0 was the first version of the protocol to be used in production systems, and it was soon superseded by SSL 3.0. After version 3.0, standards bodies superseded SSL with a more advanced protocol called Transport Layer Security, or TLS. However, by that point the term SSL was so common that it continues to persist as the de facto name for TLS.

Although certificates do not themselves perform encryption, standards-based client and server software require the presence of one for encryption to take place. This requirement is in recognition of the fact that without a reliable identity for the party on the other side of a connection, encryption itself offers no protection.

Common public key algorithms used in TLS today include RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). However, as quantum computing advances, these algorithms are expected to become vulnerable, making a transition to post-quantum cryptography (PQC) necessary to maintain long-term security.

What are the different types of SSL certificates?

There are three different types of SSL/TLS certificates categorized by validation level, including:

• Domain Validation (DV): easiest and most cost-effective way to receive industry-standard encryption
• Organization Validation (OV): a step up from DV where an organization must be a legally registered business and prove they own the domain
• Extended Validation (EV): provide the highest level of trust and is the industry standard for e-commerce websites 

Other variations of certificates are categorized by the number of domains they cover:

• Wildcard SSL certificates: for a main domain and its subdomains
• Single Domain: for a main domain and a single subdomain
• Multi-Domain: used to secure multiple domains
   

Common uses

SSL certificates are an essential part of any website’s cybersecurity measures. Millions of websites use them to secure browsing on their websites. Enabling HTTPS helps signal that a site is protected for browsing and data entry, and leading browsers actively warn users when a site is not secure. Sites without a certificate may display a “Not Secure” warning.

The growth of global websites, mobile, and internet-connected devices has also expanded the use well beyond just e-commerce. Anyone who needs to share data between devices over the internet securely can benefit from SSL certificates. They are most commonly used to secure:

• Online credit card transactions
• Web forms and customer logins
• Email and webmail applications
• Corporate communications through intranets, file sharing, extranets, and internal servers
• Cloud-based platforms and virtualized applications
• File transfers over FTPS
• Data transfer to and from mobile devices

If a website URL starts with HTTPS:// and there is a padlock icon in the address bar, then the website is using a secure SSL/TLS connection.

What are the benefits of SSL certificates?

The primary importance of installing an SSL certificate is to initiate a secure session between a web server and a browser. Once a secure connection is established, all information passed between the web server and the visitor will be kept private and encrypted

Other advantages include:

• Increases customer trust: The padlock or tune icon assures customers that their information will not be compromised. The data will be sent to the intended target servers, and it will not be redirected to unauthorized third parties.
• Protects sensitive information against phishing attacks: Phishing sites are fraudulent copies of famous websites whose purpose is to trick you into submitting valuable information like your credit card or social security numbers. Extended validation certificates provide the highest level of identity validation, which can help users and organizations distinguish legitimate sites from impersonators.
• Better search engine rankings: SSL/TLS certificates can support SEO and a website’s online presence.  Google has confirmed HTTPS as a ranking signal, adding to its importance.

How to install an SSL certificate

There are 3 simple steps for installing an SSL certificate on a website:

1. Purchase a certificate issued by a trusted CA - Trusted certificates can be bought from your web-host or direct from a trusted CA, like Sectigo. SSL certificates from a trusted CA will be recognized by all popular internet browsers used by your visitors (Chrome, Firefox, Internet Explorer, Safari, etc).
2. Activate and install the certificate - If you bought your certificate from your web-host then they can do this step for you. If you are managing the site yourself then the two steps you need to complete are to generate a certificate signing request (CSR) and then to install your certificate. We have a range of documents to help complete both tasks on different web server software in our knowledge base.
3. Convert your whole site to HTTPS - After installing your certificate on your target pages, modify your site so that all content is served securely.

Certificate lifecycle management

Installing an SSL/TLS certificate is only the beginning. Certificates must be monitored and renewed before they expire to avoid issues like unplanned outages. 

This becomes significantly more demanding as the industry shifts to shorter public SSL certificate lifetimes, with the maximum validity moving to 200 days in 2026, 100 days in 2027, and 47 days in 2029. At this rate, automated certificate lifecycle management through a platform like Sectigo Certificate Manager (SCM) is the practical way to maintain coverage and reduce expiration risk.

Getting started

Sectigo offers every type of SSL/TLS certificate for purchase along with 24/7 support for customers. As a leading commercial public CA, Sectigo has issued more than 1 billion certificates worldwide.

If you need help understanding how SSL/TLS certificates work or selecting the right one for your website, contact us today.

Want to learn more? Get in touch to book a demo of Sectigo Certificate Manager!

Electronic signatures, commonly referred to as e-signatures, are a broad set of solutions that use an electronic process for accepting a document or transaction with a signature. As documents and communication are increasingly paperless, businesses and consumers worldwide have embraced the speed and convenience of these types of signatures. But there are many different types of electronic signatures, each allowing users to sign documents digitally and offering some degree of identity authentication.

Digital signatures are a specific type of electronic signature and are the most secure type available. Digital signatures rely on PKI certificates issued by a Certificate Authority (CA). Before issuing a document signing certificate, the CA verifies the signer’s identity through a verification process. This process may involve documentation checks, organizational verification, or other procedures depending on the certificate type, organization validation (OV) or extended validation (EV). Other, less secure e-signature types may use common electronic authentication methods to verify the identity of the signer, such as an email address, a corporate username/ID, or a phone number/PIN.

As a result of different technical and security requirements, electronic signatures vary in industry, geographic, and legal acceptance. Digital signatures comply with the most demanding regulatory requirements, including the United States Federal ESIGN Act and other applicable international laws.

How do digital signatures work?

Digital signatures use PKI, which is considered the gold standard for digital identity authentication and encryption. PKI relies upon the use of two related keys, a public key and a private key, to encrypt and decrypt a message using strong public key cryptography algorithms. The signature is generated using the signer’s private key, which securely binds their identity to the document. A timestamp may also be applied to record when the document was signed and help preserve its validity over time.

Here is how sending a digital signature works:

1. The sender selects the file to be digitally signed in the document platform or application.
2. The sender’s computer calculates the unique hash value of the file content.
3. This hash value is encrypted with the sender’s private key to create the digital signature.
4. The original file, along with its digital signature, is sent to the receiver.
5. The receiver opens the file in a compatible application, which recognizes that the file has been digitally signed.
6. The receiver’s computer then decrypts the digital signature using the sender’s public key.
7. The receiver’s computer then calculates the hash of the original file and compares the hash it has computed with the now decrypted hash of the sender’s file to confirm the file has not been altered.

What security protections do they provide?

Digital signatures provide three critical security assurances:

• Authentication of the signer’s identity,
• Data integrity to confirm the document has not been altered
• Non-repudiation, meaning the signer cannot later deny approving the document

Together, these protections help organizations reduce fraud, meet compliance requirements, and conduct secure digital transactions with confidence.

How do organizations obtain a digital signature certificate?

The process to create a digital signature is easy and straightforward for both independent professionals and enterprises to adopt. You first need a digital signing certificate, which can be acquired through a trusted Certificate Authority, like Sectigo. After completing the purchase and issuance process, you can then download and install the certificate. Next, you simply use the digital signing function of the appropriate document platform or application. 

For example, most email applications provide a “Digitally Sign” button, while Microsoft Word documents may show a signature button once a signature line has been added.

How recipients verify a digitally signed document?

When sending out a document signed using a private key, the receiving party obtains the signer’s public key to verify the digital signature. Once the document is decrypted, the receiving party can view the unaltered document as the user intended. If the receiving party cannot verify the document using the public key, then it signifies that the document has been altered, or even that the signature doesn’t even belong to the original signer.

Why protecting the private key is critical?

Digital signature technology requires all involved parties to trust that the individual creating the signature has been able to keep their own private key secret. If someone else has access to the signer's private key, that party could create fraudulent digital signatures in the name of the private key holder.

What happens if a signed document is changed?

If either the sender or receiver alters the file after it has been digitally signed, the document’s hash value changes. When the recipient’s system compares the newly updated hash with the original signed hash, any mismatch reveals that the document has been modified. In this case, the digital signature is marked as invalid, alerting users to potential tampering.

What does a digital signature look like?

Since the heart of a digital signature is the PKI certificate, which is software code, the digital signature itself is not inherently visible. However, document platforms may provide easily recognizable proof that a document has been digitally signed. This representation and the certificate details shown varies by document type and processing platform. For example, an Adobe PDF displays a visual indicator such as a seal icon or blue ribbon at the top of the document, showing the signer’s name and the certificate issuer.

Additionally, it can appear on a document in the same way as signatures are applied on a physical document and can include an image of your physical signature, date, location, and official seal.

Digital signatures can also be invisible, though the digital certificate remains valid. Invisible signatures are useful when the type of document typically does not display the image of a physical signature, like a photograph. The document’s properties may disclose the information about the digital certificate, the issuing CA, and an indication of the document’s authenticity and integrity.

If a digital signature is invalid for any reason, documents display a warning that it is not to be trusted.

Why are they important?

As more business is conducted online, agreements and transactions that were once signed on paper are now handled through fully digital workflows. This shift increases the need to verify identity and ensure documents have not been altered. Digital signatures provide that trust by authenticating the signer and protecting documents from tampering or fraud.

They also support faster, more efficient workflows. Documents can be signed securely from any device, shared instantly, and tracked through completion with clear audit trails. Because the signature is embedded within the file, it remains intact and verifiable wherever the document is sent.

Beyond large organizations, digital signatures are equally valuable for independent professionals, consultants, and small businesses who need a simple, trusted way to sign contracts, agreements, and client documents without complex infrastructure. Solutions designed for individuals make it easy to establish credibility and maintain secure, compliant workflows.

It is vital these digitally signed agreements are recognized from a legal standpoint. Digital signatures support compliance with important standards like the United States Federal ESIGN Act, GLBA, HIPAA/HITECH, PCI DSS, and US-EU Safe Harbor.

Common digital signature use cases

Today, digital signatures are commonly used across a wide range of business processes to improve the security, integrity, and efficiency of critical transactions that are now handled digitally, including:

• Contracts and legal documents: Digital signatures are legally binding. Thus, they are ideal for any legal document requiring an authenticated signature by one or more parties and assurance that the document has not been modified.
• Sales agreements: By digitally signing contracts and sales agreements, both the seller and the buyer identities are authenticated, and both parties have peace of mind that the signatures are legally binding and that the terms and conditions of the agreement have not been altered.
• Financial documents: Financial departments digitally sign invoices so that customers trust the payment request is coming from the proper seller, not a bad actor trying to scam the buyer into sending payment to a fraudulent account.
• Healthcare data: In the healthcare industry, data privacy is paramount for both patient records and research data. Digital signatures ensure that this sensitive information has not been altered when shared between consenting parties.
• Government forms: Government agencies at the federal, state, and local level have stricter guidelines and regulations compared to many private sector businesses. From approving permits to clocking in on a timesheet, the signatures can streamline productivity by ensuring that the right employee is involved for the appropriate approvals.
• Shipping documents: For manufacturers, ensuring cargo manifests or bills of lading are always accurate helps reduce costly shipping errors. Yet, physical paperwork is cumbersome, isn’t always easily accessed in transit, and can be lost. By digitally signing shipping documents, shippers and receivers can access a file quickly, verify that the signature is up to date, and confirm that no tampering has occurred.

Secure your documents with Sectigo

Sectigo document signing certificates verify the signer’s identity and confirm that a document has not been altered after signing. Each signature is cryptographically bound to the file, allowing recipients to independently validate authenticity and integrity.

Sectigo offers solutions for both organizations and individuals. Document Signing Certificates support enterprise use cases with scalable, policy-driven signing, while Document Signing Professional is designed for independent professionals and small businesses that need a simple, trusted way to sign documents. In both cases, verified identity is embedded directly into each file, creating tamper-evident documents recognized by platforms like Adobe Acrobat and Microsoft Office.

Learn more about Sectigo's document signing solutions to protect contracts, reports, and other business-critical documents.