DEV Community: Certera

SSL/TLS Certificate News 2026

Certera — Mon, 02 Mar 2026 05:00:14 +0000

SSL/TLS Certificates Validity

Public SSL/TLS Certificates will no longer be issued for one year; they will now be valid for 199 days with shorter renewal periods.

DigiCert

DigiCert will implement the new validity changes in four phases. Certificates issued before February 24, 2026, will retain the current maximum validity of 397 days. Between February 24, 2026, and early 2027, the maximum validity will drop to 199 days. From early 2027 through early 2029, it will further reduce to 99 days. After early 2029, certificates will be capped at just 46 days.

Sectigo

Sectigo follows a similar but slightly different schedule. Certificates issued before March 15, 2026, will maintain the current 398-day maximum. Between March 15, 2026, and March 15, 2027, the maximum drops to 200 days. From March 15, 2027, through March 15, 2029, it reduces further to 100 days. After March 15, 2029, the maximum validity will be just 47 days.

Required Actions

To prepare for these changes, organizations should start by discovering all certificates currently in use across their infrastructure. Next, inventory every system that depends on those certificates and map out where automation can replace manual renewal processes. Build a phased rollout plan that aligns with the timeline above, and embrace automation as the foundation of your certificate management strategy going forward.

Domain Validation (DCV) Reuse Reduction

By not allowing DCV to be reused for a longer period of time, the verification process will occur more frequently.

DigiCert

DigiCert's domain validation reuse periods will mirror the certificate validity reduction timeline. Before February 24, 2026, DCV results can be reused for up to 397 days. Between February 24, 2026, and early 2027, the reuse window shortens to 199 days. From early 2027 through early 2029, it drops to 99 days. After early 2029, domain validation results will only remain valid for 9 days, meaning organizations will need to revalidate domain ownership almost weekly.

Sectigo

Sectigo's DCV reuse reduction follows its own schedule. Before March 15, 2026, validation results can be reused for up to 398 days. Between March 15, 2026, and March 15, 2027, the reuse period shrinks to 200 days. From March 15, 2027, through March 15, 2029, it reduces to 100 days. After March 15, 2029, DCV results will expire after just 10 days.

Required Actions to Take

Organizations should prepare for domain control validation to be checked far more frequently than current workflows allow. DNS-based validation methods should be prioritized because they provide the most reliable and automatable verification path. Most importantly, automate as much of the DCV process as possible, because manual revalidation every 9 or 10 days is simply not sustainable at scale.

Using MPIC for Domain Control & CAA Checks

Multi-Perspective Issuance Corroboration (MPIC) ensures that domain control and CAA checks are verified from multiple network locations to prevent BGP hijacking and other routing-based attacks.

CA/Browser Forum Timeline

The rollout happens in three phases. Phase One, effective March 2025, requires certificate authorities to perform domain validation checks from multiple network locations, though no specific minimum number of perspectives is mandated at this stage.

Phase Two takes effect in September 2025. CAs must check from at least 2 remote network locations, and one non-corroboration is allowed — meaning if one perspective fails to confirm domain control but the other succeeds, issuance can still proceed.

Phase Three begins in February 2026 and raises the bar further. CAs must check from at least 3 remote network locations spread across at least 2 different Regional Internet Registries (RIRs). One non-corroboration is still permitted.

Required Actions to Take

Organizations should ensure that their domain DNS records and HTTP validation paths are publicly accessible from networks around the world. Review firewall rules and geo-blocking configurations that might prevent validation requests from reaching your servers from different geographic regions. Additionally, closely monitor any validation failures, as MPIC introduces more potential failure points that could delay certificate issuance if not addressed promptly.

DNSSEC Enforcement

DNSSEC now plays an enhanced role in verifying domain ownership and validating the security of certificate issuance processes.

Timeline

DigiCert will begin enforcing DNSSEC validation on February 24, 2026. This means DNSSEC validation will be applied during both domain control validation and CAA record checks whenever DNSSEC is present in the domain's DNS configuration.

Sectigo's operational date follows shortly after on March 12, 2026. Sectigo's compliance hub highlights broader 2026 compliance changes, including DCV reuse shortening and reminders for proper DNSSEC signing configuration.

The CA/Browser Forum Baseline Requirements update takes effect on March 15, 2026, making DNSSEC validation mandatory for all relevant DNS lookups across the entire industry.

Required Actions to Take

Review your current DNS configurations to determine whether DNSSEC is enabled for your domains. If DNSSEC is active, ensure it is properly implemented and that all signing keys and delegation records are correctly configured. Misconfigured or broken DNSSEC records will cause certificate issuance to fail once enforcement begins, so identifying and fixing these issues before the deadlines is critical.

Sunsetting Client Authentication EKU from Public TLS Certificates

Public TLS certificates will no longer support Client Authentication Extended Key Usage (EKU). This change affects both the certificates themselves and the root hierarchies from which they are issued.

Extended Key Usage (EKU) Changes

Under Chrome's policy, both Server Authentication and Client Authentication EKUs can be included in TLS certificates prior to June 15, 2026. Starting June 15, 2026, only Server Authentication EKU will be permitted.

DigiCert's transition plan begins earlier. Starting October 1, 2025, DigiCert will begin issuing public TLS certificates with only Server Authentication EKU by default, though a temporary option to include both Server and Client Authentication EKUs will remain available during enrollment. By May 1, 2026, DigiCert will fully remove the Client Authentication EKU from all newly issued public TLS certificates, including new orders, renewals, reissues, and duplicates.

PKI Hierarchy Changes

Prior to June 15, 2026, TLS certificates may be issued from multipurpose root hierarchies. Starting June 15, 2026, TLS certificates must be issued from dedicated TLS-only root hierarchies. DigiCert will convert the following roots to dedicated TLS hierarchies:

DigiCert Global Root G2
DigiCert Global Root G3
DigiCert TLS ECC P384 Root G5
DigiCert TLS RSA4096 Root G5
QuoVadis Root CA2 G3

Required Actions to Take

Organizations must stop using public TLS certificates for client authentication purposes. Instead, switch to either a private PKI infrastructure or dedicated client-authentication certificates designed specifically for that purpose. Audit all applications across your environment that rely on Mutual TLS (mTLS) to identify where public TLS certificates are currently being used for client authentication, and plan the migration to alternative solutions before the June 2026 deadline.

Future Changes to Keep in Mind

Several additional changes are scheduled for the coming years that organizations should plan for now.

OnMarch 15, 2026, the Crossover validation method (3.2.2.4.8) will be phased out entirely. Phone and email verification methods will be officially discouraged at this point but will still remain temporarily available.

ByMarch 15, 2027, phone-based verification methods will be completely phased out. No new certificates will be issued using phone verification after this date.

Finally, onMarch 15, 2028, email-based verification methods will also be completely retired. From that point forward, all certificates will require DNS-based, HTTP-based, or IP-based verification methods exclusively.

Inspired by - Major SSL/TLS Certificate Changes 2026: Every Website Owner Must Know

Post-Quantum Cryptography for DKIM, PGP, and S/MIME

Certera — Mon, 23 Feb 2026 04:33:50 +0000

Quantum computers aren't going to nibble at email security. They're going to smash straight through the core systems that keep email trustworthy. Here's what falls apart first.

DKIM

DKIM is what tells your inbox, "This email really came from Google, Microsoft, or your bank."

The problem?

DKIM relies on RSA or ECC signatures, the exact algorithms quantum computers can tear apart. With a strong enough quantum machine, attackers can forge DKIM signatures and make a malicious email look 100% legitimate.

PGP

PGP is loved by privacy-focused users, security researchers, and anyone dealing with sensitive data.

But its strength depends entirely on one thing. Attackers cannot compute your private key.

Quantum computers change that. With Shor's algorithm, a quantum machine can derive PGP private keys almost instantly. It's like giving attackers a master skeleton key to your entire message history.

S/MIME

S/MIME is the corporate workhorse of email security. Enterprises, governments, and regulated industries rely on it for encryption, authentication, and compliance.

And it also relies on RSA and ECC. Quantum cracking makes S/MIME certificates worthless. The entire PKI chain collapses. Email confidentiality collapses with it.

How PQC Fits Into Email: The Real Upgrade Path

Now this question comes to everyone's mind. How do we actually move email from "quantum-vulnerable" to "quantum-safe"? The answer isn't ripping everything out and starting from scratch. It's transitioning carefully, step by step, using hybrid cryptography.

DKIM + PQC: Double Signatures, Double Safety

DKIM needs a quantum-safe upgrade, but we can't flip a switch overnight. That's where hybrid signatures come in.

Here's how it works:

Your mail server signs outbound emails with RSA/ECC (current standard)
And also signs them with PQC (Dilithium)
Both signatures sit inside the same DKIM DNS record

That even with the arrival of quantum computers tomorrow, your email is safe. Such standards organisations as IETF LAMPS are already specifying the appearance of these hybrid DKIM signatures.

And the big mail companies, Google, Microsoft, and Fastmail, are conducting experimental background experiments.

PGP + PQC: Hybrid Keys for Real Privacy

PGP will also shift into hybrid mode. Instead of choosing between "old crypto" and "new crypto," you combine both.

An ECC key for compatibility
A PQC key (Kyber + Dilithium) for quantum safety

Think of it like having two locks on your safe. If one fails, the other still protects you. The OpenPGP working group is actively developing this hybrid PGP design using Kyber for encryption and Dilithium for signatures.

The good part is that it's Backward compatibility. Some older PGP clients will break. Some email tools won't understand the new hybrid keys. And that means adoption will be slower, and privacy tools take time to evolve. PGP won't survive without PQC.

S/MIME + PQC: The Enterprise Shake-Up

The real headache is S/MIME. Since S/MIME is based on certificates and complicated chains of PKI, this is not as simple as the addition of a new algorithm. PQC migration (of S/MIME) implies:

New quantum-resistant certificates
New PKI chains
New trust anchors
New certificate rotation policies.

Basically, every link in the chain must be upgraded before anything works. Enterprises also need to start rotating encryption keys early. If not, they risk storing years of emails that become instantly readable when quantum decryption becomes practical.

S/MIME adoption will move more slowly than DKIM or PGP simply because the certificate ecosystem is… complicated.

Think of it like replacing the foundation of a building instead of just swapping the front door. But the shift is already happening. The vendors and certificate authorities are testing PQC-enabled S/MIME certificates today.

What Businesses Can Do

Quantum risks feel like one of those things everyone agrees are "important," but no one wants to think about yet. The problem is that crypto transitions move more slowly than people expect.

By the time the danger feels real, it's already too late to adapt.
The companies that start early won't even notice the shift. The ones that don't will eventually scramble in a way that looks embarrassing in hindsight.

Figure Out Where You're Using RSA and ECC

Most teams don't actually know. They assume they know, which is worse. Look at the parts of your email system that depend on these algorithms:

DKIM signatures
PGP keys
S/MIME certs
Whatever TLS your mail servers negotiate
Any glue code, cron jobs, or scripts still generating RSA/ECC keys

If you can't describe where your encryption lives, start writing it down. Even a messy inventory is better than guessing. Everything else in your PQC plan depends on this step.

Use PQC Libraries

You don't need to deploy anything for real yet. Just get your hands dirty. Make a small prototype. Even if it breaks, you'll understand the shape of the future a bit more clearly. Better to have things fall apart during a test project than during a real migration.

Push Your Vendors

You're not switching to PQC alone. Your stack is glued together with tools made by other people, and if they aren't moving, neither are you. Most vendors only move when customers start asking the same questions in unison. Put "PQC-ready" as a requirement in new contracts. Vendors notice those lines.

Use Hybrid Crypto where possible.

The good fact with hybrid cryptography is that there is no need to make a choice: it uses classical and post-quantum cryptography simultaneously. It interacts with the current systems but does not subject you to the problems that will arise tomorrow. Consider it as putting a seatbelt on a prehistoric motor vehicle, not ideal, but at least safer.

Revise Your Policies Before somebody pushes you to.

Finance, healthcare, and government industries have already begun developing quantum-readiness rules. You can do so without having to wait till you are mandated to.

Original Source

Post-Quantum Cryptography for DKIM, PGP, and S/MIME: Quantum Threat to Email Security

ACME Protocol

Certera — Mon, 16 Feb 2026 06:06:24 +0000

What is the ACME Protocol?

ACME or Automated Certificate Management Environment Protocol is a powerful tool for automating the management of certificates used in Public Key Infrastructure (PKI) systems.

It facilitates seamless communication between Certificate Authorities (CAs) and endpoints. Unlike other protocols, ACME is free of licensing fees and can be easily configured. It is implemented by IT teams to enhance enterprise security.

In RFC 8555, the Internet Security Research Group (ISRG) published the ACME protocol as an Internet Standard. The current version of the protocol is the ACME v2 API, released in March 2018, while the previous version (ACME v1) has been deprecated since April 2016.

How ACME Protocol Work?

The ACME protocol operates through two main components: the client and the server. The client, running on the user's server or device, uses the protocol to request certificate management actions such as certificate issuance or revocation.

The ACME server, hosted by a Certificate Authority (CA) like Sectigo and DigiCert, responds to these client requests and executes the requested actions once the client is authorized. The client and server communicate via JSON messages over a secure HTTPS connection.

Authentication plays a crucial role in the ACME protocol, specifically through an authentication step known as an ACME challenge. The CA can only issue a certificate or complete the request once the challenge is completed.

Two types of ACME challenges are commonly used:

HTTP Challenges:

In this challenge, the CA sends a token to the ACME client, which then installs the token on the server. The client creates a file that combines the token with a thumbprint of the authorization key generated during setup. This file is placed on the server. Once the file is installed, the client notifies the CA, which retrieves and validates the file to complete the challenge.

DNS Challenges:

This challenge adds a verification factor by requiring the ACME agent to place a specific value in a TXT record within the domain's DNS space. Like the HTTP challenge, the CA sends a token to the client, and the client appends the thumbprint of the authorization key to create and install the challenge file.

After the agent informs the CA that the challenge has been met, the CA performs a DNS lookup and retrieves the TXT record to validate the challenge.

The challenge process is typically fast, usually completed within 15 seconds for both types. However, ensuring the server setup is complete before the ACME client sends any requests is essential.

Delays in DNS propagation or firewall rules can cause ACME server queries to fail. It is recommended that clients should only respond to challenges once they believe the server's queries will succeed, minimizing potential errors.

Benefits of ACME

Let us examine the benefits and uses of an automated protocol, explicitly highlighting the challenges and risks associated with manual certificate deployment and management. While PKI offers a robust authentication and encryption solution, manually handling certificates can take time and introduce unnecessary risks.

Regardless of the scale of certificate deployment, whether it's a single SSL certificate for a web server or millions of certificates across various networked devices and user identities, the end-to-end process of issuance, configuration, and deployment can take several hours.

Manually managing certificates also increases the likelihood of forgetting certificate expirations, ownership gaps, and vulnerabilities to attacks like Man-in-the-Middle (MITM).

To mitigate these challenges, enterprises require an automation standard like ACME. By implementing ACME, organizations can ensure that certificates are accurately configured and deployed without human intervention on an individual certificate basis. This automation not only reduces risk but also grants IT departments more significant control over operational costs.

Inspired By

What is ACME Protocol, and How does it Work?

Clear SSL State in Browser

Certera — Fri, 06 Feb 2026 08:59:24 +0000

To clear the SSL state in Chrome, follow these steps:

Locate the Chrome browser on the available Internet-connected computer.
In the address bar, type chrome://net-internals/#sockets and press Enter.
Doing this will launch the 'Net Internals' page which will contain the information and utilities surrounding the nets in Chrome.
In the list of options provided, look at the bottom of the page and locate the "SSL" tab along with the "Clear SSL State" button under it.
You will see a pop-up window with the following message: "Clearing SSL state will weaken the security of SSL certificates that Chrome trusts and may expose users to Moran/POODLE attacks, resulting in slowdowns or errors on sites with secure connections. "
This is done to clear the SSL state and upon completion, click on the "OK" button.

The removed SSL state implies that each time the browser returns to a secure website, Chrome shall re-identify and refresh the cached SSL/TLS certificate data.

Some changes may slow down the process or even cause errors at the beginning of the process, but after the fix, all SSL-related problems should be solved.

1. Clearing Browsing Data

Launch the Chrome browser and click on the three-dot menu button found on the browser toolbar at the top right corner of the window.
Just beneath those options, click the "Settings" link.
The settings window itself is divided into distinct sections: go down the page and click on "Privacy and security".
Delete browsing history is listed, and right next to it, click on "Clear browsing data".
In the opened dialog box, in the "Clear browsing data" section, define the period of time for which you want to delete the data (for instance, "Everything" for all the data).
To clear the browsing history, tick the two options available, namely "Cookies and other site data" and "Cached images and files".
Pressing the button "Clear data" will clear not only the SSL state but also the browsing data.

It seems that, in addition to the SSL state, other browsing data, such as cookies, cached files, and website data, are deleted by this method as well.

Though its primary use may sometimes involve the troubleshooting of SSL-related problems, it has the potential to alter one's browsing preferences by erasing saved passwords and browsing history, among other features.

2. Using Chrome's Developer Tools

Load on the website that created the SSL cavities that Chrome experiences.
They often right-click the blank area of the page and then choose the command "Inspect" or "Inspect Element" from the menu options.
When the Developer Tools window is opened, go to the security tab of the window to inspect the security settings.
It will either turn into "clear all cookies and cache and then reload" if the button is available, click it.
After that, click on the Developer Tools and then go to inspect element, lastly, close Developer Tools and then refresh the website.

The benefit of this method is that it removes the SSL/TLS certificate details that Chrome has stored in the cache for the site that you are currently browsing and causes Chrome to check for the SSL state again for the site.

It can be useful if you think that the particular website has an issue, but you do not want to clear the SSL state for all the websites. connections.

Source

How to Clear SSL State in Your Browser?

Create Wildcard Subdomains in CPanel and CloudFlare

Certera — Wed, 28 Jan 2026 09:38:12 +0000

Cpanel

Login to cPanel: To get into your cPanel interface you have to open your web browser and enter login details supplied to you by your web host.
Locate Subdomains: After day and registering for an account, go to Domain manager or try using a search bar in the page to look for Subdomains.
Create Subdomain: To proceed with the subdomain manipulation click on the 'Subdomains' button. On the Subdomains page, there would be a form which users may fill to create a new subdomain.
Enter Details: In case of "Subdomain," put an asterisk (*) symbol in the text box designated for this parameter. This symbol is used to make a field or column to allow searching of any character. For instance, if your domain is 'example.' com", enter ". example. com".
Choose Document Root: The "Document Root" field is optional and will be filled by the site builder tool. This designates the directory where files that correspond to the wildcard subdomain will be located. This determines the directory where files for the wildcard subdomain are placed. Designate the folder in which to save files as the default, or select a different one if necessary.
Create Subdomain: To create the wildcard subdomain you would click on the Create button like I have highlighted below.
Confirmation: Once they are created, the admin will receive a confirmation message on the screen that a wildcard subdomain has been added.

CloudFlare

Login to Cloudflare: Visit the Cloudflare website and log in with your credentials.
Select Domain: If you own several domains, choose the one for creating a subdomain from the dashboard.
Navigate to DNS Settings: After getting on the domain dashboard, find the option labelled "DNS". This is where you manage DNS records for your domain,:
Add DNS Record: In the DNS Records section, you will see the Add Record button located at the bottom of the page.
Enter Details: In the "Name" field, you must provide a specific company subdomain name. For instance, let us consider an example of creating a "sub." example. To do this, simply press "tab" to go to the next field, and enter "sub" in the Name field.
Select Type: Select the record type depending on the complexity of the inquiry and the amount of data you want to obtain. For any standard subdomain choose 'A' if it is an IP version 4 address or 'CNAME' if it is an alias.
Enter Value: In the "IPv4 Address" or "Value" field, you need to input the IP address of the server to which the subdomain will direct. In case of using a CNAME record, specify the hostname of the target server.
Toggle Proxy Status (Optional): To proxy traffic through Cloudflare, switch proxy status to the 'Proxied' state. This comes in handy to conceal your origin server IP address.
Save Record: When you are done, click on the "Save" button to provide the DNS record of the subdomain.
Verification: Once entered, Cloudflare will show a success message saying that the selected DNS record has been added successfully. Sometimes it may take several days before the changes reflected on the website go viral on the internet
Test Subdomain: It is now possible to put the subdomain to the test by simply typing its address in the address bar of any web browser and checking whether it directs the connection to the right place.

Reference

What are Wildcard Subdomains? How to Create a Wildcard Subdomains?

Sign Documents in Adobe Acrobat

Certera — Tue, 13 Jan 2026 09:59:29 +0000

1. Open Document

You must open your PDF in Adobe Acrobat. From the left navigation, go to: All Tools → View more → Use a certificate → Digitally sign

This initiates a digital signing mode.

2. Sketch the Signature Area

Click and drag the mouse in the area where you want your signature to be displayed. A pop-up window will appear, prompting you to select, create, or import your Digital ID.

If your certificate is installed on the system, Acrobat will automatically detect it. If that's not the case, choose "Configure New Digital ID" to import a certificate.

3. Create/Select Digital ID

You have the following options:

eToken Certificate(s) (using a hardware signing token)
Cloud or PFX-based Certificate(s) (using an ID that is stored or managed locally)

Follow the directions provided on the application. If prompted, enter your token password (your private key PIN) if you have one to authorize signing the document.

Also Read: How to Know if You Had a DMARC Failure Happened? Learn How to Fix

4. Change Signature's Appearance

Before you submit your signature, you can:

Change how your signature appears (name, logo, timestamp, etc.)
Create new appearances using or saving a preset
Lock the document after you have signed it so that it is not changed after signing it.

When you're ready, select Sign.

5. Save and Timestamp Signed Document

Once completed, Acrobat will instruct you to pick a location to save the signed document. It is best practice to add a trusted timestamp to maintain long-term validity (LTV):

Choose Use a certificate → Timestamp
Add a new timestamp server. For example: http://timestamp.digicert.com
Set as default, if applicable; resign the document

Timestamping automatically keeps your signature valid if your certificate were to ever expire - great practice for legal and compliance work.

6. Verify the Signature

After you save, your document will contain a ribbon icon or signature badge at the top.

Click on "View Signatures" or "This document has signatures" to see signer information, timestamps, and certificate trust levels.

Source

Self-Signed Certificate in Certificate Chain Error

Certera — Wed, 07 Jan 2026 09:09:32 +0000

SSL and TLS errors are common, and one issue frequently seen by administrators, developers, and users is the "Self-Signed Certificate in Certificate Chain" error. This occurs when a self-signed certificate appears in the certificate chain or when the chain is incomplete. Since a trusted Certificate Authority does not verify self-signed certificates, clients cannot confirm their authenticity. As a result, secure connections fail.

Here's how you can fix it.

Update the Certificate and Chain

Verify that your certificate and its complete chain, including all intermediate and root certificates, are updated. Get the correct chain from the issuing Certificate Authority (CA) and install it on the server.

Restart the web server or related services to test your changes. This step is to also resolve any expired or misconfigured certificates that might be causing the error.

Use SSL Analysis Tools

Tools such as SSL Checker, SSL Labs, OpenSSL, or other certificate checkers will help with the determination of where the specific problem has arisen.

These tools check the certificate chain and any possible expired certificates, as well as that the appropriate domain should be mentioned on the certificate. By resolving the issues pinpointed in this way, you would be able to fix your configuration problems.

Also Read: Troubleshooting ERR_SSL_PROTOCOL_ERROR in Chrome & Android Devices

Clear Browser Cache

There could be conflicts caused by cached SSL certificates stored in your browser. Clear the cache and cookies from your browser, and reopen the site over HTTPS. This action will force the browser to fetch the most recent SSL certificate and will also fix errors caused by deprecated or incorrectly cached entries.

Examine Intermediate Certificates

Check the certificate chain intermediate certificates. Missing, misconfigured or self-signed intermediate certificates could break trust in the chain.

Acquire valid intermediate certificates from the certificate authority and install them on the server to establish a valid trust chain.

Verify the Trusted Root CA Certificate

Ensure that the root CA certificate is in the trust store of the server and client systems. The root CA must match the list of CAs recognized as trusted by major web browsers and operating systems. If the root certificate is absent or untrusted, manually download and install it to correct the trust issue.

Also Read: Troubleshooting the ERR_CACHE_MISS Error in Google Chrome

Replace Self-Signed Certificates

Replace self-signed certificates with certificates issued by a trusted Certificate Authority (CA). An authentic CA-signed certificate will be compatible with all browsers and provide an appropriate trust chain, thus eliminating the main cause of the error.

Install the Complete Certificate Chain

Make sure the web server is configured with the complete certificate chain, including the root, intermediate, and end-entity (domain) certificates.

Many errors arise from an incomplete chain, where intermediate certificates are missing. Proper chain configurations guarantee continuous validation by browsers and clients.

Source

When a Wildcard SSL Certificate Makes Sense and When It Doesn’t

Certera — Tue, 02 Dec 2025 06:48:57 +0000

A wildcard SSL certificate feels almost magical when you first learn what it does. One certificate covers your main domain and every subdomain under it. That can remove a lot of everyday work, but it is not always the best choice. The key is knowing when a wildcard makes sense and when something else keeps your site safer. This guide walks through both sides without sliding into corporate speak.

Why Wildcard SSL Certificates Exist

Websites grow fast. A simple domain often expands into many subdomains over time. You might end up with things like:

blog.yourdomain.com
app.yourdomain.com
support.yourdomain.com
dev.yourdomain.com

Managing each one with a separate certificate can become a never-ending cycle. Renewing them, installing them and tracking expiry dates takes time. A wildcard certificate solves this because it secures every subdomain that matches *.yourdomain.com in one setup.

It also helps teams that create new subdomains often. Once the wildcard is installed, new subdomains are covered right away without extra steps.

When a Wildcard SSL Certificate Makes Perfect Sense

A wildcard certificate is a strong match when your setup fits a few clear patterns:

Many subdomains under the same main domain
A project that changes often or uses many test environments
A small team that wants less certificate management work
Regional or language-based subdomains that follow a simple pattern

In these cases, a wildcard cuts down on repetitive tasks and reduces the risk of forgetting to secure one part of your site.

Also Read: SSL/TLS Certificate will Be Valid For Only 47 Days

Situations Where a Wildcard SSL Certificate Does Not Fit

A wildcard is helpful, but not a one-size solution. It falls short when you need:

More than one level of subdomains - (It covers app.yourdomain.com but not shop.eu.yourdomain.com)
Strong security separation - (One wildcard key protects everything, so a leak affects all subdomains)
Protection across multiple unrelated domains - (*.yourdomain.com cannot secure yourotherdomain.com)
Compliance or internal policies that require strict separation

None of these mean wildcards are unsafe. They simply have limits that matter in some setups.

When a Multi-Domain or Separate Certificate Is Better

There are times when a wildcard takes a back seat and other options shine:

Multi-domain certificates help when you handle many unrelated domains, while separate certificates help you isolate sensitive areas like:

payment systems
admin panels
internal dashboards

If one private key is exposed, only that part of the system is affected. This improves control and reduces risk.

Separate certificates also help during audits or troubleshooting because each part of the site has its own certificate and expiry cycle.

Choosing the Right Option for Your Project

The smartest choice depends on how your project is built and how often it changes. A wildcard fits when you manage many subdomains under one domain. If your structure is complex, involves several domains or needs strict separation, multi domain or separate certificates keep you safer.

A wildcard SSL certificate is not magic and not a shortcut. It is a tool with strengths and limits. When you understand both sides, it becomes easier to protect your visitors and keep your site easier to manage.

If you take a moment to map out your subdomains and note where the most sensitive workloads live, the correct option usually becomes clear. The right SSL setup keeps your site secure today and easier to scale tomorrow.

Purchase Wildcard SSL Certificates

Purchase Multi-domain SSL Certificate

Centralized Certificate Management for Businesses

Certera — Wed, 03 Sep 2025 07:16:35 +0000

Certificate Management Meaning

At its core, certificate management is the process of acquiring, deploying, monitoring, renewing, and revoking digital certificates. It sounds simple. But when you're managing hundreds or thousands of certificates across cloud platforms, on-prem servers, load balancers, internal apps, and third-party services, that simplicity vanishes fast.

Why Do Businesses Need Certificate Management?

Because one expired certificate can take your whole system down.

Today's businesses aren't just running a single website anymore. You're managing cloud applications, mobile platforms, IoT devices, internal services, third-party integrations, and every single one of them depends on digital certificates for secure communication.

Now imagine trying to manage all of those manually. Spreadsheets. Calendar reminders. Frantic Slack messages when something goes wrong.

It's not scalable. And it's not safe. As your organisation grows, the number of certificates grows too fast.

This explosion is especially common in:

Cloud-native environments using microservices and containers
Mobile apps that require secure back-end communication
IoT devices that depend on certificate-based identity
DevOps pipelines that issue temporary certificates for automation

The real danger is that Manual tracking can't keep up. You'll miss a renewal. You'll misconfigure something. And suddenly, your users are staring at a scary browser warning. That's not just an inconvenience, it's a loss of trust.

But it gets even more serious…

If you're in a regulated industry (finance, healthcare, eCommerce, etc.), poor certificate management can mean non-compliance. You need to meet and follow standards such as PCI DSS, HIPAA, and ISO 27001. All of these require secure encryption and proof that you manage certificates properly.

Benefits of a Centralized Certificate Manager

The moment you have more than a handful of certificates, you need a system to manage them. Not a spreadsheet, not a shared doc, an actual system.

Here's what a centralized certificate manager gives you that piecemeal tools and ad-hoc scripts can't:

End-to-End Automation

The biggest risk in certificate management isn't complexity, it's forgetfulness. A certificate doesn't care if your team's overloaded or someone's on vacation. If it expires, it expires.

With centralised automation, issuance, renewal, and revocation happen without anyone needing to remember. Machines don't forget. And neither does a good certificate manager.

Centralized Visibility

What you can not see, you cannot fix. And in the majority of companies, those certificates are scattered, some in dev, some in prod and some buried in that old Jenkins server no one uses.

All information is at a single glance through a centralised dashboard. You can actually see what is expiring, what is non-compliant, and what belongs to whom. Then add audit logs and exportable reports, and what was once a compliance fire drill now becomes a button.

Policy Enforcement

Without a standardized procedure, teams will establish the certificate in various ways. Some use SHA-1 (still these days), Others establish a validity period of 3 years (even though it's not best practices). With a centralised manager, you can set and enact policy, key sizes, trusted issuers, and validity periods in a blanket manner. A sense of uniformity is not bureaucracy. It's hygiene.

Scalability and Integration

Modern infrastructure is a patchwork of on-prem systems, cloud workloads, containers, and APIs. Managing certificates across them manually isn't just inefficient, it's impossible.

A good certificate manager plugs into your DevOps workflows (CI/CD), cloud providers (AWS, Azure, GCP), and container environments (Kubernetes), so certs flow where they're needed without you hand-holding them.

Cost & Time Savings

Missed expirations can lead to SLA breaches, financial penalties, or even lost customers. Duplicate purchases and firefighting eat into budgets. And then there's the time your team spends tracking certs that should manage themselves.

A centralised system turns all that chaos into clean workflows and pays for itself in the process.

Reference

What is Certificate Management? Why Do Businesses Need Centralized Certificate Management Solution?

BIMI Overview: How It Works And Its Benefits

Certera — Tue, 19 Aug 2025 05:15:52 +0000

What is BIMI?

BIMI, which stands for Brand Indicators for Message Identification, is an email specification that gives brands the ability to display their logo next to their emails when they appear in the recipients' inboxes. It is a visual authentication of email, as well as making brands more recognizable and raising awareness.

You could think of BIMI as the email equivalent of a verified profile picture. BIMI begins with either SPF or DKIM, and if you have DMARC, there are even more protections, by indicating that only the legitimate senders can display this representation of your brand.

How BIMI Works?

With BIMI, trust incorporates a blend of DNS records, email authentication, and a verified logo file.

The general description goes as follows:

Email Authentication (SPF, DKIM, DMARC)

BIMI stands upon a very stout email authentication. The sender domain needs to have a valid SPF, DKIM, and DMARC in place.

A DMARC policy execution of p=quarantine or p=reject is a must to ensure that emails that fail sender authentication are either not delivered or quarantined.

Verified Mark Certificate (VMC)

VMC is a digital certificate that proves your legal title to the logo you chose to display. The certificate authority (CA) issues the Verified Mark Certificate after performing its due diligence in verifying your brand identity.

It's not an absolute necessity all the time; however, some mailbox providers, Gmail being one among them, require VMC to make BIMI operational.

Logo Creation

Your logo shall be in SVG (Scalable Vector Graphics) format. And your logo must be square and in compliance with the rules established by the BIMI Group.

Setting the DNS Records

Now you must generate a TXT record under your domain's DNS setup. This record will contain the BIMI record indicating the location of your SVG logo file on the internet.

The BIMI record is made up of a version number of the BIMI specification (which is optional), the path to your SVG logo file and your VMC file (also optional).

The BIMI record type as seen in the example below:

default._bimi.yourdomain.com. IN  TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem;"

v=BIMI1: Specifies the BIMI version.
l=https://yourdomain.com/logo.svg: Specifies the URL of your SVG logo file.
a=https://yourdomain.com/vmc.pem (Optional): Specifies the URL of your VMC file.

Mailbox Provider Implementation

Mailbox providers to whom BIMI may apply will seek to verify your BIMI record within the DNS of your domain.

Provided that the record is discovered, and the email is going through the authentication validation (SPF, DKIM, DMARC), the recipient email box provider will append your logo next to your email message in the recipient's inbox.

Benefits of Brand Indicators for Message Identification

BIMI provides several advantages for organizations implementing it:

Enhanced Brand Recognition

Greater brand identity roles are fulfilled, and BIMI Ads allows images to be displayed in the recipients' inboxes so your brand can be consistent and easily identifiable. There is a very high momentum for email users to trust messages received from recognizable logos.

Improved Email Security

Higher levels of authentication than only DMARC are delivered via the logo; you can count on reduced phishing attacks and email spoofing.

Increased Email Engagement

Users and organizations who use identifiable logos in their emails provide tremendous amounts of visual stimuli- their messages become more recognizable and enticing to open.

Improved Deliverability

While it won't affect deliverability positively as a measured factor, BIMI can improve it indirectly.

Implementing strong email authentication standards (the requirement for BIMI) demonstrates to mailbox providers that you are a legitimate sender, which, in turn, builds your sender reputation and mitigates the chance of delivering spam.

Better Trust and Confidence

A verified logo can make a well-defined and identified brand even more trustworthy. If emails are authenticated and properly identified, recipients will generally have stronger trust levels.

Stronger Competition

BIMI can deliver the huge threat of making your emails more attractive and more legitimate than the unverified, unbranded emails of a competitor.

Reference

What Is BIMI? Benefits, Works and Supported Mailbox Providers

How CDNs Can Make SSL Better?

Certera — Mon, 04 Aug 2025 06:49:57 +0000

While SSL/TLS encryption improves the security of the web, there are trade-offs in terms of performance.

The secure connection uses a handshake process to establish a connection that introduces latency.

CDNs help fix these issues and improve the performance of SSL/TLS in a few ways:

It Reduces Latency with Edge Servers

SSL/TLS handshakes require a round-trip between the client and server. For users that are much further from the origin server, the number of round-trip trips can cause noticeable latency. CDNs have SSL-enabled edge servers configured, very close to the end-user.

When users make a secure connection, both the handshake and content are transferred by the nearest edge server. This drastically reduces latency and improves load times.

For example, a user in Tokyo is accessing a website hosted in New York. Without a CDN, the user will experience many delays due to the physical distance.

With CDN, the user has the SSL/TLS handshake with the Tokyo edge server, and the content is also sent back by a Tokyo edge server. Overall, it will be a great experience.

SSL Session Reuse and Session Resumption

To mitigate the computational burden of completing the entire SSL/TLS handshake process, CDNs typically make use of SSL session reuse or session resumption.

This way, clients and servers can continue encrypted sessions without renegotiating all of the parameters. This is especially advantageous for repeat visitors or users who access multiple secure assets from the same domain.

As an intermediary for users and servers, CDNs cache session information and manage TLS handshakes intelligently across millions of requests, providing benefits with respect to performance and CPU utilization on both the client-side and server-side.

TLS False Start and 0-RTT Resumption

Modern CDNs are aware of, and deploy, many performance-based features related to SSL/TLS, e.g., TLS False Start and 0-RTT (Zero Round Trip Time) Resumption.

TLS False Start allows the sending of data before finishing the handshake, and removes milliseconds from each connection. 0-RTT Resumption (which is available in TLS 1.3), allows clients to immediately send encrypted data using parameters from a previous session.

0-RTT does present some security risks to applications (such as replay attacks), but usually CDNs implement it with additional security mechanisms that provide speed with some measure of protection.

Better Certificate Management

CDNs will take the complexity of SSL certificate deployment and management out of your hands. With a CDN service, you have the option for automatic certificate provisioning through Certificate Authorities (CAs), as well as some advanced capabilities such as:

OCSP Stapling - The CDN will respond to an OCSP request by providing the certificate revocation status, thus removing the necessity to call the CA and optimizing SSL handshake times.
Server Name Indication (SNI) - CDNs allow the use of multiple SSL certificates on a single IP, thus improving scalability.
Wildcard and SAN certificates - The need for Wildcard SSL certificates across a number of subdomains and multi-domain configurations can be reduced.

Support for HTTP/2 and HTTP/3

Older versions of protocols like HTTP/1.1 or older are less equipped to provide performance benefits than the newer HTTP/2 and HTTP/3.

When combined with SSL/TLS (which offers great performance benefits), HTTP/2 gains performance increases through multiplexing, while both HTTP/2 and HTTP/3 can reduce latency and use only one connection without head-of-line blocking (HTTP/2).

HTTP/3, built on top of QUIC, utilizes UDP to provide a faster and higher-performance connection that is also more reliable in mobile or lossy environments.

Most CDNs allow it to run HTTP/2 or HTTP/3 by default, so encrypted traffic flows using these methods, which provide speed for the CDN service.

Additionally, since HTTP/1.1, HTTP/2, and HTTP/3 can only run over encrypted channels (TLS/SSL), this allows these protocols to align even more with SSL/TLS to improve overall performance.

Reference

What is SSL and CDN? How CDNs Improve SSL / TLS Performance?

PKI vs PKI as a Service

Certera — Tue, 22 Jul 2025 06:50:35 +0000

Ever wondered how websites, emails, and digital transactions stay secure? That's thanks to Public Key Infrastructure (PKI), the system behind HTTPS, digital signatures, and secure logins.

Now, what's PKI-as-a-Service (PKIaaS)? It's a cloud-based way to manage PKI easily and securely. Misconfigurations in traditional PKI can cause issues like expired certificates or failed authentications. PKIaaS simplifies the process. Still confused? This post will clear it up.

Public Key Infrastructure

PKI is a set of tools and processes that help secure data transfers over the Internet. It is the most common way to manage identity and security within Internet communications.

It uses Digital certificates to protect people, devices, and Data. The digital certificates are issued by the Certificate Authority (CA), they are trusted organisation. To get a digital certificate, you have to go through a validation process that verifies the identity of the requester, which is done by a CA.

By integrating roles, policies, hardware, software, and processes, PKI serves as the industry benchmark for authentication and encryption. It is a very important component in the Zero Trust Architecture, which verifies the identity of devices and people on the internet or in digital communication.

The Digital certificates secure and encrypt the network traffic, helping in preventing malicious threat actors from intercepting sensitive information.

PKI as a Service (PKIaaS)

PKI as a Service (PaaS) is a cloud-based solution that helps companies manage digital certificates securely without having to set up and maintain their own Public Key Infrastructure (PKI).

It can handle the entire Public Key Infrastructure (PKI) lifecycle, from setting up a Certificate Authority (CA) to issuing, managing, and revoking end-entity certificates for users' devices or domains.

It provides many important features for organisations such as better flexibility, automated procedures, and decreased IT costs. It secures an organization's digital assets from malicious hackers by providing strong authentication, data encryption, and integrity.

Difference Between PKI as a Service and Traditional PKI

Here's a comprehensive comparison to help you decide which model best fits your business needs:

Deployment
- PKIaaS: Cloud-based and fully managed by a provider.
- Traditional PKI: On-premises setup that requires manual configuration and internal management.
Infrastructure Cost
- PKIaaS: Low upfront investment.
- Traditional PKI: High initial costs for servers, HSMs, and networking.
Operational Cost
- PKIaaS: Subscription-based with predictable pricing.
- Traditional PKI: High ongoing costs for maintenance and IT staffing.
Management
- PKIaaS: Managed by experts with minimal user involvement.
- Traditional PKI: Needs in-house experts to run and maintain.
Scalability
- PKIaaS: Easily scalable to meet growing needs.
- Traditional PKI: Scaling demands extra infrastructure and investment.
Security & Compliance
- PKIaaS: Meets major standards like FIPS, NIST, PCI-DSS, GDPR.
- Traditional PKI: Needs regular updates to stay compliant.
Certificate Lifecycle Automation
- PKIaaS: Automated issuance, renewal, and revocation.
- Traditional PKI: Manual handling increases error risk.
Availability & Reliability
- PKIaaS: High availability through cloud redundancy.
- Traditional PKI: Dependent on internal system uptime.
Time to Implement
- PKIaaS: Fast deployment, minutes to hours.
- Traditional PKI: Complex and time-consuming setup.
Customization
- PKIaaS: Limited.
- Traditional PKI: Highly customizable to specific needs.

Source