Unexpected page redirection from HTTPS to HTTP - wordpress

Question

I was testing a page with Twitter Cards and for the provided URL (I'm simplifying the URL but the output is valid) using Twitters card preview tool:
https://example.net/hello/test-page/
It was pulling the card but with this warning:
INFO: Page fetched successfully
INFO: 16 metatags were found
INFO: twitter:card = summary_large_image tag found
INFO: Card loaded successfully
WARN: this card is redirected to http://example.net/hello/test-page/
The only difference here is that the HTTPS has been switched to HTTP. It is not just Twitter, but FB and LinkedIn too.
Using LinkedIn's link preview tool, it similarly reported:
URL redirect trail
1 301 Redirect https://example.net/hello/test-page/
2 200 Success http://example.net/hello/test-page/
And with Facebooks link debugger:
Response Code
200
Fetched URL
https://example.net/hello/test-page/
Canonical URL
http://example.net/hello/test-page/
Redirect Path
Input URL -> https://example.net/hello/test-page/
301 HTTP Redirect -> http://example.net/hello/test-page/
og:url Meta Tag -> https://example.net/hello/test-page/
So... I check the source of the generated web page and I can confirm:
All OG and Twitter Card related META and LINK tags are not using "http". They are all "https". The canonical LINK tag is also using "https".
If I manually go to the "http" version of the URL in the browser, it redirects me immediately to the "https" version.
Can anyone explain why this might happen, and places where I should start to dig?
One last example, when I run this curl command in Terminal, it also seems fine:
curl -sLD - https://example.net/hello/test-page/ -o /dev/null -w '%{url_effective}'
HTTP/2 200
server: nginx
date: Sun, 23 Aug 2020 16:27:28 GMT
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000
vary: Accept-Encoding
last-modified: Sun, 23 Aug 2020 16:23:11 GMT
cache-control: max-age=43, must-revalidate
x-nananana: Batcache-Hit
vary: Cookie
x-ac: 2.ord _atomic_dca
(In case its relevant; this is a WordPress site but I have no unusual plugins running)

Answer 1

The 'issue' was with hosting provider, in this case Pressable, and because we used Lets Encrypt for SSL certs.
Here are the relevant parts from the support chat:
The reason that this occurs is because on WordPress.com, there wasn't
always free SSL certificates via Let's Encrypt. So, in relation to
Facebook, for example, posts that displayed a Facebook like button
with counts would have a canonical URL at Facebook like
http://myblog.com/some/post. Turning on SSL and 301 redirecting the
http:// version of that page to https:// would wipe out those
like/share counts because Facebook sees the exact same URL with a
different protocol as two distinct things.
So, the implementation had to serve SSL certificates and force SSL for
the millions of sites that were now going to have a free Let’s Encrypt
SSL certificate, but also needed to give these crawlers a way to
access the content over http.
When doing the Pressable implementation of Let’s Encrypt, a lot of it
was copied from WordPress.com, and it was not incorrect to do so.
Pressable also didn’t always have free SSL certificates. If we started
to force the redirection of sites that were always http to https that
had “like” buttons and share counts, those counts would have been
lost.
Can't say I'm thrilled with the answer.