You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 9, 2026. It is now read-only.
Even with MDRenewViaARI off and "ari-renewals": false in the corresponding md.json, orders have the replaces attribute set.
This is unfortunate, RFC9773 says "Clients SHOULD NOT include this field if the ACME server has not indicated that it supports this protocol by advertising the renewalInfo resource in its Directory." and we do indeed use a CA that rejects these requests since they do not offer ARI.
Only "workaround" I have found so far is to either manually remove all traces of the currently-used certificate (i.e. in domains/ and archive/) or rotate the ServerName.
I guess ad_setup_order() might be a good place to check for that? (I'm sorry, I'm not fluent enough in httpd conventions to see what is easily visible where.)
Even with
MDRenewViaARI offand"ari-renewals": falsein the corresponding md.json, orders have the replaces attribute set.This is unfortunate, RFC9773 says "Clients SHOULD NOT include this field if the ACME server has not indicated that it supports this protocol by advertising the renewalInfo resource in its Directory." and we do indeed use a CA that rejects these requests since they do not offer ARI.
Only "workaround" I have found so far is to either manually remove all traces of the currently-used certificate (i.e. in domains/ and archive/) or rotate the
ServerName.I guess
ad_setup_order()might be a good place to check for that? (I'm sorry, I'm not fluent enough in httpd conventions to see what is easily visible where.)