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

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

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.

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.

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.

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.)

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.)

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

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.

> 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.

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.

> 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.

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

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...

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

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

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.

Using old compromised certificates is a legitimate MITM attack vector.

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

because you need to automate it

What is "TSSL"?

“Do you want it or not?”

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

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?

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

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

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

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.

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).

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.

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.

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

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.

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

You're training users to click away error messages.

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.

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

> 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.

>screams of extreme incompetence

Not unheard of with the military

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?

When you can't decide between TLS and SSL.

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

TESLA? They probably meant to say TLS.

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.

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.

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!

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

Looks to me like they're trying to switch from IdenTrust 1yr certs to LetsEncrypt, but haven't got it right yet (https://bgp.he.net/certs#_SearchTab?q=www.public.cyber.mil)

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.

Since revocation is also a big pain.

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.

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.

Precision lethality, not certificate renewality.

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.

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

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?

"yet another chore"

use cloudflare, never think about it.

or

use certbot, never think about it.

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

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.

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.

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

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.

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.

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.

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.

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.

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

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

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?

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).

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.

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.

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.

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

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

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.

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...

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.

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

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.

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.

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...

"Why not neither?"

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...

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.

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

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.

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.

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

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.

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

... 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!

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

"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.

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.

And the original article shows you how that is going

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