Error when accessing web page Error code: SSL_ERROR_RX_RECORD_TOO_LONG

This is often a problem with an SSL configuration on the server. Can you call someone in your company's IT department for help?

The websites SSL is broken. HTTPS won't work. Try http://www.akcost.com/ and not httpS://www.akcost.com/

If you need HTTPS to work then you need to contact the person who designed the site to fix it. PS. Even without SSL, the site looks like a splash screen where a webpage should be. Is this supposed to be a completed working website?

The certificate is self-signed. Users will receive a warning when accessing this site unless the certificate is manually added as a trusted certificate to their web browser. You can fix this error by buying a trusted SSL certificate

None of the common names in the certificate match the name that was entered (akcost.com). You may receive an error when accessing this site in a web browser. Learn more about name mismatch errors.

Common name: fileserver.gci.net
Valid from October 17, 2015 to October 14, 2025
Serial Number: 10700073028969615320 (0x947e4bba7a78cfd8)
Signature Algorithm: sha256WithRSAEncryption
Issuer: fileserver.gci.net

https://www.sslshopper.com/ssl-checker.html#hostname=akcost.com

There also appears to be a routing issue - it is completely unreachable with IPv4 from any source IP address not just Cox -

So it really sounds like the hosting of the site is sort of borked, or the site itself isn't set up correctly.

grymwulf said:
it is completely unreachable with IPv4 from any source IP address not just Cox

I didn't address routing because I am not on Cox right now. However I was able to access the server even if the ICMP stopped after hitting the firewall in Alaska between Comcast Business and General Communications. Could anyone post from Cox?

Tracing route to akcost.com [24.237.182.162]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 4 ms 4 ms 4 ms lo0-100.PRVDRI-VFTTP-xx.verizon-gni.net [72.x.x.x]
3 9 ms 6 ms 6 ms B3315.PRVDRI-LCR-22.verizon-gni.net [100.41.0.144]
4 * * * Request timed out.
5 * * * Request timed out.
6 12 ms 11 ms 12 ms 0.ae14.GW13.NYC1.ALTER.NET [140.222.234.197]
7 13 ms 14 ms 14 ms be-200-pe01.60hudson.ny.ibone.comcast.net [75.149.228.13]
8 17 ms 16 ms 17 ms be-33-cr02.newyork.ny.ibone.comcast.net [68.86.84.77]
9 34 ms 34 ms 32 ms be-10305-cr02.350ecermak.il.ibone.comcast.net [68.86.85.202]
10 61 ms 59 ms 62 ms be-10517-cr02.denver.co.ibone.comcast.net [68.86.85.170]
11 78 ms 79 ms 79 ms be-10817-cr01.seattle.wa.ibone.comcast.net [68.86.84.206]
12 80 ms 79 ms 79 ms hu-0-14-0-1-pe05.seattle.wa.ibone.comcast.net [68.86.89.118]
13 80 ms 79 ms 79 ms 66.208.228.250
29 * ^C

I'm using Google DNS for both ipv4 & ipv6.  That said, with Firefox, https://akcost.com yields:

Using unsecure http://akcost.com yields:

Using the provided ipv4 address with an unsecured connection yields the same page you received, teck.  Same result using Chrome, both Chrome & FF latest 64-bit versions.

Looks like HTTP is hitting the IPv6 address and not the IPv4. Those are different because A record and AAA record are different. Im not getting IPv6 because my ISP doesn't offer it. It looks like they don't even have the HE tunneling set up yet. Looking at the Wayback Machine, it  went down sometime between January and March of 2016. 

My guess is the page is down to be fixed. If you look at the cache, the page was never a properly set up webpage to begin with, but gave file access to files on the server.

PS. Warning to anyone trying to help, there are some domains that share the same IP space which are malicious. Ran into one while troubleshooting. Luckily I am in a virtual environment. Heads up to everyone else.