DEV Community: Fizee

Choosing an SSL certificate automation tool: acme.sh, Certimate, AWS ACM or a hosted service

Fizee — Wed, 07 Oct 2026 09:11:32 +0000

Every certificate automation tool issues certificates over ACME, and that part works much the same everywhere. This article compares acme.sh, Certimate and hosted services such as AWS ACM on three points:

Automatic renewal. Let's Encrypt certificates expire after 90 days, and since March 2026 commercial certificates are capped at 200 days, so renewing by hand will eventually slip. All the tools here renew automatically; the certificate services built into cloud providers have limits, covered further down.
How the renewed certificate is deployed, and where it can go. If the certificate only lives on one or two servers, a reload after renewal is enough and any tool can do it. Once the same certificate also has to reach a CDN, object storage or load balancers, you need a ready-made integration for each of them, or you write scripts against the cloud provider's API yourself. Deploying to cloud services also needs access keys, and some companies have a rule on whether those may leave their own servers.
What happens when a deployment fails. You want an alert that says which location failed, and on servers, a switch back to the old certificate if writing the files or the reload fails. Harder to catch is a location that was never configured: every tool only updates the locations it was given, and a missing one never produces a failure alert.

Deployment is where it went wrong for us. We have one *.example.com wildcard certificate deployed to two Nginx servers, several domains on Alibaba Cloud's DCDN, and custom domains on OSS, their object storage, all of which used to be updated by hand in each product's console. The sites that got missed were usually not the important ones: our sites have tiers, the important ones are monitored and alert on certificate errors, and some low-tier sites have no monitoring at all, so we heard from a user or a colleague, usually after the certificate had already expired.

acme.sh plus scripts

acme.sh is a good fit when the certificate only lives on one or two servers. Issuance, renewal and a reload after renewal are mature, and notifications can go to Slack, Telegram and many other channels.

Cloud services are a different story. acme.sh ships deploy hooks for a handful of CDNs and panels, plus a generic ssh hook, but nothing for AWS. Importing into ACM and pointing CloudFront or a listener at the new certificate is your own script.

Even where a hook exists, a wildcard certificate needs every target domain spelled out in a variable. Alibaba Cloud DCDN, for example:

export DEPLOY_ALI_DCDN_DOMAIN="www.example.com static.example.com"
acme.sh --deploy -d example.com --deploy-hook ali_dcdn

The variable is saved and reused after each renewal. When a new domain is added later and nobody comes back to update it, you are back to the forgotten site, just moved from a console into a config file.

We never put a script on our servers for a different reason: if it replaced something wrongly one day, we would not know, and that is worse than doing it by hand.

Certimate

Certimate is a self-hosted certificate dashboard, MIT-licensed and free. It runs as a single binary or Docker container, and you set up issuance and deployment in a web UI. It covers far more cloud services than acme.sh hooks, including AWS, Kubernetes, CDNs, WAFs and load balancers. Windows and IIS shops tend to use Certify The Web instead.

The cost of self-hosting is that the dashboard becomes one more service to run. Every cloud access key is stored on that machine, so it needs hardening. If the dashboard goes down, renewals and failure alerts stop together, so monitor it from outside as well.

If company policy does not allow cloud credentials to go to a third party, self-host, and use Certimate.

Hosted services

A hosted service runs issuance, renewal, deployment and alerts on the provider's side, so there is no server or dashboard of yours to maintain. Cloud providers have something similar for their own products: AWS Certificate Manager renews public certificates for load balancers, CloudFront and API Gateway at no cost, but those certificates cannot be copied onto your Nginx servers, and exportable ones are charged at every renewal.

If the certificate has to reach several servers and several cloud services and you do not want to run a dashboard, a hosted service fits, for example LapseZero. It issues certificates from Let's Encrypt (wildcards included), renews them 30 days before expiry by default, and deploys them to every configured location:

Cloud services: AWS CloudFront, ALB, NLB and API Gateway, plus Alibaba Cloud and Tencent Cloud CDN, load balancers and more.
Servers: over SSH, or through an open-source deployment agent that pulls jobs, so the server does not need SSH exposed.

When you add a cloud location, LapseZero uses your access key to list the CDN distributions, load balancer listeners and similar resources in the account, and you tick the ones to deploy to. Sites nobody checks show up in that list too, so it does not all rely on memory. Domains added later are not picked up automatically; you come back and tick them as well.

Each location has its own result, and failures are sent by email, Slack, Telegram or webhook. On servers, the old files are backed up first, and if writing the files or the reload fails, the server is switched back to the old certificate and the alert says how the rollback went.

The main hesitation with any hosted service is handing over cloud access keys, and with a service you have never used, we would hesitate too. Use an IAM user limited to the services you deploy to, and start with one or two low-stakes sites.

The free plan covers 3 domains and 5 deployment targets; the two Nginx servers plus one CDN domain and one storage domain above make 4. Paid plans start at $3 a month.

Expiry monitoring

A deployment reported as successful does not mean every site is serving the new certificate, and LapseZero does not visit the site after deploying to check. The never-configured location from the start of this article produces no failure alert either.

To close that gap, add every domain that uses the certificate to expiry monitoring, including the ones nobody looks at. A monitor only connects to the public HTTPS address and needs no credentials. LapseZero's certificate monitoring includes 5 sites on the free plan, or run your domains through the SSL certificate expiry checker once to see whether anything has already been missed.

How to Auto-Renew SSL Certificates on Tencent Cloud CDN and EdgeOne

Fizee — Mon, 05 Oct 2026 08:05:55 +0000

The Current Rules for Tencent Cloud Free Certificates

Since April 25, 2024, free certificates from Tencent Cloud's SSL Certificate Service have been valid for 3 months instead of 12, with a quota of 50 per account. They are single-domain DV certificates issued by TrustAsia, with no wildcard support. These rules come from the China site (cloud.tencent.com); the international site may differ.

The quota is generous. The number of replacements is what adds up. With a 90-day certificate replaced two or three weeks early, each domain needs a new certificate four or five times a year. For a domain on CDN, that means applying, waiting for validation, and swapping the certificate in the CDN console every time.

CDN and EdgeOne work differently, so they are covered separately below.

EdgeOne Only: Use Its Built-In Free Certificate

If your domain is already on EdgeOne, the simplest option is to choose "Apply for free certificate" in the domain's HTTPS settings. According to the official documentation, the certificate is issued by TrustAsia or Let's Encrypt, lasts 90 days, renews automatically 15 days before expiry, and deploys itself. There is nothing to maintain.

Its limits:

The certificate cannot be downloaded and only works on EdgeOne. If your origin or load balancer needs a certificate for the same domain, you have to get one separately.
Wildcard certificates require DNS delegation validation. After a site switches from NS access to CNAME access, its existing wildcard certificate cannot renew automatically.
With CNAME access and automatic validation, the domain must point its CNAME to EdgeOne within an hour, and split-horizon (per-line) DNS is not allowed.
No SLA. Certificates issued by Let's Encrypt do not support OCSP stapling.

If the certificate only ever lives on EdgeOne, none of this gets in your way. Use it and skip the rest of this article.

Tencent Cloud CDN: Certificate Hosting Only Handles Replacement

CDN has no one-click free certificate like EdgeOne. The usual flow is to get a certificate from the SSL Certificate Service and then deploy it to the CDN domain.

Tencent Cloud's certificate hosting covers half the work. Once enabled, when a new certificate is issued, it gets deployed at a time you choose to the cloud resources the old one was attached to, such as CDN and load balancers. Free certificates can be hosted too. The fully automatic setup in the docs is "auto-renewal plus hosting", and auto-renewal applies to paid certificates; the docs do not say that a free certificate will apply for its successor on its own. With free certificates, you still apply for a new one and complete validation every 90 days. Hosting only does the final swap.

Hosting has one more requirement: the old and new certificates must cover the same domains. Pick the wrong one and production is affected directly.

Writing Your Own Script

If you would rather not depend on the console, you can issue certificates yourself and deploy them through Tencent Cloud's API. Issuance is a solved problem: the dns_tencent plugin in acme.sh completes DNS validation through the DNSPod API and can get a wildcard certificate from Let's Encrypt.

Deployment is on you. The deploy directory in acme.sh has hooks for Alibaba Cloud CDN (ali_cdn.sh), Qiniu, and Baidu Cloud CDN, but none for Tencent Cloud. Calling the API yourself, you upload the certificate to the SSL Certificate Service to get a certificate ID, then bind it to CDN or EdgeOne:

# 1. Upload the certificate. With Repeatable=false, an identical certificate
#    is not uploaded twice; the existing ID is returned instead.
ssl.UploadCertificate
  CertificatePublicKey  = contents of fullchain.pem
  CertificatePrivateKey = contents of privkey.pem
  Repeatable            = false

# 2a. Tencent Cloud CDN: update only the certificate ID path
cdn.ModifyDomainConfig
  Domain = cdn.example.com
  Route  = Https.CertInfo.CertId
  Value  = {"update":"<certificate ID from step 1>"}

# 2b. EdgeOne: swap the certificate on the acceleration domain
teo.ModifyHostsCertificate
  ZoneId         = <zone ID>
  Hosts          = ["www.example.com"]
  Mode           = sslcert
  ServerCertInfo = [{"CertId":"<certificate ID>"}]

The CDN step is easy to get wrong. If you call UpdateDomainConfig with an Https object that contains only the certificate and private key, you run into this rule from the API documentation: for complex configuration items, "you must pass all properties of the object; properties not passed will use default values." In other words, HSTS, OCSP stapling, and TLS version restrictions that were enabled on the domain get reset to defaults on every renewal. ModifyDomainConfig updates a single path and leaves everything else unchanged, which makes it the safer call for swapping certificates.

Updating only Https.CertInfo.CertId assumes HTTPS is already enabled on the domain. If it is not, changing the certificate ID alone has no effect, and setting Https.Switch to on by itself is rejected because there is no certificate yet. In that case, set Route to Https and Value to {"update":{"Switch":"on","CertInfo":{"CertId":"<certificate ID>"}}}. Your script can check Https.Switch with DescribeDomainsConfig first and pick the right call.

Once the script works, you still need scheduling, retries, and alerting. Use a CAM sub-user for credentials, with permissions limited to DNSPod, SSL certificate upload, and CDN / EdgeOne configuration.

Ways to Stop Replacing Certificates by Hand

Option	Good for	Cost
EdgeOne free certificate	EdgeOne only	No download, wildcard limits
SSL Service + hosting	Certificates on Tencent only	Free certs still applied by hand
acme.sh + your own script	Teams happy to own code	Deploy, retry, alerts all on you
Self-hosted Certimate	Fully open source setups	You deploy, upgrade, back up
Hosted automation service	Nothing to maintain	Cloud credentials held by them

Certimate is an MIT-licensed open-source project. Once self-hosted, it issues certificates and deploys them to Tencent Cloud CDN, EdgeOne, CLB, COS, and more, along with Alibaba Cloud and other providers. Certificates, private keys, and cloud credentials stay on your own server; the trade-off is that you maintain that server and Certimate itself.

With only one or two CDN domains, replacing certificates by hand looks manageable. But four or five times a year, someone has to remember every time, and eventually nobody will. If you can automate it for free, it is worth setting up even for a few domains.

Auto-Renewing and Deploying to Tencent Cloud with LapseZero

LapseZero is a hosted certificate automation service. It issues certificates from Let's Encrypt, renews them before expiry, and deploys them to cloud products on Alibaba Cloud, Tencent Cloud, and AWS, or to your own servers. On Tencent Cloud it currently supports CDN, EdgeOne, and HTTPS listeners on CLB load balancers.

Add the domain. If DNS is on DNSPod, provide keys for a CAM sub-user with DNS permissions only, and the platform writes the validation records. If you would rather not hand over DNS access, use DNS delegation, which only needs CNAME records added once, when you add the domain. The differences are covered in HTTP-01 vs DNS-01 vs DNS delegation.
Issue the certificate. Wildcards are supported, and Tencent Cloud's 50-certificate quota is not touched.
Add deploy targets. The platform lists the CDN domains and EdgeOne acceleration domains in your account; select the ones that match the certificate. The same certificate can go to CDN, CLB, and your own servers at once.
Renew automatically. By default it renews 30 days before expiry and deploys to every target after issuance. Each target's result is recorded separately, and failures are sent to you by email, Slack, Telegram, or other channels.

Two things to know. A successful deployment means Tencent Cloud's API accepted the new certificate; the platform does not visit the domain afterwards to confirm it is live, and CDN edge nodes take time to pick it up, so check it a little later with the SSL certificate expiry checker. Your cloud credentials are stored by the platform, so use a CAM sub-user with minimal permissions. The free plan includes 3 domains and 5 deploy targets.

Certificate lifetimes keep shrinking: from March 15, 2027, every public certificate maxes out at 100 days, and 47 days from 2029, paid certificates included. See 47-day SSL certificates.

47-Day SSL Certificates: Renewing More Often Without Breaking Production

Fizee — Mon, 05 Oct 2026 03:27:34 +0000

From March 15, 2029, a publicly trusted SSL certificate can be valid for at most 47 days. The step before that, 100 days, starts on March 15, 2027, and the first step is already behind us: certificates issued since March 15, 2026 are capped at 200 days.

A certificate you used to replace once a year will need replacing at least 4 times a year in 2027 and roughly every month in 2029. Every replacement ends with a reload, and a reload is exactly the operation most people running servers would rather not do often.

The schedule

The CA/Browser Forum adopted Ballot SC-081v3 in April 2025. Every publicly trusted CA has to follow it, so paid certificates are affected too:

Effective	Max validity	Validation reuse
2026-03-15	200 days	200 days
2027-03-15	100 days	100 days
2029-03-15	47 days	10 days

The third column gets less attention. Once a CA has validated that you control a domain, it can reuse that result for a while instead of validating again for the next certificate. By 2029 that window is 10 days, so almost every certificate will need fresh domain validation. If you still buy certificates and validate them by email or by uploading a file, you will be doing that every month.

When it was once a year, the problem was remembering

A yearly renewal is hard to schedule. Set a phone reminder for a year from now and there is a fair chance you will have a different phone by then. Calendars and ticket queues are not much better, since a year is long enough for the person who owned the task to move on.

If you relied on Let's Encrypt's expiry emails as a safety net, those stopped on June 4, 2025.

So expiry is often discovered by users. A pattern we ran into fairly often: customers on our mobile client reported a "network error" and nothing mentioned certificates. Native apps and embedded webviews often hide TLS failures behind a generic message like that. The server logs had no record of those requests at all, because the client gave up during the TLS handshake and never reached Nginx.

When a client reports network errors and your server logs show nothing, check the certificate first:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Or run the domain through the SSL certificate expiry checker without logging in to anything.

At 100 days, the problem is the reload

We used to run most certificates directly on cloud VMs and later moved many of them to a CDN. Swapping a certificate on a CDN is an upload. No SSH, no service restart.

On a server, the uncomfortable part is the reload, for two reasons:

You are not sure whether someone changed the Nginx config since the last reload. A broken config sits there quietly until the next reload, and that reload happens to be the one you ran to swap a certificate.
Some servers have not been touched in months. Reloading or restarting them out of the blue is the kind of thing that surfaces problems nobody knew about.

Once a year, you can live with that risk. At 100 days, every server faces it 4 or 5 times a year; at 47 days, every month. The CA/Browser Forum's reasoning is sound: revocation does not work well in practice, so a shorter lifetime limits how long a leaked key stays useful. For the people doing the swaps, it is still more work and more risk.

Why many admins still swap by hand

Plenty of people decide not to script it, and their reasons are specific:

Servers and configs change over time. A script that was not updated along with them can do more damage than a manual swap.
When you swap by hand, you know when it happened and you test it yourself afterwards. A script can fail at 3 a.m. when nobody is around to deal with it.

These concerns are fair. The tooling for issuance and renewal is mature: certbot and acme.sh renew on a schedule and can run a reload hook, Caddy handles certificates on its own, cert-manager renews them inside Kubernetes, and AWS Certificate Manager renews the certificates it issues for services like CloudFront and ALB. If everything you run fits one of these, you may not need anything else.

The gaps show up with a mix of servers and cloud services. certbot has no failure notifications, and acme.sh has notification hooks you have to configure yourself. Pushing a certificate to a CDN or load balancer outside those integrations usually means writing your own script against the provider's API, and that script is exactly the part that breaks when the environment changes.

Doing it by hand is a reasonable choice today. At 100 days the number of manual swaps stops being manageable, so automation has to win the same trust the manual process has.

The bar for automation: it can fail, but it must not touch production

The standard we hold automation to is a single rule: it can fail, but it must never take production down. Either the swap succeeds completely, or nothing changes.

A failed issuance or a failed deploy is fine. If certificates renew 30 days before expiry, a failure leaves weeks to fix it, and a failure at 3 a.m. is just a message to read in the morning. What is not fine is a half-finished swap that breaks the live service.

Services only reread certificate files on reload or restart. That means a deploy cannot hurt production as long as you do the following:

Before replacing anything, confirm the new certificate and private key match.
Back up the old files, then overwrite in place. Writing with cat > keeps the file's owner, permissions, and symlinks; writing a temp file and mv-ing it over the original replaces all three.
Run nginx -t before reloading. If the check fails, restore the old files and skip the reload.
Make sure a failure reaches a person.

If you swap certificates on your own servers, this script is a starting point:

#!/usr/bin/env bash
set -euo pipefail

CERT=/etc/nginx/ssl/example.com.pem
KEY=/etc/nginx/ssl/example.com.key
NEW_CERT=$1
NEW_KEY=$2

# The certificate and the key must share the same public key
if [ "$(openssl x509 -noout -pubkey -in "$NEW_CERT" | openssl sha256)" != \
     "$(openssl pkey -pubout -in "$NEW_KEY" | openssl sha256)" ]; then
  echo "Certificate and key do not match, nothing changed" >&2
  exit 1
fi

cp -a "$CERT" "$CERT.bak"
cp -a "$KEY" "$KEY.bak"

if cat "$NEW_CERT" > "$CERT" && cat "$NEW_KEY" > "$KEY" \
   && nginx -t && systemctl reload nginx; then
  echo "Replaced"
else
  cat "$CERT.bak" > "$CERT"
  cat "$KEY.bak" > "$KEY"
  echo "Replacement failed, old certificate restored" >&2
  exit 1
fi

The script exits non-zero on failure. Pair it with cron's MAILTO, or post to a Slack or Telegram webhook in the else branch, and someone will hear about it. For services that need a restart, such as Tomcat, restart again after restoring the old files, or the service stays down.

Managed services are simpler. On CloudFront, for example, the new certificate is imported into ACM first, and the distribution switches to it in a single update call. If that call fails, the distribution keeps serving the old certificate, so there is no half-swapped state.

If you would rather not maintain the script

You can hand it to LapseZero. It issues certificates from free CAs such as Let's Encrypt, renews them before they expire, and deploys them to your servers or to AWS, Alibaba Cloud, and Tencent Cloud services such as CDNs and load balancers.

On servers, it does roughly what the script above does: back up the existing files, write everything before running the post-deploy command, and restore the old files if a write fails. If the post-deploy command fails, it restores the files and runs the command once more to bring the service back on the old certificate, then tells you "rolled back, the old certificate is still live" and waits for you to check the cause before retrying. Including nginx -t in the post-deploy command is recommended here as well.

Confused by DV, OV, and EV SSL Certificates? This Article Will Clear It All Up

Fizee — Thu, 18 Jun 2026 08:33:10 +0000

First, Let's Clarify What SSL Certificates Actually Do

Before diving into DV/OV/EV, let's quickly run through the basics of SSL certificates.

An SSL certificate (technically called a TLS certificate today, though "SSL" stuck) serves two core purposes:

1. Encrypting communication: It turns the data traveling between your browser and the server into ciphertext — unreadable and untamperable by anyone in the middle.

2. Proving identity: It tells users "this website really is who it claims to be," rather than a phishing site pretending to be it.

Every SSL certificate handles the first job.

The second job is where DV, OV, and EV diverge — their core difference lies in how rigorously identity is verified.

DV Certificate: Proves You Own the Domain

DV = Domain Validation.

The CA (Certificate Authority) verifies exactly one thing: whether you control the domain.

How? Typically one of the following:

Adding a specific TXT or CNAME record to your DNS
Placing a specific verification file in your website's root directory
Clicking a confirmation link sent to admin@yourdomain.com

The whole process is fully automated — done in minutes, or at most a few hours. The CA doesn't care who you are, what your company is called, or whether you have a business license. All that matters is proving you control the domain.

What a DV Certificate Looks Like

In the browser address bar, a site with a DV certificate shows a small padlock icon (exact appearance varies by browser version). Clicking it shows the certificate details — but you'll only see the domain name. No organization or company name is listed.

The Limitation of DV

A DV certificate cannot prove which company owns the site — only that someone controls the domain. A bad actor could register ba1du.com (with the number 1, not the letter i), get a DV certificate, and the browser will still show a padlock and HTTPS. That doesn't stop it from being a phishing site.

So remember: a padlock ≠ trustworthy site. It only means the connection is encrypted.

OV Certificate: Verifies Your Organization Actually Exists

OV = Organization Validation.

Before issuing an OV certificate, the CA verifies domain control and also checks your organization:

Whether the business or organization genuinely exists (typically via business registration records)
Whether the organization name matches what was submitted
Usually includes a phone verification as well

This process requires human review and typically takes 1–3 business days.

What an OV Certificate Looks Like

The padlock in the browser address bar looks identical to a DV certificate — ordinary users can't tell the difference at a glance. But inside the certificate details, the Subject field includes the organization name (O field), such as O = Example Inc.

Wait — if it looks the same to users, how can they tell?

Honestly… most users can't, which is one reason OV gets criticized as "not worth it" by some. OV's value is more about a company's internal compliance requirements and is mainly meaningful to technical staff or auditors.

EV Certificate: The Strictest Verification (and That Historic Green Bar)

EV = Extended Validation.

EV is the most rigorous of the three. The CA conducts a thorough background check:

Verifying the company's legal entity information
Confirming the organization's operating address
Confirming the applicant is authorized to act on behalf of the organization
Cross-checking various official databases

The entire process can take days to weeks, and it's the most expensive option.

A Bit of History: The Green Address Bar That Disappeared

If you were around the internet circa 2015, you might remember how some bank and payment websites had a green address bar that displayed the company name — something like PayPal, Inc. [US] right there in plain sight. Very noticeable.

That was EV certificates' signature visual treatment.

Starting in 2019, however, Chrome, Firefox, and Safari all dropped the green EV address bar. The reason was straightforward: research showed users simply didn't notice it, and it offered almost no real benefit against phishing.

Today, EV certificates look the same as OV in the browser — just a padlock. You need to open the certificate details to see the fuller organization information.

Is EV Still Worth Buying?

This is an ongoing debate in the security community. My take:

If your business has specific regulatory compliance requirements that explicitly call for EV (as some financial industry regulations do), then yes, get it.
If you just want to "appear more secure" or "build user trust," that argument has been pretty weak ever since the green bar went away.

Side Note: IP Certificates

Now that we've covered DV/OV/EV, let's quickly touch on another type of certificate that doesn't come up as often — the IP certificate.

What Is an IP Certificate?

Regular SSL certificates are issued to domain names, like example.com. But sometimes a service has no domain name — only a public IP address, like https://1.2.3.4. If you want HTTPS in that case, you need an IP certificate (also called an IP SAN certificate).

When Would You Need One?

Internal services or device management dashboards accessed directly by IP, with no domain name
IoT devices — many embedded devices only have an IP
Certain B2B integrations that communicate directly via IP

Comparison: All Four Certificate Types

	DV	OV	EV	IP Certificate
Full name	Domain Validation	Organization Validation	Extended Validation	IP Address Certificate
Issued to	Domain name	Domain name	Domain name	Public IP address
What's verified	Domain control	Domain + organization legitimacy	Domain + org + strict legal review	IP control (optionally + organization)
Issuance speed	Minutes to hours	1–3 business days	Days to weeks	Depends on validation level
Cost	Free or very cheap	Moderate	Expensive	Moderate

Common Misconceptions

Misconception 1: "Free certificates are less secure"

Wrong. Free DV certificates use the same encryption strength as paid ones, and many major companies rely on them. The difference between free and paid is validation level and commercial support, not encryption strength.

Misconception 2: "An EV certificate makes my website more secure"

Not quite. EV improves identity trustworthiness, not server security. If your server code has vulnerabilities, no certificate can fix that.

Misconception 3: "The HTTPS padlock means a site is trustworthy"

This is the most dangerous misconception. The padlock only means the connection is encrypted — not that the site's content or operators are trustworthy. Phishing sites can have HTTPS too.

So Which Should You Choose?

Here's a simple decision tree:

Your service has no domain name — only an IP address?
  → You need an IP certificate (public IPs only)
  → For private IPs (192.168.x.x / 10.x.x.x), consider a self-signed cert or internal CA

If you have a domain, keep reading:

  Personal project or small team, not handling finance/medical/sensitive data?
    → DV is fine. Use Let's Encrypt for free.

  A business with a public-facing brand and services?
    → OV is the safer, more professional choice.

  Explicit compliance requirement calling for EV (it's in your regulatory docs)?
    → Then go with EV.

  Still not sure? Honestly, DV is probably enough — same encryption strength,
  free, and easy to manage.
  With CertFlow you can also automate renewal and deployment so you never
  have to worry about it again.

In short, DV, OV, and EV each have their place. Which one you need depends on your business requirements and compliance obligations — not on encryption strength. Hope this article helps you finally tell them apart!

If you'd like a deeper look at SSL certificate purchasing and deployment, check out our earlier piece on Free vs. Paid SSL Certificates for a more detailed comparison and hands-on guidance.

If you want a free certificate with automatic renewal, auto-deployment, and expiry alerts all taken care of, CertFlow handles everything — give it a try!

Apply, Renew, and Monitor SSL Certificates for Free with CertFlow

CertFlow supports free issuance of single-domain and wildcard SSL certificates, with automatic renewal, auto-deployment, and expiry monitoring alerts. Built for individual developers, small teams, and multi-subdomain projects.

Get Started with CertFlow

HTTP-01, DNS-01, and DNS Delegation: What's the Difference When Getting an SSL Certificate?

Fizee — Thu, 18 Jun 2026 08:32:49 +0000

First-timers applying for an SSL certificate almost always get stuck at this step — picking a validation method. The UI shows HTTP-01, DNS-01, and sometimes DNS delegation. Three options, no explanation. Which one do you click?

What Does "Validation" Actually Mean?

Applying for an SSL certificate is essentially telling an organization called a CA (Certificate Authority): "This domain is mine — please issue me a certificate."

But the CA doesn't know you. It needs you to prove that you actually control the domain. Validation is how that works: the CA gives you a challenge to complete, and once you complete it, the CA trusts that you own the domain.

HTTP-01 and DNS-01 are two different types of challenges. DNS delegation is more of a helper strategy built on top of DNS-01. Let's go through each one.

HTTP-01: Drop a File on Your Web Server

How It Works

The CA says: "Put a file with specific content at http://your-domain/.well-known/acme-challenge/, and I'll go fetch it. If I get the right response, you're verified."

You put the file in place, the CA makes an HTTP request to that URL, gets the expected content, and the certificate gets issued.

Pros

Straightforward — as long as you control the web root, just drop a file
No DNS changes needed, no DNS access required

Limitations

Your server must be publicly accessible on the internet
Only works for single domains — no wildcard certificates (e.g. *.example.com)
Can be unreliable in certain network environments, since most CAs are overseas; restricted networks like government clouds may block or slow down the HTTP request, causing validation to fail

Who It's For

Websites hosted on a public-facing server, where you don't need a wildcard cert and don't have access to manage DNS.

DNS-01: Add a TXT Record to Your DNS

How It Works

The CA says: "Add a TXT record to your domain with this specific value, and I'll look it up in DNS. If it's there, you're verified."

You go into your DNS management panel (Cloudflare, Route 53, GoDaddy, etc.) and add:

_acme-challenge.your-domain.  TXT  "the-random-value-from-CA"

The CA queries DNS, finds the record, and validation passes.

Pros

Your server doesn't need to be publicly accessible — works for internal/private servers
Supports wildcard certificates — something HTTP-01 can't do
Generally more reliable — DNS propagation is more predictable than HTTP requests across varied network environments

Limitations

You need access to manage DNS for the domain

Who It's For

Anyone who needs a wildcard certificate, runs servers on a private network, or doesn't want to expose port 80.

Side by Side

	HTTP-01	DNS-01
Where you act	Drop a file on your server	Add a TXT record in DNS
Server needs public internet	Yes	No
Wildcard certificate support	❌	✅
Network sensitivity	Higher — especially when CA is overseas	Lower — DNS lookups are generally stable
Technical complexity	Higher — requires server config, open ports, redirect handling	Lower — just a DNS record change

DNS Delegation: Taking DNS-01 Further

Now that we've covered both validation methods, let's talk about DNS delegation — this is not a third validation method. It's an enhancement built on top of DNS-01.

DNS-01 itself isn't complicated, but if you want automatic renewal, your tooling needs to be able to write a new TXT record every time the certificate renews — which means it needs API access to your DNS provider.

That's where two real-world problems come up.

Not every DNS provider has an API. A lot of domains are hosted with smaller or older providers that simply don't offer one. That means every renewal requires manually logging into the DNS panel and updating the record — every 90 days, without fail. Easy to forget, easy to mess up.
Even if your provider has an API, the access scope is too broad. Your main domain's DNS controls everything — all your subdomains, mail records, the works. Handing that API key to a cert tool means the tool could theoretically modify any record on your domain. If the key leaks or the tool misbehaves, the entire domain's DNS is at risk.

DNS delegation exists to solve both problems at once.

How DNS Delegation Solves This

You create a dedicated subdomain just for ACME validation:

_acme-challenge.example.com

Then, in your main domain's DNS, you add a CNAME pointing that address to a separate, purpose-built DNS zone — one with tightly scoped permissions:

_acme-challenge.example.com.  CNAME  _acme-challenge.example.com.acme-dns.io

From that point on, all ACME TXT records get written to that dedicated zone. When the CA queries _acme-challenge.example.com, it follows the CNAME and finds the right TXT record. Validation passes.

Why This Is Better

Your main DNS only needs one CNAME added once — never touched again, no matter how many times the certificate renews
The API key your cert tool holds is scoped only to that small dedicated zone — even if it leaks, the damage is limited to that one validation subdomain
It doesn't matter what provider hosts your main DNS, or whether it has an API at all — the validation side runs on its own API-capable service independently

A practical example: CertFlow supports DNS delegation — configure it once and it handles automatic renewals without ever needing access to your main DNS again.

Who It's For

You want automatic renewal but your main DNS provider doesn't offer an API
Your provider has an API, but you don't want to hand over full DNS access to a cert tool
You're managing renewals across multiple domains and want a unified, lower-risk setup

So Which One Should You Use?

These aren't mutually exclusive — pick based on your situation:

Need a wildcard certificate → Must use DNS-01 or DNS delegation
Have DNS access → DNS-01 is simpler and more reliable
No DNS access → HTTP-01 is your only option, but watch out for network issues and server configuration gotchas

Once you understand what's actually happening under the hood, the choice stops being confusing.

If you want to learn more about choosing and deploying SSL certificates, check out our earlier post on free vs. paid SSL certificates for a more detailed breakdown.

And if you want to get a free certificate with automatic renewal, auto-deployment, and expiry alerts all in one place, CertFlow has you covered.

Apply, Renew, and Monitor SSL Certificates for Free with CertFlow

Get Started with CertFlow

What's the Difference Between Free and Paid SSL Certificates — and Why Do Prices Vary So Much?

Fizee — Thu, 18 Jun 2026 08:26:30 +0000

When people first encounter SSL certificates, they often ask the same question:

If a free SSL certificate can already make a website HTTPS and browsers show it as a secure connection, why do paid SSL certificates exist — some costing hundreds or even thousands of dollars?

Is there actually a security difference, or is it just brand markup?

In most cases, free and paid certificates are equally effective at encrypting communications. Whether data gets encrypted when a user visits your site depends primarily on the TLS protocol, cipher suites, server configuration, and whether the certificate is trusted by mainstream browsers and operating systems.

In other words, whether a certificate is free or paid does not directly determine the strength of HTTPS encryption.

The real differences come down to four things.

1. Validation Level

The most common free SSL certificates are DV certificates — Domain Validation certificates.

What they verify is simple: do you control this domain?

If you can add a specific DNS record or place a specific file in your web directory, the certificate authority can confirm you have control over the domain and issue the certificate.

But a DV certificate does not verify which company or organization is behind the domain. It does not check whether the company is real, whether the business address is accurate, or whether the brand entity is consistent.

Paid certificates commonly include OV and EV options, which add organization identity verification.

OV verifies the business or organization identity. EV applies a stricter standard — typically cross-checking company registration information, business entity details, and authorization relationships.

So DV is essentially saying: "This domain is under your control."

OV/EV goes further: "The organization behind this domain has also been verified."

This is the first source of the price difference between free and paid certificates: paid certificates are not just selling encryption — they include a more complete identity verification process.

2. Trust Endorsement

EV certificates used to have a prominent selling point: browsers would display the company name in the address bar, sometimes even showing a green bar.

Today, mainstream browsers have largely removed these visual indicators. Most ordinary users just see HTTPS and a browser security indicator, and rarely distinguish between DV, OV, and EV.

This is why free DV certificates are typically sufficient for personal websites, blogs, standard SaaS dashboards, and API services.

But in certain contexts, OV/EV still carries real value.

In finance, e-commerce, payments, government or enterprise partnerships, procurement processes, or websites at high risk of brand impersonation — customers, partners, or compliance teams may require organization-validated certificates.

In these cases, the value of a paid certificate is not "stronger encryption." It is "stronger identity endorsement."

It solves a trust and compliance problem, not a purely technical encryption problem.

3. Service and Support

Free certificates typically rely on automation tools and community ecosystems.

The advantages are clear: free, open, fast to issue, and ideal for technical teams doing automated deployments.

Paid certificates, however, usually include commercial services — human support, enterprise accounts, bulk management, invoicing, contracts, refund policies, site seals, warranty coverage, or indemnification clauses.

These may not matter much to individual developers.

But for some organizations, they are part of the procurement process and risk management framework.

For example: internal policy may require vendors to provide contracts and invoices; clients may require enterprise-validated certificates; operations teams may want a clear support contact when something goes wrong.

So part of what you pay for with a paid certificate is commercial service, procurement process support, and accountability commitments.

Whether those commitments are actually valuable for your situation depends entirely on your context.

4. Coverage Scope

Certificate pricing is also affected by coverage scope.

Protecting a single domain is naturally a different cost than protecting multiple domains or multiple subdomains simultaneously.

Common certificate types include:

Single-domain certificates, which protect one specific domain.

Wildcard certificates, which protect multiple subdomains under a single level.

Multi-domain (SAN) certificates, which include multiple distinct domains on a single certificate.

Protecting just example.com is a different management challenge from simultaneously protecting api.example.com, admin.example.com, and www.example.com.

But there is also a common misconception here:

Not every multi-domain or multi-subdomain scenario requires purchasing an expensive certificate.

In many cases, by thoughtfully splitting certificates, using DNS validation, and integrating ACME-based automated issuance, you can keep certificate costs very low.

Conclusion

The difference between free and paid certificates is not, fundamentally, a difference between "secure" and "insecure."

Free certificates have primarily lowered the barrier to adopting HTTPS.

The value of paid certificates lies mostly in identity verification, commercial support, and procurement compliance.

A Certificate Doesn't End When It's Issued

In real-world operations, there is another problem that gets overlooked far too often:

A certificate does not end when it is purchased or issued.

The real headache is what comes after.

When does the certificate expire?

Did the renewal succeed?

If renewal fails, is there an alert?

Was the certificate deployed to the correct server?

Will you get a reminder before a certificate expires?

These are the actual source of most HTTPS incidents.

Especially now that certificate validity periods are shrinking — the industry is broadly pushing toward shorter renewal cycles.

This is good for security: the shorter the validity period, the lower the long-term risk from key compromise or misconfiguration.

But for operations teams, it means certificate renewals happen more frequently, and the risk of manual management failures increases accordingly.

If a team only has one or two domains, handling renewals manually may still be manageable.

But if you have dozens of domains, multiple environments, several servers, multiple cloud providers, and multiple CDNs — relying on spreadsheets, calendar reminders, and manually logging into consoles to update certificates is a recipe for things going wrong.

So in my view, talking about SSL certificates today cannot stop at "free vs. paid."

The more important questions are:

Is your renewal process automated?

Is your certificate deployment automated?

Can your monitoring and alerting catch problems before they affect users?

This is exactly why we built CertFlow.

CertFlow is not trying to simply tell you "whether to use a free or paid certificate." It is about making certificate issuance, renewal, deployment, and monitoring genuinely simpler.

For many small and medium teams, independent developers, and solo product builders, the most practical first step is actually straightforward:

Can I get a free certificate?

Can I get a free wildcard certificate?

Can I get an alert before my certificate expires?

These are exactly the problems CertFlow is focused on solving first.

Through CertFlow, you can more easily apply for and manage free SSL certificates, including single-domain and wildcard certificates.

Beyond certificate issuance, CertFlow also provides free certificate monitoring.

You can add your existing website certificates to monitoring, and get early warnings about certificates nearing expiration, certificate anomalies, or deployment inconsistencies — before users see errors or API calls start failing.

For many teams, the certificate itself may be free, but the outage caused by a certificate expiring is not.

A single HTTPS failure can mean lost users, failed API calls, broken payment callbacks, or an emergency at 2 a.m.

So CertFlow aims to get the most fundamental, most common, and most easily overlooked things right:

Free SSL certificate issuance.

Free wildcard certificate issuance.

Free certificate status monitoring.

Early warnings for certificate risk.

Turning certificate management from "something you remember to do" into "something the system continuously handles."

Apply, Renew, and Monitor SSL Certificates for Free with CertFlow

Get Started with CertFlow

What's the Difference Between SSL Certificate CA Brands — and Why Do Prices Vary So Much?

Fizee — Sun, 31 May 2026 09:58:22 +0000

You open your browser, visit a website, and see a little padlock 🔒 in the address bar. You know it means "secure" — but have you ever wondered who gets to decide that?

The answer is: a CA.

What Is a CA?

CA stands for Certificate Authority. Its job is simple: vouch for your website and tell browsers "this site is legitimate, not a phishing page."

When you need something officially notarized, you go to a government-recognized notary — you can't just write a note saying "I certify that I'm trustworthy." SSL certificates work the same way. They have to be issued by a CA that browsers and operating systems already trust. Without that, browsers throw up a red warning and your visitors run.

Getting onto that trusted list is no small feat. Chrome, Firefox, and Safari each maintain a root certificate trust store, and getting in requires passing rigorous security audits, complying with international standards (like those set by the CA/Browser Forum), and undergoing regular third-party reviews. Only then does a CA's certificates actually work.

There are only a few dozen CAs trusted by major browsers worldwide. DigiCert, Sectigo (formerly Comodo), GlobalSign, and Entrust are among the largest by market share. China has WoSign, but after being caught mis-issuing certificates, it was removed from Mozilla's and Apple's trust lists in 2016. They've since made changes, but it's worth double-checking compatibility before using them.

So What Actually Differs Between CAs?

If all CA-issued certificates are trusted by browsers, does it matter which one you pick?

It does. Here's where they actually differ:

How Rigorous Is the Validation?

SSL certificates come in three validation levels — DV, OV, and EV. I covered the differences in detail in a previous post, so I won't repeat it all here.

The short version: DV only verifies domain ownership and takes minutes; OV confirms your organization actually exists and takes a few days; EV is the most thorough and can take a week or two.

What's less obvious is that different CAs apply these standards with different levels of strictness. Two CAs can both offer OV certificates — one might approve you after a quick phone call, another might require notarized documents. That affects the certificate's credibility, which is why larger enterprises tend to stick with established CAs whose audit track record is well-documented.

Has the CA Ever Had a Security Incident?

A CA's entire value is built on trust — and when that trust breaks, the consequences are severe.

There are real cautionary tales. Dutch CA DigiNotar was hacked in 2011, fraudulent certificates were issued at scale, and the company was wiped from every browser's trust list and went out of business shortly after. WoSign, mentioned above, was removed for rule violations.

When evaluating a CA, it's worth checking how long they've been around, whether they've had any major incidents, and whether they've ever been sanctioned by browser vendors. Established names have a longer track record to scrutinize — which is usually a good thing.

Root Certificate Coverage

This is a slightly more technical difference: whether a CA's root certificate is pre-installed across all major devices.

Major CAs got their root certificates into Windows, macOS, iOS, and Android trust stores early — so compatibility is essentially universal. Newer or smaller CAs may not be in every legacy system yet. If that happens, visitors to your site will see a certificate warning even though you paid for a valid cert.

For most use cases this isn't an issue — the mainstream CAs are fine. But if your users are on older hardware, legacy operating systems, or embedded devices, this is worth checking carefully.

So Why Do Prices Vary So Much?

With that background, the price differences start to make sense.

The same DV certificate is free from Let's Encrypt, costs around ¥199/year from some domestic platforms, and can run over ¥1,000/year from DigiCert. Same encryption, same browser trust — what are you actually paying for?

Brand Value and Procurement

DigiCert and GlobalSign carry real weight in enterprise procurement, compliance audits, and financial regulation. When a large company buys an SSL certificate, finance needs to log the vendor, IT needs documentation, and legal needs to sign off on supplier qualifications.

You're not just buying a certificate — you're buying a brand name that can go on a purchase order.

From an individual's perspective this might look like a premium for nothing. In enterprise procurement, it's a genuine requirement.

Warranty Coverage

Many paid certificates include a commercial warranty. If a certificate-related issue — say, a CA private key compromise leading to a fraudulent cert — causes losses for users, the CA promises to pay up to a certain amount.

DigiCert's premium certificates go up to $1.75 million. Entry-level Sectigo might cover $10,000. Let's Encrypt: $0.

These warranties are rarely invoked in practice, but in finance, healthcare, and other risk-sensitive industries, that number gets taken seriously.

Support and SLA

Have an issue with Let's Encrypt? Post on the community forum and wait for a volunteer to respond.
Have an issue with DigiCert? Call them. There's a dedicated support team, and response times are written into the contract.

A significant chunk of what enterprise customers pay for is the assurance that if something breaks, someone is accountable.

Additional Features

Higher-priced certificates often bundle extras: certificate lifecycle management platforms, automation APIs, multi-domain and wildcard support, dedicated monitoring services. These matter when you're managing hundreds of certificates across an organization.

A Few Common Brands at a Glance

Brand	Positioning	Notes
Let's Encrypt	Free, nonprofit	Free DV only; 90-day certs require auto-renewal; no commercial support; backed by ISRG
ZeroSSL	Free + paid	Similar to Let's Encrypt; paid plans offer longer validity and email support
Sectigo (formerly Comodo)	Best value	Largest market share globally; affordable; full DV/OV/EV lineup
DigiCert	Enterprise, premium	Most expensive; best support; preferred by financial institutions and governments
GlobalSign	Enterprise, mid-to-high	Popular with European enterprises; thorough compliance documentation
Entrust	Enterprise / government	Widely used by North American government agencies; includes identity and document signing

Which One Should I Actually Buy?

One common myth first:

"More expensive certificates have stronger encryption."

No. Whether you spend $30 or $300, the encryption algorithms (TLS 1.3, AES-256) are identical — they're negotiated between your server and the browser during the handshake, and have nothing to do with which CA signed the cert.

What you're actually paying more for: stricter identity verification, brand credibility, warranty coverage, and a support team that picks up the phone.

From a pure encryption standpoint, Let's Encrypt and DigiCert are on equal footing.

Here's how to think about your actual choice:

Need compatibility with old devices or legacy systems → Go with DigiCert or GlobalSign. Their root certificates have been in major trust stores the longest and have the broadest coverage — least likely to have issues with Windows XP, older Android versions, or embedded devices.
Have compliance or audit requirements → DigiCert or GlobalSign OV/EV. Financial regulators, cybersecurity certifications like SOC 2, and similar audits often scrutinize your CA choice — a recognizable name makes that conversation easier.
Just need HTTPS with no special requirements → Let's Encrypt is completely sufficient. Free, broadly compatible, just make sure you configure auto-renewal for the 90-day expiry.

The other dimension is certificate type — DV, OV, or EV. I covered that in detail in a previous post if you want to dig in.

And if you want free certificates with automatic renewal, auto-deployment, and expiry alerts all handled for you, CertFlow takes care of the whole certificate management headache.