Microsoft Teams outage due to expired certificate

The redirect you’re getting is to a “consent” page that’s not actually compliant with the GDPR as it takes a good 5 minutes to opt out of all the bullshit tracking and even then I don’t trust it to actually opt me out and not track.

Yahoo/Verizon is cancer and should die in a fire.

It's a feature, not a bug.

Now I avoid TC at all costs, it's contaminated with vile ad trackers.

https://en.wikipedia.org/wiki/Automated_Certificate_Manageme...

https://tools.ietf.org/html/rfc8555

Even with letsencrypt you still MUST have a monitoring system, notifications going to the right person, and in general an organization that can act on this. The problem is often not technical: your organization must be structured in a way that those notifications are acted upon. If anything, letsencrypt lessens the frequency of those notifications so I posit that it’s even worse from the point of view of validating your organization: with regular certs, you get notified once every year or two.

Anyway, letsencrypt is a good thing: it’s just not a solution to this problem.

Challenge is discovering all the certs that exist across the org (10k+ often) and then having a fully automated renewal process requires a pretty advanced / complex platform - don’t know anyone who has built this tech successfully in house - curious if anyone has though in the HN community?

Disclosure I’m an investor in AppViewX

https://microsoftteams.uservoice.com/

It seems like it's a clone made just to get into this space and everything looks like a generic attempt to throw money into an app to take on Slack.

Whenever Teams comes up on HN, there are people complaining about how much infinitely better some cooler product is. I don't doubt that you see a huge difference, but I feel like I'm listening to a wine expert explain how some $1000 bottle of wine is better than a $20 bottle, when to me they taste the same.

My main worry was about voice and video quality as I’m full time remote, but it’s more or less perfect I think. Haven’t had a disconnect or poor audio/video.

The screen sharing does disconnect some times which is annoying to say the least.

I just don't like the fact I can't control my notifications and chat history well, probably because it's enterprise. There's also a creepy 'get notification when colleague is online' feature that I can't turn off in my privacy settings. Otherwise quite nice.

I interface with too many people, it has brought the dumpster fire of sharepoint to a chat client. I’m now enrolled in 96 teams, 94 of which have no activity.

I think there is a universal law of chat client entropy. All chat clients only get worse over time. The category hit peak UX in 1999 with AIM/Yahoo, and gets worse every day. Eventually, Teams will merge into exchange, and your chats will be specially formatted emails, stored in Sharepoint.

From experience this probably wouldn't fix things.

What often happens is that somebody creates a system that uses a certificate, doesn’t automate renewal, and then the person responsible for renewing it changes teams or leaves the company. Email reminders only go so far—they not only need to go into the right inbox, but the person watching that inbox has to care.

For future reference, it was probably this one: https://news.ycombinator.com/item?id=22222121

It would be nice if they prompted you to 'add to calendar' when you are creating certs.

At larger companies a lot of the issue isn't literally generating reminders, it is making sure they're sent to the correct people/departments and are actioned by anyone.

For example you sometimes have reminders sent to ex-employees, or sent to a mailing list and everyone assuming everyone else is going to action it. Or the reminder gets ping-ponged between multiple managers via email with nobody either able or willing to deal with it.

None of these are tech' issues, and they don't have technology solutions as a consequence. So whenever I see an embarrassing expired cert, I don't assume technical malfunction, I assume political malfunction.

  import ssl
  import OpenSSL

  from datetime import datetime

  cert = ssl.get_server_certificate((www.google.com, 443))
  x509 = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, cert)
  expiry_dt = datetime.strptime(x509.get_notAfter()[:8].decode('utf-8'), '%Y%m%d')

    tcp_client = TCPSocket.new(domain, 443)
    ssl_client = OpenSSL::SSL::SSLSocket.new(tcp_client)
    ssl_client.hostname = domain
    ssl_client.connect
    cert = OpenSSL::X509::Certificate.new(ssl_client.peer_cert)
    ssl_client.sysclose
    tcp_client.close

    certprops = OpenSSL::X509::Name.new(cert.issuer).to_a
    issuer = certprops.select { |name, data, type| name == "O" }.first[1]

    results = {
      valid_on: cert.not_before.utc,
      valid_until: cert.not_after.utc,
      issuer: issuer,
      days_left: (cert.not_after.utc - Time.now.utc).to_i / (24 * 60 * 60),
    }

I appreciate the sentiment but I think it's fine for them to just say "we examined our processes, found out what led to the issue, and have modified procedures". I worry a detailed post mortem would just throw specific folks under the bus (most likely some low level employee who isn't actually the root cause)

if free, simple and it checks your TLS settings too

  alert: TlsCertExpiringSoon
  expr: (probe_ssl_earliest_cert_expiry
    - time()) < (86400 * 14)
  for: 10m
    labels:
    product: Name_of_Product
    severity: page
  annotations:
    description: the tls cert for the URL {{ $labels.instance }} expires in less than 14 days!
  summary: TLS cert for {{$labels.instance}} expiring

https://news.ycombinator.com/from?site=keychest.net

You have to rely on either the code itself checking each time it uses the certificate, and alerting.

Or (taken from elsewhere in this thread) you test it during your build, and hope that someone is still building the code by the time the cert comes up for renewal.

I'll probably be doing both.

Any thoughts on the license? How is it working? Why did you pick that? I like that type of license, but it's not very common. Drone does it too, but I haven't seen many others. You don't have to answer if you don't want to, but it's nice to see people deviating from standard licenses like GPL and MIT since I feel like those make it too easy for large businesses to take advantage of small projects.

Your licensing and attribution pages look like a lot of thought went into it, so you probably have some decent insight.

isn't that what ACME is suppose to do?

https://en.wikipedia.org/wiki/Automated_Certificate_Manageme...

Initially, I made light of a requirement that we send out automated nag emails starting a couple months before the keys expired. With a bit more time and observation it became pretty clear this was a valid concern. I eventually came around, and while I didn't implement the feature, I did create the integration tests.

Making certs is stupid simple. Maintaining them takes some support and we don't always have it at the ready. Remembering to do something once a year or two years isn't something we're particularly built for. We have a habit of forgetting these duties when we hand projects over to others.

I wonder, has Lets Encrypt solved this?

All certificates in the Web PKI are obliged to use SAN (Subject Alternative Name). Although it is often mistaken for some sort of aliasing feature, SAN is the Internet's agreed alternative way to name things. X.509 is intended as part of the X.500 directory system, a global directory system which obviously was never actually built, and so its built-in name scheme doesn't resemble anything that actually exists.

When Netscape invented SSL back in the 1990s they hijacked X.509's Common Name field to write DNS names in, but this field is just defined as arbitrary human readable text. "news.ycombinator.com" is text, but so is "News·YCombinator,coM " and only one of those is a DNS name. So, when the IETF standardised PKIX it designed a dedicated schema for the various types of Internet names to put into certificates, Subject Alternative Names SANs.

Unlike the Common Name a SAN dnsName literally can't be anything but a DNS name using A-labels ("punycode"). So the opportunity for confusion is removed. Since it doesn't need to address universal human text it doesn't need to support weird encodings or anything else.

When PKIX was standardised the existing abuse of Common Name was grandfathered in. PKIX says all certs should list one or more SANs but they may continue to have a DNS name in the Common Name too. The Baseline Requirements, years later, explicitly tell CAs to only use a Common Name which matches one of the SANs they've also baked into the certificate, if there are no SANs they're doing it wrong. Alas, as so often, commercial priorities beat security and so even last decade it was common to find people trying to get away without SANs. However the roll out of Certificate Transparency allowed us to have a clear view, without waiting for incident reports from affected users, of non-compliant certificates still being issued, so we could address it as it happened. A few years ago Firefox and Chrome (and Safari I think?) were able to remove their code for trying to process the human readable Common Name as if it might be important, and so if anybody were to issue such a certificate with no SANs today it wouldn't "work" in popular browsers.

Heck - googling - https://tecadmin.net/auto-renew-lets-encrypt-certificates/

Now, with Let's Encrypt, there's no excuse to not SSL.

All of them. Script jacking, ad insertion, redirection, tracking insertion, etc. are all done at scale by everything from national ISPs to coffe shop routers.

HTTPS provides authenticity of all transmitted data; this is more important than confidentiality because without authenticity you can’t tell that you are talking in secret with an atttacker.

It's barely usable.