I hope someone, especially, @ravenstar68 may be able to help.
I've read all posts similar to this issue, but they don't quite address the precise nature of my problem.
I've been an NTL / VM customer since 2003. I have been hosting a quite high profile website (featured in national mainstream media on many occasions) from a Debian server based at home since 2012.
I've successfully deployed Apache, PHP, MySQL and even SSL certificates without any problems.
For a while I toyed with Bind9 and name servers and even got those working brilliantly to my surprise. But a change of IP address forced on me by Virgin Media in February 2019 made maintaining the name server aspect just too much hassle.
I decided to revert my name servers back to my domain registrar and I experienced the expected significant delay until my own DNS, then VM's local DNS was refreshed, even though my registrar's control panel changes went live within the hour.
Once the DNS settled after a few days, I was shocked to be presented with worrying console error messages in all browsers when viewing my own website from my home VM connection. They were the dreaded ERR_SSL_PROTOCOL_ERROR in Google Chrome (and SSL_ERROR_BAD_MAC_READ in Firefox).
Following industry best practice, I serve HTML from the main "www.mydomain.co.uk" address, while CSS, JS and JPEGs are served from a subdomain "https://static.mydomain.co.uk" at the same IP address. Everything is handled within Apache virtual hosts.
The SSL errors seem to be concentrated on the static content (mainly JPGs) but I'm not 100% sure - it might just be that because JPGs are so numerous, they show the errors more.
The SSL errors affect different JPGs every time a web page is refreshed - seemingly random - and not all JPGs, but a significant majority.
Before I reverted the name servers to my registrar, the website was behaving and performing perfectly and even got an A+ rating at HTTPS test sites. All config files were spot on. All port forwarding was working exactly as expected and still is.
After the name servers had been reverted to the registrar and the initial DNS delay had passed, however, these SSL errors cropped up.
If I make entries in my Windows Host file along the lines of:-
the SSL errors go away instantly, as I am viewing the website directly from my local machine attached to the private network IP address 192.168.0.5.
Likewise, if I delete those Windows Host entries and view my own website from a mobile phone 4G data plan (thereby going through my mobile provider's DNS, not Virgin), or via a Tor connection on my desktop computer, the SSL errors are gone.
This, so far, is similar to many threads on here kindly commented on by @ravenstar68
The difference, though, is that this SSL problem has now been going on since I reverted the name servers on 21 February 2019. It is now mid March! Surely VM's local DNS cache at 126.96.36.199, etc., isn't causing the problem?
If so, please confirm (or otherwise) and hopefully someone can advise a solution.
By the way, I have tried all the "fixes" like ipconfig /flushdns in Windows Admin terminal and the equivalent in Chrome browser. Nothing affects it.
Please help - anyone! Especially @ravenstar68 whose posts I've been scouring in search of the holy grail.
Perhaps it's possible that for whatever reason your site is suddenly being put through VMs filter, have you tried running nslookup on the domain to see if it's returning the expected A record? If it's returning something else check if the IP address being returned is a different VM IP, if so it's likely their filter.
Yes, as soon as I was provided with the new IP address by VM and made the control panel changes at the registrar, within the hour the correct new IP address was being returned by "nslookup" and "dig" commands locally. Then the following day, all global DNS was reflecting the change and the correct DNS 'A' records have been returned ever since.
Using "dig" through VM's DNS returns the correct IP address too and has done since a day after the IP change.
I suspect some aspect of the local Virgin Media DNS cache is the problem but I can't fathom exactly how. Because I would have expected any cache to have been cleared and refreshed after a full three weeks!
Generally nameserver records only have a TTL of 1 day, so they really shouldn't be cached if they still are, if querying the ISP DNS servers returns the IP address you'd expect it to I don't see why you'd be getting the issue you are anyway. Have you asked anyone else you know on VM if they have the same issue when accessing the website?
Also for a website hosted from home you might want to look into Cloudflare for handling the DNS, you could set the static subdomain to go through their caches so that the content can be served more rapidly and with less load on your upstream, plus faster load times for the end user.
Yes, that's another reason why I gave up on attempting to do the DNS for the name server aspect of my website. The nightmare involved in editing all the entries in Bind9 and the fact that my registrar's servers are faster.
That's why I reverted the name servers to my registrar so I could easily change the 'A' records if VM force another IP address change.
But these SSL errors only cropped up after the 21 February name server reversion. All other aspects of my home server are unchanged. The Linux / Debian installation is not corrupted - otherwise it wouldn't serve the website properly anywhere in the world.
I've even totally recreated the SSL certificates (from Let's Encrypt) - they were perfectly valid anyway - and that made no difference to the error messages either.
I need someone with VM insider technical know-how!
; <<>> DiG 9.10.6-P1 <<>> www.sxxxxxxxxxxs.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41077
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.sxxxxxxxxxxxxs.co.uk. IN A
;; ANSWER SECTION:
www.sxxxxxxxxxxs.co.uk. 14400 IN A 86.9.xxx.xxxx
;; Query time: 38 msec
;; SERVER: 188.8.131.52#53(184.108.40.206)
;; WHEN: Thu Mar 14 09:49:05 GMT Standard Time 2019
;; MSG SIZE rcvd: 66
Thanks for supplying the url via PM. I did a quick check and I can connect over Chrome. Doing a quick search suggested users getting this were using Firefox, so I checked using Firefox and again I connected to the site with no issues.
The 14400 TTL means that Virgin Media only caches the entry for 4 hours BTW. (For my part I understand why @DreamOfCheese gave the 1 day quote but in reality there are too .many exceptions to the 1 day rule that I always prefer to check).
@Pagliacci - Have you tried updating OpenSSL on your server? At least one answer suggested that this fixed this for them.
As a Very Insightful Person, I'm here to share my knowledge. I don't work for Virgin Media.
I agree that visitors have no problem actually connecting to the website because the DNS is correct, and was resfreshed within a day of the IP change globally. But I can't figure out what is causing the SSL errors.
Did you click through and visit pages beyond the top level landing page and check whether any SSL errors were generated on the JPGs or other static content served from the https://static.*** addresses?
Meanwhile I shall look at the OpenSSL upgrade you suggest.
Can you point me towards discussions of this precise problem that you have seen?