Feature #8228
closed
HAProxy ssl verify none
0%
Description
Dear All,
I've a strange issue with HAProxy serving HTTPS pages and phones with Android/Chrome. THe issue is the same as described in the following forum: https://stackoverflow.com/questions/19311094/certificate-issue-ssl-page-brings-up-you-need-to-set-a-lock-screen-pin-or-pass.Regarding to the documentation of HAProxy I need to set up the "verify" option to none:"verify [none|optional|required]
This setting is only available when support for OpenSSL was built in. If set
to 'none', client certificate is not requested. This is the default. In other
cases, a client certificate is requested. If the client does not provide a
certificate after the request and if 'verify' is set to 'required', then the
handshake is aborted, while it would have succeeded if set to 'optional'. The
certificate provided by the client is always verified using CAs from
'ca-file' and optional CRLs from 'crl-file'. On verify failure the handshake
is aborted, regardless of the 'verify' option, unless the error code exactly
matches one of those listed with 'ca-ignore-err' or 'crt-ignore-err'."
In the HAProxy package if I set the option "Allows clients without a certificate to connect." then in the config will appears the "SSL verify optional", but I need "SSL verify none". Can you please add one more option for this in the GUI?Kind Regards,
bzgFiles
Updated by Pi Ba over 6 years ago
"If set to 'none', client certificate is not requested. This is the default."
As it is the default you don't need the setting..
Updated by Pi Ba over 6 years ago
p.s.
If you don't want to use client certificates, then just don't configure any of the options related to that.?
Updated by Jim Pingle over 6 years ago
- Status changed from New to Rejected
- Priority changed from High to Normal
Updated by Zoltan Beck over 6 years ago
- File pfsense_1.png pfsense_1.png added
sorry but I think we are talking about different things. So if I use the options like on the screenshot attached, then the pfsense makes the following config:
/var/etc/haproxy/haproxy.cfg file contents:
frontend _blank_https-merged
bind x.x.x.x:443 name x.x.x.x:443 ssl crt /var/etc/haproxy/https_xxx.pem crt ca-file /var/etc/haproxy/clientca__blank_https.pem verify optional crl-file /var/etc/haproxy/clientcrl__blank_https.pem
The problem is the keyword: "verify optional".
To resolve the Android/Chrome compatibility problem Ineed to set up: "verify none"
Updated by Zoltan Beck over 6 years ago
- File pfsense_2.png pfsense_2.png added
But if I use the options like on the screenshot attached, then the pfsense makes the following config:
/var/etc/haproxy/haproxy.cfg file contents:
frontend _blank_https-merged
bind x.x.x.x:443 name x.x.x.x:443 ssl crt /var/etc/haproxy/https_xxx.pem crt ca-file /var/etc/haproxy/clientca__blank_https.pem verify required crl-file /var/etc/haproxy/clientcrl__blank_https.pem
The problem is the keyword: "verify required".
To resolve the Android/Chrome compatibility problem Ineed to set up: "verify none"
Updated by Pi Ba over 6 years ago
I think we have a problem with the word 'ALL' here.
Don't configure a CA to check client certificates against if you don't want to use client certificates. You have configured a ca-file so you apparently do want to use client certificates. Cant have it both ways at the same time.. (Not request them but do check them against a CA to be valid..)
Updated by Zoltan Beck over 6 years ago
Thank you very much for your help, now it's clear what happens, but still I have something unclear.
So we have two sites on https, let's say https://example1.com and https://example2.com and a self signed certificate authority.
The https://example1.com is publicly available.
The https://example2.com is available only if the user has a valid certificate signed by the self signed certificate authority and the certificate CN contains a specified username. I'm using for this a custom ACL: ssl_c_s_dn(cn) -m sub user1 user2 ...
So the question is, how can I resolve both issues? Currently only one of the requirements works. Maybe if I buy one more IP, then I should put the https://example1.com to one of the IP's and disable the CA and put https://example2.com to the other IP and set up the CA?
Updated by Pi Ba over 6 years ago
-Yes buying a extra IP would work could point the example2.com there and have a Frontend specifically for that.
-Other option make a frontend accept the 443 connection in mode TCP, pass it based on SNI to a second/third frontend that does the offloading. But that does mean that traffic will make a little loop on pfSense
Client>FrontendSNI>backendPassToFE1(TCPmode with SNI)>FrontendExample1(SSLoffloading)>BackendExample1>WebServer1 Client>FrontendSNI>backendPassToFE2(TCPmode with SNI)>FrontendExample2(SSLoffloading with CA client validation)>BackendExample2>WebServer2
-Or perhaps the best, but not yet possible option use "crt-list" from haproxy 1.8 which could probably solve it nicely, but the haproxy-devel package webgui on pfSense doesn't use/support that option yet from the gui, [[http://cbonte.github.io/haproxy-dconv/1.8/snapshot/configuration.html#5.1-crt-list]].. It would require some extra settings being available on the webgui.. Not sure yet how i'm going to do that :). That could be a valid feature request though :).
Updated by Zoltan Beck over 6 years ago
Thank you one more time, how/where can I open a feature request? :)
Updated by Pi Ba over 6 years ago
Basically same way you open a bug, just set the Tracker option to 'Feature' which is actually the same as you did for this one. Just make sure to describe it a bit different :). Making clear that you want 2 domains on 1 ip:port with only one of them using client certificates, so using different ssl options based on the sni name. Like in reply #note-8, and noting that support for crt-list probably solves that would be nice. In this current issue there was no mention of 2 domains before #note-8 and the request for 'none' combined with the need for ca-file for another domain was not described in a clear way (not to me anyhow). So probably better start a new 'issue' here on redmine.