The operating system my web server runs on is (include version): alpine via docker
My hosting provider, if applicable, is: Azure
I can login to a root shell on my machine (yes or no, or I don’t know): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0
I have helped my client setup an external domain and the letsencrypt appears to work. However when they test internally in their network, the cert appears to be taken over by OpenDNS.
I suspect they are using OpenDNS somehow, but my contacts at the client are not IT so they are unsure themselves.
This isn't an issue with your certificate or LetsEncrypt, simply that they are using an OpenDNS blocklist which is blocking your site. This is manifesting as a broken man-in-the-middle crypto attack. It is an issue with the client's network configuration. Nothing can be done other than get them to turn off the blocking, or use different connectivity that doesn't have this "feature", or switch to a domain that OpenDNS approves of.
I got curious about this thing, I had read in the past some article from a respected Internet expert stating that you should never use public DNS servers, and I got this:
The misconception here is that OpenDNS is what it says on the tin and just an Open public DNS. I guess in some ways it is, but their main product is an Internet blocking service which allows it’s implementors to selectively censor/break the Internet connection for their users by poisoning and faking the DNS results they get.
This doesn’t work well for SSL sites, so they have an adjunct service that that attempts to man-in-the-middle SSL sessions in order to either snoop on the site being accessed or present a meaningful block message (never stuck around on an encumbered connection long enough to work out which).
In order to work properly this service has to be deployed along with their security destroying fake root CA, so many layers of evil here, on all of the devices that may use the connection. Most folks who deploy this s**t are too clueless/powerless to actually understand or do this so instead their hapless users get SSL errors. I’ve lost count of the number of times I’ve seen this on public WiFi.