Issues creating account with Actalis EAB

[alyx161]

Hi,

I’m running into issues with account creation when using Actalis as the CA.
Since Actalis requires EAB, I’ve used the ZeroSSL example as a basis.

eab := acme.ExternalAccountBinding{
	KeyIdentifier: acmeProvider.KeyIdentifier,
	MacKey:        acmeProvider.MacKey,
	Algorithm:     "HS256",
	HashFunc:      crypto.SHA256,
}

account, err := client.NewAccountOptions(
	privKey,
	acme.NewAcctOptAgreeTOS(),
	acme.NewAcctOptWithContacts("mailto:me@example.com"),
	acme.NewAcctOptExternalAccountBinding(eab),
)
if err != nil {
	return acme.Account{}, fmt.Errorf("error creating new account: %v", err)
}

acc := acmeAccountFile{
	PrivateKey: string(key2pem(privKey)),
	Url:        account.URL,
}

When running this, the ACME server replies with:

error creating new account: acme: error code 400 \"urn:ietf:params:acme:error:userActionRequired\": onlyReturnExisting must be true

If I then add NewAcctOptOnlyReturnExisting(), the request obviously fails:

account, err := client.NewAccountOptions(
	privKey,
	acme.NewAcctOptAgreeTOS(),
	acme.NewAcctOptWithContacts("mailto:me@example.com"),
	acme.NewAcctOptExternalAccountBinding(eab),
	acme.NewAcctOptOnlyReturnExisting(),
)

error creating new account: acme: error code 400 \"urn:ietf:params:acme:error:accountDoesNotExist\": "

Any ideas on what I might be missing here?

[defacto64]

@alyx161 , did you solve your problem?

[alyx161]

@defacto64 Unfortunately not.. Still no idea how I could solve this :/

[cpu]

This is a bug in the Actalis ACME server that should be reported to them to fix.

A similar issue was reported to another ACME client I help maintain. There's some analysis in this issue but the TLDR is Actalis is refusing new account requests with onlyReturnExisting set to false instead of omitted. This is not justified by my reading of RFC 8555 and a bug on their part.

The JSON tags on the eggsampler/acme type representing a new account request would include the false value in requests, provoking the buggy response from the Actalis ACME server:

acme/types.go

Line 220 in 18f89bd

OnlyReturnExisting bool `json:"onlyReturnExisting"`

I believe adding omitempty to the JSON tags would work-around the issue, but as mentioned in the instant-acme issue, this should be fixed once and for all by Actalis instead of patched in each and every standards compliant ACME client.

[alyx161]

@defacto64 is from Actalis, so maybe he can take a look on that or forward it to the right place?

[defacto64]

I am not aware of any bugs in our ACME server, and we have quite a number of customers. But you never know.
Have you tried, @alyx161 , to first request a certficate using a command-line ACME client such as Certbot or Win-ACME ?
I suggest you do it, so we can rule out certain possible problems.
Make sure you subscribed to the right plan (for you) on the Actalis website and that you are using the right EAB credentials.

[cpu]

I am not aware of any bugs in our ACME server, and we have quite a number of customers

This bug would specifically prevent users of some clients from being able to register an account, so you likely do not hear from them.

Have you tried, alyx161 , to first request a certficate using a command-line ACME client such as Certbot or Win-ACME ?

As my previous messages details, a client that omits the field when the value is false will not trigger the bug so tests with other clients that succeed are not demonstration of the absence of an issue with the server.

The point is that sending the value when it's false is allowed by the protocol RFC so the error result w/ a problem description ("onlyReturnExisting must be true") that your server is returning is incorrect behavior. There is no text in RFC 8555 that I'm aware of requiring that field be omitted, or have the value true.

[alyx161]

I am not aware of any bugs in our ACME server, and we have quite a number of customers. But you never know. Have you tried, @alyx161 , to first request a certficate using a command-line ACME client such as Certbot or Win-ACME ? I suggest you do it, so we can rule out certain possible problems. Make sure you subscribed to the right plan (for you) on the Actalis website and that you are using the right EAB credentials.

Yes, I can use the EAB credentials with other clients like Certbot or acme.sh.
I can even use an account created by acme.sh with eggsampler/acme to request certificates.

Also, when I use different or invalid EAB details, I get a different error message.

I’m quite sure this is an issue caused by some behavior on the Actalis ACME server side, since the exact same code works perfectly fine with ZeroSSL, SSL.com, and the Google CA.
Not saying this is Actalis fault, just that the Actalis ACME server behaves slightly different than those from the other CAs I've tested.

It seems to be related to the issue @cpu mentioned.

[defacto64]

I think I understand the issue.
If someone had written to us directly to report this, we certainly would have looked into it sooner. I just stumbled upon this by chance, while looking for other things...
Now that I'm aware of this problem, we'll definitely start looking into it.
I'll let you know.

[cpu]

If someone had written to us directly to report this, we certainly would have looked into it sooner.

I've been encouraging customers to report the problem since it wasn't clear how a non-customer could. In the event something like this comes up again in the future, what mechanism would you recommend ACME client developers use to report issues like this one?

I wouldn't want to use the certificate problem report mechanism from your CP/CPS for this, but your software doesn't have a GitHub presence and your website contact information directs non-customers to provide information for the sales department.

Now that I'm aware of this problem, we'll definitely start looking into it.

Thank you!

[defacto64]

We've managed to reproduce the issue in our development environment.
I will let you know when we plan to release a fix.