Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Willy Tarreau]

Alexander,

I now merged your patch with the SMP_VAL_ change, after verifying that
the reg-test is still OK. Thus 2.9-dev9 will contain it. Thanks!

Willy

Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Willy Tarreau]

On Fri, Nov 03, 2023 at 08:35:08PM +, Stephan, Alexander wrote:
> Hi Willy,
> 
> Thanks for the review. No problem for calling me Stephan, I am totally used
> to that, my teachers did that for years.

Oh I was sure you were used to but anyway I don't like calling people
incorrectly.

> > Yeah I agree, that part is not pretty. And as often in such code, not
> > handling errors makes them even more complicated to unroll as you
> > experienced in the list loop you added, which could otherwise have been
> > addressed using just a goto and a few free().
> 
> > Do not hesitate to propose extra patches to improve this, contributions
> > that make the code more reliable and maintainable are totally welcome!
> 
> Sure, if I have some extra time on my hands. Actually, a colleague of mine is
> preparing some patches like this. Since there are many small changes (e.g.,
> adding a free), should can we batch them or are individual commits required?

It depends. The rule of thumb for this is to think about the risk of breakage
and the ability to bisect (and possibly revert) later. But it's clear that
some API changes need to be performed atomically and can sometimes be a bit
larger than initially expected. Among the things we practice if some large
area changes are needed, is to try to make a first set of preparation patches
that apply most of the visual changes without changing semantics (e.g. move
some code into a separate function, or reindent 500 lines at once in an
"if (1)" block etc). And only then the patches that perform the real changes
are applied. This has the benefit that the first patch promises not to
change the logic so that it cannot break on bisect and doesn't need to be
analyzed later, and the patches that change the logic are much smaller.

> > Are you sure it was not a side effect of a debugging session with some 
> > temporary code in it ?
> 
> Pretty sure, yes. I'll will get back to this at the beginning of next week,
> if it's okay. I compiled with a debug flag, but I wouldn't usually expect
> this to be an issue.

OK let's try to figure that later. I'll merge your code in its current
form for now.

> > So if that's OK for you I can change it now before merging.
> 
> Ah, I had used a SMP_VAL_* before, but I was not 100% about the meaning. Then
> I fell back to the proxy. Feel free to change it!

;-)  Will do.

> > Yes very likely. Originally the code didn't check for allocation errors
> > during parsing because it was the boot phase, and we used to consider that
> > a memory allocation error would not always be reportable anyway, and given
> > that it was at boot time, the result was going to be the same.
> > But much later the code began to be a bit more dynamic, and such practices
> > are no longer acceptable in parts that can be called at run time (e.g.
> > during an "add server" on the CLI). It's particularly difficult to address
> > some of these historic remains but from time to time we manage to pass an
> > extra pointer to some functions to write an error, and make a function
> > return a set of flags among ERR_{WARN,FATAL,ALERT,ABORT}. But it takes a
> > lot of time > for little to no perceived value for the vast majority of
> > users :-(
> 
> Interesting how that came to be, no accusations. I see that this is not a
> high priority. Not sure if I have the time to provide a fix here but I'll
> keep it mind.

OK. No rush but similarly, patches welcome of course.

> > Another point, in make_proxy_line_v2() I'm seeing that you've placed
> > everything under "if (strm)". I understand why, it's because you didn't
> > want to call build_logline() without a stream. That made me think "hmmm we
> > already have the ability to do that", and I found it, you can use
> > sess_build_logline() instead, that takes the session separately, and
> > supports an optional stream. That would be useful for health checks for
> > example, since they don't have streams. But there's a catch: in function
> > make_proxy_line_v2() we don't have the session at the moment, and
> > build_logline() extracts it from the stream. Normally during a session
> > establishment, the session is present in connection->owner, thus
> > remote->owner in make_proxy_line_v2(). I suggest that you give this a
> > try to confirm that it works for you, this way we'd be sure that health
> > checks can also send the ppv2 fields. But that's not critical given that
> > there's no bad behavior right now, it's just that fields will be ignored,
> > so this can be done in a subsequent patch.
> 
> Again, I don't mind if you make the SMP_VAL_*.

OK will do it.

> I tried the
> sess_build_logline() and it seems to work perfectly. The tests also still
> pass, so looks good. I would like to provide a second patch for this next
> week, if this okay.

Sure, that would be great!

thanks and have a nice week-end!
Willy

RE: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Stephan, Alexander]

Hi Willy,

Thanks for the review. No problem for calling me Stephan, I am totally used to 
that, my teachers did that for years.

> At first glance the patches look nice.
Great! 

> Yeah I agree, that part is not pretty. And as often in such code, not 
> handling errors makes them even more complicated to unroll as you experienced 
> in the list loop you added, which could otherwise have been addressed using 
> just a goto and a few free().

> Do not hesitate to propose extra patches to improve this, contributions that 
> make the code more reliable and maintainable are totally welcome!

Sure, if I have some extra time on my hands. Actually, a colleague of mine is 
preparing some patches like this. Since there are many small changes (e.g., 
adding a free), should can we batch them or are individual commits required?

> Are you sure it was not a side effect of a debugging session with some 
> temporary code in it ?

Pretty sure, yes. I'll will get back to this at the beginning of next week, if 
it's okay. I compiled with a debug flag, but I wouldn't usually expect this to 
be an issue.

> So if that's OK for you I can change it now before merging.

Ah, I had used a SMP_VAL_* before, but I was not 100% about the meaning. Then I 
fell back to the proxy. Feel free to change it!

> Yes very likely. Originally the code didn't check for allocation errors 
> during parsing because it was the boot phase, and we used to consider that a 
> memory allocation error would not always be reportable anyway, and given that 
> it was at boot time, the result was going to be the same.
> But much later the code began to be a bit more dynamic, and such practices 
> are no longer acceptable in parts that can be called at run time (e.g.
> during an "add server" on the CLI). It's particularly difficult to address 
> some of these historic remains but from time to time we manage to pass an 
> extra pointer to some functions to write an error, and make a function return 
> a set of flags among ERR_{WARN,FATAL,ALERT,ABORT}. But it takes a lot of time 
> > for little to no perceived value for the vast majority of users :-(

Interesting how that came to be, no accusations. I see that this is not a high 
priority. Not sure if I have the time to provide a fix here but I'll keep it 
mind.

> Another point, in make_proxy_line_v2() I'm seeing that you've placed 
> everything under "if (strm)". I understand why, it's because you didn't want 
> to call build_logline() without a stream. That made me think "hmmm we already 
> have the ability to do that", and I found it, you can use
> sess_build_logline() instead, that takes the session separately, and supports 
> an optional stream. That would be useful for health checks for example, since 
> they don't have streams. But there's a catch: in function
> make_proxy_line_v2() we don't have the session at the moment, and
> build_logline() extracts it from the stream. Normally during a session 
> establishment, the session is present in connection->owner, thus
> remote->owner in make_proxy_line_v2(). I suggest that you give this a
> try to confirm that it works for you, this way we'd be sure that health 
> checks can also send the ppv2 fields. But that's not critical given that 
> there's no bad behavior right now, it's just that fields will be ignored, so 
> this can be done in a subsequent patch.

Again, I don't mind if you make the SMP_VAL_*.  I tried the 
sess_build_logline() and it seems to work perfectly. The tests also still pass, 
so looks good. I would like to provide a second patch for this next week, if 
this okay.

Best,
Alexander

-Original Message-
From: Willy Tarreau  
Sent: Friday, November 3, 2023 8:11 PM
To: Stephan, Alexander 
Cc: haproxy@formilux.org
Subject: Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated 
proxy-v2-options

Hi Alexander,

(and BTW sorry for having called you Stephan twice in the last thread, each 
time I have to make a mental effort due to how your first and last names are 
presented in your e-mail address).

On Sat, Oct 28, 2023 at 07:32:20PM +, Stephan, Alexander wrote:
> I've just finished the implementation based on the tip with the 
> deferred log format parsing so the default-server should be also fully 
> supported now. ?

At first glance the patches look nice.

> I guess using the finalize method of the parser is the canonic implementation 
> of this.
> 
> I have a few remarks about the current state of the code:
> - srv_settings_cpy in server.c has no form of error handling 
> available. This is potentially causes trouble due to lack of error handling:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fhaproxy%2Fhaproxy%2Fblob%2F47ed1181f29a56ccb04e5b80ef4f941446
> 6ada7a%2Fsrc%2Fserver.c%23L2370=05%7C01%7Calexander.stephan%40sap
> .com%7Cd49f35f800cd493ad76408dbdca0934d%7C42f7676cf455423c82f6dc2d9979
> 1af7%7C0%7C0%7C638346354457583668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> 

Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Willy Tarreau]

Hi Alexander,

(and BTW sorry for having called you Stephan twice in the last thread,
each time I have to make a mental effort due to how your first and last
names are presented in your e-mail address).

On Sat, Oct 28, 2023 at 07:32:20PM +, Stephan, Alexander wrote:
> I've just finished the implementation based on the tip with the deferred log
> format parsing so the default-server should be also fully supported now. ?

At first glance the patches look nice.

> I guess using the finalize method of the parser is the canonic implementation 
> of this.
> 
> I have a few remarks about the current state of the code:
> - srv_settings_cpy in server.c has no form of error handling available. This
> is potentially causes trouble due to lack of error handling:
> https://github.com/haproxy/haproxy/blob/47ed1181f29a56ccb04e5b80ef4f9414466ada7a/src/server.c#L2370
> For now, I did not want to change the signature, but I think, error handling
> would be beneficial here.

Yeah I agree, that part is not pretty. And as often in such code, not
handling errors makes them even more complicated to unroll as you
experienced in the list loop you added, which could otherwise have been
addressed using just a goto and a few free().

Do not hesitate to propose extra patches to improve this, contributions
that make the code more reliable and maintainable are totally welcome!

> - In the new list_for_each in srv_settings_cpy I have to check for srv_tlv ==
> NULL as for some reason, the list contains NULL entries. I don't see any
> mistakes with the list handling. Maybe it is just due to the structure of the
> server logic. 

I don't see how this is possible:

list_for_each_entry(srv_tlv, >pp_tlvs, list) {
if (srv_tlv == NULL)
break;

For srv_tlv to be NULL, it would mean that you visited (NULL)->list
at some point, and apparently pp_tlvs is always manipulated with
LIST_APPEND() only, so I don't see how you could end up with
something like last->next = (NULL)->list. Are you sure it was not a 
side effect of a debugging session with some temporary code in it ?
I'd be interested in knowing if you can reproduce it so that we can
find the root cause (and hopefully address it).

> - Please double check that my arguments for the parse_logformat_string
> function are correct. I omit log options for now and use the capabilities of
> the proxy. Seems like the best fit, but I could be wrong.

Ah good point. The argument you're missing and for which use used
px->cap is one of SMP_VAL_*. It indicates at which point(s) the
log-format may be called so that the parser can emit suitable
warnings if some sample fetch functions are not available. Here it
will be used during the server connect() phase, so there is already
one perfect for this, which is SMP_VAL_BE_SRV_CON. It's already used 
by the source and sni arguments. For the options I think it's OK that
it stays zero, that's how it's used everywhere else :-)

I could verify that your reg test still works with this change:

  --- a/src/server.c
  +++ b/src/server.c
  @@ -3252,7 +3252,7 @@ static int _srv_parse_finalize(char **args, int cur_arg,
  list_for_each_entry(srv_tlv, >pp_tlvs, list) {
  LIST_INIT(_tlv->fmt);
  if (srv_tlv->fmt_string && 
unlikely(!parse_logformat_string(srv_tlv->fmt_string,
  -   srv->proxy, _tlv->fmt, 0, px->cap, ))) {
  +   srv->proxy, _tlv->fmt, 0, SMP_VAL_BE_SRV_CON, 
))) {
  if (errmsg) {
  ha_alert("%s\n", errmsg);
  free(errmsg);

So if that's OK for you I can change it now before merging.

> - I noticed that there are also no checks for strdup in server.c, that might
> need to be addressed in the future. For the srv_settings_cpy I cannot give an
> error, but only try to avoid the memory leak.

Yes very likely. Originally the code didn't check for allocation errors
during parsing because it was the boot phase, and we used to consider
that a memory allocation error would not always be reportable anyway,
and given that it was at boot time, the result was going to be the same.
But much later the code began to be a bit more dynamic, and such practices
are no longer acceptable in parts that can be called at run time (e.g.
during an "add server" on the CLI). It's particularly difficult to
address some of these historic remains but from time to time we manage
to pass an extra pointer to some functions to write an error, and make a
function return a set of flags among ERR_{WARN,FATAL,ALERT,ABORT}. But
it takes a lot of time for little to no perceived value for the vast
majority of users :-(

Another point, in make_proxy_line_v2() I'm seeing that you've placed
everything under "if (strm)". I understand why, it's because you didn't
want to call build_logline() without a stream. That made me think "hmmm
we already have the ability to do that", and I found it, 

Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Willy Tarreau]

On Fri, Nov 03, 2023 at 05:15:03PM +, Stephan, Alexander wrote:
> Hi Willy,
> 
> Sorry, my email client probably did something weird...
> I attached them now, should hopefully prevent any reformatting.

Thanks for the fast response. I'll check them keeping in mind your
last comments in your previous e-mail for patch2. Hopefully this
evening before issuing 2.9-dev9 with them.

Willy

RE: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Stephan, Alexander]

Hi Willy,

Sorry, my email client probably did something weird...
I attached them now, should hopefully prevent any reformatting.

Best,
Alexander

-Original Message-
From: Willy Tarreau  
Sent: Friday, November 3, 2023 5:52 PM
To: Stephan, Alexander 
Cc: haproxy@formilux.org
Subject: Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated 
proxy-v2-options

On Fri, Nov 03, 2023 at 05:14:33PM +0100, Willy Tarreau wrote:
> Hi Stephan,
> 
> On Fri, Nov 03, 2023 at 01:54:26PM +, Stephan, Alexander wrote:
> > Hi Willy,
> > 
> > Did you receive the other two mails with the updated patches? I 
> > couldn't find it the reply to first page in the archive although I 
> > CCed the list. That's why I wanted to double-check, not to run in the 
> > previous situation.
> 
> Yes, sorry, it's just that I have been busy on other stuff and didn't 
> have the time to have a look yet, but I'm seeing them still marked 
> unread here. I'm doing my best to review and merge them ASAP.

Stephan, I just noticed that your patches were mangled with tabs turned to 
spaces. Please just resend them attached (the two in the same message if you 
want).

Thanks,
Willy


0001-MINOR-server-Add-parser-support-for-set-proxy-v2-tlv.patch
Description:  0001-MINOR-server-Add-parser-support-for-set-proxy-v2-tlv.patch


0002-MINOR-connection-Send-out-generic-user-defined-serve.patch
Description:  0002-MINOR-connection-Send-out-generic-user-defined-serve.patch

Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Willy Tarreau]

On Fri, Nov 03, 2023 at 05:14:33PM +0100, Willy Tarreau wrote:
> Hi Stephan,
> 
> On Fri, Nov 03, 2023 at 01:54:26PM +, Stephan, Alexander wrote:
> > Hi Willy,
> > 
> > Did you receive the other two mails with the updated patches? I couldn't 
> > find
> > it the reply to first page in the archive although I CCed the list. That's
> > why I wanted to double-check, not to run in the previous situation.
> 
> Yes, sorry, it's just that I have been busy on other stuff and didn't
> have the time to have a look yet, but I'm seeing them still marked
> unread here. I'm doing my best to review and merge them ASAP.

Stephan, I just noticed that your patches were mangled with tabs turned
to spaces. Please just resend them attached (the two in the same message
if you want).

Thanks,
Willy

Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Willy Tarreau]

Hi Stephan,

On Fri, Nov 03, 2023 at 01:54:26PM +, Stephan, Alexander wrote:
> Hi Willy,
> 
> Did you receive the other two mails with the updated patches? I couldn't find
> it the reply to first page in the archive although I CCed the list. That's
> why I wanted to double-check, not to run in the previous situation.

Yes, sorry, it's just that I have been busy on other stuff and didn't
have the time to have a look yet, but I'm seeing them still marked
unread here. I'm doing my best to review and merge them ASAP.

Thanks,
Willy

RE: [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options

[Stephan, Alexander]

Hi Willy,

Did you receive the other two mails with the updated patches? I couldn't find 
it the reply to first page in the archive although I CCed the list. That's why 
I wanted to double-check, not to run in the previous situation.

Best,
Alexander

-Original Message-
From: Willy Tarreau  
Sent: Friday, October 27, 2023 4:22 PM
To: Stephan, Alexander 
Cc: haproxy@formilux.org
Subject: Re: [PATCH 2/4] MEDIUM: connection: Send out generically allocated 
proxy-v2-options

Hi Alexander,

On Fri, Oct 27, 2023 at 02:12:10PM +, Stephan, Alexander wrote:
> > BTW, please check if this works in default-server directives.
> 
> struct srv_pp_tlv_list {
> struct list list;
> struct list fmt;
> unsigned char type;
> };
> 
> To allow for use with the default server, I adjusted srv_settings_cpy 
> accordingly such that the server TLV entries (see above) are deep copied.
> It works, but there is an edge case with the struct logformat_node 
> that is contained in such a TLV struct. default-server directives Its 
> member expr has the type of a void pointer, therefore I cannot 
> directly copy it. Alternatively, if I would reuse the memory by simply 
> copying the pointer, a double free will likely happen in srv_drop (I 
> always free the TLV list in it, alongside the logformat node list).
> Besides, the servers created from the default-backend should operate 
> independently, so this is not an option, I guess.

Definitely. From what I remember about what we do for other such expressions 
that are inherited from defaults, we use a trick: we only save the expression 
as a string during parsing, that's the same that is kept on the default server. 
Thus the new server just does an strdup() of that log-format expression that's 
just a string. And only later we resolve it. That's not the best example but 
the first I just found, please have a look at uniqueid_format_string. It's 
handled exactly like this and resolved in check_config_validity().

> > You may want to have a look at how the "sni" keyword which also 
> > supports an expression is handled, as I don't recall the exact details.
> > Maybe in your case we don't need the expression but the log-format 
> > instead and it's not an issue, I just don't remember the details 
> > without having a deeper look to be honest.
> 
> Maybe let's just use a sample expression as its usage is more straight 
> forward, basically similar to the sni option? Or do you have any other 
> ideas on how to tackle the issue I described above?

Parsing the log-format string late definitely is the best option, and not too 
cumbersome. You can even still report the line number etc from the "server" 
struct to indicate in the parsing error if any, since everything is on the same 
line, so there's really no problem with parsing late.

> Disabling the default-server support could be another solution. I am 
> very interested in your opinion on this.

I'd really avoid disabling default-server as much as possible, or it will start 
to be quite difficult to configure given that other related options are 
accepted there. I tend to consider that the effort needed by users to work 
around our limited designs often outweighs the efforts we should have involved 
to make it smoother for them, so until we're certain it's not possible it's 
worth trying ;-)

Thanks!
Willy

Re: [PATCH] MINOR: sample: Add fetcher for getting all cookie names

[Willy Tarreau]

On Fri, Nov 03, 2023 at 08:55:54AM +, Ruei-Bang Chen wrote:
> Hi Willy,
> 
> The simplification makes sense! I don't mind you changing it at all. I really
> appreciate the feedback from you.

Perfect, that's merged now :-)

Thank you for doing this work!
Willy

Re: [PATCH] MINOR: sample: Add fetcher for getting all cookie names

[Ruei-Bang Chen]

Hi Willy,

The simplification makes sense! I don't mind you changing it at all. I really 
appreciate the feedback from you.

Ruei-Bang

From: Willy Tarreau 
Sent: Friday, November 3, 2023 1:50 AM
To: Ruei-Bang Chen 
Cc: haproxy@formilux.org 
Subject: Re: [PATCH] MINOR: sample: Add fetcher for getting all cookie names

Hi Ruei-Bang,

On Fri, Nov 03, 2023 at 04:58:36AM +, Ruei-Bang Chen wrote:
> Hi Willy and the team,
>
> I just want to send a friendly reminder that I am still looking for feedback
> for this patch.

Thanks!

> I totally understand that there might be other priorities coming up. When you
> get a chance, can you please take a look at the patch from my last email?

While I'm indeed busy on other reviews and bugs in parallel, for this
one I messed up. I can't find your message in my mbox but my logs tell
me it was delivered to the correct box. Thus it looks like a manipulation
error on my side, sorry for this. Anyway I got it from the archives.

Looks good overall, my only comment is this one:

  /* For Set-Cookie, we need to fetch the entire header line (set flag to 
1) */
  if ((is_req && !http_find_header(htx, hdr, , 0)) ||
  (!is_req && !http_find_header(htx, hdr, , 1)))
  break;

If you're OK I'll simplify it this way which is much more readable IMHO:

  if (!http_find_header(htx, hdr, , !is_req))
  break;

Please just let me know if you don't mind me changing it, and I can take
it with today's dev9.

Thanks!
Willy

Re: [PATCH] MINOR: sample: Add fetcher for getting all cookie names

[Willy Tarreau]

Hi Ruei-Bang,

On Fri, Nov 03, 2023 at 04:58:36AM +, Ruei-Bang Chen wrote:
> Hi Willy and the team,
> 
> I just want to send a friendly reminder that I am still looking for feedback
> for this patch.

Thanks!

> I totally understand that there might be other priorities coming up. When you
> get a chance, can you please take a look at the patch from my last email?

While I'm indeed busy on other reviews and bugs in parallel, for this
one I messed up. I can't find your message in my mbox but my logs tell
me it was delivered to the correct box. Thus it looks like a manipulation
error on my side, sorry for this. Anyway I got it from the archives.

Looks good overall, my only comment is this one:

  /* For Set-Cookie, we need to fetch the entire header line (set flag to 
1) */
  if ((is_req && !http_find_header(htx, hdr, , 0)) ||
  (!is_req && !http_find_header(htx, hdr, , 1)))
  break;

If you're OK I'll simplify it this way which is much more readable IMHO:

  if (!http_find_header(htx, hdr, , !is_req))
  break;

Please just let me know if you don't mind me changing it, and I can take
it with today's dev9.

Thanks!
Willy

Re: No Private Key found in '/etc/letsencrypt/live/www.mydomain.org/fullchain.pem.key

[Christoph Kukulies]

Thanks, Shawn,

I always have my problems with the open form of the configuration file syntax 
(lua ?).
The docs say it is a keyword under "crt" which in turn belongs to the "bind" 
options.

Would it be correct to place it that way?:

frontend http-in
bind *:80
bind *:443 ssl crt /etc/haproxy/fullchain.pem crt ssl-skip-self-issued-ca


> Am 03.11.2023 um 03:50 schrieb Shawn Heisey :
> 
> On 11/2/2023 02:35, Christoph Kukulies wrote:
>> In /etc/letsencrypt/live/www.mydomain.org I have:
>> lrwxrwxrwx 1 root root  41 Oct 23 17:22 *cert.pem*-> 
>> ../../archive/www.mydomain.org/cert12.pem 
>> 
>> lrwxrwxrwx 1 root root  42 Oct 23 17:22 *chain.pem*-> 
>> ../../archive/www.mydomain.org/chain12.pem 
>> 
>> lrwxrwxrwx 1 root root  46 Oct 23 17:22 *fullchain.pem*-> 
>> ../../archive/www.mydomain.org/fullchain12.pem 
>> 
>> lrwxrwxrwx 1 root root  13 Nov  1 12:12 *fullchain.pem.key*-> fullchain.pem
>> lrwxrwxrwx 1 root root  44 Oct 23 17:22 *privkey.pem*-> 
>> ../../archive/www.mydomain.org/privkey12.pem 
>> 
>> lrwxrwxrwx 1 root root  11 Nov  1 12:11 *privkey.pem.key*-> privkey.pem
>> -rw-r--r-- 1 root root 692 Nov 13  2021 README
>> But note, that the file ending on .key are put there on an expermental 
>> basis, because I read somewhere in the haproxy docs that one could a file 
>> with extension .key
>> there and haproxy then adds interprets that as the private key. Location for 
>> this hint escaped me for the moment.
> 
> The link named 'fullchain.pem.key' is not pointing at a key.  It is pointing 
> at the fullchain, which as already mentioned, does NOT contain the private 
> key.
> 
> If you change that symlink to point at privkey.pem instead of fullchain.pem, 
> haproxy might start working.  You do not need the privkey.pem.key symlink.
> 
> If you're going to use the fullchain file in haproxy, then you should also 
> use the ssl-skip-self-issued-ca config that William mentioned so the root 
> cert is not sent to browsers.
> 
> Thanks,
> Shawn
> 

--
Christoph




smime.p7s
Description: S/MIME cryptographic signature