Re: acme-client issue with domain w/ alternative name
On Thu, Nov 07, 2019 at 11:34:48PM +, Mik J wrote: > Hello, > What this does mean ?> Just to follow up: Of my two problem domains, one was > caused by pebkac pebkac = problem exists between keyboard and chair. In other words, user error
Re: acme-client issue with domain w/ alternative name
Hello, What this does mean ?> Just to follow up: Of my two problem domains, one was caused by pebkac I tried to force the renewal -F but have that error. Also I read that someone had a A record missing, I have a CNAME with NOERROR. It should also work with a valid CNAME. Regards Le mercredi 23 octobre 2019 à 07:44:12 UTC+2, Ian Darwin a écrit : On 10/21/19 19:38, Ian Darwin wrote: > Today acme-client renewed all but 2 of my domains; the two that have > "alternative names" > in the certificates. I cannot get it to renew those two. This is on amd64 on > 6.6-current, > updated today. > Just to follow up: Of my two problem domains, one was caused by pebkac (sorry) and the other, which I tried 5 or 6 times last night, worked like a charm this morning, with no config changes. I'll just blame transient network conditions for that one.
Re: acme-client issue with domain w/ alternative name [Solved]
Daniel Winters(daniel.wint...@tydirium.org) on 2019.10.24 10:53:22 +0100: > For the archives: > > With the help of Florian and Ian we managed to find the error in the > setup: One of the alternative names in acme-client.conf had no A record > in DNS anymore (it was removed a few days prior). > > acme-client will fail in such a case and return "status": "invalid" in > the output of acme-client -vv. > > After removing the entry from acme-client.conf everything works as > expected (with the "EOF without close" warning which is unrelated). > > Thanks to everybody who helped! Thanks for figuring it out. I wont be searching for a bug then.
Re: acme-client issue with domain w/ alternative name [Solved]
For the archives:
With the help of Florian and Ian we managed to find the error in the
setup: One of the alternative names in acme-client.conf had no A record
in DNS anymore (it was removed a few days prior).
acme-client will fail in such a case and return "status": "invalid" in
the output of acme-client -vv.
After removing the entry from acme-client.conf everything works as
expected (with the "EOF without close" warning which is unrelated).
Thanks to everybody who helped!
Daniel
>>> > Today acme-client renewed all but 2 of my domains; the two that have
>>> > "alternative names" in the certificates. I cannot get it to renew
>>> > those two. This is on amd64 on 6.6-current, updated today.
>>>
>>> I can reproduce this on amd64 current, as well as on 6.6.
>>>
>>> Same error and and very similar configuration based on the one in
>>> /etc/examples.
>>
>> you mean renewing fails for you with alternative names or you mean you
>> see tls_close: EOF without close notify? I think everybody sees that.
>> It started to show up some time ago. I think let's encrypt changed
>> something on the server.
>
> Sorry for not being more clear - I was not aware of the EOF without
> close warning and had not seen this on the logs before. I thought this
> was related to my renewal error.
>
>> In any case, I just force-renewed a cert with alt names and it just
>> worked.
>
> I can confirm it works on stock 6.6 as expected (with the EOF warning),
> however I still cannot get it to work on a -current amd64 web server.
>
>> please run acme-client with -vv to see what's going on over the
>> network if you have renew problems.
>
> Here it is (sensitive parts replaced with ):
>
> photon# acme-client -vv .com
> acme-client: acme-client: /etc/ssl/www..com.crt: certificate
> renewable: 17 days left
> acme-client: /etc/ssl/private/www..com.key: loaded domain key
> /etc/acme/letsencrypt-privkey.pem: loaded account key
> acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
> acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
> acme-client: transfer buffer: [{ "4-vjXo89exY":
> "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;,
> "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change;, "meta":
> { "caaIdentities": [ "letsencrypt.org" ], "termsOfService":
> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;,
> "website": "https://letsencrypt.org; }, "newAccount":
> "https://acme-v02.api.letsencrypt.org/acme/new-acct;, "newNonce":
> "https://acme-v02.api.letsencrypt.org/acme/new-nonce;, "newOrder":
> "https://acme-v02.api.letsencrypt.org/acme/new-order;, "revokeCert":
> "https://acme-v02.api
> .letsencrypt.org/acme/revoke-cert" }] (658 bytes)
> acme-client: acme-v02.api.letsencrypt.org: cached
> acme-client: acme-v02.api.letsencrypt.org: cached
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: transfer buffer: [{ "key": { "kty": "RSA", "n":"", "e":
> "AQAB" }, "contact": [], "initialIp": "","createdAt":
> "2018-09-10T00:42:09Z", "status": "valid" }] (857 bytes)
> acme-client: acme-v02.api.letsencrypt.org: cached
> acme-client: acme-v02.api.letsencrypt.org: cached
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: transfer buffer: [{ "status": "pending", "expires":
> "2019-10-30T11:21:09.947891596Z", "identifiers": [ { "type": "dns", "value":
> ".com" }, { "type": "dns", "value": "mail..com" }, { "type":
> "dns", "value": "photon..com" }, { "type": "dns", "value":
> "www..com" } ], "authorizations": [
> "https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372032;,
> "https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372034;,
> "https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372035;,
> "https://acme-v02.api.letsencrypt.org/acme/authz-v3/904391026; ], "finalize":
> "https://acme-v02.api.letsencrypt.org/acme/finalize/41820606/1346625758; }]
> (757 bytes)
> acme-client: dochngreq:
> https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372032
> acme-client: acme-v02.api.letsencrypt.org: cached
> acme-client: acme-v02.api.letsencrypt.org: cached
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value":
> ".com" }, "status": "valid", "expires": "2019-11-28T08:41:55Z",
> "challenges": [ { "type": "http-01", "status": "valid", "url":
> "https://acme-v02.api.letsencrypt.org/acme/chall-v3/888372032/TlKsVA;,
> "token": "v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg", "validationRecord": [
> { "url":
> "http://.com/.well-known/acme-challenge/v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg",
> "hostname": ".com", "port": "80", "addressesResolved": [
> "" ], "addressUsed": "" } ] }, { "type": "dns-01",
> "status": "pending", "url":
> "https://acme-v02.api.letsencrypt.org/acme/chall-v3/888372032/BC5eNQ;,
> "token": "v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg" }, { "type":
>
Re: acme-client issue with domain w/ alternative name
Hi Florian,
>> > Today acme-client renewed all but 2 of my domains; the two that have
>> > "alternative names" in the certificates. I cannot get it to renew
>> > those two. This is on amd64 on 6.6-current, updated today.
>>
>> I can reproduce this on amd64 current, as well as on 6.6.
>>
>> Same error and and very similar configuration based on the one in
>> /etc/examples.
>
> you mean renewing fails for you with alternative names or you mean you
> see tls_close: EOF without close notify? I think everybody sees that.
> It started to show up some time ago. I think let's encrypt changed
> something on the server.
Sorry for not being more clear - I was not aware of the EOF without
close warning and had not seen this on the logs before. I thought this
was related to my renewal error.
> In any case, I just force-renewed a cert with alt names and it just
> worked.
I can confirm it works on stock 6.6 as expected (with the EOF warning),
however I still cannot get it to work on a -current amd64 web server.
> please run acme-client with -vv to see what's going on over the
> network if you have renew problems.
Here it is (sensitive parts replaced with ):
photon# acme-client -vv .com
acme-client: acme-client: /etc/ssl/www..com.crt: certificate renewable:
17 days left
acme-client: /etc/ssl/private/www..com.key: loaded domain key
/etc/acme/letsencrypt-privkey.pem: loaded account key
acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
acme-client: transfer buffer: [{ "4-vjXo89exY":
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;,
"keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change;, "meta": {
"caaIdentities": [ "letsencrypt.org" ], "termsOfService":
"https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, "website":
"https://letsencrypt.org; }, "newAccount":
"https://acme-v02.api.letsencrypt.org/acme/new-acct;, "newNonce":
"https://acme-v02.api.letsencrypt.org/acme/new-nonce;, "newOrder":
"https://acme-v02.api.letsencrypt.org/acme/new-order;, "revokeCert":
"https://acme-v02.api
.letsencrypt.org/acme/revoke-cert" }] (658 bytes)
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: transfer buffer: [{ "key": { "kty": "RSA", "n":"", "e":
"AQAB" }, "contact": [], "initialIp": "","createdAt":
"2018-09-10T00:42:09Z", "status": "valid" }] (857 bytes)
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: transfer buffer: [{ "status": "pending", "expires":
"2019-10-30T11:21:09.947891596Z", "identifiers": [ { "type": "dns", "value":
".com" }, { "type": "dns", "value": "mail..com" }, { "type":
"dns", "value": "photon..com" }, { "type": "dns", "value":
"www..com" } ], "authorizations": [
"https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372032;,
"https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372034;,
"https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372035;,
"https://acme-v02.api.letsencrypt.org/acme/authz-v3/904391026; ], "finalize":
"https://acme-v02.api.letsencrypt.org/acme/finalize/41820606/1346625758; }]
(757 bytes)
acme-client: dochngreq:
https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372032
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value":
".com" }, "status": "valid", "expires": "2019-11-28T08:41:55Z",
"challenges": [ { "type": "http-01", "status": "valid", "url":
"https://acme-v02.api.letsencrypt.org/acme/chall-v3/888372032/TlKsVA;, "token":
"v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg", "validationRecord": [ { "url":
"http://.com/.well-known/acme-challenge/v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg",
"hostname": ".com", "port": "80", "addressesResolved": [ ""
], "addressUsed": "" } ] }, { "type": "dns-01", "status": "pending",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/888372032/BC5eNQ;,
"token": "v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg" }, { "type":
"tls-alpn-01", "status": "pending", "url":
"https://acme-v02.api.letsencrypt.org/acme/chall-v3/888372032/MNZeLQ;, "token":
"v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg" } ] }] (1131 bytes)
acme-client: challenge, token:v0Hxmbjl_8FtlvG-pvOylQuH_8BUS73WVMMOiXfwtBg,
uri:https://acme-v02.api.letsencrypt.org/acme/chall-v3/888372032/TlKsVA,status:
2
acme-client: dochngreq:
https://acme-v02.api.letsencrypt.org/acme/authz-v3/888372034
Re: acme-client issue with domain w/ alternative name
On 10/21/19 19:38, Ian Darwin wrote: Today acme-client renewed all but 2 of my domains; the two that have "alternative names" in the certificates. I cannot get it to renew those two. This is on amd64 on 6.6-current, updated today. Just to follow up: Of my two problem domains, one was caused by pebkac (sorry) and the other, which I tried 5 or 6 times last night, worked like a charm this morning, with no config changes. I'll just blame transient network conditions for that one.
Re: acme-client issue with domain w/ alternative name
On Tue, Oct 22, 2019 at 09:56:57AM +0100, Daniel Winters wrote:
> Good morning,
>
> > Today acme-client renewed all but 2 of my domains; the two that have
> > "alternative names" in the certificates. I cannot get it to renew
> > those two. This is on amd64 on 6.6-current, updated today.
>
> I can reproduce this on amd64 current, as well as on 6.6.
>
> Same error and and very similar configuration based on the one in
> /etc/examples.
you mean renewing fails for you with alternative names or you mean you
see tls_close: EOF without close notify? I think everybody sees that.
It started to show up some time ago. I think let's encrypt changed
something on the server.
In any case, I just force-renewed a cert with alt names and it just
worked.
please run acme-client with -vv to see what's going on over the
network if you have renew problems.
>
> Daniel
>
>
> > My acme-config.conf is the latest example version, with the v2 URLs
> > and with example.com replaced by my domains.
> >
> > #
> > # $OpenBSD: acme-client.conf,v 1.2 2019/06/07 08:08:30 florian Exp $
> > #
> > authority letsencrypt {
> > api url "https://acme-v02.api.letsencrypt.org/directory;
> > account key "/etc/acme/letsencrypt-privkey.pem"
> > }
> >
> > authority letsencrypt-staging {
> > api url "https://acme-staging-v02.api.letsencrypt.org/directory;
> > account key "/etc/acme/letsencrypt-staging-privkey.pem"
> > }
> >
> > domain androidcookbook.com {
> > alternative names { androidcookbook.net }
> > domain key "/etc/ssl/private/androidcookbook.com.key"
> > domain certificate "/etc/ssl/androidcookbook.com.crt"
> > domain full chain certificate
> > "/etc/ssl/androidcookbook.com.fullchain.pem"
> > sign with letsencrypt
> > }
> > domain annabot.org {
> > domain key "/etc/ssl/private/annabot.org.key"
> > domain certificate "/etc/ssl/annabot.org.crt"
> > domain full chain certificate
> > "/etc/ssl/annabot.org.fullchain.pem"
> > sign with letsencrypt
> > }
> > ...
> >
> > The first domain fails, the second one succeeded.
> >
> > $ doas acme-client androidcookbook.com
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > $ echo $?
> > 1
> > $
> >
> > IDK what those EOF w/o notify are caused by, but the domains that worked
> > also gave a similar bunch of that message.
> >
> > Running with -v does not give any useful info except it ends with -1:
> >
> > $ doas acme-client -v -F androidcookbook.com
> > acme-client: /etc/ssl/androidcookbook.com.crt: certificate renewable: 29
> > days left
> > acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
> > acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: dochngreq:
> > https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690343
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: challenge, token: 22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So,
> > uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q,
> > status: 0
> > acme-client: /var/www/acme/22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So:
> > created
> > acme-client:
> > https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q:
> > challenge
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: dochngreq:
> > https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690357
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: challenge, token: XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU,
> > uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw,
> > status: 0
> > acme-client: /var/www/acme/XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU:
> > created
> > acme-client:
> > https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw:
> > challenge
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: order.status -1
> > acme-client: bad exit: netproc(82984): 1
> > $
> >
> >
> > Any thoughts or more info? Thx.
>
--
I'm not entirely sure you are real.
Re: acme-client issue with domain w/ alternative name
Good morning,
> Today acme-client renewed all but 2 of my domains; the two that have
> "alternative names" in the certificates. I cannot get it to renew
> those two. This is on amd64 on 6.6-current, updated today.
I can reproduce this on amd64 current, as well as on 6.6.
Same error and and very similar configuration based on the one in
/etc/examples.
Daniel
> My acme-config.conf is the latest example version, with the v2 URLs
> and with example.com replaced by my domains.
>
> #
> # $OpenBSD: acme-client.conf,v 1.2 2019/06/07 08:08:30 florian Exp $
> #
> authority letsencrypt {
> api url "https://acme-v02.api.letsencrypt.org/directory;
> account key "/etc/acme/letsencrypt-privkey.pem"
> }
>
> authority letsencrypt-staging {
> api url "https://acme-staging-v02.api.letsencrypt.org/directory;
> account key "/etc/acme/letsencrypt-staging-privkey.pem"
> }
>
> domain androidcookbook.com {
> alternative names { androidcookbook.net }
> domain key "/etc/ssl/private/androidcookbook.com.key"
> domain certificate "/etc/ssl/androidcookbook.com.crt"
> domain full chain certificate
> "/etc/ssl/androidcookbook.com.fullchain.pem"
> sign with letsencrypt
> }
> domain annabot.org {
> domain key "/etc/ssl/private/annabot.org.key"
> domain certificate "/etc/ssl/annabot.org.crt"
> domain full chain certificate
> "/etc/ssl/annabot.org.fullchain.pem"
> sign with letsencrypt
> }
> ...
>
> The first domain fails, the second one succeeded.
>
> $ doas acme-client androidcookbook.com
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> $ echo $?
> 1
> $
>
> IDK what those EOF w/o notify are caused by, but the domains that worked
> also gave a similar bunch of that message.
>
> Running with -v does not give any useful info except it ends with -1:
>
> $ doas acme-client -v -F androidcookbook.com
> acme-client: /etc/ssl/androidcookbook.com.crt: certificate renewable: 29 days
> left
> acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
> acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: dochngreq:
> https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690343
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: challenge, token: 22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So,
> uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q,
> status: 0
> acme-client: /var/www/acme/22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So:
> created
> acme-client:
> https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q: challenge
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: dochngreq:
> https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690357
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: challenge, token: XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU,
> uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw,
> status: 0
> acme-client: /var/www/acme/XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU:
> created
> acme-client:
> https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw: challenge
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: 172.65.32.248: tls_close: EOF without close notify
> acme-client: order.status -1
> acme-client: bad exit: netproc(82984): 1
> $
>
>
> Any thoughts or more info? Thx.
acme-client issue with domain w/ alternative name
Today acme-client renewed all but 2 of my domains; the two that have
"alternative names"
in the certificates. I cannot get it to renew those two. This is on amd64 on
6.6-current,
updated today.
My acme-config.conf is the latest example version, with the v2 URLs and with
example.com replaced by
my domains.
#
# $OpenBSD: acme-client.conf,v 1.2 2019/06/07 08:08:30 florian Exp $
#
authority letsencrypt {
api url "https://acme-v02.api.letsencrypt.org/directory;
account key "/etc/acme/letsencrypt-privkey.pem"
}
authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory;
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
domain androidcookbook.com {
alternative names { androidcookbook.net }
domain key "/etc/ssl/private/androidcookbook.com.key"
domain certificate "/etc/ssl/androidcookbook.com.crt"
domain full chain certificate
"/etc/ssl/androidcookbook.com.fullchain.pem"
sign with letsencrypt
}
domain annabot.org {
domain key "/etc/ssl/private/annabot.org.key"
domain certificate "/etc/ssl/annabot.org.crt"
domain full chain certificate
"/etc/ssl/annabot.org.fullchain.pem"
sign with letsencrypt
}
...
The first domain fails, the second one succeeded.
$ doas acme-client androidcookbook.com
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
$ echo $?
1
$
IDK what those EOF w/o notify are caused by, but the domains that worked
also gave a similar bunch of that message.
Running with -v does not give any useful info except it ends with -1:
$ doas acme-client -v -F androidcookbook.com
acme-client: /etc/ssl/androidcookbook.com.crt: certificate renewable: 29 days
left
acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: dochngreq:
https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690343
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: challenge, token: 22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So,
uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q,
status: 0
acme-client: /var/www/acme/22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So: created
acme-client:
https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q: challenge
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: dochngreq:
https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690357
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: challenge, token: XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU,
uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw,
status: 0
acme-client: /var/www/acme/XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU: created
acme-client:
https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw: challenge
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: order.status -1
acme-client: bad exit: netproc(82984): 1
$
Any thoughts or more info? Thx.
