HAProxy требует сертификат клиента на определенном URL-адресе и пересылает его на backend
frontend front
bind *:80
bind *:443 ssl crt /etc/haproxy/certs/server.pem ca-file /etc/haproxy/certs/id.crt verify required
option tcplog
mode http
default_backend app
backend app
balance roundrobin
cookie SERVERID insert
option ssl-hello-chk
mode http
option httpclose
option forwardfor
option httpchk get /WebApi/help
server app1 1.1.1.1:443 check ssl fall 1 rise 3 verify none cookie webA
server app2 1.1.1.2:443 check ssl fall 1 rise 3 verify none cookie webB
для определенной страницы / логина / идентификатора мне нужно запросить сертификат клиента и отправить его на серверную часть (IIS), которая будет использовать его для аутентификации, я не могу найти способ запросить сертификат на определенном пути и перенаправление сертификата на бэкэнд также не работает, предыдущая конфигурация использовала "режим tcp", который перенаправляет все в IIS, и он работал, но мне нужно использовать "acl" для пересылки запроса с определенным путем на другой сервер, но " acl "не работает в https, поэтому должен быть http
Вы не можете запросить сертификат для определенного пути, потому что согласование TLS уже завершено до того, как путь известен, поэтому, как только вы знаете путь, уже слишком поздно.
Точно так же невозможно «переслать» сертификат клиента - если этот прокси находится в режиме http , тогда есть два сеанса TLS - один между клиентом и прокси, а другой между прокси и обратным сервером. конечный сервер. Прокси-сервер не имеет закрытого ключа сертификата клиента, поэтому он не может согласовывать TLS с серверной частью, используя сертификат клиента. Если бы можно было использовать чей-то сертификат клиента, не обладая его закрытым ключом, сертифицированный клиент был бы бесполезен - сертификат также является открытым ключом, а открытые ключи являются «общедоступными», потому что сами по себе они не представляют
Можно переслать атрибуты сертификата, представленного клиентом, установив их в качестве заголовков HTTP-запроса в прокси-сервере, используя выборку уровня 5 , но это вряд ли удовлетворит серверную часть, которая должна видеть фактический сертификат.
Можно даже вставить весь сертификат клиента в заголовок запроса для серверной части ...
http-request set-header X-Client-Certificate %[ssl_c_der,base64]
... но маловероятно, что это будет из используйте в описанном вами сценарии.
Точно так же вы можете использовать bind ... ssl ... verify optional вместо required , а затем заблокировать запросы для определенных путей, если сертификат уже был представлен ...
http-request deny if { path_beg /login/idcard } !{ ssl_fc_has_crt }
... это сделает сертификат необязательным, но отклонит запросы с этим префиксом пути, если сертификат еще не был представлен.
Опять же, технически действителен, но не обязательно то, что вам действительно нужно.