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 对于某些页面/login/ idcard我需要客户端证书，并将其发送到后端（IIS），将用于authentication，我无法find方式来问某些path证书和证书转发到后端也不工作，以前configuration是使用“模式tcp”转发一切到IIS和它正在工作，但我需要使用“acl”转发请求与某些path到另一台服务器，但“acl”不工作在https，所以它应该是http
你不能要求某个path的证书，因为在path已知之前TLS协商已经完成，所以一旦你知道path，就已经太迟了。
同样，不能“转发”客户端证书 – 如果此代理处于mode http则有两个TLS会话 – 一个在客户端和代理之间，另一个在代理和后端服务器之间。 该代理没有客户端证书的私钥，因此无法使用客户端证书与后端协商TLS。 如果可以使用某人的客户证书而不拥有其私钥，那么客户证书将是无用的 – 证书也是公钥，而公钥是“公开”的，因为它们本身并不代表任何有价值的东西
有可能转发由客户端提供的证书的属性 ，通过将它们设置为代理中的HTTP请求头，使用第5层提取，但是不太可能满足需要查看实际证书的后端。
甚至可以将整个客户端证书注入到后端的请求头中。
http-request set-header X-Client-Certificate %[ssl_c_der,base64]
…但这不太可能在你描述的场景中被使用。
同样，您可以使用bind ... ssl ... verify optional而不是required ，然后阻止对特定path的请求，除非证书已经呈现…
http-request deny if { path_beg /login/idcard } !{ ssl_fc_has_crt }
…这将使证书可选，但拒绝具有此path前缀的请求，如果证书还没有出现。
再次，技术上有效，但不一定是你真正需要的。