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)
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.
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)
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: