Much Ado About Certificates

It's all about TRUST

2026 will be the year of the certificate.

Why? Because the governing body that dictates certificate requirements for browsers has, in its infinite wisdom, decided that certificate lifetimes should be reduced to 47 days.

This won’t happen overnight, but step by step — and the end is nigh. The first milestone is a reduction to 200 days, starting in March 2026. This affects public TLS certificates, meaning those issued by a public Certificate Authority (CA).

I do a lot of work with certificates and PKI, and it’s one of those mysterious technologies that tends to be misunderstood. That’s why I’ve decided to publish a series of articles explaining the basics. Don’t worry — I’ll leave the boring math aside for now.

The first thing to understand about certificates is simple:

Certificates are about trust.

Let’s start there, by looking at the three levels of trust — from low to high.


Self-Signed Certificates

“Trust me, I’m a doctor!” is a famous line from Star Trek. That pretty much sums up self-signed certificates.

With a self-signed certificate, you can put any information you want into it. You’re both judge and jury: you define the contents, and you approve it yourself. If you don’t want the certificate to expire for another hundred years, that’s fine — you’re in charge.

Sounds great, right?

The downside is obvious: who will trust it?

Using a self-signed certificate is like walking through airport security with a piece of paper you printed at home with your name on it. You’ll be denied — and possibly detained.

So why use self-signed certificates at all? They make sense for testing, or when you fully control the environment. For example, securing TLS connections between two servers you own can be perfectly reasonable.

Anyone can choose to trust the certificate, but they’ll be greeted with plenty of warnings and “Are you really sure?” pop-ups.

Self-signed certificates are free and don’t require a full PKI infrastructure — but trust is entirely your responsibility.

Trust me, I'm a doctor

Internal Certificates

Internal certificates are a step up.

With self-signed certificates, trust has to be configured on each machine individually. There’s no central management and no automation. That doesn’t scale.

That’s why many organizations run their own internal PKI. Because they control the systems on their network, they can ensure that their internal Certificate Authority is trusted by every computer in the environment.

This allows them to issue certificates at scale, automate renewals, and centrally revoke certificates when something goes wrong.

Who does this? Usually the IT department.

While internal certificates are “free” in the sense that you don’t buy them from a vendor, they still have a cost: running and maintaining the infrastructure behind the CA. A common example is the Microsoft CA, which can be deployed as an Active Directory role.

Think of internal certificates as corporate ID badges. They’re valid inside the company — but outside, they don’t carry much weight.


Trusted only by your organization – Think of corporate IDs, as an example

Public Certificates

This is the gold standard.

Whenever you need certificates that must be trusted by everyone, they need to be issued by a public CA. Examples include DigiCert or Sectigo (commercial) and Let’s Encrypt (non-profit).

Operating systems and browsers ship with a root trust store: a list of CAs that are trusted by default. Any certificate issued by one of these authorities is automatically trusted.

With great power comes great responsibility. Public CAs are therefore tightly regulated. The rules are set by the CA/Browser Forum, which includes all major browser and operating system vendors.

So when they say, “TLS certificate lifetime will be 47 days,” that’s what will happen.

There is criticism of this process. Some argue that it lacks transparency or legitimacy. But anyone who has ever manually renewed a public TLS certificate for a website knows exactly what shorter lifetimes mean. Increased security but also more headaches, more work.

Think of public certificates as the equivalent of passports or national ID cards. Because of the strict security rules and regulations, these usually come at a cost – you pay per issued certificate.


There are more granular trust levels — such as Domain Validation and Organization Validation — even within public certificates. We’ll cover those in a future article.

So remember: Certificates are not just about encryption. They are about who you choose to trust, and under what conditions.

To be continued.

Veröffentlicht von Click Coach - Approach the Coach

I’ve been working in IT for over 20 years, mainly within the Microsoft world. Over the years, I’ve come across the same questions and problems again and again. On my blog, I share tips and tricks on all kinds of IT topics. It’s not meant for IT pros — but they’re welcome to read along too! 😊

Hinterlasse einen Kommentar