# Custom 404 error page? **URL:** \ **Category:** Network\ **Created:** [1 October 2020 04:42 UTC](https://community.ipfire.org/t/custom-404-error-page/3324 "2020-10-01T04:42:45Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![pmueller](https://community.ipfire.org/user_avatar/community.ipfire.org/pmueller/32/9019_2.png) [@pmueller](https://community.ipfire.org/u/pmueller)\ **Post date:** [5 October 2020 14:24 UTC](https://community.ipfire.org/t/custom-404-error-page/3324/4 "2020-10-05T14:24:58Z")
Hi Dave, > So, is there no way to redirect bad https links to a meaningful page as with http ?? not really, as such kinds of redirections is precisely what a we are trying to avoid by validating DNSSEC, enforcing HTTPS across all places and prevent downgrades to HTTP. > In places I have worked the 404 page took customers to a help page with links to contact numbers/customer service/etc. Since IPFire’s web proxy is not able to intercept HTTPS/TLS connections for security reasons (as discussed [here](https://community.ipfire.org/t/blockage-page-http-for-https/2986/7)), I am afraid you cannot display a custom error page to your users if they are trying to reach HTTPS destinations. > That strikes me as something of a backward step. It depends. Intercepting TLS looks like a MITM attack to clients (and servers, if they notice TLS behaviours of their clients closely enough), opening up a huge abuse vector. Further, it requires additional code to be executed on IPFire (currently, the Squid proxy is compiled without SSL/TLS support), processing untrusted data. Ultimately, adding support for this causes more security trouble than it solves. If you want to run such a setup - I happen to administer them in professional environments -, building dedicated server farms with secure CA storage is a better idea anyway, which goes beyond the job of a firewall distribution. Thanks, and best regards, Peter Müller --- _[View the full topic](https://community.ipfire.org/t/custom-404-error-page/3324)._