Hacker News

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

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

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.

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.

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.

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.

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.

What is "TSSL"?

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

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.

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

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

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.

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

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

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?

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.

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.

You're training users to click away error messages.

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.

It's a pretty dopey thing to miss.

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.

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.

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

MITM

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

“Do you want it or not?”

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

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

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.

Using old compromised certificates is a legitimate MITM attack vector.

because you need to automate it

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

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

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

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.