LinkedIn Bot just lost TLS 1.3 support

     

The problem

Sometimes I post my stuff to LinkedIn to maybe get a few more clicks. And it’s been working just fine. Posting involves LinkedIn’s bot to fetch info about the URL, render the OpenGraph data, like headline, og:image thumbnail, and so on, in a nicely formatted preview card.

And this is precisely what broke for me in recent weeks.

Cannot display preview. You can post as is, or try another link.

The investigation

The strange thing is that I knew it worked, because I posted my previous article just 3 weeks ago there:

So what gives? They have a post inspector too, but it’s not much help either:

We cannot display a preview for this URL.
We encountered a server error while trying to inspect the URL.
0 undefined

Rofl, that’s so much better. Not. So then I went into the JavaScript console, which complained about some headers and policies blocking Google fonts. I have several headers set, like X-Content-Type-Options, X-XSS-Protection, Content-Security-Policy, Referrer-Policy, X-Frame-Options, so I turned them all off. Of course, nothing improved.

So then I looked at the nginx access logs, and it confirmed my suspicion: the requests don’t even make it to my server. Soooo that means it’s blocked by Cloudflare in front of my server.

Welp, I guess we’re making progress. In the meanwhile I also find the OpenGraph tester, but it also fails miserably:

Request failed with status code 403 Forbidden

Well, well. So at this point I go to Cloudflare settings, and start turning things off:

  • Security Level: Essentiall Off
  • Browser Integrity Check: Off
  • Bot Fight Mode: Off

And THEN, after the third change, the OpenGraph site immediately starts working. Yay! Then I also find the actual blocks on Cloudflare’s site under Security / Events:

So yeah, it was Bot Fight Mode blocking OpenGraph. But not LinkedIn. There’s absolutely no trace of LinkedIn here. And it just won’t work, even after turning off Bot Fight Mode. Not to mention that Cloudflare actually introduced the concept of Friendly Bots back in 2022, and LinkedIn is indeed listed on their Verified Bots list as well, so it can’t be it.

So what the actual feck broke in the past 3 weeks that makes LinkedIn unable to render previews for my blog posts?

I then make a completely wild guess and go to TLS settings. I bumped Minimum TLS Version to 1.3 about a year ago, because I figured, if you want to use a browser that’s older than 5 years, you might as well get off my site. So now I changed the minimum TLS version from 1.3 back to 1.2. And guess what, within minutes, both the LinkedIn post inspector and LinkedIn itself start rendering the previews correctly:

Facepalm, facepalm, facepalm.

The conclusion

It’s just so many so stupid things at once, but let me try to summarize it:

  • Depending on your settings, Cloudflare may block certain bots. These bots are sometimes scraper bots that send legitimate requests to your site to render previews for your links.
  • Cloudflare has a built-in, manually curated list of “friendly bots”. The site you try to post on may or may not be on this list.
  • LinkedIn used to support TLS 1.3 in its scraper bot called “LinkedIn Bot”, but sometime in March 2023 they broke it and now it’s only capable to send TLS 1.2 requests.
  • Twitter never supported TLS 1.3. Link previews work on 1.2, but not on 1.3, period.
  • Facebook’s been supporting TLS 1.3 for a good while, and it’s still functional at the time of writing.

So now the only question is, how did this happen? My best guess is that for whatever reason the DevOps engineers at LinkedIn downgraded the servers/containers/pods/whatever used to fetch URL information. For example, a RHEL 8 to RHEL 7 downgrade is precisely a case where this would happen. Please note that this is not limited to Red Hat Enterprise Linux, it applies to all derivates, like CentOS, Rocky, Alma Linux, etc.

And why would anyone downgrade from EL8 to EL7, you might ask? Because Red Hat acquired CentOS, and after a short while, as a funny coincidence, the CentOS project announced they’re shifting their focus to CentOS Stream. Let me translate: if you want proper support, buy RHEL. They didn’t have the nerve the screw over existing CentOS 7 users, so it led to a funny situation where CentOS 7’s EOL occurs later than that of CentOS 8.

But this is 100% speculation. The morale of the story is that:

  • Even the seemingly most irrelevant changes can lead to completely random side effects. Call it the butterfly effect, if you wish.
  • Never ever neglect regression testing. Testing is life.

Update: right after publishing this article, CentOS was kind enough to remind us that even for CentOS 7, the EOL is nearing. How cute <3