2

With TLS 1.0 disabled this is causing some unneeded troubleshooting for some clients (clients being internal applications of various kinds, mostly case handling applications). By unneeded I mean that off course a warning has been issued about this, but not all system responsible has either read it or fully understood the consequence for their application. So if we could have configured a custom error message/page for clients expecting TLS 1.0 to be supported that would have been great.

Problem is - server returns a generic http 500, and we would like the error message to apply only for the TLS error. Is this in anyway possible for Apache to distinguish between a generic http 500 and a http 500 caused by TLS 1.0 not being supported?

1

you would need to handle this at a higher level(proxy / F5) - a 500 of apache is a failure of it's runtime. Alternatively, you could build(or find, i couldn't find) a middleware mod for apache which is able to wrap any exception in an evaluation process (think try and catch) - this would need to be a mod and would need to essentially wrap every method of the apache runtime - probably why it hasn't been written...

Generally this sort of thing is handled by a proxy or forwarding service that lies above the web server layer in the system architecture and is quite easy to address if you have the availability of said resources. If you do not, then you'll need to better broker your redirect/rewritting processes to afford a "more appropriate" http response when TLS can't be satisfied as the requestor asks

  • And actually just perfect, we use Apache in our test environment to simulate F5 which we have in stage and production. So we can live with not having this feature in test. Thanks! – rhellem Apr 26 '17 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.