Hi Aleks, On Sat, Nov 22, 2025 at 09:10:17AM +0100, Aleksandar Lazic wrote: > > acme: none.at.pem: Successful update of the certificate.
Great! > After the successful creation of the Cert+Key here the feedback to the docs. > > In https://docs.haproxy.org/dev/management.html#9.3-acme%20status > > > - The state of the acme task, either "Running", "Scheduled" or "Stopped" > > When is the Certificate Ready or usable? > > As the state "Scheduled" can't be find in > https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.6 , I expect this > means 'Scheduled for renew and valid for usage' right? > Well that's normal, it is not related to the status of an Authorization object in the ACME protocol. It's really just the status of the ACME task associated to a certificate. > Maybe the command "acme status none.at.pem" shows more detail about the acme > state similar to "show ssl cert none.at.pem" to be able to automate the acme > stuff like this. But this command is about the scheduling of the task, not about the certificate. If you want to know about the certificate, you just use "show ssl cert". If the "expires in" is not 0, your certificate is usable. > ``` > echo "acme status none.at.pem" | socat - /tmp/hap-stats | grep -Ei invalid > => trigger renew > ``` > or with json output. > There's no "invalid" state, you are confusing the ACME protocol with the state of the scheduling. You don't have to manually trigger the renew, it is scheduled, everything is automated depending on the expiration date. That's why you have a scheduled date in the command. > Looks like in dpapi sink are the infos. > > ```shell > alex@alex-tuxedoinfinitybooks1517gen7 on 22/11/2025 at 08:39:47_CET > /datadisk/git-repos/haproxy $ > # echo "show events dpapi" | socat - /tmp/hap-stats > ... > <0>2025-11-22T08:18:36.970272+01:00 acme deploy none.at.pem thumbprint > KUPYKb-oN7x2ZsaWObc5_odROuGfkQgOdRpVQ9N_zWw > dns-01-record "StQiL5JrufnS8PrI1-zu2kpLm7O-Lo4qC7Yj3YBcQLQ" > { > "identifier": { > "type": "dns", > "value": "none.at" > }, > "status": "valid", > "expires": "2025-12-22T07:07:09Z", > "challenges": [ > { > "type": "dns-01", > "url": > "https://acme-staging-v02.api.letsencrypt.org/acme/chall/244976483/20362691543/maH2Iw";, > "status": "valid", > "validated": "2025-11-22T07:07:08Z", > "token": "aahPPGJXuCBB2A2dWILR8K6K5NcBjF0a0lglDtnMla8", > "validationRecord": [ > { > "hostname": "none.at", > "addressUsed": "" > } > ] > } > ] > } > > <0>2025-11-22T08:18:37.128883+01:00 acme deploy none.at.pem thumbprint > KUPYKb-oN7x2ZsaWObc5_odROuGfkQgOdRpVQ9N_zWw > dns-01-record "_wcHgxxgc7UodVnjkroQknQSHZKrggzFVgkt7KAk320" > { > "identifier": { > "type": "dns", > "value": "none.at" > }, > "status": "valid", > "expires": "2025-12-22T07:07:09Z", > "challenges": [ > { > "type": "dns-01", > "url": > "https://acme-staging-v02.api.letsencrypt.org/acme/chall/244976483/20362691533/RLZYJw";, > "status": "valid", > "validated": "2025-11-22T07:07:08Z", > "token": "0SJwmK1NThNDHCxRu-wNQTTXOgIr8xfcXElJbGW-H5g", > "validationRecord": [ > { > "hostname": "none.at", > "addressUsed": "" > } > ] > } > ], > "wildcard": true > } > > <0>2025-11-22T08:19:34.862874+01:00 acme newcert none.at.pem > ``` > These are things that I didn't document for now, that's the protocol which is used by the dataplaneAPI to trigger the DNS API calls, and save the certificate on the disk. > I have seen that in the Dataplane API is the acme part on the way to be > integrated ( > https://github.com/haproxytech/dataplaneapi/commit/673f23c990c347a99ef66fdc37213acd471b0720 > ) it would be nice to add the libdns/desec provider as asked in > https://github.com/haproxytech/dataplaneapi/issues/395 so that it can be > tried to test the dpapi with ACME DNS feature. > I think you also have a way to launch a script manually from the dataplaneapi to do that, but I'm not sure how it's don.e > I like the https://github.com/haproxy/wiki/wiki/ACME:--native-haproxy how > can I contribute to it? > I'll check with Willy if we can add you directly in the wiki permission list. > A big thank you for the great work to all Humans which was involved to bring > this Feature into HAProxy. > Thanks! > Some question not related to the ACME stuff. > > What tell this output to the users? > > ``` > Sharing caphdr with caphdr > Sharing caphdr with caphdr > Sharing ptrcap with ptrcap > Sharing ptrcap with ptrcap > ``` > That's debug information of the pool sharing because you compiled in debug mode. Users are not supposed to have this :-) > When I start haproxy? > ```alex@alex-tuxedoinfinitybooks1517gen7 on 22/11/2025 at 09:01:27_CET > /datadisk/git-repos/haproxy $ > # ./haproxy -W -db -f ../haproxy_acme.cfg > [NOTICE] (14018) : Initializing new worker (14020) > Sharing caphdr with caphdr > Sharing caphdr with caphdr > Sharing ptrcap with ptrcap > Sharing ptrcap with ptrcap > [NOTICE] (14020) : Automatically setting global.maxconn to 524263. > Sharing stk_ctr with caphdr > [NOTICE] (14018) : Loading success. > ``` > It would be nice to add some log level to the message like "[NOTICE] : " so > that log parsers can be used in generic way. > That's debugging, maybe we could just have [DEBUG] but I don't know if it's adapted for every cases we have. > My global section. > ``` > global > expose-experimental-directives > log stdout format raw daemon info > stats socket /tmp/hap-stats mode 660 level admin expose-fd listeners > ``` Well it does not use the log, it's really just some fprintf on stderr. > > I like the new SSL infos :-) > > > 127.0.0.1:40140 [22/Nov/2025:08:23:38.291] in/2: SSL handshake failure > (error:0A000418:SSL routines::tlsv1 alert unknown ca) > We have these for a few versions now, you can also customized it with the error-log-format like these: https://docs.haproxy.org/3.2/configuration.html#8.2.5 Regards, -- William Lallemand
