Something like this?
Probably caused by the load balancing techniques used by Facebook.
Essentially, when your computer issues a DNS request to your local DNS server (usually the one run by your ISP), it in turn contacts the authoritative DNS servers for the Facebook domain. Those servers in turn direct the DNS request to Akamai DNS servers, which return an IP address for a Facebook web server based on a number of factors, like geographical distance, load, and congestion.
This has been seen before. A section of that Ars Technica article reveals what has to happen for HTTPS content to be properly delivered over a CDN like Akamai (emphasis mine):
We’ve looked pretty extensively at serving Ars Technica over HTTPS in
the past. Here’s what we’d need to do to make this a reality:
First, we would need to ensure that all third-party assets are served
over SSL. All third-party ad providers, their back-end services,
analytics tools, and useful widgets we include in the page would need
to come over HTTPS. Assuming they even offer it, we would also need to
be confident that they’re not letting unencrypted content sneak in.
Facebook and Twitter are probably safe (but only as of the past few
weeks), and Google Analytics has been fine for quite a while. Our ad
network, DoubleClick, is a mixed bag. Most everything served up from
the DoubleClick domain will work fine, but DoubleClick occasionally
serves up vetted third-party assets (images, analytics code) which may
or may not work properly over HTTPS. And even if it “works,” many of
the domains this content is served from are delivered by CDNs like
Akamai over a branded domain (e.g. the server’s SSL cert is for
*.akamai.com, not for s0.mdn.net, which will cause most browsers to balk).
Next, we would need to make sure our sensitive cookies have both the
Secure and HttpOnly flags set. Then we would need to find a CDN with
SSL abilities. Our CDN works really well over HTTP, just like most
other CDNs. We even have a lovely “static.arstechnica.net” branded
host. CDNs that do expose HTTPS are rare (Akamai and Amazon’s
CloudFront currently support it), and leave you with URLs like
“static.arstechnica.net.cdndomain.com”. It would work, but we’d be sad
to lose our spiffy host name and our great arrangement with CacheFly.
My guess is that your ISP is doing something that affects DNS resolution of one of the domains involved in the FB page request, perhaps directing it to an Akamai server that is not properly configured to serve a Facebook page, thus causing the error.