Re: crashes with 2.0.14

2020-06-09 Thread Sander Hoentjen 

Just created an issue now: https://github.com/haproxy/haproxy/issues/671

Thanks, Sander

On 6/9/20 2:07 PM, Илья Шипицин wrote:

it is a good report. backtraces are very useful

is there github issue filled for it ? if no, can you please create one ?
I hope, it won't be lost that way

вт, 9 июн. 2020 г. в 15:13, Sander Hoentjen <mailto:san...@hoentjen.eu>>:


Is there anybody with a clue? If I need to supply more info I can
do so,
of course.

Kind regards,

Sander

On 6/2/20 4:12 PM, Sander Hoentjen wrote:
> Hi list,
>
> Some time ago (around april 21st) we were using 1.8.13 and we
switched
> from nbthread = 1 to nbthread = 4
>
> This seemed stable for us, but 2 weeks ago we started seeing hangs
> (100% CPU haproxy processes)
>
> We then updated to haproxy 2.0.14. The hangs are gone, but
instead we
> see disappearing haproxy processes.
>
> I turned on coredumps, and I have some output from gdb.
>
> Hope this is helpful in figuring out what's wrong.
>
>
=
>
> (gdb) bt
> #0  0x7fb4770854f5 in raise () from /lib64/libc.so.6
> #1  0x7fb477086cd5 in abort () from /lib64/libc.so.6
> #2  0x0054ce3c in ha_panic () at src/debug.c:207
> #3  0x0054d674 in wdt_handler (sig=14, si= out>, arg=) at src/wdt.c:119
> #4  
> #5  0x7fb47713ccd7 in socket () from /lib64/libc.so.6
> #6  0x004fc75e in my_socketat (conn=0x7fb470036490,
flags=8)
> at include/common/namespace.h:28
> #7  create_server_socket (conn=0x7fb470036490, flags=8) at
> src/proto_tcp.c:257
> #8  tcp_connect_server (conn=0x7fb470036490, flags=8) at
> src/proto_tcp.c:323
> #9  0x004e8c94 in si_connect (s=0x7fb4703ad540) at
> include/proto/stream_interface.h:513
> #10 connect_server (s=0x7fb4703ad540) at src/backend.c:1591
> #11 0x0044f373 in sess_update_stream_int
(s=0x7fb4703ad540) at
> src/stream.c:1015
> #12 0x0045527e in process_stream (t=0x7fb4703b5620,
> context=0x7fb4703ad540, state=)
>     at src/stream.c:2414
> #13 0x0052a875 in process_runnable_tasks () at
src/task.c:413
> #14 0x004980f8 in run_poll_loop (data=)
> at src/haproxy.c:2627
> #15 run_thread_poll_loop (data=) at
> src/haproxy.c:2754
> #16 0x7fb477a25aa1 in start_thread (arg=0x7fb476786700) at
> pthread_create.c:301
> #17 0x7fb47713bc2d in clone () from /lib64/libc.so.6
> (gdb) bt full
> #0  0x7fb4770854f5 in raise () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x7fb477086cd5 in abort () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x0054ce3c in ha_panic () at src/debug.c:207
> No locals.
> #3  0x0054d674 in wdt_handler (sig=14, si= out>, arg=) at src/wdt.c:119
>     n = 
>     p = 
>     thr = 1
> #4  
> No symbol table info available.
> #5  0x7fb47713ccd7 in socket () from /lib64/libc.so.6
> No symbol table info available.
> #6  0x004fc75e in my_socketat (conn=0x7fb470036490,
flags=8)
> at include/common/namespace.h:28
> No locals.
> #7  create_server_socket (conn=0x7fb470036490, flags=8) at
> src/proto_tcp.c:257
>     ns = 0x0
> #8  tcp_connect_server (conn=0x7fb470036490, flags=8) at
> src/proto_tcp.c:323
>     fd = 
>     srv = 0x4850bf0
>     be = 0x25606b0
>     src = 
>     use_fastopen = 0
>     addr = 
> #9  0x004e8c94 in si_connect (s=0x7fb4703ad540) at
> include/proto/stream_interface.h:513
>     ret = 0
>     conn_flags = 
> ---Type  to continue, or q  to quit---
> #10 connect_server (s=0x7fb4703ad540) at src/backend.c:1591
>     cli_conn = 0x7fb4703ca8f0
>     srv_conn = 0x7fb470036490
>     old_conn = 
>     srv_cs = 0x7fb4703eb310
>     srv = 
>     reuse = 
>     reuse_orphan = 
>     init_mux = 1
>     alloced_cs = 
>     err = 
> #11 0x0044f373 in sess_update_stream_int
(s=0x7fb4703ad540) at
> src/stream.c:1015
>     conn_err = 
>     srv = 0x4850bf0
>     si = 0x7fb4703ad840
>     req = 0x7fb4703ad550
> #12 0x0045527e in process_stream (t=0x7fb4703b5620,
> context=0x7fb4703ad540, state=)
>     at src/stream.c:2414
>     srv = 
>    

Re: crashes with 2.0.14

2020-06-09 Thread Sander Hoentjen 
Is there anybody with a clue? If I need to supply more info I can do so, 
of course.


Kind regards,

Sander

On 6/2/20 4:12 PM, Sander Hoentjen wrote:

Hi list,

Some time ago (around april 21st) we were using 1.8.13 and we switched 
from nbthread = 1 to nbthread = 4


This seemed stable for us, but 2 weeks ago we started seeing hangs 
(100% CPU haproxy processes)


We then updated to haproxy 2.0.14. The hangs are gone, but instead we 
see disappearing haproxy processes.


I turned on coredumps, and I have some output from gdb.

Hope this is helpful in figuring out what's wrong.

=

(gdb) bt
#0  0x7fb4770854f5 in raise () from /lib64/libc.so.6
#1  0x7fb477086cd5 in abort () from /lib64/libc.so.6
#2  0x0054ce3c in ha_panic () at src/debug.c:207
#3  0x0054d674 in wdt_handler (sig=14, si=out>, arg=) at src/wdt.c:119

#4  
#5  0x7fb47713ccd7 in socket () from /lib64/libc.so.6
#6  0x004fc75e in my_socketat (conn=0x7fb470036490, flags=8) 
at include/common/namespace.h:28
#7  create_server_socket (conn=0x7fb470036490, flags=8) at 
src/proto_tcp.c:257
#8  tcp_connect_server (conn=0x7fb470036490, flags=8) at 
src/proto_tcp.c:323
#9  0x004e8c94 in si_connect (s=0x7fb4703ad540) at 
include/proto/stream_interface.h:513

#10 connect_server (s=0x7fb4703ad540) at src/backend.c:1591
#11 0x0044f373 in sess_update_stream_int (s=0x7fb4703ad540) at 
src/stream.c:1015
#12 0x0045527e in process_stream (t=0x7fb4703b5620, 
context=0x7fb4703ad540, state=)

    at src/stream.c:2414
#13 0x0052a875 in process_runnable_tasks () at src/task.c:413
#14 0x004980f8 in run_poll_loop (data=) 
at src/haproxy.c:2627
#15 run_thread_poll_loop (data=) at 
src/haproxy.c:2754
#16 0x7fb477a25aa1 in start_thread (arg=0x7fb476786700) at 
pthread_create.c:301

#17 0x7fb47713bc2d in clone () from /lib64/libc.so.6
(gdb) bt full
#0  0x7fb4770854f5 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x7fb477086cd5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x0054ce3c in ha_panic () at src/debug.c:207
No locals.
#3  0x0054d674 in wdt_handler (sig=14, si=out>, arg=) at src/wdt.c:119

    n = 
    p = 
    thr = 1
#4  
No symbol table info available.
#5  0x7fb47713ccd7 in socket () from /lib64/libc.so.6
No symbol table info available.
#6  0x004fc75e in my_socketat (conn=0x7fb470036490, flags=8) 
at include/common/namespace.h:28

No locals.
#7  create_server_socket (conn=0x7fb470036490, flags=8) at 
src/proto_tcp.c:257

    ns = 0x0
#8  tcp_connect_server (conn=0x7fb470036490, flags=8) at 
src/proto_tcp.c:323

    fd = 
    srv = 0x4850bf0
    be = 0x25606b0
    src = 
    use_fastopen = 0
    addr = 
#9  0x004e8c94 in si_connect (s=0x7fb4703ad540) at 
include/proto/stream_interface.h:513

    ret = 0
    conn_flags = 
---Type  to continue, or q  to quit---
#10 connect_server (s=0x7fb4703ad540) at src/backend.c:1591
    cli_conn = 0x7fb4703ca8f0
    srv_conn = 0x7fb470036490
    old_conn = 
    srv_cs = 0x7fb4703eb310
    srv = 
    reuse = 
    reuse_orphan = 
    init_mux = 1
    alloced_cs = 
    err = 
#11 0x0044f373 in sess_update_stream_int (s=0x7fb4703ad540) at 
src/stream.c:1015

    conn_err = 
    srv = 0x4850bf0
    si = 0x7fb4703ad840
    req = 0x7fb4703ad550
#12 0x0045527e in process_stream (t=0x7fb4703b5620, 
context=0x7fb4703ad540, state=)

    at src/stream.c:2414
    srv = 
    s = 0x7fb4703ad540
    sess = 0x7fb4703ca620
    rqf_last = 9469952
    rpf_last = 2147483648
    rq_prod_last = 8
    rq_cons_last = 0
    rp_cons_last = 8
    rp_prod_last = 0
    req_ana_back = 0
---Type  to continue, or q  to quit---
    req = 0x7fb4703ad550
    res = 0x7fb4703ad5b0
    si_f = 0x7fb4703ad7e8
    si_b = 0x7fb4703ad840
    rate = 151
#13 0x0052a875 in process_runnable_tasks () at src/task.c:413
    t = 0x7fb4703b5620
    state = 
    ctx = 
    process = 0x453b30 
    lrq = 
    grq = 
    t = 
    max_processed = 46
#14 0x004980f8 in run_poll_loop (data=) 
at src/haproxy.c:2627

    next = 
    wake = 
#15 run_thread_poll_loop (data=) at 
src/haproxy.c:2754

    ptaf = 
    ptif = 
    ptdf = 
    ptff = 
    init_left = 0
    init_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, 
__nusers = 0, __kind = 0, __spins = 0,
    __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' 
, __align = 0}
    init_cond = {__data = {__lock = 0, __futex = 10, __total_seq = 
5, __wakeup_seq = 5, __woken_seq = 5,

    __mutex = 0xa42120, __nwaiters = 0, __broadcast_seq = 3},
  __size = 
"\000\000\000\000\n\000\000\000\005\000\

Re: kernel panics after updating to 2.0

2019-12-06 Thread Sander Hoentjen 



On 12/6/19 10:20 AM, Pavlos Parissis wrote:

On Παρασκευή, 6 Δεκεμβρίου 2019 9:23:24 Π.Μ. CET Sander Hoentjen wrote:

Hi list,

After updating from 1.8.13 to 2.0.5 (also with 2.0.10) we are seeing
kernel panics on our production servers. I haven't been able to trigger
them on a test server, and we rollbacked haproxy to 1.8 for now.

I am attaching a panic log, hope something useful is in there.

Anybody an idea what might be going on here?


Have you noticed any high CPU utilization prior the panic?

Nothing out of the ordinary, but I have only minute data, so I don't 
know for sure things about seconds before crash.


Also of interest might be that at all the crashes I checked there were 2 
haproxy instances running. One of them has-sf , so the 
other is in "finishing mode".

kernel panics after updating to 2.0

2019-12-06 Thread Sander Hoentjen 

Hi list,

After updating from 1.8.13 to 2.0.5 (also with 2.0.10) we are seeing 
kernel panics on our production servers. I haven't been able to trigger 
them on a test server, and we rollbacked haproxy to 1.8 for now.


I am attaching a panic log, hope something useful is in there.

Anybody an idea what might be going on here?

Kind regards,

Sander Hoentjen

Dec  2 21:17:08 hostname [2409002.997008] NMI watchdog: Watchdog detected hard 
LOCKUP on cpu 12
Dec  2 21:17:08 hostname 
Dec  2 21:17:08 hostname [2409002.999146] Kernel panic - not syncing: Hard 
LOCKUP
Dec  2 21:17:08 hostname [2409003.000808] CPU: 12 PID: 3428667 Comm: haproxy 
ve: 0 Tainted: P   O      
3.10.0-962.3.2.lve1.5.26.2.el6h.x86_64 #1 61.16
Dec  2 21:17:08 hostname [2409003.004086] Hardware name: Supermicro 
SSG-6039P-E1CR16L/X11DPH-T, BIOS 3.1 05/22/2019
Dec  2 21:17:08 hostname [2409003.005737] Call Trace:
Dec  2 21:17:08 hostname [2409003.007316]   [] 
dump_stack+0x19/0x1b
Dec  2 21:17:08 hostname [2409003.008894]  [] panic+0xe6/0x21c
Dec  2 21:17:08 hostname [2409003.010512]  [] 
nmi_panic+0x3b/0x40
Dec  2 21:17:08 hostname [2409003.012081]  [] 
watchdog_overflow_callback+0x11f/0x140
Dec  2 21:17:08 hostname [2409003.013649]  [] 
__perf_event_overflow+0x57/0x110
Dec  2 21:17:08 hostname [2409003.015204]  [] 
perf_event_overflow+0x14/0x20
Dec  2 21:17:08 hostname [2409003.016680]  [] 
intel_pmu_handle_irq+0x245/0x4f0
Dec  2 21:17:08 hostname [2409003.018200]  [] ? 
vunmap_page_range+0x24e/0x450
Dec  2 21:17:08 hostname [2409003.019636]  [] ? 
ghes_copy_tofrom_phys+0x116/0x2c0
Dec  2 21:17:08 hostname [2409003.021053]  [] ? 
ghes_read_estatus+0xa0/0x190
Dec  2 21:17:08 hostname [2409003.022447]  [] 
perf_event_nmi_handler+0x30/0x50
Dec  2 21:17:08 hostname [2409003.023867]  [] 
nmi_handle.constprop.0+0x78/0x130
Dec  2 21:17:08 hostname [2409003.025272]  [] 
do_nmi+0x181/0x480
Dec  2 21:17:08 hostname [2409003.026649]  [] 
end_repeat_nmi+0x1e/0x81
Dec  2 21:17:08 hostname [2409003.028002]  [] ? 
native_queued_spin_lock_slowpath+0x1d2/0x220
Dec  2 21:17:08 hostname [2409003.029297]  [] ? 
native_queued_spin_lock_slowpath+0x1d2/0x220
Dec  2 21:17:08 hostname [2409003.030558]  [] ? 
native_queued_spin_lock_slowpath+0x1d2/0x220
Dec  2 21:17:08 hostname [2409003.031781]   [] 
queued_write_lock_slowpath+0x8b/0x90
Dec  2 21:17:08 hostname [2409003.033003]  [] 
_raw_qwrite_lock+0x29/0x30
Dec  2 21:17:08 hostname [2409003.034228]  [] 
tasklist_write_lock_irq+0x3b/0x50
Dec  2 21:17:08 hostname [2409003.035447]  [] 
do_exit+0x452/0xac0
Dec  2 21:17:08 hostname [2409003.036647]  [] ? 
hrtimer_try_to_cancel.part.27+0x5b/0x100
Dec  2 21:17:08 hostname [2409003.037828]  [] 
do_group_exit+0x43/0xb0
Dec  2 21:17:08 hostname [2409003.038982]  [] 
get_signal_to_deliver+0x28c/0x630
Dec  2 21:17:08 hostname [2409003.040084]  [] 
do_signal+0x57/0x710
Dec  2 21:17:08 hostname [2409003.041161]  [] ? 
ep_poll+0x347/0x3d0
Dec  2 21:17:08 hostname [2409003.042210]  [] ? 
cpu_clock_sample+0x85/0xb0
Dec  2 21:17:08 hostname [2409003.043280]  [] ? 
wake_up_state+0x20/0x20
Dec  2 21:17:08 hostname [2409003.044329]  [] 
do_notify_resume+0x72/0xd0
Dec  2 21:17:08 hostname [2409003.045336]  [] 
int_signal+0x12/0x17
Dec  2 21:17:08 hostname [2409003.059190] NMI watchdog: Watchdog detected hard 
LOCKUP on cpu 17
Dec  2 21:17:08 hostname 
Dec  2 21:17:08 hostname [2409003.059225] Modules linked in: cls_fw sch_sfq 
sch_htb kcare(O) arc4 md4 nls_utf8 cifs dns_resolver xt_comment ip6t_REJECT 
nf_reject_ipv6 ip_set_hash_ipport ip_set_hash_ip xt_set ip_set_hash_net 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 nf_log_ipv4 nf_log_common ip_set 
nfnetlink ip6table_filter xt_owner nf_nat_ftp xt_REDIRECT nf_nat_redirect 
xt_conntrack nf_conntrack_ftp ipt_REJECT nf_reject_ipv4 xt_LOG xt_limit 
iptable_filter xt_multiport iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c netconsole 8021q mrp garp stp llc 
bonding kmodlve(O) vzdev ip6table_mangle ip6_tables iptable_mangle xt_mark 
ip_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm 
ib_core binfmt_misc iTCO_wdt iTCO_vendor_support pcspkr zfs(PO) zcommon(PO) 
znvpair(PO) icp(PO) spl(O) zavl(PO) zunicode(PO) ipmi_devintf ipmi_si 
ipmi_msghandler ses enclosure i2c_i801 shpchp lpc_ich joydev mei_me mei sg nfit 
libnvdimm acpi_power_meter acpi_pad acpi_cpufreq ext4 jbd2 mbcache raid1 sd_mod 
crc_t10dif crct10dif_common mpt3sas scsi_transport_sas raid_class i40e ptp 
pps_core ahci libahci libata wmi ast ttm drm_kms_helper drm i2c_algo_bit 
i2c_core dm_mirror dm_region_hash dm_log dm_mod 
Dec  2 21:17:08 hostname [2409003.070286] CPU: 17 PID: 3428639 Comm: haproxy 
ve: 0 Tainted: P   O      
3.10.0-962.3.2.lve1.5.26.2.el6h.x86_64 #1 61.16
Dec  2 21:17:08 hostname [2409003.072324] Hardware name: Supermicro 
SSG-6039P-E1CR16L/X11DPH-T, BIOS 3.1 05/22/2019
Dec  2 21:17:08 hostname [2409003.073366] Call Trace:
Dec  2 21:17:08 hostname

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-05-24 Thread Sander Hoentjen 
On 05/23/2018 09:48 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 23 May 2018 at 18:29, Emeric Brun  wrote:
>> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or 
>> number of request.
>>
>> If /dev/urandom is used as seeding source when haproxy is chrooted it fails 
>> to re-open /dev/urandom 
>>
>> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as 
>> seeding source and fallback on /dev/urandom if not available.
>>
>> So you don't face the issue if your openssl-1.1.1 is compiled to use 
>> getrandom
>>
>> But getrandom syscall is available only since kernel > 3.17 and the main 
>> point: for glibc > 2.25.
>>
>> With openssl-1.1.1 you can check this this way:
>> # ./openssl-1.1.1/openssl version -r
>> Seeding source: getrandom-syscall
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
>
> lukas@dev:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> lukas@dev:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> lukas@dev:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> lukas@dev:~/libsslbuild/bin$
>
>
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).
>
>
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
When I make /dev/*random available in the chroot, indeed it works fine.
Thanks guys!
As you all have guessed, I am indeed running an older kernel that
doesn't have the getrandom syscall.

Regards,
Sander

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-05-23 Thread Sander Hoentjen 


On 05/22/2018 04:31 PM, Sander Hoentjen wrote:
> On 05/22/2018 04:19 PM, Emeric Brun wrote:
>> Hi Sander,
>>
>> On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
>>> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>>>> Hello,
>>>>
>>>> On 22 May 2018 at 11:48, Sander Hoentjen <san...@hoentjen.eu> wrote:
>>>>> I did, but I still experience the same issues. What is your exact
>>>>> haproxy version you tested with? Mine is 1.8.8
>>>>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>>>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>>> I'm using the development tree. So if it doesn't depend on openssl, it
>>>> may be bug that has been fixed in haproxy itself.
>>>>
>>>> Can you try 1.8.9?
>>> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
>>> issue unfortunately.
>>>
>> Do you use chroot ?
>>
>> I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time 
>> (or a number of new sess) openssl
>> try to re-open some /dev/Xrandom sources. And it could fail in a chroot.
>>
>> https://github.com/openssl/openssl/issues/5330
>>
>>
> Thanks, I do use chroot. In that issue it is mentioned that this problem
> has been fixed, but I will test without chroot anyway. Will report
> tomorrow if this worked or not.
I can confirm the issue is gone when I don't use chroot. I will try to
see if I can get more info like a strace soon. I won't be able to today
though. Thanks Lucas and Emeric!

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-05-22 Thread Sander Hoentjen 
On 05/22/2018 04:19 PM, Emeric Brun wrote:
> Hi Sander,
>
> On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
>> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>>> Hello,
>>>
>>> On 22 May 2018 at 11:48, Sander Hoentjen <san...@hoentjen.eu> wrote:
>>>> I did, but I still experience the same issues. What is your exact
>>>> haproxy version you tested with? Mine is 1.8.8
>>>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>> I'm using the development tree. So if it doesn't depend on openssl, it
>>> may be bug that has been fixed in haproxy itself.
>>>
>>> Can you try 1.8.9?
>> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
>> issue unfortunately.
>>
> Do you use chroot ?
>
> I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time 
> (or a number of new sess) openssl
> try to re-open some /dev/Xrandom sources. And it could fail in a chroot.
>
> https://github.com/openssl/openssl/issues/5330
>
>
Thanks, I do use chroot. In that issue it is mentioned that this problem
has been fixed, but I will test without chroot anyway. Will report
tomorrow if this worked or not.

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-05-22 Thread Sander Hoentjen 
On 05/22/2018 12:04 PM, Lukas Tribus wrote:
> Hello,
>
> On 22 May 2018 at 11:48, Sander Hoentjen <san...@hoentjen.eu> wrote:
>> I did, but I still experience the same issues. What is your exact
>> haproxy version you tested with? Mine is 1.8.8
>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> I'm using the development tree. So if it doesn't depend on openssl, it
> may be bug that has been fixed in haproxy itself.
>
> Can you try 1.8.9?
I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
issue unfortunately.

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-05-22 Thread Sander Hoentjen 
On 05/19/2018 04:55 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 19 April 2018 at 11:09, Sander Hoentjen <san...@hoentjen.eu> wrote:
>> I just tried 1.1.1-pre5, and I still have the same issue.
> I'm running 1.1.1-pre6 now with good results. You may want to check that out.
I did, but I still experience the same issues. What is your exact
haproxy version you tested with? Mine is 1.8.8
Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018

-- 
Sander

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-04-19 Thread Sander Hoentjen 
Hi Lucas,

On 04/17/2018 04:27 PM, Lukas Tribus wrote:
> Hello Sander,
>
>
> On 16 April 2018 at 10:55, Sander Hoentjen <san...@hoentjen.eu> wrote:
>> Reading my email again it looks like somehow I messed up part of it,
>> retrying:
>>
>> Hi all,
>>
>> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
>> running haproxy stops accepting new SSL connections.
> I have seen something like that a few weeks ago as well, but I've
> reverted to openssl stable, as I did not have time to get involved
> with troubleshooting openssl master at this point.
>
>
> That having said you may want to retry with latest 1.1.1-pre5, it may
> have been already fixed (Prevent a possible recursion in ERR_get_state
> ...).
I just tried 1.1.1-pre5, and I still have the same issue. What do you
think, is it better to report to the openssl team, or here? I have no
idea where the issue is coming from, but I was hoping the "broken after
exactly 1 hour" would ring some bells.

Sander

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-04-16 Thread Sander Hoentjen 
Reading my email again it looks like somehow I messed up part of it,
retrying:

Hi all,

I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
running haproxy stops accepting new SSL connections. When I restart it
works again for almost(?) exactly 1 hour, then stops. Any idea what
might be causing this, or where I should look? Especially the part that
it works for one hour seems weird to me. Next to that, only SSL
connections stop working, the plain ones continue to work. The setup has
one frontend that accepts both http and https, using:
    tcp-request inspect-delay 500ms
    tcp-request content accept if HTTP
    tcp-request content accept if { req.ssl_hello_type 1 }
Maybe this has something to do with it?
Exactly the same config, with only difference being built agains openssl
1.1.0 works without any issues.

Any help appreciated.

Regards,
Sander


On 04/13/2018 10:27 AM, Sander Hoentjen wrote:
> Hi all,
>
> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
> running haproxy stops accepting new SSL connections. When I restart it
> works again for almost(?) exactly 1 hour, then stops.
> Any idea what might be causing this, or where I should look
>
> # haproxy -vv
> HA-Proxy version 1.8.7 2018/04/07
> Copyright 2000-2018 Willy Tarreau <wi...@haproxy.org>
>
> Build options :
>   TARGET  = linux2628
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -fno-strict-overflow -Wno-unused-label
>   OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
> USE_PCRE=1
>
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with network namespace support.
> Built with zlib version : 1.2.3
> Running on zlib version : 1.2.3
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with PCRE version : 7.8 2008-09-05
> Running on PCRE version : 7.8 2008-09-05
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with multi-threading support.
> Encrypted password support via crypt(3): yes
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Built with OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
> Running on OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
>
> Available polling systems :
>   epoll : pref=300,  test result OK
>    poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available filters :
>     [TRACE] trace
>     [COMP] compression
>     [SPOE] spoe
>
> Regards,
> Sander Hoentjen
>

Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

2018-04-13 Thread Sander Hoentjen 
Hi all,

I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
running haproxy stops accepting new SSL connections. When I restart it
works again for almost(?) exactly 1 hour, then stops.
Any idea what might be causing this, or where I should look

# haproxy -vv
HA-Proxy version 1.8.7 2018/04/07
Copyright 2000-2018 Willy Tarreau <wi...@haproxy.org>

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -fno-strict-overflow -Wno-unused-label
  OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with network namespace support.
Built with zlib version : 1.2.3
Running on zlib version : 1.2.3
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 7.8 2008-09-05
Running on PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with multi-threading support.
Encrypted password support via crypt(3): yes
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Built with OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
Running on OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
    [TRACE] trace
    [COMP] compression
    [SPOE] spoe

Regards,
Sander Hoentjen

Re: [PATCH] MINOR: ssl: ocsp response with 'revoked' status is correct

2017-10-23 Thread Sander Hoentjen 
Hi Willy,


On 10/22/2017 10:02 AM, Willy Tarreau wrote:
> Hi Manu,
>
> On Tue, Oct 10, 2017 at 03:44:07PM +0200, Emmanuel Hocdet wrote:
>> Hi Emeric,
>>
>>
>> ocsp_status can be 'good', 'revoked', or 'unknown'. 'revoked' status
>> is a correct status and ocsp response should not be dropped.
>> In case of certificate with OCSP must-stapling extension, response with
>> 'revoked' status must be provided as well as 'good' status.
> given that it looks like a bug, I merged it and re-tagged it with BUG.
The manpage says:
"OCSP_single_get0_status() returns the status of single or -1 if an
error occurred."
With this change, the -1 case is not handled correctly anymore it seems?
I am not sure if it will ever happen, but I have attached a patch for it.

Regards,
Sander

>From 3ed07896ac1f5730dc34900988ae255c7462f8ff Mon Sep 17 00:00:00 2001
From: Sander Hoentjen <shoent...@antagonist.nl>
Date: Mon, 23 Oct 2017 10:45:46 +0200
Subject: [PATCH] BUG/MINOR: ssl: catch failure of OCSP_single_get0_status

The manpage says:
"OCSP_single_get0_status() returns the status of single or -1 if an error
occurred." So we must handle -1 as well.
---
 src/ssl_sock.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 7b8570c74..5fb82fd62 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -625,6 +625,10 @@ static int ssl_sock_load_ocsp_response(struct chunk *ocsp_response, struct certi
 		memprintf(err, "OCSP single response: certificate status is unknown");
 		goto out;
 	}
+	else if (rc == -1) {
+		memprintf(err, "OCSP single response: certificate status request failed");
+		goto out;
+	}
 
 	if (!nextupd) {
 		memprintf(err, "OCSP single response: missing nextupdate");
-- 
2.13.6

Re: Certificate order

2017-04-21 Thread Sander Hoentjen 
On 04/21/2017 07:27 AM, Willy Tarreau wrote:
> On Thu, Apr 20, 2017 at 11:33:17PM +0200, Lukas Tribus wrote:
>> Hello,
>>
>>
>> Am 20.04.2017 um 15:05 schrieb Sander Hoentjen:
>>> A new patch, that puts the order like this:
>>> config:
>>> crt A crt B
>>>
>>> [...]
>>> If A contains wildcard, and B contains exact match, then wildcard is used.
>>>
>>> This last one is different behavior from what is implemented now.
>> People rely on the specific current behavior you are changing already.
>> We made it clear that exact matches always take precedence; inverting the
>> behavior fixes your single use-case but breaks many others.
>>
>>
>> My opinion about your use-case is that your provisioning layer has to handle
>> this and remove, if necessary, any more specific and unwanted lets-encrypt
>> certificates.
>> Maybe the crt-list [1] feature can be an alternative, otherwise, what you'd
>> need from haproxy would be a multi-layered approach, with certificate
>> "weights", which I don't believe makes sense to implement (but should be
>> abstracted into provisioning tools).
> +1
Well, in essence certificate "weights" is what I implemented in the
patch, with the config order determining the weight. While unfortunate
for me, I can understand your reasoning. I do still think my approach
offers more flexibility. Anyway, I attached a new patch which I hope you
will consider :)
As for my own use case, I'll just carry the previous patch myself.
In my case I can't just simply remove a (multi-domain) certificate,
since they may contain names that are not covered by the wildcard. This
means I need to use a neg filter, but I can't use a directory in
crt-list, so I need to specify all certificates in the list. While not a
very large issue it adds unneeded complexity, with a chance for things
to go out of sync.
In the end I would like to say that while I hoped my patch would be
accepted, I appreciate the responses on this mailing list. I prefer
being told no to being ignored. Thanks for this awesome project with a
healthy community. Maybe in the future I can contribute something else :)

Regards,
Sander
commit 2132209181c7fe961396673465bbf619b91a5e02
Author: Sander Hoentjen <shoent...@antagonist.nl>
Date:   Fri Apr 21 10:38:06 2017 +0200

Make load order of (wildcard) certificates clearer in docs

diff --git a/doc/configuration.txt b/doc/configuration.txt
index e6ea2cf..fed73b3 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -10226,11 +10226,13 @@ crt 
   that directory will be loaded in alphabetic order unless their name ends with
   '.issuer', '.ocsp' or '.sctl' (reserved extensions). This directive may be
   specified multiple times in order to load certificates from multiple files or
-  directories. The certificates will be presented to clients who provide a
-  valid TLS Server Name Indication field matching one of their CN or alt
-  subjects.  Wildcards are supported, where a wildcard character '*' is used
-  instead of the first hostname component (eg: *.example.org matches
-  www.example.org but not www.sub.example.org).
+  directories. When specified multiple times, the certificates will be looked up
+  in the order they are specified in the configuration, with the exception of
+  wildcard certificates, they will always be looked up last. The certificates
+  will be presented to clients who provide a valid TLS Server Name Indication
+  field matching one of their CN or alt subjects.  Wildcards are supported, where
+  a wildcard character '*' is used instead of the first hostname component (eg:
+  *.example.org matches www.example.org but not www.sub.example.org).
 
   If no SNI is provided by the client or if the SSL library does not support
   TLS extensions, or if the client provides an SNI hostname which does not

Re: Certificate order

2017-04-20 Thread Sander Hoentjen 
Now with patch attached, thanks Fred :)

On 04/20/2017 03:05 PM, Sander Hoentjen wrote:
> A new patch, that puts the order like this:
> config:
> crt A crt B
>
> if A contains wildcard, but not exact match, then wildcard is used.
> if A contains exact match, exact match is used.
> (this also means that if A contains both wildcard and exact match, exact
> match is used.)
> If A contains wildcard, and B contains exact match, then wildcard is used.
>
> This last one is different behavior from what is implemented now.
>
>
>
>
>
> On 04/18/2017 12:09 PM, Sander Hoentjen wrote:
>> On 04/18/2017 11:52 AM, Willy Tarreau wrote:
>>> Hi Daniel,
>>>
>>> On Tue, Apr 18, 2017 at 11:25:43AM +0200, Daniel Schneller wrote:
>>>> Hi!
>>>>
>>>> Not being very familiar with the code, so I thought I'd ask before 
>>>> something
>>>> changes unexpectedly :)
>>>> I asked about certificate ordering a while ago, too, and I seem to remember
>>>> (and we currently rely on this) that exact domain matches are "weighted
>>>> higher" than wildcard matches on purpose, so that if I just dump the
>>>> certificates in a directory, it will pick a more specific one over a 
>>>> wildcard
>>>> that is also there as a "catchall".
>>>>
>>>> Not saying one or the other is right or wrong, but if this should be 
>>>> merged,
>>>> it must be made very clear that people might have to change their setups.
>>> FQDN matches always have precedence over wildcards (fortunately). Sander,
>>> I'm a bit surprized by your motivation for this change. You always want
>>> foo.example.com to have precedence over *.example.com and this is not a
>>> matter of directory. By changing this you'd silently break some certs by
>>> presenting the wrong one (the wildcard one) instead of the fully qualified
>>> name. If you have any reason for wanting to do that anyway, I think this
>>> is the wrong approach and you should instead refuse to load domain certs
>>> when they conflict with a wildcard, or at least emit a warning indicating
>>> that there's overlapping. But that still seems very strange to me :-/
>> Hi Willy,
>>
>> In our case we always request Let's Encrypt certificates for all our
>> customers. We put those in a directory that is loaded last. When a
>> customer buys a certificate himself this certificate is put in a
>> directory that is loaded before the Let's Encrypt ones. If a customer
>> has bought a certificate he always wants that certificate to be used,
>> even if it is a wildcard. If and when a customer removes his own cert,
>> he will always still have working SSL.
>>
>> Regards,
>> Sander
>>
>

diff --git a/include/types/ssl_sock.h b/include/types/ssl_sock.h
index e71ba79..b382f0b 100644
--- a/include/types/ssl_sock.h
+++ b/include/types/ssl_sock.h
@@ -27,6 +27,7 @@
 
 struct sni_ctx {
 	SSL_CTX *ctx; /* context associated to the certificate */
+	int dirorder; /* directive order for the certificate */
 	int order;/* load order for the certificate */
 	int neg;  /* reject if match */
 	struct ebmb_node name;/* node holding the servername value */
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index a9a8f06..9344048 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -130,6 +130,7 @@ enum {
 
 int sslconns = 0;
 int totalsslconns = 0;
+int dirorder = 0;
 
 #if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
 struct list tlskeys_reference = LIST_HEAD_INIT(tlskeys_reference);
@@ -1453,9 +1454,12 @@ static int ssl_sock_switchctx_cbk(SSL *ssl, int *al, struct bind_conf *s)
 			break;
 		}
 	}
-	if (!node && wildp) {
+	if (wildp) {
 		/* lookup in wildcards names */
-		node = ebst_lookup(>sni_w_ctx, wildp);
+		n = ebst_lookup(>sni_w_ctx, wildp);
+		if (!node || n && container_of(n, struct sni_ctx, name)->dirorder < container_of(node, struct sni_ctx, name)->dirorder) {
+			node = n;
+		}
 	}
 	if (!node || container_of(node, struct sni_ctx, name)->neg) {
 		SSL_CTX *ctx;
@@ -1785,6 +1789,7 @@ static int ssl_sock_add_cert_sni(SSL_CTX *ctx, struct bind_conf *s, char *name,
 			return order;
 		memcpy(sc->name.key, trash.str, len + 1);
 		sc->ctx = ctx;
+		sc->dirorder = dirorder;
 		sc->order = order++;
 		sc->neg = neg;
 		if (wild)
@@ -5208,6 +5213,7 @@ static int bind_parse_ciphers(char **args, int cur_arg, struct proxy *px, struct
 static int bind_parse_crt(char **args, int cur_arg, struct proxy *px, struct bind_conf *conf, char **err)
 {
 	char path[MAXPATHLEN];
+	dirorder += 1;
 
 	if (!*args[cur_arg + 1]) {
 		memprintf(err, "'%s' : missing certificate location", args[cur_arg]);
@@ -5235,6 +5241,7 @@ static int bind_parse_crt(char **args, int cur_arg, struct proxy *px, struct bin
 /* parse the "crt-list" bind keyword */
 static int bind_parse_crt_list(char **args, int cur_arg, struct proxy *px, struct bind_conf *conf, char **err)
 {
+	dirorder += 1;
 	if (!*args[cur_arg + 1]) {
 		memprintf(err, "'%s' : missing certificate location", args[cur_arg]);
 		return ERR_ALERT | ERR_FATAL;

Re: Certificate order

2017-04-20 Thread Sander Hoentjen 
A new patch, that puts the order like this:
config:
crt A crt B

if A contains wildcard, but not exact match, then wildcard is used.
if A contains exact match, exact match is used.
(this also means that if A contains both wildcard and exact match, exact
match is used.)
If A contains wildcard, and B contains exact match, then wildcard is used.

This last one is different behavior from what is implemented now.





On 04/18/2017 12:09 PM, Sander Hoentjen wrote:
>
> On 04/18/2017 11:52 AM, Willy Tarreau wrote:
>> Hi Daniel,
>>
>> On Tue, Apr 18, 2017 at 11:25:43AM +0200, Daniel Schneller wrote:
>>> Hi!
>>>
>>> Not being very familiar with the code, so I thought I'd ask before something
>>> changes unexpectedly :)
>>> I asked about certificate ordering a while ago, too, and I seem to remember
>>> (and we currently rely on this) that exact domain matches are "weighted
>>> higher" than wildcard matches on purpose, so that if I just dump the
>>> certificates in a directory, it will pick a more specific one over a 
>>> wildcard
>>> that is also there as a "catchall".
>>>
>>> Not saying one or the other is right or wrong, but if this should be merged,
>>> it must be made very clear that people might have to change their setups.
>> FQDN matches always have precedence over wildcards (fortunately). Sander,
>> I'm a bit surprized by your motivation for this change. You always want
>> foo.example.com to have precedence over *.example.com and this is not a
>> matter of directory. By changing this you'd silently break some certs by
>> presenting the wrong one (the wildcard one) instead of the fully qualified
>> name. If you have any reason for wanting to do that anyway, I think this
>> is the wrong approach and you should instead refuse to load domain certs
>> when they conflict with a wildcard, or at least emit a warning indicating
>> that there's overlapping. But that still seems very strange to me :-/
> Hi Willy,
>
> In our case we always request Let's Encrypt certificates for all our
> customers. We put those in a directory that is loaded last. When a
> customer buys a certificate himself this certificate is put in a
> directory that is loaded before the Let's Encrypt ones. If a customer
> has bought a certificate he always wants that certificate to be used,
> even if it is a wildcard. If and when a customer removes his own cert,
> he will always still have working SSL.
>
> Regards,
> Sander
>

Re: Certificate order

2017-04-18 Thread Sander Hoentjen 


On 04/18/2017 11:52 AM, Willy Tarreau wrote:
> Hi Daniel,
>
> On Tue, Apr 18, 2017 at 11:25:43AM +0200, Daniel Schneller wrote:
>> Hi!
>>
>> Not being very familiar with the code, so I thought I'd ask before something
>> changes unexpectedly :)
>> I asked about certificate ordering a while ago, too, and I seem to remember
>> (and we currently rely on this) that exact domain matches are "weighted
>> higher" than wildcard matches on purpose, so that if I just dump the
>> certificates in a directory, it will pick a more specific one over a wildcard
>> that is also there as a "catchall".
>>
>> Not saying one or the other is right or wrong, but if this should be merged,
>> it must be made very clear that people might have to change their setups.
> FQDN matches always have precedence over wildcards (fortunately). Sander,
> I'm a bit surprized by your motivation for this change. You always want
> foo.example.com to have precedence over *.example.com and this is not a
> matter of directory. By changing this you'd silently break some certs by
> presenting the wrong one (the wildcard one) instead of the fully qualified
> name. If you have any reason for wanting to do that anyway, I think this
> is the wrong approach and you should instead refuse to load domain certs
> when they conflict with a wildcard, or at least emit a warning indicating
> that there's overlapping. But that still seems very strange to me :-/
Hi Willy,

In our case we always request Let's Encrypt certificates for all our
customers. We put those in a directory that is loaded last. When a
customer buys a certificate himself this certificate is put in a
directory that is loaded before the Let's Encrypt ones. If a customer
has bought a certificate he always wants that certificate to be used,
even if it is a wildcard. If and when a customer removes his own cert,
he will always still have working SSL.

Regards,
Sander

Re: Certificate order

2017-04-18 Thread Sander Hoentjen 
Hi Daniel,

Yes, I understand your concern. I don't know if haproxy developers are
willing to accept this change. Personally I think it is a good idea,
because as it is now a sysadmin cannot ensure ordering of a specific
wildcard before some domain specific one, whereas with my patch you are
in full control (if you want it to have less preference, just make sure
it is loaded later).

Regards,
Sander

On 04/18/2017 11:25 AM, Daniel Schneller wrote:
> Hi!
>
> Not being very familiar with the code, so I thought I’d ask before
> something changes unexpectedly :)
> I asked about certificate ordering a while ago, too, and I seem to
> remember (and we currently rely on this) that exact domain matches are
> “weighted higher” than wildcard matches on purpose, so that if I just
> dump the certificates in a directory, it will pick a more specific one
> over a wildcard that is also there as a “catchall”.
>
> Not saying one or the other is right or wrong, but if this should be
> merged, it must be made very clear that people might have to change
> their setups.
>
> Daniel
>
>
>
> -- 
> Daniel Schneller
> Principal Cloud Engineer
>  
> CenterDevice GmbH  | Hochstraße 11
>| 42697 Solingen
> tel: +49 1754155711| Deutschland
> daniel.schnel...@centerdevice.de
> <mailto:daniel.schnel...@centerdevice.de>   | www.centerdevice.de
> <http://www.centerdevice.de>
>
> Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
> Michael Rosbach, Handelsregister-Nr.: HRB 18655,
> HR-Gericht: Bonn, USt-IdNr.: DE-815299431
>
>
>> On 10. Apr. 2017, at 20:02, Sander Hoentjen <san...@hoentjen.eu
>> <mailto:san...@hoentjen.eu>> wrote:
>>
>> This is a corrected patch against 1.7.5.
>>
>> On 04/10/2017 05:00 PM, Sander Hoentjen wrote:
>>> No scratch that, this is wrong.
>>>
>>> On 04/10/2017 04:57 PM, Sander Hoentjen wrote:
>>>> The attached patch against haproxy 1.7.5 honours crt order also for
>>>> wildcards.
>>>>
>>>> On 04/07/2017 03:42 PM, Sander Hoentjen wrote:
>>>>> Hi Sander,
>>>>>
>>>>> On 04/06/2017 02:06 PM, Sander Klein wrote:
>>>>>> Hi Sander,
>>>>>>
>>>>>> On 2017-04-06 10:45, Sander Hoentjen wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> We have a setup where we sometimes have multiple certificates for a
>>>>>>> domain. We use multiple directories for that and would like the
>>>>>>> following behavior:
>>>>>>> - Look in dir A for any match, use it if found
>>>>>>> - Look in dir B for any match, use it if found
>>>>>>> - Look in dir .. etc
>>>>>>>
>>>>>>> This works great, except for wildcards. Right now a domain match
>>>>>>> in dir
>>>>>>> B takes precedence over a wildcard match in dir A.
>>>>>>>
>>>>>>> Is there a way to get haproxy to behave the way I describe?
>>>>>> I have been playing with this some time ago and my solution was to
>>>>>> just think about the order of certificate loading. I then found out
>>>>>> that the last certificate was preferred if it matched. Not sure if
>>>>>> this has changed over time.
>>>>> This does not work for wildcard certs, it seems they are always
>>>>> tried last.
>>>>>
>>>>> Regards,
>>>>> Sander
>>>>>
>>>
>>
>> 
>

Re: Certificate order

2017-04-10 Thread Sander Hoentjen 
This is a corrected patch against 1.7.5.

On 04/10/2017 05:00 PM, Sander Hoentjen wrote:
> No scratch that, this is wrong.
>
> On 04/10/2017 04:57 PM, Sander Hoentjen wrote:
>> The attached patch against haproxy 1.7.5 honours crt order also for
>> wildcards.
>>
>> On 04/07/2017 03:42 PM, Sander Hoentjen wrote:
>>> Hi Sander,
>>>
>>> On 04/06/2017 02:06 PM, Sander Klein wrote:
>>>> Hi Sander,
>>>>
>>>> On 2017-04-06 10:45, Sander Hoentjen wrote:
>>>>> Hi guys,
>>>>>
>>>>> We have a setup where we sometimes have multiple certificates for a
>>>>> domain. We use multiple directories for that and would like the
>>>>> following behavior:
>>>>> - Look in dir A for any match, use it if found
>>>>> - Look in dir B for any match, use it if found
>>>>> - Look in dir .. etc
>>>>>
>>>>> This works great, except for wildcards. Right now a domain match in dir
>>>>> B takes precedence over a wildcard match in dir A.
>>>>>
>>>>> Is there a way to get haproxy to behave the way I describe?
>>>> I have been playing with this some time ago and my solution was to
>>>> just think about the order of certificate loading. I then found out
>>>> that the last certificate was preferred if it matched. Not sure if
>>>> this has changed over time.
>>> This does not work for wildcard certs, it seems they are always tried last.
>>>
>>> Regards,
>>> Sander
>>>
>

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index f947c99..ad70783 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -130,6 +130,7 @@
 
 int sslconns = 0;
 int totalsslconns = 0;
+int order = 0;
 
 #if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
 struct list tlskeys_reference = LIST_HEAD_INIT(tlskeys_reference);
@@ -1453,9 +1454,12 @@
 			break;
 		}
 	}
-	if (!node && wildp) {
+	if (wildp) {
 		/* lookup in wildcards names */
-		node = ebst_lookup(>sni_w_ctx, wildp);
+		n = ebst_lookup(>sni_w_ctx, wildp);
+		if (!node || n && container_of(n, struct sni_ctx, name)->order < container_of(node, struct sni_ctx, name)->order) {
+			node = n;
+		}
 	}
 	if (!node || container_of(node, struct sni_ctx, name)->neg) {
 		SSL_CTX *ctx;
@@ -2265,7 +2269,6 @@
 	X509 *x = NULL, *ca;
 	int i, err;
 	int ret = -1;
-	int order = 0;
 	X509_NAME *xname;
 	char *str;
 	pem_password_cb *passwd_cb;

Re: Certificate order

2017-04-10 Thread Sander Hoentjen 
No scratch that, this is wrong.

On 04/10/2017 04:57 PM, Sander Hoentjen wrote:
> The attached patch against haproxy 1.7.5 honours crt order also for
> wildcards.
>
> On 04/07/2017 03:42 PM, Sander Hoentjen wrote:
>> Hi Sander,
>>
>> On 04/06/2017 02:06 PM, Sander Klein wrote:
>>> Hi Sander,
>>>
>>> On 2017-04-06 10:45, Sander Hoentjen wrote:
>>>> Hi guys,
>>>>
>>>> We have a setup where we sometimes have multiple certificates for a
>>>> domain. We use multiple directories for that and would like the
>>>> following behavior:
>>>> - Look in dir A for any match, use it if found
>>>> - Look in dir B for any match, use it if found
>>>> - Look in dir .. etc
>>>>
>>>> This works great, except for wildcards. Right now a domain match in dir
>>>> B takes precedence over a wildcard match in dir A.
>>>>
>>>> Is there a way to get haproxy to behave the way I describe?
>>> I have been playing with this some time ago and my solution was to
>>> just think about the order of certificate loading. I then found out
>>> that the last certificate was preferred if it matched. Not sure if
>>> this has changed over time.
>> This does not work for wildcard certs, it seems they are always tried last.
>>
>> Regards,
>> Sander
>>

Re: Certificate order

2017-04-10 Thread Sander Hoentjen 
The attached patch against haproxy 1.7.5 honours crt order also for
wildcards.

On 04/07/2017 03:42 PM, Sander Hoentjen wrote:
> Hi Sander,
>
> On 04/06/2017 02:06 PM, Sander Klein wrote:
>> Hi Sander,
>>
>> On 2017-04-06 10:45, Sander Hoentjen wrote:
>>> Hi guys,
>>>
>>> We have a setup where we sometimes have multiple certificates for a
>>> domain. We use multiple directories for that and would like the
>>> following behavior:
>>> - Look in dir A for any match, use it if found
>>> - Look in dir B for any match, use it if found
>>> - Look in dir .. etc
>>>
>>> This works great, except for wildcards. Right now a domain match in dir
>>> B takes precedence over a wildcard match in dir A.
>>>
>>> Is there a way to get haproxy to behave the way I describe?
>> I have been playing with this some time ago and my solution was to
>> just think about the order of certificate loading. I then found out
>> that the last certificate was preferred if it matched. Not sure if
>> this has changed over time.
> This does not work for wildcard certs, it seems they are always tried last.
>
> Regards,
> Sander
>

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index f947c99..ad70783 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1453,9 +1453,12 @@
 			break;
 		}
 	}
-	if (!node && wildp) {
+	if (wildp) {
 		/* lookup in wildcards names */
-		node = ebst_lookup(>sni_w_ctx, wildp);
+		n = ebst_lookup(>sni_w_ctx, wildp);
+		if (!node || n && container_of(n, struct sni_ctx, name)->order < container_of(node, struct sni_ctx, name)->order) {
+			node = n;
+		}
 	}
 	if (!node || container_of(node, struct sni_ctx, name)->neg) {
 		SSL_CTX *ctx;

Re: Certificate order

2017-04-07 Thread Sander Hoentjen 
Hi Sander,

On 04/06/2017 02:06 PM, Sander Klein wrote:
> Hi Sander,
>
> On 2017-04-06 10:45, Sander Hoentjen wrote:
>> Hi guys,
>>
>> We have a setup where we sometimes have multiple certificates for a
>> domain. We use multiple directories for that and would like the
>> following behavior:
>> - Look in dir A for any match, use it if found
>> - Look in dir B for any match, use it if found
>> - Look in dir .. etc
>>
>> This works great, except for wildcards. Right now a domain match in dir
>> B takes precedence over a wildcard match in dir A.
>>
>> Is there a way to get haproxy to behave the way I describe?
>
> I have been playing with this some time ago and my solution was to
> just think about the order of certificate loading. I then found out
> that the last certificate was preferred if it matched. Not sure if
> this has changed over time.
This does not work for wildcard certs, it seems they are always tried last.

Regards,
Sander

Certificate order

2017-04-06 Thread Sander Hoentjen 
Hi guys,

We have a setup where we sometimes have multiple certificates for a
domain. We use multiple directories for that and would like the
following behavior:
- Look in dir A for any match, use it if found
- Look in dir B for any match, use it if found
- Look in dir .. etc

This works great, except for wildcards. Right now a domain match in dir
B takes precedence over a wildcard match in dir A.

Is there a way to get haproxy to behave the way I describe?

Regards,
Sander