Обычно для разгрузки SSL используется Apache в качестве обратного прокси, поэтому Apache обрабатывает все материалы SSL, а внутренний сервер просто управляет простым http. Но можно ли сделать наоборот? Я не говорю о SSLProxy, где Apache и серверная часть общаются через https. Я хочу, чтобы моя серверная часть согласовывала SSL с клиентом.
Немного о том, зачем мне это нужно:
Я работаю с аутентификацией сертификата клиента, и когда аутентификация не выполняется, пользователь получает страницу с ошибкой, не удобную для пользователя. Итак, мы создаем страницу диагностики, чтобы показать пользователю, почему аутентификация не удалась. Эта страница должна разрешать ввод любого сертификата, чтобы мы могли проверить его самостоятельно и выяснить, что не так.
Сначала мы попробовали optional_no_ca настройки на Apache, но он все еще выполняет некоторые проверки, такие как срок годности. Мы смогли заставить его работать с Tomcat (также было удобно делать это с Java).
На данный момент единственным жизнеспособным решением, похоже, является установка второго сервера (физического) с tomcat в качестве передней. Но просто визуализировать одну страницу кажется тяжелым делом.
Если я хорошо понимаю вашу проблему, я могу увидеть другое решение, не связанное с прокси:
по умолчанию клиент попадает на страницу диагностики (сертификат не требуется), которая выполняет фоновый запрос AJAX в защищенную зону. В зависимости от результата запроса JavaScript перенаправляет на защищенную страницу или показывает сообщение, объясняющее, что с сертификатом что-то не так.
Apache не может этого сделать. Если вам нужен промежуточный прокси, но от него не будет никаких операций TLS, ваш прокси по сути является TCP-туннелем.
Некоторое время назад, когда я хотел сделать что-то подобное, я наткнулся на снайпрокси. Мне кажется, что он может делать то, что вы хотите. Если вам нужен Apache для других частей вашего сайта, вы можете запустить Apache за sniproxy. Имейте в виду, что из-за того, как работает SNI в SSL / TLS, вы не можете запускать несколько бэкэндов на одном имени хоста. Используйте что-то вроде www.example.com в Apache и app.example.com для приложения сертификата клиента. Это решение, которое я бы порекомендовал, если у вас есть только один доступный IP-адрес.
Другой альтернативой является просто запуск TCP-прокси, например, с помощью HAproxy, или просто запуск приложения непосредственно на выделенном IP-адресе. Однако в этой ситуации вы теряете возможность запускать несколько сайтов на одном IP-адресе. (нет возможности для vhosts). Это решение, которое я бы порекомендовал, если у вас есть несколько доступных IP-адресов.
Вы не можете точно пройти через это. Но есть несколько приемов, которые вы можете использовать, если хотите изменить свой бэкэнд. Сертификат клиента представляется как часть согласования TLS, которое по определению не может быть выполнено.
Например, вы можете заставить Apache проанализировать сертификат и распространить сведения о сертификате (прошедшем проверку подлинности) с помощью таких директив, как RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s". См. Здесь пример.
Конечно, чтобы использовать это для аутентификации, вам нужно будет ограничить доступ к бэкэнду и использовать TLS между прокси и сервером.
Суть https заключается в том, чтобы убедиться, что клиент и сервер видят друг друга выше сетевого уровня, поэтому apache не может проксировать http на https в бэкэнде.
Помимо снайпрокси, который я вижу в другом ответе, я бы предложил haproxy. Это быстрый TCP-прокси с множеством функций.