Quoting Guilhem Moulin (2020-12-08 12:04:15) > On Mon, 07 Dec 2020 at 16:07:28 +0100, Jonas Smedegaard wrote: > > Error: Invalid order DNS:mail.homebase.dk, DNS:www.mail.homebase.dk > > [mail.homebase.dk] Error: Couldn't issue X.509 certificate! accept: > > Invalid argument at /usr/libexec/lacme/webserver line 80. Connection > > to jawa.homebase.dk closed. > > > > Now, one issue is that it fails. I guess I made some error in the > > setup of mail.homebase.dk config snippet. > > FWIW “Error: Invalid order” is because the ACME challenge object > received from the server had "status": "invalid", cf. RFC 8555 sec. > 7.1.6. AFAICT there is no "detail" field with a human-friendly error > message here, so ACME clients don't have much extra reasoning to > provide. > > > Main issue I raise here, however, is more generally that it is not > > helpful to the user that an internal-to-lacme call to > > /usr/libexec/lacme/webserver passes broken arguments. > > Shouldn't this be merged with #970458?
I don't think so: This bugreport is about confusingly communicating a fatal error, where the other bugreport is about seemingly harmless noise. But see my remark at bottom... > > I guess it might be more helpful if such internal errors would trace > > the error back to the user-facing command. > > You mean the order itself? It's indicated inside the brackets :-) I mean that it seems /usr/libexec/lacme/webserver is saying "I don't understand that command" but for a command given not by me but by lacme or some intermediary library, so instead of telling _me_ that error message it should tell it back to whoever called it, who could then compare the error with whatever it was specifically doing at the time and throwing something more meaningful and/or detailed out to me the user who has only the command-line call to compare against. > The "Error: Invalid order" is spit out by `/usr/libexec/lacme/client`, > attaching an order name to it would be doable but require a bit of > refactoring as the name is currently not included in the IPC. Might not be needed to tie order name - see below... > Could you suggest a better error message here? Generally, I think is might help if informed who says what. I.e. when passing on an error message either received from Letsencrypt or captured from stderr or spawned webserver, then a) mention the origin and b) indent the fowarded message to tie it to previous local message: [jawa.homebase.dk] Valid until 2021-01-21 06:36:57 UTC, skipping [mail.homebase.dk] request failed: rejected by Letsenctypt: Error: Invalid order DNS:mail.homebase.dk, DNS:www.mail.homebase.dk [mail.homebase.dk] Error: Couldn't issue X.509 certificate! [internal error] spurious message from internal webserver: accept: Invalid argument at /usr/libexec/lacme/webserver line 80. [internal error] spurious message from internal webserver: Connection to jawa.homebase.dk closed. You might consider using Log::Any - unless it is deliberate (for security reasons?) to limit use of shared modules. More specifically, it might help if lacme could correlate the various parts that me as operator might not be aware of. One of the errors I made was failing to enable the apache2 snippet to the vhost, which means requests initiated from Letscencrypt didn't get received by lacme. I imagine that when lacme sends a request out and waits for a response, then it could mention that no response was received at all. If lacme already does this, but only when debugging is enabled, then I suggest to simply raise verbosity on failure. > As for "accept: Invalid argument", this comes from > `/usr/libexec/lacme/webserver` , a single instance of which is used > for the entire command so it's not specific to a particular order. I > agree with you that it's not really useful, but the web server is > (intentionally) pretty dumb and will only fail due to socket errors > which don't really have a corresponding user-facing command. This > particular error comes from the accept(2) syscall failing and setting > errno to EINVAL. I *think* it's due to a race condition: lacme(8) > shuts down the webserver's listening socket *before* terminating the > child, causing any blocking accept(2) call to fail, and the scheduler > might allow the error to be spit out before signal handling kicks in. > Need to do more tests but I think simply shutting down the socket last > would fix this. _This_ part seems to be bug#970458, so I suggest re-posting there to reduce the number of issues discusses in same email thread :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
