Re: acme-client(1): fulfil all challenges, then tell the the CA
On Wed, Dec 23, 2020 at 09:58:41PM +, Stuart Henderson wrote:
> On 2020/12/23 18:09, Florian Obser wrote:
> > First fulfil all challenges then tell the CA that it should check.
> >
> > With a CSR with multiple SANs acme-client would write one challenge,
> > tell the CA, write the next challenge and so on.
> >
> > For http-01 this doesn't matter but I think this will be nicer for dns-01
> > because there are propagation delays to consider.
> >
> > Please be extra careful checking this. If I mess this up people might
> > run into renewal issues months from now. And when that happens people
> > tend to comment... (Which I also pull this out of the big diff I'm
> > currently working on for dns-01.)
> >
> > OK?
>
> I tested by forcibly renewing some multi-name certificates. I saw that
> letsencrypt didn't bother re-challenging because they already had a
> recent auth so I moved them to buypass, all looks good. (FWIW I did
Yes, it's a bit annoying that you can't force a revalidation.
Say you fiddle around with your webserver config and want to test if
acme-client still works. Chances are that you won't notice if there is
a problem because let's encrypt just hands you a renewed cert.
Another way to force a revalidation is deleting the account key...
> some ecdsa as well as rsa, not that it matters for this test).
Thanks, one thing I'm worried about is some challenges being valid and
others are pending. (I.e. is the "if() continue" correct, pretty sure
it is since I just pull it down...) But I have no idea how to test
that.
>
> Reads good and works for me, OK.
>
>
> > diff --git netproc.c netproc.c
> > index 38732a4dd01..7c502643acc 100644
> > --- netproc.c
> > +++ netproc.c
> > @@ -840,7 +840,12 @@ netproc(int kfd, int afd, int Cfd, int cfd, int dfd,
> > int rfd,
> > if (readop(Cfd, COMM_CHNG_ACK) != CHNG_ACK)
> > goto out;
> >
> > - /* Write to the CA that it's ready. */
> > + }
> > + /* Write to the CA that it's ready. */
> > + for (i = 0; i < order.authsz; i++) {
> > + if (chngs[i].status == CHNG_VALID ||
> > + chngs[i].status == CHNG_INVALID)
> > + continue;
> > if (!dochngresp(, [i]))
> > goto out;
> > }
> >
> >
> > --
> > I'm not entirely sure you are real.
> >
>
--
I'm not entirely sure you are real.
Re: acme-client(1): fulfil all challenges, then tell the the CA
On 2020/12/23 18:09, Florian Obser wrote:
> First fulfil all challenges then tell the CA that it should check.
>
> With a CSR with multiple SANs acme-client would write one challenge,
> tell the CA, write the next challenge and so on.
>
> For http-01 this doesn't matter but I think this will be nicer for dns-01
> because there are propagation delays to consider.
>
> Please be extra careful checking this. If I mess this up people might
> run into renewal issues months from now. And when that happens people
> tend to comment... (Which I also pull this out of the big diff I'm
> currently working on for dns-01.)
>
> OK?
I tested by forcibly renewing some multi-name certificates. I saw that
letsencrypt didn't bother re-challenging because they already had a
recent auth so I moved them to buypass, all looks good. (FWIW I did
some ecdsa as well as rsa, not that it matters for this test).
Reads good and works for me, OK.
> diff --git netproc.c netproc.c
> index 38732a4dd01..7c502643acc 100644
> --- netproc.c
> +++ netproc.c
> @@ -840,7 +840,12 @@ netproc(int kfd, int afd, int Cfd, int cfd, int dfd, int
> rfd,
> if (readop(Cfd, COMM_CHNG_ACK) != CHNG_ACK)
> goto out;
>
> - /* Write to the CA that it's ready. */
> + }
> + /* Write to the CA that it's ready. */
> + for (i = 0; i < order.authsz; i++) {
> + if (chngs[i].status == CHNG_VALID ||
> + chngs[i].status == CHNG_INVALID)
> + continue;
> if (!dochngresp(, [i]))
> goto out;
> }
>
>
> --
> I'm not entirely sure you are real.
>
acme-client(1): fulfil all challenges, then tell the the CA
First fulfil all challenges then tell the CA that it should check.
With a CSR with multiple SANs acme-client would write one challenge,
tell the CA, write the next challenge and so on.
For http-01 this doesn't matter but I think this will be nicer for dns-01
because there are propagation delays to consider.
Please be extra careful checking this. If I mess this up people might
run into renewal issues months from now. And when that happens people
tend to comment... (Which I also pull this out of the big diff I'm
currently working on for dns-01.)
OK?
diff --git netproc.c netproc.c
index 38732a4dd01..7c502643acc 100644
--- netproc.c
+++ netproc.c
@@ -840,7 +840,12 @@ netproc(int kfd, int afd, int Cfd, int cfd, int dfd, int
rfd,
if (readop(Cfd, COMM_CHNG_ACK) != CHNG_ACK)
goto out;
- /* Write to the CA that it's ready. */
+ }
+ /* Write to the CA that it's ready. */
+ for (i = 0; i < order.authsz; i++) {
+ if (chngs[i].status == CHNG_VALID ||
+ chngs[i].status == CHNG_INVALID)
+ continue;
if (!dochngresp(, [i]))
goto out;
}
--
I'm not entirely sure you are real.
