Jonathan Matthew writes:
> On Thu, Jun 11, 2026 at 04:26:06AM -0600, Anthony J. Bentley wrote:
> > Jonathan Matthew writes:
> > > Sadly this adds yet another base64 decoder implementation, because there
> > > wasn't one using the base64url encoding that acme-client could get to.
> > > This one is based on the libc bcrypt implementation, because it's short a
> nd
> > > uncomplicated and doesn't care about padding.
> > 
> > It seems that padding matters here. Actalis gave me a key ending in =
> > which acme-client doesn't understand:
> > 
> > $ acme-client -e XXXXXXXXXXXXXXXXXXXXXXXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
> YYYYYYYYYABC= mydomain
> > acme-client: unable to decode EAB key
>
> Interesting.  Most of the code I've looked at for dealing with EAB keys
> will fail if the base64url encoded string is padded with '='s, so I assumed
> we weren't going to see that in the wild.  Can you try this diff?

Yes, this diff allows me to use the key I received from Actalis to get
a certificate.

> Index: base64.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/acme-client/base64.c,v
> diff -u -p -r1.10 base64.c
> --- base64.c	22 May 2026 01:53:10 -0000	1.10
> +++ base64.c	22 Jun 2026 05:08:17 -0000
> @@ -113,6 +113,8 @@ unbase64buf_url(const unsigned char *dat
>                  if ((p + 2) >= data + len)
>                          break;
>  
> +                if (*(p + 2) == '=')
> +                        break;
>                  c3 = CHAR64(*(p + 2));
>                  if (c3 == 255)
>                          return -1;
> @@ -121,6 +123,8 @@ unbase64buf_url(const unsigned char *dat
>                  if ((p + 3) >= data + len)
>                          break;
>  
> +                if (*(p + 3) == '=')
> +                        break;
>                  c4 = CHAR64(*(p + 3));
>                  if (c4 == 255)
>                          return -1;