New version of Actalis' ACME server just deployed in production fixing a number of minor issues

[defacto64]

Actalis has deployed into production this morning a new version of its ACME server that addresses the following issues mentioned in #605:

• The directory endpoint advertises a keyChange endpoint, but when you try to do an account key rollover, you get an ACME error with the text, "key rollover failed".
• Account objects advertise the orders field, but when queried with a POST-as-GET, just the account object is returned.
• Attempting to create an order with an IP address identifier results in an ACME error with the text, "Blocking CAA record(s) found on one or more of the specified domains".
• Authorization objects don't seem to be cached like other CAs (which is fine). It just means you have to re-authorize every time. And attempting to explicity deactivate an authorization doesn't throw an error, but also doesn't seem to change the status of the authorization object you supposedly deactivated.
• Cert revocation only seems to work when signing the request with the account key that generated the cert. Signing the request with the cert key throws an error, urn:ietf:params:acme:error:accountDoesNotExist

So, @rmbolger, I would like to ask you to also carry out a further test (when you feel like) and then, if everything is well, to modify (or remove) the Actalis-related notes at the bottom of page https://poshac.me/docs/latest/Guides/ACME-CA-Comparison/ accordingly (alternatively, could we do a PR for this purpose?).

[rmbolger]

Just wanted to say I haven't forgotten about this. Hoping to get to it soon now that the holidays are over.

[defacto64]

Ok, TIA.

[defacto64]

Hi, any chance you can redo some testing in the next few days?

[rmbolger]

Doing some testing this evening and I'd just like to say congrats on having the first (that I'm aware of) real implementation of the ACME Orders List. No clients I know of (including this one) support it very well. But now that there's a reference implementation to test against, I know I plan on fleshing out support for it.

One minor nitpick. The spec says the server "SHOULD NOT include orders that are invalid in the array of URLs". But all of my previous expired/invalid orders are currently being returned. It's technically optional with the "SHOULD" wording, but in case your devs feel like going the extra mile. 😉

[rmbolger]

Finished re-testing all of the bullet points you mentioned and updated the page accordingly. The only thing I didn't test was the failed challenge retries because you didn't mention it and I ran out of time tonight. Was that fixed as well or are you still working on it?

[defacto64]

Will check and revert.