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
I'm currently implementing the ACME interface for a CA and used your client library for testing the implementation which was very helpful.
During my tests I stumbled upon one thing in the GenericAcmeProvider which caused some issues in my tests:
public URL resolve(URI serverUri) {
try {
return new URL(serverUri.getScheme(), serverUri.getHost(), serverUri.getPort(), serverUri.getPath());
} catch (MalformedURLException ex) {
throw new IllegalArgumentException("Bad generic server URI", ex);
}
}
Any query parameters of the directory URL passed into acme4j will get stripped here. Since in my implementation query parameters of the directory URL are used to add additional information to the order URL (e.g. choosing different certificate types) this information is lost.
I know that is is possible to override this by writing a custom provider which is what I did in the end.
Nevertheless, I wanted to ask you if there is a particular reason why the URI is not passed in completely since there is no requirement in RFC 8555 which prohibits the use of query parameters.
The text was updated successfully, but these errors were encountered:
My plans are to reserve the query parameters as parameters to be used by the acme: URI style providers.
But I also didn't expect the directory resource to accept query parameters. 😃 The GenericAcmeProvider should not strip, but forward them. I will fix that.
Hi,
I'm currently implementing the ACME interface for a CA and used your client library for testing the implementation which was very helpful.
During my tests I stumbled upon one thing in the GenericAcmeProvider which caused some issues in my tests:
Any query parameters of the directory URL passed into acme4j will get stripped here. Since in my implementation query parameters of the directory URL are used to add additional information to the order URL (e.g. choosing different certificate types) this information is lost.
I know that is is possible to override this by writing a custom provider which is what I did in the end.
Nevertheless, I wanted to ask you if there is a particular reason why the URI is not passed in completely since there is no requirement in RFC 8555 which prohibits the use of query parameters.
The text was updated successfully, but these errors were encountered: