Hello
Basically what I need is when I browse /service/ws to use client certificate
authentication otherwise for everything else to use normal ssl termination
This configuration was validated by haproxy and it told that it was correct and
it works but not with Firefox and google chrome.
Please help me with some suggestion cause I really need to make this work
Regards
Peter
> On 24 Aug 2017, at 19:18, Yann Cézard <ycez...@viareport.com> wrote:
>
> Hi Peter,
>
> There are several things which looks really wrong in your config.
>
> Are you sure this configuration is validated by haproxy ? Or did you only
> reload
> and it in facts still uses the old conf ?
>
> On 24/08/2017 15:48, Keresztes Péter-Zoltán wrote:
>> Hello,
>>
>> Sorry I was confused about what the client wanted. First I thought hat they
>> want to talk ssl with the backend but they actually want a client
>> certificate authentication. I have modified my haproxy.cfg with the
>> following configurations:
>>
>> [...]
>> frontend http-in
>> bind 10.0.0.2:80
>> redirect scheme https code 301 if !{ ssl_fc }
>> frontend https-in
>> bind 10.0.0.2:443 ssl crt /etc/ssl/certs/veracityid.com.crt
>> mode http
> That part looks wrong :
>> acl client_ssl path_beg /service/ws
>> redirect location https://10.0.0.2/service/ws
>> <https://10.0.0.2/service/ws> if client_ssl
> It looks like a redirect loop to me.
Probably but I couldn’t think at anything else on how to force the haproxy to
use the client certificate when that path is used.
>> default_backend idfusion_all
>> frontend apidev
>> bind 10.0.0.2:443 ssl crt /etc/ssl/certs/veracityid.com.crt ca-file
>> /etc/ssl/certs/ca-certificates.crt verify required
> => you defined two times the same ip:port, how HAProxy is supposed to know
> which one the user is asking for ?
> I would be surprised if it doesn't throw an error with such a configuration.
Don’t know if this supposed to work or not but it’s actually working
>> [...]
>>
>> This configuration is working on some browsers like safari but it does not
>> work with Firefox or chrome since I am having
>> SSL_ERROR_HANDSHAKE_FAILURE_ALERT
>>
>> Any idea how to fix it?
> You didn't explain what you wanted to achieve, but my guess is that you want
> clients
> to be cert authenticated/validated to access the /service/ws path, and you
> don't care for other
> paths if the client are cert validated or not (you just want to have HTTPS).
> In that case, look at
> https://www.haproxy.com/blog/ssl-client-certificate-management-at-application-level/
>
> <https://www.haproxy.com/blog/ssl-client-certificate-management-at-application-level/>
> (Phase 2: Client Certificate optional)
> => use "verify optional"
> => ensure { ssl_fc_has_crt } if accessing /service/ws
>
> Hope this helps,
>
> Yann
>>
>> Regards,
>> Peter
>>
>>> On 23 Aug 2017, at 10:42, Yann Cézard <ycez...@viareport.com
>>> <mailto:ycez...@viareport.com>> wrote:
>>>
>>> Hi Peter,
>>>
>>> On 23/08/2017 00:48, Keresztes Péter-Zoltán wrote:
>>>> Hello,
>>>>
>>>> I am trying to setup haproxy with two way authentication. While the
>>>> frontend looks good one of the backends is giving me headaches with ssl
>>>> handshake failures.
>>>>
>>>> Here is how the frontends and backends does look like:
>>>>
>>>> frontend http-in
>>>> bind 69.64.57.197:80
>>>> redirect scheme https code 301 if !{ ssl_fc }
>>>>
>>>> frontend https-in
>>>> bind 10.0.0.2:443 ssl crt /etc/ssl/certs/veracityid.com.crt
>>>> mode http
>>>> acl client_ssl path_beg /service/ws
>>>> use_backend test_client_ssl if client_ssl
>>>> default_backend test_all
>>>>
>>>> backend test_all
>>>> mode http
>>>> balance leastconn
>>>> timeout connect 1s
>>>> timeout server 300s
>>>> timeout queue 30s
>>>> option redispatch
>>>> retries 3
>>>> cookie rc_cookie_vers insert indirect nocache secure
>>>> server usloft4778 192.168.0.1:8080 cookie rc_cookie_vers check
>>>> inter 1000 fastinter 500 rise 2 fall 1
>>>> server loft10179 192.168.0.2:8080 cookie rc_cookie_vers check
>>>> inter 1000 fastinter 500 rise 2 fall 1
>>>>
>>>> backend test_client_ssl
>>>> mode http
>>>> balance leastconn
>>>> timeout connect 1s
>>>> timeout server 300s
>>>> timeout queue 30s
>>>> option httpchk GET "/service/ws" "HTTP/1.0"
>>>> cookie rc_cookie_vers insert indirect nocache secure
>>>> server usloft4778 192.168.0.1:8080 ssl verify required ca-file
>>>> /etc/ssl/certs/ca_full.crt crt /etc/ssl/certs/client.crt
>>>> server loft10179 192.168.0.2:8080 ssl verify required ca-file
>>>> /etc/ssl/certs/ca_full.crt crt /etc/ssl/certs/client.crt
>>> You are using the same server:port for both HTTP and HTTPS backends, I
>>> doubt those backend are able to speak HTTP and HTTPS
>>> on the same port.
>>> Not sure what you are trying to achieve, but the config you sent means
>>> that you want :
>>> - to connect to the backend in HTTP mode if path does not begin with
>>> /service/ws
>>> - to connect to the backend in HTTPS mode + client verification if the
>>> path begins with /service/ws
>>>
>>> Not sure what you are trying to do though :
>>> 1. two way auth between client and HAProxy ?
>>> 2. two way auth between HAProxy and backend servers ?
>>>
>>> For the first one, you'll have to configure that in the frontend
>>> (https://www.haproxy.com/blog/ssl-client-certificate-management-at-application-level/
>>>
>>> <https://www.haproxy.com/blog/ssl-client-certificate-management-at-application-level/>)
>>> For the second one, you'll probably have to check the ports you used
>>> between HAproxy and your backends.
>>>>
>>>> Any suggestion to make this work?
>>>>
>>>> Thanks in advance
>>>> Peter
>>> Hope this helps,
>>>
>>> Yann
>>> --------------------------- DISCLAIMER ------------------------- This
>>> message and any attachment are proprietary and confidential information and
>>> might be legally privileged in your country. These elements are intended
>>> solely for the addressee. Any unauthorized use or disclosure, in whole or
>>> in part, is prohibited. E-mails are subject to any alteration, change or
>>> falsification. The sender declines any liability to this message and any
>>> attachment. If you are not the intended recipient of this message, please
>>> delete this message and notify immediately the sender.
>>> --------------------------------------------------------------------
>>
>
> --------------------------- DISCLAIMER ------------------------- This message
> and any attachment are proprietary and confidential information and might be
> legally privileged in your country. These elements are intended solely for
> the addressee. Any unauthorized use or disclosure, in whole or in part, is
> prohibited. E-mails are subject to any alteration, change or falsification.
> The sender declines any liability to this message and any attachment. If you
> are not the intended recipient of this message, please delete this message
> and notify immediately the sender.
> --------------------------------------------------------------------
