8 ms·

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

165 points by Eduard 7mo ago

dmitrygr 7mo ago
So what? They keep shortening the validity length of these certificates, making them more and more of a pain to deal with.
- hhh 7mo ago
  because you need to automate it
  - dmitrygr 7mo ago
    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.
    - bombcar 7mo ago
      Shortening certificate periods is just their way of admitting that certification revocation lists are absolutely worthless.
      - nathanaldensr 7mo ago
        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.
      - nightpool 7mo ago
        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.
        pas 7mo ago
        ... 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!
        bombcar 7mo ago
        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.
        crote 7mo ago
        > 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...
        nightpool 7mo ago
        Sure, happy to. The average revocation ticket is something like https://bugzilla.mozilla.org/show_bug.cgi?id=1892419 https://bugzilla.mozilla.org/show_bug.cgi?id=1892419 or https://bugzilla.mozilla.org/show_bug.cgi?id=1624527 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.
    - dpoloncsak 7mo ago
      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?
      - dmitrygr 7mo ago
        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.
        dpoloncsak 7mo ago
        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 https://arxiv.org/abs/2512.22720
      - shagie 7mo ago
        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?
      - JoshTriplett 7mo ago
        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).
    - danesparza 7mo ago
      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.
      - ajsnigrutin 7mo ago
        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.
        hananova 7mo ago
        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.
        ajsnigrutin 7mo ago
        It's the government... they have 30 different services just in that department, made by 30 different companies with 30 different support companies, two of those don't exist anymore, 3 have been bought by cisco, two by google, 2 services are behind some old palo alto web proxy that's centrally managed by some other department, one service is written in cobol, one requires the cert to be on a usb flash drive and another on a memory stick. It's cheaper to pay someone just to take care of the certs (unless their bosses and procurement and accounting messes up) than to fix all that. I've seen government stuff, i wouldn't touch it with a 5m pole.
        hananova 7mo ago
        I don't see how any of that is the CA's problem. As far as I'm concerned, the CA's and browser vendors are entirely in the right to go "Here's the new rules. Adapt. Or don't, we don't care."
    - allthetime 7mo ago
      "yet another chore" use cloudflare, never think about it. or use certbot, never think about it.
      - dmitrygr 7mo ago
        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...
        allthetime 7mo ago
        In this case some manual work may need to be done.
        hananova 7mo ago
        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.
        icedchai 7mo ago
        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.
- gslepak 7mo ago
  Using old compromised certificates is a legitimate MITM attack vector.
  - dmitrygr 7mo ago
    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?
    - smashed 7mo ago
      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.
      - dmitrygr 7mo ago
        This was the predictable outcome of shortening certificate length validity to appoint where they are now.
        lynndotpy 7mo ago
        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-officially-reduce-to-47-days https://www.digicert.com/blog/tls-certificate-lifetimes-will...
        HackerThemAll 7mo ago
        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.
- fidotron 7mo ago
  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.
- k33n 7mo ago
  DNSSEC+DANE will fix it. Soon we will have self-signed certificates once again!
  - icedchai 7mo ago
    I can't wait. Now I can screw up DNSSEC and take out my entire domain in the process.
- SAI_Peregrinus 7mo ago
  And in turn making revocation less & less of a pain. Since that was more of the pain, overall it's getting easier.
- lynndotpy 7mo ago
  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.
  - yesod 7mo ago
    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 https://bgp.he.net/certs#_SearchTab?q=www.public.cyber.mil)
- koakuma-chan 7mo ago
  I also don't get it, why do certificates need to expire?
  - hugo1789 7mo ago
    Since revocation is also a big pain.
  - RIMR 7mo ago
    I bet some guy with a ton of badges on his suit is asking the exact question in some Pentagon boardroom right now.
  - icedchai 7mo ago
    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!
tuwtuwtuwtuw 7mo ago
> Users on civilian network can continue downloads through the Advance tab in the error message. Good stuff.
- DANmode 7mo ago
  “Do you want it or not?” …or were you referring to the piss-poor English used? ^_^
- whalesalad 7mo ago
  "We have sent you a OTP code of 459-312 please check your device and enter this code below"
petcat 7mo ago
Is there anything inherently insecure about an expired cert other than your browser just complaining about it?
- Spooky23 7mo ago
  It's a pretty dopey thing to miss.
- zeroxfe 7mo ago
  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.)
  - jp191919 7mo ago
    >screams of extreme incompetence Not unheard of with the military
    - cozzyd 7mo ago
      Precision lethality, not certificate renewality.
      - hoherd 7mo ago
        Let's not kid ourselves, the lethality isn't even that precise.
        rectang 7mo ago
        "Why not neither?"
        crote 7mo ago
        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...
bilekas 7mo ago
> DoD Cyber Exchange site is undergoing a TSSL Certification renewal TSSL renewal does not cause downtime.. If it's actually done of course.
- Stefan-H 7mo ago
  What is "TSSL"?
  - winstonwinston 7mo ago
    TESLA? They probably meant to say TLS.
  - progbits 7mo ago
    When you can't decide between TLS and SSL.
  - bilekas 7mo ago
    "THE" SSL ... Clearly! /s
    - Stefan-H 7mo ago
      Well I ask because I know it is not a real thing, and you seemingly doubled down acting like it is a real thing, showing that you don't know what you are talking about either.
amluto 7mo ago
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/unclass-cio_memo_update_commercial_certs.pdf 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.
jeroenhd 7mo ago
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.
stephbook 7mo ago
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
- johnisgood 7mo ago
  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 https://wormhole.app/MbljK6#qfysvKJOQh1whLcMz9JXxw
  - stephbook 7mo ago
    This is the screen on my phone. https://wormhole.app/9Xv0p0#Hsq0fhLpWsr8ndJDktt2YQ 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.
    - jeroenhd 7mo ago
      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.
nik282000 7mo ago
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.
- ocdtrekkie 7mo ago
  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.
  - Koffiepoeder 7mo ago
    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.
    - ocdtrekkie 7mo ago
      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.
    - bigfatkitten 7mo ago
      > 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.
supermatt 7mo ago
Clearly this is some advanced cyber-warfare technique intended to cause adversaries tools to fail with an "expired certificate" error...
_slih 7mo ago
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...
- driftnet 7mo ago
  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.
0xbadcafebee 7mo ago
> 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.
- RIMR 7mo ago
  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.
  - mpyne 7mo ago
    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.
driftnet 7mo ago
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.
qcautomation 7mo ago
[dead]
yesod 7mo ago
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 https://bgp.he.net/certs#_SearchTab?q=www.public.cyber.mil)
- piyh 7mo ago
  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.
deleted 7mo ago
[deleted]

165 points by Eduard 7mo ago

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

hhh 7mo ago
because you need to automate it
- dmitrygr 7mo ago
  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.
  - bombcar 7mo ago
    Shortening certificate periods is just their way of admitting that certification revocation lists are absolutely worthless.
    - nathanaldensr 7mo ago
      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.
    - nightpool 7mo ago
      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.
      - pas 7mo ago
        ... 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!
        bombcar 7mo ago
        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.
        crote 7mo ago
        > 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...
        nightpool 7mo ago
        Sure, happy to. The average revocation ticket is something like https://bugzilla.mozilla.org/show_bug.cgi?id=1892419 https://bugzilla.mozilla.org/show_bug.cgi?id=1892419 or https://bugzilla.mozilla.org/show_bug.cgi?id=1624527 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.
  - dpoloncsak 7mo ago
    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?
    - dmitrygr 7mo ago
      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.
      - dpoloncsak 7mo ago
        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 https://arxiv.org/abs/2512.22720
    - shagie 7mo ago
      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?
    - JoshTriplett 7mo ago
      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).
  - danesparza 7mo ago
    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.
    - ajsnigrutin 7mo ago
      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.
      - hananova 7mo ago
        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.
        ajsnigrutin 7mo ago
        It's the government... they have 30 different services just in that department, made by 30 different companies with 30 different support companies, two of those don't exist anymore, 3 have been bought by cisco, two by google, 2 services are behind some old palo alto web proxy that's centrally managed by some other department, one service is written in cobol, one requires the cert to be on a usb flash drive and another on a memory stick. It's cheaper to pay someone just to take care of the certs (unless their bosses and procurement and accounting messes up) than to fix all that. I've seen government stuff, i wouldn't touch it with a 5m pole.
        hananova 7mo ago
        I don't see how any of that is the CA's problem. As far as I'm concerned, the CA's and browser vendors are entirely in the right to go "Here's the new rules. Adapt. Or don't, we don't care."
  - allthetime 7mo ago
    "yet another chore" use cloudflare, never think about it. or use certbot, never think about it.
    - dmitrygr 7mo ago
      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...
      - allthetime 7mo ago
        In this case some manual work may need to be done.
      - hananova 7mo ago
        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.
      - icedchai 7mo ago
        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.
gslepak 7mo ago
Using old compromised certificates is a legitimate MITM attack vector.
- dmitrygr 7mo ago
  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?
  - smashed 7mo ago
    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.
    - dmitrygr 7mo ago
      This was the predictable outcome of shortening certificate length validity to appoint where they are now.
      - lynndotpy 7mo ago
        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-officially-reduce-to-47-days https://www.digicert.com/blog/tls-certificate-lifetimes-will...
      - HackerThemAll 7mo ago
        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.
fidotron 7mo ago
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.
k33n 7mo ago
DNSSEC+DANE will fix it. Soon we will have self-signed certificates once again!
- icedchai 7mo ago
  I can't wait. Now I can screw up DNSSEC and take out my entire domain in the process.
SAI_Peregrinus 7mo ago
And in turn making revocation less & less of a pain. Since that was more of the pain, overall it's getting easier.
lynndotpy 7mo ago
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.
- yesod 7mo ago
  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 https://bgp.he.net/certs#_SearchTab?q=www.public.cyber.mil)
koakuma-chan 7mo ago
I also don't get it, why do certificates need to expire?
- hugo1789 7mo ago
  Since revocation is also a big pain.
- RIMR 7mo ago
  I bet some guy with a ton of badges on his suit is asking the exact question in some Pentagon boardroom right now.
- icedchai 7mo ago
  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!

tuwtuwtuwtuw 7mo ago

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

DANmode 7mo ago
“Do you want it or not?” …or were you referring to the piss-poor English used? ^_^
whalesalad 7mo ago
"We have sent you a OTP code of 459-312 please check your device and enter this code below"

petcat 7mo ago

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

Spooky23 7mo ago
It's a pretty dopey thing to miss.
zeroxfe 7mo ago
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.)
- jp191919 7mo ago
  >screams of extreme incompetence Not unheard of with the military
  - cozzyd 7mo ago
    Precision lethality, not certificate renewality.
    - hoherd 7mo ago
      Let's not kid ourselves, the lethality isn't even that precise.
      - rectang 7mo ago
        "Why not neither?"
      - crote 7mo ago
        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...

bilekas 7mo ago

> DoD Cyber Exchange site is undergoing a TSSL Certification renewal TSSL renewal does not cause downtime.. If it's actually done of course.

Stefan-H 7mo ago
What is "TSSL"?
- winstonwinston 7mo ago
  TESLA? They probably meant to say TLS.
- progbits 7mo ago
  When you can't decide between TLS and SSL.
- bilekas 7mo ago
  "THE" SSL ... Clearly! /s
  - Stefan-H 7mo ago
    Well I ask because I know it is not a real thing, and you seemingly doubled down acting like it is a real thing, showing that you don't know what you are talking about either.

amluto 7mo ago

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/unclass-cio_memo_update_commercial_certs.pdf 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.

jeroenhd 7mo ago

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.

stephbook 7mo ago

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

johnisgood 7mo ago
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 https://wormhole.app/MbljK6#qfysvKJOQh1whLcMz9JXxw
- stephbook 7mo ago
  This is the screen on my phone. https://wormhole.app/9Xv0p0#Hsq0fhLpWsr8ndJDktt2YQ 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.
  - jeroenhd 7mo ago
    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.

nik282000 7mo ago

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.

ocdtrekkie 7mo ago
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.
- Koffiepoeder 7mo ago
  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.
  - ocdtrekkie 7mo ago
    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.
  - bigfatkitten 7mo ago
    > 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.

supermatt 7mo ago

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

_slih 7mo ago

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

driftnet 7mo ago
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.

0xbadcafebee 7mo ago

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

RIMR 7mo ago
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.
- mpyne 7mo ago
  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.

driftnet 7mo ago

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.

qcautomation 7mo ago

[dead]

yesod 7mo ago

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 https://bgp.he.net/certs#_SearchTab?q=www.public.cyber.mil)

piyh 7mo ago
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.

deleted 7mo ago

[deleted]