Hi,

I am developing a non-letsencrypt acme-proxy and use win-acme during regular regression-testing.

I came across an interoperability issue between my proxy and win-acme. Looking deeper into the problem I noticed that win-acme is constructing the renewal-info path by just adding the base64url-encoded certID to the renewal-info resource.

{renewalInfo url} || certid

The RFC drafts 01 and 02 however require a forward slash between url and certid.

{renewalInfo url} || '/' || certid

Although the problem is not visible when testing against LE (LE sets a forward-slash at the end of the renewal-info resource see below)

grindsa@bumper:~# curl https://acme-v02.api.letsencrypt.org/directory
{
…
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-01/renewalInfo/",
…
}
grindsa@bumper:~#

It might cause issues with othe acme-server implementations (like mine) who are following the RFC draft more strictly. Thus, it would be good to implement midterm a fix by adding a forward slash between renewalinfo url and certid if its not already part of the renewalinfo url.

Thx
G.

Platform:

• OS: Windows 10, English
• win-acme version 2.2.6