[HN Gopher] CA Root expired on 30 May 2020
___________________________________________________________________
CA Root expired on 30 May 2020
Author : gionn
Score : 168 points
Date : 2020-05-30 17:16 UTC (5 hours ago)
(HTM) web link (support.sectigo.com)
(TXT) w3m dump (support.sectigo.com)
| snapetom wrote:
| Yep. Got woken up early today for this. We renewed our cert about
| a month and two days ago. Namecheap, the vendor, sent us the bad
| AddTrust cert in the bundle. They weren't updating the bundles
| until two days after we renewed the cert.
| Cymen wrote:
| Same exact thing happened to me (Namecheap, PositiveSSL,
| renewed roughly a month ago). I went the reissue route on
| Namecheap and that fixed it (and I ended up with a certificate
| chain that is one certificate shorter).
| MobileVet wrote:
| This appears to have caused our Heroku managed apps to go offline
| for 70+ minutes.
|
| https://status.heroku.com/incidents/2034
|
| Anyone that was already connected was able to continue accessing
| the sites but new connections failed. This mostly affected web
| users.
|
| Our main app server continued to crank along thankfully (also on
| Heroku) and that kept the mobile traffic going which is 90% of
| our users.
|
| Edit: adding Heroku ticket link
| ta17711771 wrote:
| Surely the current CA paradigm shouldn't continue to be accepted
| by the people who keep infrastructure running anymore?
|
| We need to do something.
| jpalomaki wrote:
| At least for many web apps the future is likely automatically
| created and managed domain validated certificates. Amazon and
| Azure provide these free of charge and then you have Let's
| encrypt.
|
| This does not change the CA paradigm, but removes many
| operational issues.
| admax88q wrote:
| Honestly, certificates should never expire or should expire
| daily. If certificate revocation works then its pointless to have
| expiring certs. Its just a mechanism for CAs to seek rent.
|
| If certificate revocation doesnt work then certs need to expire
| super frequently to limit potential damage if compromised.
|
| A certificate that expires in 20 years does absolutely nothing
| for security compared to a certificate that never expires. Odds
| are that in 20 years the crypto will need to be updated anyways,
| effectively revoking the certificate.
| jakub_g wrote:
| Someone on Twitter (forgot whom, maybe swiftonsecurity?)
| suggested lately in a tongue-in-cheek way that the certs should
| not hard-expire, but instead add an exponentially-increasing
| slowdown at TLS handshake.
|
| Once the slowdown is too big, someone will notice and have a
| look.
| elcomet wrote:
| What if your CA is down for a day? Imagine let's encrypt being
| down for 24 hours and all if it's certificates going invalid.
| That would be millions of websites unavailable..
| josephcsible wrote:
| Exactly. Certificate expiration has never really been about
| security. It's purely for practicality, so that CRLs won't grow
| without bound.
|
| This is especially true now that we have OCSP stapling. From a
| security perspective, a short-lived certificate is exactly
| equivalent to a long-lived certificate with mandatory OCSP
| stapling and a short-lived OCSP response, but the latter is
| much more complicated.
|
| And in this case since it's a root, it goes even further than
| that. Root CA's can't be revoked anyway, so if they're
| compromised, a software update to distrust it is required.
| There's really not a good reason for them to expire at all.
| sleevi wrote:
| It's not true that expiration is not about security. Dan
| Geer's talk in 1998, noted at
| https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html , is
| just as relevant today in the design of key management
| systems.
|
| Expiration is not "just" about cryptographic risk either;
| there are plenty of operational risks. If you're putting your
| server on the Internet, and exposing a service, you should be
| worried about key compromise, whether by hacker or by
| Heartbleed. Lifetimes are a way of expressing, and managing,
| that risk, especially in a world where revocation has a host
| of failure modes (operational, legal/political,
| interoperability) that may not be desirable.
|
| As for Root expiration, it's definitely more complicated than
| being black and white. It's a question about whether software
| should fail-secure (fail-closed) or fail-insecure (fail-
| open). The decision to trust a CA, by a software vendor, is
| in theory backed by a variety of evidence, such as the CA's
| policies and practices, as well as additional evidence such
| as audits. On expiration, under today's model, all of those
| requirements largely disappear; the CA is free to do whatever
| they want with the key. Rejecting expired roots is, in part,
| a statement that what is secure now can't be guaranteed as
| secure in 5 years, or 10 years, or 6 months, whatever the
| vendor decides. They can choose to let legacy software
| continue to work, but insecurely, potentially laying the
| accidental groundwork for the botnets of tomorrow, or they
| can choose to have legacy software stop working then, on the
| assumption that if they were receiving software updates, they
| would have received an update to keep things working / extend
| the timer.
|
| Ultimately, this is what software engineering is: balancing
| these tradeoffs, both locally and in the broader ecosystem,
| to try and find the right balance.
| josephcsible wrote:
| I don't see anything about expiration in that talk.
|
| If you don't have a strong revocation system, then your
| host is vulnerable whether or not you have expiration,
| since attackers aren't going to wait until the day before
| your key expires to try to steal it.
|
| In general, when a CA's root certificate expires, it
| creates a new one and gives it to browser and OS vendors.
| What's the difference between the CA continuing to guard
| their old private key, and starting to guard the new
| private key?
| sleevi wrote:
| Search for "Needham & Schroeder"
|
| It's not either/or expiration vs revocation; they are the
| same thing. Expiration is natural revocation and a
| ceiling function to the overall cost.
|
| The statement "when a CA's root certificate expires, it
| creates a new one" is not a general statement. That's the
| exception, rather than the rule, as evidenced by just
| watching the changes to root stores over the past 30
| years. More CAs have left the CA business / folded / been
| acquired than have carried on. A classic example of this
| is the AOL root, for which the long-standing scuttlebutt
| is that no one knows what happened to the key after AOL
| exited the CA business. The reason it's scuttlebutt, as
| opposed to being a Sky is falling DigiNotar, is that the
| certificate expired. Or, for that matter, look at how
| many CAs have been distrusted. Expiration fits as a
| natural bound for legacy software that doesn't receive
| updates, failing-secure rather than failing insecurely.
| [deleted]
| cheerlessbog wrote:
| Expiration may be useful but how is expiration in 2038
| useful?
| sleevi wrote:
| It isn't, but then again, in 1995 we might have said the
| same for expirations in 2015, and yet so, so many poorly
| managed CAs were expunged in the past 5 years.
|
| A healthy root store would set revocation at a much more
| aggressive period; say, every five years. Every three
| years, the CA applies to have their new root trusted,
| which gives two years to distribute that root to clients
| that need it, while having the old root sign the new
| root, to support an immediate transition to the new root.
| Among other things, this encourages a more robust and
| healthy CA ecosystem, because you don't end up with
| lopsided balances based on "who has the oldest root."
| That imbalance encouraged poor behavior which got CAs
| distrusted, in the past, because they behaved in a manner
| that assumed they were too big, by virtue of being too
| ubiquitous, to fail.
| Ididntdothis wrote:
| I tend to agree. Seems dealing with expiration dates is just
| another burden without real security. If something goes wrong
| you have to revoke now and not wait for another year until the
| cert expires.
| vbezhenar wrote:
| To revoke a certificate you must keep a list of revoked
| certificates. Without expiration date that list would grow
| infinitely. And that list should be downloaded periodically by
| every entity which wants to verify certificate.
| josephcsible wrote:
| They said "certificates should never expire or should expire
| daily". Roots already can't be revoked, so they should never
| expire. Intermediates and leaves should expire daily. Since
| currently, OCSP responses are often valid for that long,
| there'd be no need for revocation anymore then.
| compumike wrote:
| Stripe Webhooks are currently failing "for some users"
| https://twitter.com/stripestatus/status/1266756286734938116 --
| some chance that's related.
|
| Edit: for https://www.circuitlab.com/ we saw all Stripe webhooks
| failing from 4:08am through 12:04pm PDT today with "TLS error".
| Since 12:04pm (5 minutes ago), some webhooks are succeeding and
| others are still failing.
|
| Edit 2: since 12:17pm all webhooks are succeeding again. Thanks
| Stripe!
| compumike wrote:
| For backwards compatibility, I updated our intermediate
| certificates to provide the AAA Certificate Services signing
| https://censys.io/certificates/68b9c761219a5b1f0131784474665...
| to replace the expired 2nd intermediate certificate. (Modifying
| the "GandiStandardSSLCA2.pem" file in my case.)
| PixelPaul wrote:
| The amount of times I told the CA that this will be an issue is a
| lot. And the amount of time they replied saying there will be no
| issue is every single time. Dam I hate CAs like Comodo
| zouhair wrote:
| I was wondering why Lynx started spouting some nonsense:
| $ lynx -dump https://wiki.factorio.com/Version_history
| Looking up wiki.factorio.com Making HTTPS connection to
| wiki.factorio.com SSL callback:certificate has expired,
| preverify_ok=0, ssl_okay=0 Retrying connection without
| TLS. Looking up wiki.factorio.com Making HTTPS
| connection to wiki.factorio.com SSL callback:certificate
| has expired, preverify_ok=0, ssl_okay=0 Alert!: Unable to
| make secure connection to remote host. lynx:
| Can't access startfile https://wiki.factorio.com/Version_history
| halukakin wrote:
| Site24x7's ssl monitor caught this for us yesterday. And i
| thought they were wrong as we purchased this last certificate
| just a few months back.
| vld wrote:
| ip-api.com was also affected by this. After our first alert at
| 10:49 (cert expired at 10:48:38) and a minute of being puzzled as
| to why our certificate expired, we realized the root we bundled
| is the issue. We finished updating our primary API servers at
| 10:55.
| LeonM wrote:
| This one bit me today and abruptly ended my day at the beach.
|
| The certificate reseller advised my customer that it was okay to
| include the cross-signing cert in the chain, because browsers
| will automatically ignore it once it expires, and use the Comodo
| CA root instead.
|
| And that was true for browsers I guess. But my customer also has
| about 100 machines in the field that use cURL to access their
| HTTPS API endpoint. cURL will throw an error if one of the certs
| in the chain has expired (may be dependent on the order, don't
| know).
|
| Anyway, 100 machines went down and I had a stressed out customer
| on the phone.
| 0x0 wrote:
| Sounds like a good test case for exercising those otherwise
| useless "million dollar insurances" that some certificate
| vendors flash in their sales materials?
| donmcronald wrote:
| Have you ever read the terms? I don't know if they even
| publish them anymore, but I read one many years ago. TLDR;
|
| 1. The CA must misissue a cert.
|
| 2. The misissued cert is used by a malicious party to
| impersonate you.
|
| 3. Every user (your users) must prove their damages and claim
| individually.
|
| 4. There might have been a low maximum, per-user claim, but I
| can't remember.
|
| I'd be amazed if there's a single person on the internet
| who's been paid out by that warranty.
| mehrdadn wrote:
| Is that a cURL bug?
| mshade wrote:
| It seems only to be older versions of curl or curl with
| openssl <= 1.1.1. My macbook's curl fails, but my arch linux
| box's curl works fine.
| pixmin wrote:
| Everything is fine with PKI and SSL certificates. It was a bug in
| OpenSSL 1.0.1 / 1.0.2 in dealing with two times cross-signed root
| CA. It is fixed in 1.1.1, but these older versions are still
| default on RHEL6/RHEL7/Centos6/Centos7 and even Ubuntu16.04.
|
| I think a large portion of online communications have been
| affected today.
| m-p-3 wrote:
| That explains why some of Integromat automations failed, they
| rely on Sectigo when I checked this morning.
| luckylion wrote:
| Any predictions how much the usage of _CURLOPT_SSL_VERIFYPEER,
| false_ will increase in the next 7 days?
| gregmac wrote:
| Yikes.. yeah, if you're going to do this, consider wrapping it
| in an `if (date < 2020-06-15)` and be sure to fix it properly
| before then. This reduces the ability to just forget about it
| (or have the fix constantly deprioritized) and leave your
| software with a security vulnerablty.
| elithrar wrote:
| Predictions?
| https://github.com/search?o=desc&q=SSL+verify&s=committer-da...
|
| :)
| josephcsible wrote:
| IMO, there's a bit of a design flaw with curl here. There
| should be an easy flag to say "trust the particular certificate
| with this hash, no matter what's wrong with it", but there
| isn't, so people instead use the one that says "trust whatever
| certificate you get, no matter what's wrong with it".
| user5994461 wrote:
| Trusting a specific hash would blow up when the service
| rotate its self-signed certificate, defeating the point of
| ignoring certificate error.
| josephcsible wrote:
| If you're rotating a self-signed certificate, then how do
| you suppose that clients securely trust it? Or if you just
| mean replacing it when it expires, then this could instead
| be tied to the underlying public key alone, which can be
| reused.
| elithrar wrote:
| Great thread by Ryan Sleevi tracking the many (and growing)
| reports of issues caused by this root expiring:
| https://twitter.com/sleevi_/status/1266647545675210753
|
| Top offender so far seems to be GnuTLS.
| Mojah wrote:
| This issue is largely cause by people still stuffing old root
| certificates in their certificate chains, and serving that to
| their users.
|
| As a general rule of thumb:
|
| 1) You don't need to add root certificates to your certificate
| chain
|
| 2) You especially don't need to add expired root certificates to
| the chain
|
| For additional context and the ability to check using `openssl`
| what certificates you should modify in your chain, I found this
| post useful: https://ohdear.app/blog/resolving-the-addtrust-
| external-ca-r...
| toast0 wrote:
| You shouldn't need to send the root certificate (unless the
| clients are _really_ dumb, but I worked with a lot of dumb
| clients, and did not see any issues with only sending
| intermediates and the entity cert), but a fair number of cert
| chain verifiers are fairly dumb and won't stop when they get to
| a root they know which makes things tricky.
|
| If some of your clients don't have the UserTrust CA, but do
| have the AddTrust CA, up until today, you probably wanted to
| include the UserTrust CA cert signed by AddTrust. Clients with
| the UserTrust CA _should_ see that the intermediate cert is
| signed by UserTrust and not even read that cross signed cert,
| but many do see the cross signed cert and then make the trust
| decision based on the AddTrust CA.
|
| It's hard to identify clients in the TLS handshake to give them
| a cert chain tailored to their individual needs; there's some
| extensions for CA certs supported, but they're largely unused.
| encoderer wrote:
| Any guess at what percentage is this versus the case where
| these certs are cross-signed with a newer root but older
| clients with outdated bundles do not trust the newer root?
|
| (At Cronitor, we saw about a 10% drop in traffic, presumably
| from those with outdated bundles)
| Mojah wrote:
| Hard to say, as we don't have any insights into the client-
| side. But we can say that only ~2% of our clients had
| expiring root certificates in their chain in the last few
| weeks, so it's definitely a minority.
|
| Since you don't control the clients in anyway, it might be
| that there are clients that haven't updated their local
| certificate stores in ages and don't yet trust the new root
| certificates.
| seibelj wrote:
| DataDog failed this morning because of root CA issue.[0] Was a
| fun Saturday morning with 5000 alarms blowing up my phone.
|
| [0] https://status.datadoghq.com/incidents/6bqpd511nj4h
| Operyl wrote:
| Datadog failed, and our WAF provider failed at the same time
| too (internal services). It was .. rather confusing at it
| seemed like the sky was falling D: .
| jimdigriz wrote:
| Yeah, took me a while to figure this out, the alerts were not
| welcome.
|
| Found it ironic that the top of their page advertises "Security
| Monitoring now available".
| x3n0ph3n3 wrote:
| Thanks for mentioning this, since it caused me to go check
| metrics and find they weren't coming in... Luckily only a
| couple of my alarms come from metrics via the agent itself.
| sleevi wrote:
| Andrew Ayer has a write-up about this at
| https://www.agwa.name/blog/post/fixing_the_addtrust_root_exp...
|
| At the core, this is not a problem with the server, or the CA,
| but with the clients. However, servers have to deal with broken
| clients, so it's easy to point at the server and say it was
| broken, or to point at the server and say it's fixed, but that's
| not quite the case.
|
| I discussed this some in
| https://twitter.com/sleevi_/status/1266647545675210753 , as
| clients need to be prepared to discover and explore alternative
| certificate paths. Almost every major CA relies on cross-
| certificates, some even with circular loops (e.g. DigiCert), and
| clients need to be capable of exploring those certificates and
| finding what they like. There's not a single canonical "correct"
| certificate chain, because of course different clients trust
| different CAs.
|
| Regardless of your CA, you can still do things to reduce the
| risk. Using tools like mkbundle in CFSSL (with
| https://github.com/cloudflare/cfssl_trust ) or
| https://whatsmychaincert.com/ help configure a chain that will
| maximize interoperability, even with dumb and old clients.
|
| Of course, using shorter lived certificates, and automating them,
| also helps prepare your servers, by removing the toil from
| configuring changes and making sure you pickup updates (to the
| certificate path) in a timely fashion.
|
| Tools like Censys can be used to explore the certificate graph
| and visualize the nodes and edges. You'll see plenty of sites
| rely on this, and that means clients need to not be lazy in how
| they verify certificates. Or, alternatively, that root stores
| should impose more rules on how CAs sign such cross-certificates,
| to reduce the risk posed to the ecosystem by these events.
| telesilla wrote:
| Andrew Ayer's tip on getting Debian sorted may have saved me
| hours.
| mehrdadn wrote:
| Given you mention OpenSSL is _currently_ terrible at verifying
| "real" certificates: why doesn't e.g. Google just throw a bit
| of money at them and fix their bugs when they're clearly so
| well-known? It seems like such an obvious thing to do for a
| company whose entire business is built on the web. Is there
| really too little benefit to justify the cost of the
| engineer(s) it would take even for big companies? Or are the
| projects somehow blocking help?
| sleevi wrote:
| Google has, in the past. Look at the ChangeLog for 1.0.0 -
| the massive improvements made (around PKITS) were sponsored
| by Google.
|
| Google has a healthy Patch Rewards program (
| https://www.google.com/about/appsecurity/patch-rewards/ )
| that rewards patches to a variety of Open Source Projects.
|
| Google also finds a variety of projects through the Core
| Infrastructure Initiative (
| https://www.coreinfrastructure.org/ ), which OpenSSL is part
| of https://www.coreinfrastructure.org/announcements/the-
| linux-f...
| fragsworth wrote:
| Some users on Safari (probably old versions) appear to be getting
| bad cert warnings for https://www.playsaurus.com. REALLY glad I
| found this post here, it was driving me nuts.
| CaveTech wrote:
| FWIW I'm getting cert errors on that site on the latest chrome.
| foepys wrote:
| I don't. Isn't chrome using the systems CA store and
| encryption infrastructure if possible? At least on Windows
| it's using Windows' built-in certs.
| badrabbit wrote:
| Shouldn't it be fairly simple to monitor expiry's that affect a
| lot of sites using censys.io dataset?
| 0x0 wrote:
| Are we going to experience the same bug next year for all
| LetsEncrypt certificates when the DST Root CA X3 expires? I guess
| modern devices could deal with LetsEncrypt issuing directly from
| their own modern ISRG Root X1, but would that leave legacy
| clients completely stranded (iOS <10, older versions of Windows
| and Android...?)
| bransonf wrote:
| Fairly certain this affected Kroger. My sister called me this
| morning asking to troubleshoot why her laptop was warning of an
| unsecured connection.
|
| Perhaps a coincidence, but also likely that their cert expired.
| niffydroid wrote:
| Thankfully our uptime services spotted this earlier in the week.
| I'm terrible with certs, so no idea why a cert we brought this
| year is even using this root ca. To be honest, things like let's
| encrypt or cloud services which manage ssl is a great help
| taypo wrote:
| We had our CI systems fail today because of this. They were
| running Ubuntu 16.04. Check the below thread, they say an openssl
| bug is also a contributing factor. Removing the expired root CA
| fixed the issue for me. (edit: removed from the clients)
|
| https://www.reddit.com/r/linux/comments/gshh70/sectigo_root_...
| itsthecourier wrote:
| Oh god, today was an interesting day. 8am, updating thousands of
| servers CAs...
| encoderer wrote:
| I have never really wanted to go "serverless" until today.
|
| TIL that I can buy a cert that expires in a year that is signed
| by a root certificate that expires sooner. Still not sure WHY
| this is the case, but this is definitely the case.
| ta17711771 wrote:
| Because the certificate authority paradigm is LITERALLY INSANE.
| AmericanChopper wrote:
| It's the PKI paradigm that creates most of the insanity.
| Authentication is still an unsolved issue with PKI, there's
| many ways that you can perform authentication, but all of the
| different approaches lead to one form of insanity or another.
| The CA system has its share of insanity, but it is the most
| successful PKI implementation in history, and by a long way.
| Sphax wrote:
| As far as I understand your certificate is still valid but you
| need to remove the intermediate certificate from your bundle.
| That was the case for me anyway.
| encoderer wrote:
| If your traffic comes from a browser you are fine with this
| but if you're coming from e.g. Curl you will find that you
| need to include an intermediate chain.
|
| (The reason for the difference being that browser stay up to
| date, many old client systems do not.)
|
| We ended up getting a new cert from a different provider.
| ric2b wrote:
| CloudAMPQ (managed RabbitMQ) was affected:
| https://status.cloudamqp.com/
|
| Caused us some connections issues that required a restart of both
| our clients and the rabbitmq cluster.
| CarlHoerberg wrote:
| yes, a bunch of older clusters were affected by this. They
| included an intermediate of USERTrust that was signed by
| AddTrust, clients that didn't check for alternate chains would
| then fail. We pushed the new chain (which now only includes the
| server cert and the Sectigo RSA cert), and dynamically reloaded
| the TLS listener in RabbitMQ, it should have solved it for most
| ppl, email support@cloudamqp.com if it didn't for you. We're
| sorry we didn't pushed this earlier. We were aware that the
| AddTrust would expire during the life time of the server
| certificate, but we assumed that all TLS client would find the
| valid chain regardless, that assumption was obviously wrong.
| jeffbee wrote:
| Quick reminder from your friendly local SRE: never ever issue
| certificates that expire on weekends. Make certs expire in the
| middle of the afternoon on a business day wherever your operators
| live and work. The cert in question expires at May 30 10:48:38
| 2020 GMT, which smells suspiciously like a fixed time after the
| cert was generated, rather than at a well-chosen point in time.
| encoderer wrote:
| Great tip. Did you notice that cert in this case was issued 20
| years ago? It's crazy to me that it was still being used to
| sign certs as recently as last week (according to twitter)
| jeffbee wrote:
| Of course, but that doesn't really excuse them. My first
| experience with middle-of-Sunday-night SSL certificate
| expiration was in December 1998, and it was already a well-
| known doctrine by then. I'd expect a commercial certificate
| authority to have these kinds of things squared away.
| user5994461 wrote:
| My experience with commercial CA is that they set the
| expiry exactly 1 year from creation. Doesn't matter if it's
| a week end or a holiday.
| jis wrote:
| It's actually worse. The new root (good I believe until 2038)
| uses the same key as the now expired certificate. It has to
| or it would not be possible to validate the certificates that
| were issued. And this new one is a root certificate installed
| in browsers!
|
| What "should" happen is that no certificate should be issued
| with an expiration date later than the issuing certificate.
| Then as the issuing certificate gets closer to expiration, a
| new one, with a new key pair, should be created and this new
| certificate should sign subordinate certificates.
| jis wrote:
| Sorry to reply to my own comment. But I want to clarify.
| Two certificates (at least) expired. The root named
| "AddTrust External CA Root" and a subordinate certificate
| with a subject of "USERTrust RSA Certification Authority."
| Both expired around the same time.
|
| The "USERTrust RSA Certification Authority" certificate
| signed yet another layer of intermediate certificates.
|
| The "USERTrust RSA Certification Authority" certificate was
| promoted to a self-signed certificate, now in the browser
| trust stores, using the same key pair as the original
| certificate that was signed by "AddTrust External CA Root."
| It has an expiration of 2038 (although that concept is a
| bit vague in a root certificate).
| josephcsible wrote:
| There's actually a third certificate for "USERTrust RSA
| Certification Authority", also using the same key pair,
| signed by a different root called "AAA Certificate
| Services". It looks like the intended replacement for the
| expiring one is this one, rather than the one where it's
| the root itself.
| dylz wrote:
| It is explicitly not a replacement, but some kind of
| legacy fallback that they don't want you to use, but
| exists for enterprise customers that absolutely can't get
| trust.
| josephcsible wrote:
| Are you sure? That's the path that InCommon has been
| providing me for new certificates since they switched
| away from the expiring one.
| beamatronic wrote:
| Also make a Calendar placeholder (like a fake meeting), invite
| a lot of folks or a distribution list, and turn on an alert for
| 24 hours ahead.
| folmar wrote:
| For long-lived certificates they will outlive your calendar
| tech. The bit rot leave maybe the events fine, but anything
| fancier like notifications will fad away.
|
| Source: BTDT 3 times in 7 years, and it was all with "Big
| Enterprise" grade products.
| kjaftaedi wrote:
| "Middle of the afternoon" .. for who?
| lmilcin wrote:
| All my applications use a component that watches certs
| configured (everything in cert and trust store) and returns
| warning in telemetry from the application if any of the
| certificates is less than a week from expiration. This is
| checked periodically while the application runs.
|
| This not only makes sure we don't miss expiration but also
| ensures we don't forget to configure any of the application.
|
| We had a situation when the cert was replaced but the file was
| placed in incorrect path and was not actually used by the app.
| Having the app report on what is actually being in use is the
| best way to prevent this from ever happening.
| kl4m wrote:
| Good old "cert replaced but apache/nginx failed to reload"
| has bitten me more than once...
| [deleted]
| colechristensen wrote:
| I've used this https://manpages.debian.org/testing/nagios-
| plugins-contrib/c...
|
| After one scrambling emergency with a cert expiring in the
| middle of the day, a constant check with warnings and alerts
| a couple of weeks before expiry made a matter of defensive
| organization into something trivial.
| BurningFrog wrote:
| There is just no substitute for Reality!
| btgeekboy wrote:
| If you get to the point where the exact expiration date on the
| certificate matters, you've already lost the game.
| techslave wrote:
| it's more like blue m&m's than an actual requirement
| alasdair_ wrote:
| >it's more like blue m&m's than an actual requirement
|
| Did you mean Van Halen's famous "WARNING: ABSOLUTELY NO
| BROWN M&Ms" clause?
|
| https://www.snopes.com/fact-check/brown-out/
| colechristensen wrote:
| Engineering for failure is important, you should always set
| yourself up so that you have several lines of defence which
| can fail. Some lines of defence to make failing "impossible"
| others to make a fail softer, even when you think failing is
| impossible.
| DavidSJ wrote:
| Defense in depth.
| dvdkhlng wrote:
| This just hit me via Debian's 'apt-get update': I'm using jitsi's
| package repository which is hosted via HTTPS and seems to rely on
| the expired root-CA. Certificate checks started failing for
| everybody a few hours ago [1].
|
| That's quite bad, as I tried to do a clean re-install of jitsi-
| meet, and now I have no installation at all any more.
|
| [1] https://github.com/jitsi/jitsi-meet/issues/6918
___________________________________________________________________
(page generated 2020-05-30 23:00 UTC)