alt.hn

3/23/2026 at 3:25:04 PM

Cyber.mil serving file downloads using TLS certificate which expired 3 days ago

 https://www.cyber.mil/stigs/downloads

by Eduard

3/23/2026 at 4:22:38 PM

This is kind of amazing. I'm suspicious that the site operator has absolutely no idea what they're doing.

> DoD Cyber Exchange site is undergoing a TSSL Certification renewal

I'm imagining someone searching around for a consulting or testing company that will help them get a personal TSSL Certification, whatever that is (a quick search suggests that it does not exist, as one would expect). And perhaps they have no idea what TLS is or how any modern WebPKI works, which is extra amazing, since cyber.mil is apparently a government PKI provider (see the top bar).

Of course, the DoD realized that their whole web certificate system was incompatible with ordinary browsers and they wrote a memo (which you have to click past the certificate error to read):

https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/uncl...

saying that, through February 2024, unclassified DoD sites are permitted to use ordinary commercial CAs.

If the DoD were remotely competent at this sort of thing, they would (a) have CAA records (because their written policy does nothing whatsoever to tell the CA/B-compliant CAs of the world not to issue .mil certificates, (b) run their own intermediate CA that had a signature from a root CA (or was even a root CA itself), and (c) use automatically-renewed short-lived certificates for the actual websites.

cyber.mil currently uses IdenTrust, which claims to be DoD approved. They also, ahem, claim to support ACME:

> In support of the broader CA community, IdenTrust—through HID and the acquisition of ZeroSSL—actively contributes to the development and maintenance of major open-source ACME clients, including Caddy Server and ACME.sh. These efforts help promote accessibility, interoperability, and automation in certificate management.

Err... does that mean that they actually support ACME on their DoD-approved certificates or does that mean that they bought some companies that participate in the ACME ecosystem? (ACME is not amazing except in contrast to what came before and as an exercise in getting something reasonable deployed in a very stodgy ecosystem, but ACME plus a well-designed DNS-01 implementation plus CAA can be very secure.)

The offending certificate is:

    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                40:01:95:b4:87:b3:a3:a9:12:e0:d7:21:f8:b3:91:61
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: C=US, O=IdenTrust, OU=TrustID Server, CN=TrustID Server CA O1
            Validity
                Not Before: Mar 20 17:09:07 2025 GMT
                Not After : Mar 20 17:08:07 2026 GMT
            Subject: C=US, ST=Maryland, L=Fort Meade, O=DEFENSE INFORMATION SYSTEMS AGENCY, CN=public.cyber.mil
At least the site uses TLS 1.3.

by amluto

3/23/2026 at 5:09:12 PM

> If the DoD were remotely competent at this sort of thing

That's probably one of the things they were forced to contract out.

by BigTTYGothGF

3/23/2026 at 6:56:45 PM

There are a few reasons DoD PKI is a shitshow which make it somewhat more understandable (although only somewhat).

First, the issues you describe affect only unclassified public-facing web services, not internal DoD internet services used for actual military operations. DoD has its own CA, the public keys for which are not installed on any OS by default, but anyone can find and install the certs from DISA easily enough. Meaning, the affected sites and services are almost entirely ones not used by members of the military for operational purposes. That approach works for internal DoD sites and services where you can expect people to jump through a couple extra hoops for security, but is not acceptable for the general public who aren't going to figure out how to install custom certs on their machine to deal with untrusted cert errors in their browser. That means most DoD web infra is built around their custom PKI, which makes it inappropriate for hosting public sites. Thus anyone operating a public DoD site is in a weird position where they deviate from DoD general standards but also aren't able to follow commercial standard best practices without getting approval for an exception like the one you linked to. Bureaucratically, that can be a real nightmare to navigate, even for experienced DoD website operators, because you are way off the happy path for DoD web security standards.

Second, many DoD sites need to support mTLS for CAC (DoD-issued smartcards) authentication. That requires the site to use the aforementioned non-standard DoD CA certs to validate the client cert from the CAC, which in turn requires that the server's TLS cert be issued by a CA in the same trust chain, which means the entire site will not work for anyone who hasn't jumped through the hoops to install the DoD CA certs. Meaning, any public-facing site has to be entirely segregated from the standard DoD PKI system. For now, that means using commercial certs, which in turn requires a vendor that meets DoD supply chain security requirements.

Third, most of these sites and services run on highly customized, isolated DoD networks that are physically isolated from the internet. There's NIPR (unclassified FOUO), SIPR (classified secret), and JWICS (classified top secret). NIPR can connect to the regular internet, but does so through a limited number of isolated nodes, and SIPR/JWICS are entirely isolated from the public internet. DoD cloud services are often not able to use standard commercial products as a result of the compatibility problems this isolation causes. That puts a heavy burden on the engineers working these problems, because they can't just use whatever standard commercial solutions exist.

Fourth, the DoD has only shifted away from traditional old school on-prem Windows Server hosting for website to cloud-hosting over the past few years. That has required tons of upskilling and retraining for DoD SREs, which has not been happening consistently across the entire enterprise. It also has made it much harder to keep up with the standards in the private sector as support for on-prem has faded, while the assumptions about cloud environments built into many private sector solutions don't hold true for DoD.

Fifth, even with the move to cloud services, the working conditions can be so extraordinarily burdensome and the DoD-specific restrictions so unusual, obscure, poorly documented, and difficult to debug that it dramatically slows down all software development. e.g., engineers may have to log into a jump box via a VDI to then use Jenkins to run a Groovy script to use Terraform to deploy containers to a highly customized version of AWS.

Ultimately, the sites this affects are ones which are lower priority for DoD because they are not operationally relevant, and setting up PKI that can easily service both their internal mTLS requirements and compatibility with commercial standards for public-facing sites and services is not totally straightforward. That said, it is an inexcusable shitshow. Having run CAC-authenticated websites, I can tell you it's insane how much dev time is wasting trying to deal with obscure CAC-related problems, which are extremely difficult to deal with for a variety of technical and bureaucratic reasons.

by stult

3/23/2026 at 7:41:59 PM

Good write up. Not to mention the other big HR constraints on DoD engineers: they almost always have to be a “US person.”

Anyone who gets a CAC working on a personal computer deals with this all too much. The root certs DoD uses are not part of the public trusted sources that commonly come installed in browsers.

by master_crab

3/23/2026 at 7:43:23 PM

lol I very nearly included a rant about that but decided it was too far off topic. Not being able to smoke weed may be more of an obstacle these days though.

by stult

3/23/2026 at 8:08:39 PM

> That requires the site to use the aforementioned non-standard DoD CA certs to validate the client cert from the CAC, which in turn requires that the server's TLS cert be issued by a CA in the same trust chain, which means the entire site will not work for anyone who hasn't jumped through the hoops to install the DoD CA certs. Meaning, any public-facing site has to be entirely segregated from the standard DoD PKI system. For now, that means using commercial certs, which in turn requires a vendor that meets DoD supply chain security requirements.

Is this actually all the way technically correct? As far as I know, there is no requirement that the trust chains for server certificates and client certificates are in any way related. It seems to me that it would be perfectly possible for the DoD to use its own entirely private client certificate infrastructure but to still have the server certificate use something resembling an ordinary root certificate.

This is not to say that this would actually be all that worthwhile.

by amluto

3/23/2026 at 8:39:32 PM

> Is this actually all the way technically correct? As far as I know, there is no requirement that the trust chains for server certificates and client certificates are in any way related. It seems to me that it would be perfectly possible for the DoD to use its own entirely private client certificate infrastructure but to still have the server certificate use something resembling an ordinary root certificate.

I think you're right that it's possible in principle for a Web server to enforce use of DoD CAC (enforcing the client cert being in the DoD PKI) without itself using a DoD PKI cert on the server side.

That said there's little benefit to it, users who haven't jumped through hoops to install DoD root CA certs won't typically be able to get their browsers to present them to the remote server in the first place, and if we're willing to jump through those hoops then there's no good reason for the DoD server not to have a DoD PKI cert.

by mpyne

3/23/2026 at 8:50:36 PM

I've never used one of the DoD smartcards, but I can certainly imagine the DoD wanting a user of one of these smartcards to be able to use it with a COTS client device to authenticate themselves.

by amluto

3/23/2026 at 9:26:48 PM

Sure, people do that all the time. After they run "InstallRoot" to install DoD root certs on their COTS device, that is. I'm honestly not sure any major browser will allow you to use a client smartcard without having the smartcard's certificate chain to the trust store used by the browser so this part seems unavoidable.

FWIW I just tested it and yes you can run a web server using a commercial server cert that enforces client PKI tied to the client having a DoD PKI cert. It works just fine.

by mpyne

3/23/2026 at 10:09:42 PM

> I'm honestly not sure any major browser will allow you to use a client smartcard without having the smartcard's certificate chain to the trust store used by the browser so this part seems unavoidable.

It’s been a while, but I’ve used file-backed client certs issued by a private CA in an ordinary browser without installing anything into the trust store, and it worked fine. I don’t see why a client cert using PKCS11 or any other store would work any differently. Why would the browser want to verify a certificate chain at all?

by amluto

3/23/2026 at 10:23:33 PM

I'm really just talking about the browser trusting the user cert itself. I've done the softcert thing myself before, I forget if it used commercial root CA or not but it did work.

I guess you could flag the leaf (user) cert as ultimately trusted and that should be fine, but if the browser doesn't see that trust notation, and does see an intermediate CA, it's going to try to pull that back to a trusted root.

One way or the other the user will have to fiddle with browser settings to make a CAC work, either to tell the browser to trust their cert explicitly, or to have the browser trust DoD certs.

by mpyne

3/23/2026 at 10:55:14 PM

Wait, what part of the whole login flow involves the browser even contemplating whether it trusts its user’s client cert?

by amluto

3/23/2026 at 9:51:22 PM

No unfortunately it is not correct. You can supply a different CA to verify client certs against to what is given in server hello. There's no need for them to be related at all.

Critically you probably want to use a custom CA for client certs. The usual implementation logic in servers is "is this cert from the client signed by one I trust?". If that CA is LetsEncrypt say then that's a lot of certificates that will pass that check.

by zahllos

3/23/2026 at 7:32:44 PM

> engineers may have to log into a jump box via a VDI to then use Jenkins to run a Groovy script to use Terraform to deploy containers to a highly customized version of AWS.

This hits too close to home. I'm sending you my therapist's bill for this month.

by robolange

3/23/2026 at 7:11:53 PM

I do lots of fed cloud work and im stealing this comment to use during the next conversation around why on-prem DoD PKI is now a huge PIA.

by notesinthefield

3/23/2026 at 8:39:42 PM

A site can authenticate a client cert from a different PKI than one it has.

by wbl

3/24/2026 at 1:20:03 AM

All of the meaningful users are on GFE and will never encounter this. I can get a new DoD PKI certificate for a server in 10 minutes and everyone hitting the server will seamlessly validate it and have no problem logging in with their smart card. I'm not saying that this failure is excusable. But there is a lot of misinformation in the comments here from people who aren't familiar with the systems involved and how they work, and the real impact of this issue.

by driftnet

3/23/2026 at 5:25:36 PM

I think you underestimate the number of people who accidentally have their https carts expire. Instead of blaming the people running these systems on why they let it expires, it would be more productive to improve the system to make this less likely to happen.

by charcircuit

3/23/2026 at 6:19:52 PM

ACME [1] has been a thing for more than 10 years and has been a stable specification for 7 years. There were similar vendor-specific implementations that preceded it. The DoD has employed none of these solutions for their flagship infosec public web presence. If they were going to automate this then they surely would have done so by now. The reasons why are opaque but people who have experience working in this space might be able to make an educated guess.

[1] https://en.wikipedia.org/wiki/Automatic_Certificate_Manageme...

by alexjplant

3/23/2026 at 9:05:58 PM

It may be a thing, but it is not mandatory and issues can still happen that cause the automatic renewal to fail. There still exist holes where someone can have a cert for their site expire.

by charcircuit

3/23/2026 at 5:49:01 PM

Which is exactly what has happened, with an automated protocol for certificate renewal.

by JoshTriplett

3/23/2026 at 9:05:56 PM

Even with that existing there are still holes with that solution as it's still happening.

by charcircuit

3/23/2026 at 8:27:06 PM

Look, when I forget to renew the cert on my Jellyfin server, like 4 people suffer.

When the DoD forgets to renew the cert for their cybersecurity download website AND can't figure what a A TLS cert even is (calling it a "TSSL Certification"), this is an indicator that our military has absolutely zero understanding of the most basic cybersecurity concepts.

If you can't tell the difference between a hobbyist forgetting to renew their Let's Encrypt cert, vs. a trillion-dollar military not even knowing what a certificate is, maybe you should work for our military, because they can't tell the difference either.

by RIMR

3/23/2026 at 7:09:33 PM

> Users on civilian network can continue downloads through the Advance tab in the error message.

They are literally telling users to click through the browser errors about the bad cert. They don't mention that there is a very specific error they should be looking for (expired cert). This gives any MITMer the opportunity right now to replace downloaded executables with malware-laden ones using nothing more than a self-signed cert and a proxy. You can bet your boots China, NK, Iran, Russia are all having a good laugh. Biggest military in the world and they can't get a web server working.

by 0xbadcafebee

3/23/2026 at 8:31:49 PM

Oh wow, they really are telling people to bypass the cert warning! It's a shame that the average layperson won't understand how breathtakingly stupid this is, because more people need to be paying attention to the staggering incompetence of the US military under this administration.

by RIMR

3/23/2026 at 9:32:08 PM

Honestly this isn't even the first time this kind of advice has been given to non-DoD users needing to access a DoD service over commercial means.

The Navy a few years back were experimenting with letting users check basic HR things in their service record (e.g. to request days off) and despite the leadership's stated intent being for Sailors to be able to do this on their actual personal mobile devices, the IT people duly signed all the relevant server certs under the DoD PKI "because policy forces us to", and then cooked up user training guides that patiently explained to Sailors how to bypass security warnings in their browser.

So if nothing else at least there's experience to go by here, ha.

by mpyne

3/23/2026 at 5:48:45 PM

TD bank, in Canada, has had their cert expire several times in the past 10 years.

It blows me away that a bank can't afford to do for themselves what Certbot and Lets Encrypt does for me, for free.

Like, pay a guy a whole week to automate this and it will save you the 12hrs losses every time your cert expires.

by nik282000

3/23/2026 at 6:17:35 PM

Turns out ”bank-grade security” is not something to strive towards. In the case of TLS certificates, most banks still believe they need EV certs, even though browsers stopped making any visual distinctions for EV certificates around 2018-2019.

by Kwpolska

3/23/2026 at 7:45:44 PM

Apart from the fact one dev as a test exploited a loophole to make a single sort of convincing EV cert (which could easily be fixed by a policy change), EV certs are still vastly harder to exploit or clone than almost any other certificate. The eventual solution will be an EV cert that isn't named an EV cert so that the CA/B can protect their reputations for claiming they're a bad idea.

The fact the browsers stopped recognizing this is political, not based on any reality of sense. Everyone appeals to authority what the best way to do TLS is, and the problem is the authority is stupid.

by ocdtrekkie

3/23/2026 at 8:38:05 PM

> which could easily be fixed by a policy change

It can't. Nothing is guaranteeing that organization names are globally unique, so getting an EV cert for a conflicting org name will always be possible. Well-known counterexamples are Apple (Beatles or tech company?), Nissan (computer repair guy, or car maker?), and Microsoft/MikeRoweSoft (some guy named Mike Rowe, or software giant from Redmond?).

Unless you're willing to retroactively cancel a massive number of trademarks, EVs with human-readable company names are not going to happen. The best you can do is some kind of unique company id, but who's going to check that "US0378331005" is the right one?

by crote

3/23/2026 at 9:18:59 PM

Also, legal names of companies can sometimes not match the well-known brand, making it harder to decide if the EV cert was issued for the correct company.

by Kwpolska

3/23/2026 at 11:09:58 PM

This is actually not hard for most cases: Add a flag next to the name.

The other thing people don't realize is that cost is a huge mitigator: EV certs costing money makes them not worth using for an exploit.

by ocdtrekkie

3/23/2026 at 11:43:21 PM

A flag of the country? Each US state has its own company register. A flag of the US state? Who is going to remember which company is incorporated where? Can you tell US state flags apart when they’re scaled down to a height of ~20 px?

by Kwpolska

3/23/2026 at 9:17:46 PM

Is there any evidence of EV certs actually helping prevent phishing back when browsers showed them much more prominently? Or did users just not care/understand the difference?

by Kwpolska

3/23/2026 at 6:14:50 PM

Certificate/key renewal was a mess in every enterprise environment I worked in.

My suspicion is that corporations in general don‘t handle tasks well that need to follow an exact timeline and can‘t be postponed by a week or two.

by fzeindl

3/23/2026 at 8:46:39 PM

The real fun starts when you have to do an unscheduled renewal!

Companies are generally able to develop a workable process around regularly-scheduled tasks. If you can't, you'll quickly run into trouble due to late salary payouts or missed tax filing deadlines. They'll rapidly accumulate a thick layer of bureaucracy around it, but as long as it gets exercised regularly it'll remain more-or-less functional.

Try the same with PKI and you'll run into massive issues during mass revocation events. Having a renewal process which takes 2 months and involves dozens of stakeholders is totally fine for a cert which gets renewed every 12 months on a well-known date - but not when you're working with a 72-hour deadline...

by crote

3/23/2026 at 8:18:06 PM

As well as having; proper documented (and tested) procedures and appropriate level of staffing/staff availability (not overburdened by juggling too many tasks and projects) - AND... keeping staff over several period/activity cycles, so they have actual experience performing the ongoing maintenance activities required. Oh - and heck, even a master calendar of "events" which need to be acted on, with - ya'know reminders and things...

Yeah - I have almost never seen any corporate or government environment actually take a "forward-thinking" approach to any of the above...

by jjkaczor

3/23/2026 at 5:56:17 PM

Anyone who thinks this is that trivial has never worked in enterprise IT.

Automated certificate renewal is maybe supported by 10% of services I operate where I work. And we're pretty modern. An organization with more legacy platforms is likely at "nothing supports automated renewal".

We are a decade or two out from 47 day expiry being a sane concept.

by ocdtrekkie

3/23/2026 at 8:54:42 PM

This is exactly why CAs are slowly reducing cert validity.

With a 47-day validity already on the calendar for 2029, nobody in their right mind is going to onboard a new service/device without automated renewal in 2026. Same with any kind of contract renewal: are you going to risk staying with the current vendor who is "considering" supporting ACME "at some point in the future", or would you rather ask their competitor who already supports it to make you a nice deal to convince your manager?

Sure, automated cert renewal might be supported by 10% of services right now, but what is that going to look like a couple of years from now when 100% of businesses are pestering their vendors for it, and leaving for competitors if they can't deliver?

by crote

3/23/2026 at 9:53:27 PM

> nobody in their right mind is going to onboard a new service/device without automated renewal in 2026

We're talking about people that didn't bother about an event scheduled in 365 days.

Why would they care about something that may happen in 2029?

No later than last week I had to setup a service using a 365 days cert that was provided to me as a ZIP archive.

The provider have everything in place to set automated renewal.

But they decided against it because it forces providing us with (scoped) API access to the provider.

Instead they put a reminder in Outlook and forgot about it.

Hopefully in ~50 weeks from now someone will see the reminder, decide to act on it, find someone available with access to the provider to renew the certs and someone available that'll read the doc I had to wrote explaining how to put new certs in place, someone willing to schedule the operation... all of that before the certs do actually expire.

by wiether

3/23/2026 at 6:24:23 PM

Can confirm. Have encountered many on-prem and lift-and-shift solutions with no automated means of updating certs. The worst contenders are usually 1) executables on windows server (version 2012, of course), 2) old, obscure or very outdated database servers and 3) custom hardware firewalls. They are the worst.

To make things easy they usually all use different cert formats as well, requiring you to have an arsenal of conversion scripts ready.

by Koffiepoeder

3/23/2026 at 7:38:34 PM

> 3) custom hardware firewalls.

In this case, “custom” means firewalls made by pretty much any of the major vendors.

Cisco, Juniper, Fortinet and Palo Alto have a lot to answer for with their laziness. Cisco and Fortinet added support only recently. Palo and Juniper haven’t bothered at all.

by bigfatkitten

3/23/2026 at 6:49:56 PM

Even plain IIS still doesn't support ACME on Windows Server 2025 without you grabbing some random scripts off the Internet written by people you don't know.

But yeah a lot of Windows server software uses inbuilt web servers with no ability to tweak or tamper beyond what the application exposes in its own settings panel.

by ocdtrekkie

3/23/2026 at 6:25:43 PM

That's why I suggested that a week of dev time woule be reasonable for automating the task.

I work in a multinational nightmare corp, we still have a mission critical Win95 machine.

by nik282000

3/23/2026 at 5:55:35 PM

Certificate expiration notifications are a checkbox in uptime-kuma, which is itself incredibly easy to install and configure. We're not talking a week, we're talking a matter of minutes to go from zero to receiving notifications 21 days in advance of certificate or domain expiration.

by hoherd

3/23/2026 at 3:49:29 PM

Is there anything inherently insecure about an expired cert other than your browser just complaining about it?

by petcat

3/23/2026 at 3:54:30 PM

Expiries are a defence-in-depth that exist primarily for crypt hygiene, for example to protect from compromised keys. If the private key material is well protected, the risk is very low.

However, an org (particularaly a .mil) not renewing its TLS certs screams of extreme incompetence (which is exactly what expiries are meant to protect you from.)

by zeroxfe

3/23/2026 at 4:06:57 PM

>screams of extreme incompetence

Not unheard of with the military

by jp191919

3/23/2026 at 5:02:10 PM

Precision lethality, not certificate renewality.

by cozzyd

3/23/2026 at 5:57:40 PM

Let's not kid ourselves, the lethality isn't even that precise.

by hoherd

3/23/2026 at 8:57:05 PM

It is quite precise, it just isn't accurate.

On the one hand, they can do a perfect triple-tap. On the other hand, the perfect triple-tap hit a girls' school rather than a military base...

by crote

3/23/2026 at 6:41:42 PM

"Why not neither?"

by rectang

3/23/2026 at 4:14:10 PM

the idea behind expiration is:

- TLS certificates do leak, not just due to worst case bugs like heart blead

- revocation does not work well in practice

- affected operators aren't always aware if a certificate leaked

so by having expiration (and in recent years increasingly short validity duration) you reduce how the consequences of an leak, potentially to nothing if the attacker only gets their hand on the cert after it expired

this also has the unintended consequence that a long time expired certificate leaking isn't seen as a security issues, nor will you revoke it (it's already invalid).

But if you visit site with expired certificates you have the problem that you only know it had been valid in the past. You don't know if it was leaked after it became invalid or similar. I.e. you can't reasonable differentiate anymore between "forgotten to renew" and MITM attack. At which point it worth pointing out that MITM attacks aren't just about reading secrets you send, but can also inject malicious JS. And browser sandbox vulnerabilities might be rare but do exist.

A more extremem case of this dynamics are OIDC/OAuth access tokens. Which are far more prone to leak then certs, but in turn are only valid for a short time (max 5min) and due to that normally don't have a revocation system. (Thinks are different for the refresh token you use to get the access token, but the refresh token also is only ever send to the auth server which makes handling that way easier.)

by dathinab

3/23/2026 at 7:57:18 PM

Revocations works great in theory, and in theory & practice particularly in DOD.

The problem is a ton of certificate authorities consciously chose not to produce validation data previously, created insecure CAs, chose not to cache validation data, had knee jerk reactions to potential exposures, and many industries chose not to invest in technical capability to make revocation data available, performant, resilient, failing-over, failing gracefully, etc.

MITM is now the default for half the enterprise security solutions operating with cert to website “suspected good whitelists” which makes new domains on HN nigh unreadable

by OrvalWintermute

3/23/2026 at 5:26:30 PM

Its more or less the same as using expired in person documents.

Instrinsically no, but at the same time its generally easier to source an expired identity document. If its long expired the verification standards might be different. People dont really put as much effort into destroying or revoking expired documents. The info might no longer be accurate.

The only addition in the computer context is it trains users to blindly click through warnings. If this becomes a pattern they will eventually not realize it if the error becomes something more serious.

by bawolff

3/23/2026 at 3:54:11 PM

No, but it reflects poorly on the maintainer. Plus, any browser complaint contributes to error fatigue. Users shouldn't just ignore these, and we shouldn't encourage them to ignore them just because we fail at securing our websites.

by mr_mitm

3/23/2026 at 3:59:19 PM

[flagged]

by UqWBcuFx6NV4r

3/23/2026 at 4:05:59 PM

There is a reason why certs have expiration dates. It's to control the damage after the site owner or someone else in the cert chain messes up. That doesn't mean expired certs are inherently not secure, only that you should still care about it and do your best to avoid using expired certs.

by mr_mitm

3/23/2026 at 4:06:30 PM

On the contrary, it's a very precise answer.

by gpvos

3/23/2026 at 5:07:46 PM

Certificate revocations are not required to be reported after the expiration date, so you can no longer reliably check if a certificate has been revoked (e.g., because its underlying key was exfiltrated or because it was misissued).

by jcranmer

3/23/2026 at 3:53:00 PM

To prevent abuse, for example to prevent an old owner of domain to have a valid certificate for the domain indefinitely after transfer.

by Manfred

3/23/2026 at 3:57:53 PM

Yes. Visitors to the site are vulnerable to Man in the Middle (MitM) attacks, IF they click past the warning (which many people do)

by sciencejerk

3/23/2026 at 4:03:29 PM

That’s not true. The encryption still works as well as it did 3 days ago, and doesn’t care if the certificate is expired.

by LadyCailin

3/23/2026 at 4:07:34 PM

I think the argument would go that if people are clicking through certificate errors and you're in a position to MITM their traffic, you can just serve them a different certificate and they'll click through the error without noticing or understanding the specifics.

by russell_h

3/23/2026 at 5:24:04 PM

IMHO host mismatch is more serious than expired cert and browsers should treat it as such

by eli

3/23/2026 at 5:24:13 PM

That could happen either way regardless of expiry. The only reason for an expiration date is to force site owners to cycle their certs at regular intervals to defeat the long time it takes to brute force a successful forgery.

by austin-cheney

3/23/2026 at 5:11:29 PM

Fair point, but I think the situation is a bit more complicated when a user "needs the site for work", or something urgent. You might have smart cautious users that feel like they have no choice but to proceed and click through the warnings since the site is most likely still legitimate

by sciencejerk

3/23/2026 at 4:10:21 PM

It's true that the expiration doesn't mean the encryption no longer works, but if the user is under a MITM attack and is presented by their browser with a warning that the certificate is invalid, then the encryption will still work but the encrypted communication will be happening with the wrong party.

I don't trust the average user to inspect the certificate and understand the reason for the browser's rejection.

by LeifCarrotson

3/23/2026 at 5:09:15 PM

Okay, but that’s not what was being asked. OP, someone who presumably understands the difference between a totally invalid cert and an expired one, was asking specifically whether clicking through the latter is dangerous.

by umanwizard

3/23/2026 at 5:18:44 PM

"Visitors to the site are vulnerable to Man in the Middle (MitM) attacks, IF they click past the warning". I think it's true when there is a man in the middle.

by axus

3/23/2026 at 5:45:34 PM

Based on history of this type of attack, it can also be true with a valid certificate ;)

by fylo

3/23/2026 at 5:28:16 PM

It's entirely the second paragraph and not part of certificate expiration, in and of itself, lends to being MITM. Firefox tells me what the problem is, expired, wrong name, etc. So, it's not just saying "oh no, something is wrong." I can tell what is wrong before I choose to proceed.

by wang_li

3/23/2026 at 5:10:38 PM

This is an infohazard. True information that can cause harm or enable some agent to cause harm.

Telling people not to worry about expired cert warnings makes them vulnerable to a variety of attacks.

by hamdingers

3/23/2026 at 4:07:39 PM

I think they mean that a non-observant visitor cannot tell the difference between both situations

by f_devd

3/23/2026 at 6:00:38 PM

If you're ignoring certificate warnings, then you'll ignore mismatching domain warnings.

More over, if your org's browser setting allow you to override the warnings, thast also pretty bad for anything other than a small subset of your team.

by KaiserPro

3/23/2026 at 6:49:29 PM

That's not what man in the middle attacks are about.. it's not about the encryption, it's about verifying that you really know who you're talking to.

by ktm5j

3/23/2026 at 4:02:19 PM

An expired certificate alone doesn't enable a MITM attack.

by belter

3/23/2026 at 5:59:03 PM

Its a signifier of other problems.

but, in terms of security, wrong cert looks the same to most people as wrong domain. So once people get used to the cert being wrong and click through anyway, its easy to switcheroo and do a half arsed man in the middle.

But, it signifies that people are not monitoring the outside of the network. We have cert checks which alert if they are less than 5 days from expiry, as they should have been renewed and restarted automatically. If you're not doing that, what else are you halfarsing?

by KaiserPro

3/23/2026 at 3:53:45 PM

Not inherently, but it can introduce risk. Such as a bad actor using an old expired certificate it was able to acquire to play man-in-the-middle. But if that is happening you have bigger problems.

by m348e912

3/23/2026 at 6:22:10 PM

You're training users to click away error messages.

by hannob

3/23/2026 at 7:52:30 PM

Everyone, including every professional network engineer, does this regularly. I've never seen a TLS error message that actually reflected a security issue, as opposed to a configuration problem.

The whole thing is silly.

by ocdtrekkie

3/23/2026 at 4:17:33 PM

I'm not actually sure if browsers validate expired certificates. I couldn't find out if an invalid cert authority and an invalid date would look different than just the error for an invalid date. Educated guess says so, but that's just a guess.

The biggest concern is you'd hope the DoD (/DoW) is on top of their stuff, especially the DISA. This is a sign they are not. This is something that should never happen.

But then, there's this message:

> DoD Cyber Exchange site is undergoing a TSSL Certification renewal resulting in download issues for some users. Users on civilian network can continue downloads through the Advance tab in the error message.

Uh oh!!! This is concerning because (1) "Ignore SSL errors" is something you should never be telling users to do and (2) this is extra concerning because whoever wrote this does not seem to have a grasp on the English language:

- "TSSL Certification renewal" should be TLS/SSL Certificate renewal. (Caveat: Defense is full of arcane internal acronyms and TSSL could just be one of them.)

- "Users on civilian network" should be "Users on civilian networks", or "Users on a civilian network".

- "Advance tab" should be "Advance button".

So, we have three glaring red flags. Expired certs, telling users to ignore cert warnings, and various spelling and grammar mistakes.

People are citing the short 40-day certificate renewal window, but that's not the problem here. It's not a case of administration transition either. This cert was issued 2025-Mar-20 and was valid for 1 year. But IdenTrust DoD certs can't be renewed after they expire, so that might be why this is so broken.

In the most generous interpretation, the once-responsible party was cut with the huge DOGE cuts back in May 2025, and this failure of web administration is just one visible sign of the internal disarray you'd expect with losing 10% of your workforce.

by lynndotpy

3/23/2026 at 3:51:42 PM

It's a pretty dopey thing to miss.

by Spooky23

3/23/2026 at 4:04:24 PM

Can you live without your immune system? Sure, for a little while. It’s the defense against man in the middle and many other things.

by PilotJeff

3/23/2026 at 4:08:15 PM

Inherently, not really. An expired, self-signed or even incorrect (as in, the wrong domain is listed) certificate can be used to secure a connection just as well as a perfectly valid certificate.

Rather, the purpose of all of these systems (in theory) is to verify that the certificate belongs to the correct entity, and not some third party that happens to impersonate the original. It's not just security, but also verification: how do I know that the server that responds to example.com controls the domain name example.com (and that someone else isn't just responding to it because they hijacked my DNS.)

The expiration date mainly exists to protect against 2 kinds of attacks: the first is that, if it didn't exist, if you somehow obtained a valid certificate for example.com, it'd just be valid forever. All I'd need to do is get a certificate for example.com at some point, sell the domain to another party and then I'd be able to impersonate the party that owns example.com forever. An expiration date limits the scope of that attack to however long the issued certificate was valid for (since I wouldn't be able to re-verify the certificate.)

The second is to reduce the value of a leaked certificate. If you assume that any certificate issued will leak at some point, regardless of how it's secured (because you don't know how it's stored), then the best thing you can do is make it so that the certificate has a limited lifespan. It's not a problem if a certificate from say, a month ago, leaks if the lifespan of the certificate was only 3 days.

Those are the on paper reasons to distrust expired certificates, but in practice the discussion is a bit more nuanced in ways you can't cleanly express in technical terms. In the case of a .mil domain (where the ways it can resolve are inherently limited because the entire TLD is owned by a single entity - the US military), it's mostly just really lazy and unprofessional. The US military has a budget of "yes"; they should be able to keep enough tech support around to renew their certificates both on time and to ensure that all their devices can handle cert rotations.

Similarly, within a network you fully control, the issues with a broken certificate setup mostly just come down to really annoying warnings rather than any actual insecurity; it's hard to argue that the device is being impersonated when it's literally sitting right across from you and you see the lights on it blink when you connect to it.

Most of the issues with bad certificate handling come into play only when you're dealing with an insecure network, where there's a ton of different parties that could plausibly resolve your request... like most of the internet. (The exception being specialty domains like .gov/.mil and other such TLDs that are owned by singular entities and as a result have secondary, non-certificate ways in which you can check if the right entity owns them, such as checking which entity the responding IP belongs to, since the US government literally owns IP ranges.)

by noirscape

3/23/2026 at 6:54:27 PM

Well it means that you can MITM a user and they won't know the difference (an expired cert is an expired cert, whether it's self-signed or not, the user clicks through anyway). It also means nobody is doing the regular maintenance to rotate keys and do upgrades/patches/etc.

by 0xbadcafebee

3/23/2026 at 4:54:19 PM

“It’s an older code but it checks out.”

by jl6

3/23/2026 at 6:05:44 PM

We are green on opsec!

by Arubis

3/23/2026 at 5:54:40 PM

Anything that relies on certificate validation might not be working because of it.

I didn't see it mentioned, so I'll add the Broken Windows Theory. Simply put, this is at the very least, indicative of serious failures in other areas.

by jasonlotito

3/23/2026 at 4:00:24 PM

MITM

by ddtaylor

3/23/2026 at 4:08:10 PM

No.

by gpvos

3/23/2026 at 3:56:01 PM

> DoD Cyber Exchange site is undergoing a TSSL Certification renewal

TSSL renewal does not cause downtime.. If it's actually done of course.

by bilekas

3/23/2026 at 6:42:31 PM

What is "TSSL"?

by Stefan-H

3/23/2026 at 7:20:46 PM

When you can't decide between TLS and SSL.

by progbits

3/23/2026 at 7:09:34 PM

TESLA? They probably meant to say TLS.

by winstonwinston

3/23/2026 at 9:26:17 PM

"THE" SSL ... Clearly! /s

by bilekas

3/23/2026 at 6:46:10 PM

telling users on a cybersecurity website to click past certificate warnings is training them to do the exact thing every security awareness program says never to do. DISA runs the security standards that every defense contractor has to comply with...

by kevincloudsec

3/24/2026 at 1:00:18 AM

The requirements for vendors are based on NIST standards and frameworks. They do not have to apply DISA STIGs to their own systems. And the mandatory annual cybersecurity awareness training for anyone with a CAC does include teaching users not to click through these warnings. DoD users wouldn't typically see this page at all.

by driftnet

3/23/2026 at 8:33:16 PM

So it looks like a new cert was issued back in February, but they've not deployed it yet (https://bgp.he.net/certs#_SearchTab?q=www.public.cyber.mil)

by yesod

3/23/2026 at 8:45:41 PM

Certificate readiness across the force has been dropping as procurement and testing costs have soared with inflation. It's now estimated that only 50% of .mil website are now ready for a conflict in the South China Sea.

by piyh

3/23/2026 at 5:58:12 PM

Clearly this is some advanced cyber-warfare technique intended to cause adversaries tools to fail with an "expired certificate" error...

by supermatt

3/23/2026 at 7:31:17 PM

Inexcusable but should clarify that cyber.mil and public.cyber.mil are actually different things. Most people downloading from the site are not using public.cyber.mil, so maybe they care less? This is still one of those highly-visible things that is going to bring down the heat quickly, so it's just dumb to let it happen.

by driftnet

3/23/2026 at 3:48:46 PM

> Users on civilian network can continue downloads through the Advance tab in the error message.

Good stuff.

by tuwtuwtuwtuw

3/23/2026 at 3:58:07 PM

“Do you want it or not?”

…or were you referring to the piss-poor English used? ^_^

by DANmode

3/23/2026 at 4:01:10 PM

"We have sent you a OTP code of 459-312 please check your device and enter this code below"

by whalesalad

3/23/2026 at 5:21:00 PM

For some reason the warning icon is huge on my phone.

Someone please verify that the exclamation point inside of the warning icon has always been gold and that this website's design hasn't fallen victim to Trump's dragon-like gold hoarding obsession.

by jeroenhd

3/23/2026 at 5:23:34 PM

iOS Safari. I see a yellow banner, the navigation bar and the rest of the screen is just a warning sign image.

Is there more..?

Checked on Chrome too, I see nothing.

iOS Chrome

by stephbook

3/23/2026 at 5:28:18 PM

What do you mean? You see nothing on the website?

I captured the full page, you can view it here: https://wormhole.app/MbljK6#qfysvKJOQh1whLcMz9JXxw

by johnisgood

3/23/2026 at 6:38:11 PM

This is the screen on my phone.

https://wormhole.app/9Xv0p0#Hsq0fhLpWsr8ndJDktt2YQ

You see the little "Red hat Enterprise" at the bottom? That's the whole scrollable area. The rest is fixed and stays at the top.

by stephbook

3/23/2026 at 7:30:56 PM

Must be an iOS thing. On Blink and Gecko the page just scrolls like normal, the warning scrolls with the rest of the page when scrolling down.

They still messed up the CSS because the downloads table goes straight beyond the mobile viewport on the bottom and to the right.

by jeroenhd

3/23/2026 at 7:45:48 PM

[dead]

by qcautomation

3/23/2026 at 3:47:37 PM

So what? They keep shortening the validity length of these certificates, making them more and more of a pain to deal with.

by dmitrygr

3/23/2026 at 4:24:55 PM

Not applicable in this case. This was a certificate issued March 20th 2025 and which expired March 20th 2026. Also concerning are the instructions written in broken English instructing visitors to ignore all SSL warnings.

by lynndotpy

3/23/2026 at 3:54:31 PM

Using old compromised certificates is a legitimate MITM attack vector.

by gslepak

3/23/2026 at 3:54:57 PM

Which would make sense if they were valid for 10 years and somebody forgot about them. Not when they’re valid for, what is it now, 40 days?

by dmitrygr

3/23/2026 at 4:01:55 PM

An official government source is teaching users to ignore security warnings about expired certificates.

Mistakes happen, some automation failed and the certs did not renew on time, whatever. Does not inspire confidence but we all know it happens.

But then to just instruct users to click through the warning is very poor judgement on top of poor execution.

by smashed

3/23/2026 at 4:05:58 PM

This was the predictable outcome of shortening certificate length validity to appoint where they are now.

by dmitrygr

3/23/2026 at 4:31:02 PM

No, because that's not what happened here.

The certificate they failed to renew was issued 2025-Mar-20th, and expired 2026-Mar-20th. That is a 365 day cert.

The maximum length for a new cert is now 200 days, with the 47 day window coming in three years: https://www.digicert.com/blog/tls-certificate-lifetimes-will...

by lynndotpy

3/23/2026 at 6:01:58 PM

Have you heard of automation? Cron? Certbot? You can schedule cert renewal and it happens automatically. It could be refreshed every 1 day, I don't care. The fact that it's so painful for you means you need to learn a bit more.

by HackerThemAll

3/23/2026 at 4:28:27 PM

The certificate they failed to renew was valid for 365 days. You can check this in any modern desktop browser.

by lynndotpy

3/23/2026 at 3:48:58 PM

because you need to automate it

by hhh

3/23/2026 at 3:49:54 PM

Which is yet another chore. And it doesn’t add any security. A certificate expired yesterday proves I am who I am just as much as it did yesterday. As long as the validity length is shorter than how long it would take somebody to work out the private key from the public key, it is fine.

by dmitrygr

3/23/2026 at 3:50:51 PM

Shortening certificate periods is just their way of admitting that certification revocation lists are absolutely worthless.

by bombcar

3/23/2026 at 4:13:19 PM

No, they're not useless at all. The point of shortening certificate periods is that companies complain when they have to put customers on revocation lists, because their customers need ~2 years to update a certificate. If CRLs were useless, nobody would complain about being put on them. If you follow the revocation tickets in ca-compliance bugzilla, this is the norm—not the exception. Nobody wants to revoke certificates because it will break all of their customers. Shortening the validity period means that CAs and users are more prepared for revocation events.

by nightpool

3/23/2026 at 5:11:07 PM

... what are the revocation tickets about then? how is it even a question whether to put a cert on the CRL? either the customer wants to or the key has been compromised? (in which case the customer should also want to have it revoked ASAP, no?)

can you elaborate on this a bit? thank you!

by pas

3/23/2026 at 9:10:35 PM

> what are the revocation tickets about then

Usually, technical details. Think: a cert issued with a validity of exactly 1000 days to the second when the rules say the validity should be less than 1000 days. Or, a cert where the state name field contains its abbreviation rather than the full name. The WebPKI community is rather strict about this: if it doesn't follow the rules, it's an invalid cert, and it MUST be revoked. No "good enough" or "no real harm done, we'll revoke it in three weeks when convenient".

> either the customer wants to or the key has been compromised

The CA wants to revoke, because not doing so risks them being removed from the root trust stores. The customer doesn't want to revoke, because to them the renewal process is a massive inconvenience and there's no real risk of compromise.

This results in CAs being very hesitant to revoke because major enterprise / government customers are threatening to sue and/or leave if they revoke on the required timeline. This in turn shows the WebPKI community that CAs are fundamentally unable to deal with mass revocation events, which means they can't trust that CAs will be able to handle a genuinely harmful compromise properly.

By forcing an industry-wide short cert validity you are forcing large organizations to also automate their cert renewal, which means they no longer pose a threat during mass revocation events. No use threatening your current CA when all of its competitors will treat you exactly the same...

by crote

3/23/2026 at 6:15:46 PM

From my experience the biggest complaints/howlings are when the signing key is compromised; e.g., your cert is valid and fine, but the authority screwed up and so they had to revoke all certs signed with their key because that leaked.

E.g., collateral damage.

by bombcar

3/24/2026 at 12:07:53 AM

Sure, happy to. The average revocation ticket is something like https://bugzilla.mozilla.org/show_bug.cgi?id=1892419 or https://bugzilla.mozilla.org/show_bug.cgi?id=1624527. The CA shipped some kind of bug leading to noncompliance with baseline requirements. This could be anything from e.g. not validating the email address properly, inappropriately using a third-party resolver to fetch DNS names, or including some kind of extra flag set that they weren't supposed to have set. The CA doesn't want to revoke these certificates, because that would cause customers to complain:

    In response to this incident of mistaken issuance, the verification targets are all government units and government agency websites. We have assessed that the cause of this mis-issuance does not involve a key issue, but only a certificate field issue, which will not affect the customer's information security. In addition, in accordance with the administrative efficiency of government agencies, from notification to the start of processing, it requires agency supervisors at all levels. Signing and approval, and some public agencies need to find information vendors for processing, so it is difficult to complete the replacement within 5 days. Therefore, the certificate is postponed and revoked within a time limit so that the certificates of all websites can be updated smoothly.
[...]

    In this project we plan to initially issue new certificates using the same keys for users to install, and then revoke the old certificates. As these are official government websites, and considering the pressure from government agencies and public opinion, we cannot immediately revoke all certificates without compromising security. Doing so would quickly become news, and we would face further censure from government authorities.
The browsers want them to revoke the certificates immediately, because they rely on CAs to agree to the written requirements of the policy. If you issue certificates, you must validate them in precisely this way, and you must generate certificates with precisely these requirements. The CAs agree in their policies to revoke within 24 hours (serious) or 120 hours (less serious) any certificates issued that violate policy.

And yet when push comes to shove, certificates don't actually get revoked. Everybody has critical clients who pay them $$$$$ and no CAs actually want to make those clients mad. Browsers very rarely revoke certificates themselves, and realistically their only lever is to trust or distrust a CA—they need to rely on the CA to be truthful and manage their own certificates properly. They don't know exactly all of which certificates would be subject to an incident, they don't want to punish CAs for disclosing info publicly, etc. So instead, they push for systematic changes that will make it easier for CAs to revoke certificates in the future, including ACME ARI and shorter certificate lifetimes.

by nightpool

3/24/2026 at 8:32:48 AM

Thank you for the detailed answer!

It's unacceptable that operational matters are not handled by a standing ops team that covers so and so gov agencies.

(And at least Apple did something useful by pushing for shorter validity time for certs.)

by pas

3/23/2026 at 3:54:38 PM

Right. It's the same debate about how long authorization cookies or tokens should last. At one point in time--only one--authentication was performed in a provable enough manner that the certificate was issued. After that--it could be seconds, hours, days, years, or never--that assumption could become invalid.

by nathanaldensr

3/23/2026 at 3:53:39 PM

An expired cert is a smell. It shows somebody isn't paying attention.

And a short expiration time absolutely increases security by reducing attack surface.

by danesparza

3/23/2026 at 3:56:26 PM

Or that someone asked to renewed it, one of their four bosses didn't sign off the apropriate form, the only person to take that form to whoever does the certs is on a vacation, person issuing certs needs all four of his bosses to sign it off, and one of those bosses has been DOGE-ed and not yet replaced.

expired letsencrypt cert on a raspberrypi at home smells of not paying attention... with governments, there are many, many points of failure.

by ajsnigrutin

3/23/2026 at 5:27:16 PM

The whole point of these shorter certificate durations is to force companies to put in automation that doesn't require 14 layers of paperwork. Some companies will be stubborn, and will thus be locked in an eternal cycle of renew->get paperwork started for renew. Most will adapt.

by hananova

3/23/2026 at 8:00:44 PM

Humbly, I disagree with you. What better use of our tax dollars than to automate away as many problems as we can?

by danesparza

3/23/2026 at 3:58:14 PM

It did until it got so short that it created a new potential attack surface — the scripts everyone is using to auto update them.

by dmitrygr

3/23/2026 at 4:01:11 PM

Compared to the manual processes these scripts replaced, I'd put more trust in the automations.

by organsnyder

3/23/2026 at 4:06:30 PM

And the original article shows you how that is going

by dmitrygr

3/23/2026 at 4:16:40 PM

"yet another chore"

use cloudflare, never think about it.

or

use certbot, never think about it.

by allthetime

3/23/2026 at 4:24:47 PM

I am curious how long the approval process in some large corp or the military would be for either of those options...

Hand over our private keys to a third party or run this binary written by some volunteers in some basements who will not sign a support contract with us...

by dmitrygr

3/23/2026 at 5:46:21 PM

I've worked with large "enterprises" that refuse to use the easy-to-automate certificate services, including AWS Certificate Manager. They would rather continue to procure certificates through a third party, email around keys, etc. They somehow believe these archaic practices are more secure.

by icedchai

3/23/2026 at 5:29:14 PM

Well they can either automate it, or soon spend literally every waking moment in a cycle of paperwork to chase the next renewal.

The whole point was to force automation, and if corps want to be stubborn that's no skin of my back, the shorter durations are coming regardless.

by hananova

3/23/2026 at 4:56:56 PM

In this case some manual work may need to be done.

by allthetime

3/23/2026 at 3:52:21 PM

Isn't that why certificates expire, and the expiry window is getting shorter and shorter? To keep up with the length of time it takes someone to crack a private key?

by dpoloncsak

3/23/2026 at 5:53:42 PM

No, it has nothing to do with the time to crack encryption. It's to protect against two things: organizations that still have manual processes in place (making them increasingly infeasible in order to require automatic renewal) and excessively large revocation lists (because you don't need to serve data on the revocation of a now-expired certificate).

by JoshTriplett

3/23/2026 at 4:01:51 PM

It's also a "how much exposure do people have if the private key is compromised?"

Yes, its to make it so that a dedicated effort to break the key has it rotated before someone can impersonate it... its also a question of how big is the historical data window that an attacker has i̶f̶ when someone cracks the key?

by shagie

3/23/2026 at 3:55:52 PM

No. The sister comment gave the correct answer. It is because nobody checks revocation lists. I promise you there’s nobody out there who can factor a private key out of your certificate in 10, 40, 1000, or even 10,000 days.

by dmitrygr

3/23/2026 at 4:00:42 PM

I thought I remembered someone breaking one recently, but (unless I've found a different recent arxiv page) seems like it was done using keys that share a common prime factor. Oops!

Fwiw: https://arxiv.org/abs/2512.22720

by dpoloncsak

3/23/2026 at 4:01:11 PM

And in turn making revocation less & less of a pain. Since that was more of the pain, overall it's getting easier.

by SAI_Peregrinus

3/23/2026 at 6:04:42 PM

I also don't get it, why do certificates need to expire?

by koakuma-chan

3/23/2026 at 8:55:43 PM

1) To encourage good security practices in the event of compromise or technical improvements. Original '90s "export approved" SSL certificates were only 56-bits. If sites still used those today, they could be easily cracked.

2) To guarantee a recurring revenue stream for TLS/SSL issuers. Originally certificates were $50 to $100/year and there was a big process around renewal and verification. I remember having to fax in corporate paperwork. What a pain!

by icedchai

3/23/2026 at 6:43:43 PM

Since revocation is also a big pain.

by hugo1789

3/23/2026 at 8:34:09 PM

I bet some guy with a ton of badges on his suit is asking the exact question in some Pentagon boardroom right now.

by RIMR

3/23/2026 at 3:57:21 PM

DNSSEC+DANE will fix it. Soon we will have self-signed certificates once again!

by k33n

3/23/2026 at 4:08:10 PM

I can't wait. Now I can screw up DNSSEC and take out my entire domain in the process.

by icedchai

3/23/2026 at 3:52:18 PM

On the one side all the users will need to prove their ID to access websites, and on the website side the site will have to ask permission to continue operating at ever increasing frequency.

That is the future we have walked into.

by fidotron