fix: skip "onlyReturnExisting" if it's set to false

[DorianNiemiecSVRJS]

This pull request causes instant-acme to skip serializing the "onlyReturnExisting" field, if only_return_existing field of instant_acme::NewAccount struct is set to false.

This would fix issues creating new accounts in the Actalis ACME directory.

I have seen a note about the only_return_existing field:

Setting this to false has not been tested.

[cpu]

👋 Thanks for the patch.

This would fix issues creating new accounts in the Actalis ACME directory.

I think this is a bug that Actalis should fix regardless of a change on our side. Have you reported it to them?

RFC 8555 specs this field as an optional boolean and so seeing it present with the false value is wasted bytes on the wire from a semantic point of view, but certainly not invalid from a protocol point of view. They should process the new account request as normal.

[DorianNiemiecSVRJS]

I think this is a bug that Actalis should fix regardless of a change on our side. Have you reported it to them?

Well, I haven't reported this to Actalis yet...

In current upstream instant-acme, when trying to use with Actalis ACME directory, if only_return_existing field of instant_acme::NewAccount struct is set to false, this causes the API error: onlyReturnExisting must be true (urn:ietf:params:acme:error:userActionRequired) error, but when it's set to true, this can cause the API error (urn:ietf:params:acme:error:accountDoesNotExist) error.

When "onlyReturnExisting" JSON field is omitted (like it's on my fork, when only_return_existing field of instant_acme::NewAccount struct is set to `false), the ACME account gets created just fine (at least during my own testing).

[cpu]

Well, I haven't reported this to Actalis yet...

I think it's worthwhile. The behaviour you're describing is a bug in their ACME implementation and will continue to cause interop. issues with other standards compliant ACME clients in the future.

if only_return_existing field of instant_acme::NewAccount struct is set to false, this causes the API error: onlyReturnExisting must be true (urn:ietf:params:acme:error:userActionRequired) error

There's no RFC text that justifies this API response and that's the crux of the bug they should fix. The value is allowed to be present+false, and should only be processed when it's both present+true.

[cpu]

The behaviour you're describing is a bug in their ACME implementation and will continue to cause interop. issues with other standards compliant ACME clients in the future.

For example: eggsampler/acme#29 !