ZeroSSL integration failing to create account

[johnfishbein]

Hi,

I am trying to invoke the lua-resty-acme library from kong using the acme plugin . I have been successfully using this workflow with LetsEncrypt for a long time now. Recently, I have started to hit rate limit concerns from letsencrypt and have been investigating switching over to a paid CA. My overall goal is to use this same kong + lua-resty-acme workflow with ZeroSSL. Howver, it is not working.

Originally I was specifying EAB credentials into client initialization acme.new. This was getting the error:

2022/06/27 16:13:17 [error] 20949#0: *1900 [kong] handler.lua:118 failed to update certificate: eab_handler undefined while EAB is required by CA, context: ngx.timer, client: 205.209.24.227, server: 0.0.0.0:443

I believe this is because I have provided the eab credentials in the config, this handler is unable to be loaded due to this condition here. Because the eab_handler is not set here, later in the execution flow, there is a condition that explicitly requires the eab handler here. This causes the error log that I am seeing.

Overall - I think this is because I am specifying EAB credentials and then also invoking the acme_client:new_account(). From the ZeroSSL discovery at https://acme.zerossl.com/v2/DV90, clearly "externalAccountRequired" = true and so I orignally thought that I needed to provied external EAB credentials. This was probably my initial misundersanding of the role of the EAB credentials.

---

In any case, I tried removed the eab_kid and eab_hmac_key from the acme client instantiation and instead let the account (and credentials) be created by the handler in the library.

From the logs, the zerossl eab handler is successfully creating eab credentials (I assume that these credentials are related to my account through the account_email though I am not sure.). The error occurs in the first request to the acme server that needs to use the credentials to create an account. Following the logs, the library injects some JWS stuff into the request which includes the credentials generated in the previous step.

2022/06/27 17:23:45 [debug] 30427#0: *802 [acme] client.lua:259: jws payload: {"payload":{"termsOfServiceAgreed":true,"contact":["mailto:johnf@truera.com"],"externalAccountBinding":{"protected":"eyJraWQiOiJKUVNqQmVqNjVDdmdxdGhRZW1DTjRnIiwiYWxnIjoiSFMyNTYiLCJ1cmwiOiJodHRwczpcL1wvYWNtZS56ZXJvc3NsLmNvbVwvdjJcL0RWOTBcL25ld0FjY291bnQifQ","payload":"eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsIm4iOiJyTlhzRFJWQU9DV1RKNU1ZbUY2am1RZTRNNmJyUUMxa0Iycng2RVZXd0xHZ1B6d3FkLUhzZEZzTFRPb0ZuU240Q0lnRXM4MXgzLXRlQkhVLVZ6dnRMOGNDYVR2RTB2THd6N0xKcEtHYnF1eThhZEJpSUJGUEJubTZaQVBLaDRUNFI0OVpwQTV5eTZiNDBaZ1BIMUJlNk5idXR4U2QwQVBWSlNYcjhlbWhKYTg4SkZKSW9LRDZyRGVRUU1tTnRLY2dRQnd6ZEpnSzlWVWR1OG5HUzJKTGFjZEFRQ3NpY1h0XzdQTm9jLVJBQTdXdnpkMGszbURITXRxNU9mMWNtV2lxMTFxUHZVSGNpLUM5eEVoaDVwV3BIT3pDV2x4TDRsOTB6Wnp4SUtobXJRbjkwU0FzZFZtMUdzSmlQZVVxNHR5Snp5VXFQWkN5UWdCeHZOQ1V2VDg1akZpdzI0SGxPLTNQOHRkNW9nLTFDYkpGZnZQUWN3V2ZtN2pJZXVnVE1fV1dKNDNOX1ZrY2FLOElvdlhRSDlkVm42YlppMWFfUzk5X2diQ2syWVRIVlJiWVZYNmZZY042aUw2Zmc5cldEWmxvcjl4Qi1zdFZ3TzZmNFpEV2w3UzBlbGJiTDhhUU1qclFGZmhreGJ3dVkxVVp6MDZ6eW16bl9MT1lGNVdTOGFpVW5fUzQ5ZF92LTdNWFY2RkNXR1JTdmZqQ3g3ZjNVdGdaUHozRFQwTzZ1WlBPOENYSVdPeXpkZWpkN0pTVzZEZUcwNzJwQUZRXzJWRTR4U05kQUppOTM5OEZKdUIyRmdiblNEaEpfQmxyUmw2d3RaMzc5a3poM3lHTERjdTdPaG9LRGluTEVnSklLUXpwS2lGblA2RE83MFFXVEdpMmVVajlpRy1XQWRPaFBUVSJ9","signature":"kXv0CIP3tXrEY5WiJi6VrzXm2EAlrE--SfskgfFlwoE"}},"protected":{"jwk":{"kty":"RSA","e":"AQAB","n":"rNXsDRVAOCWTJ5MYmF6jmQe4M6brQC1kB2rx6EVWwLGgPzwqd-HsdFsLTOoFnSn4CIgEs81x3-teBHU-VzvtL8cCaTvE0vLwz7LJpKGbquy8adBiIBFPBnm6ZAPKh4T4R49ZpA5yy6b40ZgPH1Be6NbutxSd0APVJSXr8emhJa88JFJIoKD6rDeQQMmNtKcgQBwzdJgK9VUdu8nGS2JLacdAQCsicXt_7PNoc-RAA7Wvzd0k3mDHMtq5Of1cmWiq11qPvUHci-C9xEhh5pWpHOzCWlxL4l90zZzxIKhmrQn90SAsdVm1GsJiPeUq4tyJzyUqPZCyQgBxvNCUvT85jFiw24HlO-3P8td5og-1CbJFfvPQcwWfm7jIeugTM_WWJ43N_VkcaK8IovXQH9dVn6bZi1a_S99_gbCk2YTHVRbYVX6fYcN6iL6fg9rWDZlor9xB-stVwO6f4ZDWl7S0elbbL8aQMjrQFfhkxbwuY1UZz06zymzn_LOYF5WS8aiUn_S49d_v-7MXV6FCWGRSvfjCx7f3UtgZPz3DT0O6uZPO8CXIWOyzdejd7JSW6DeG072pAFQ_2VE4xSNdAJi9398FJuB2FgbnSDhJ_BlrRl6wtZ379kzh3yGLDcu7OhoKDinLEgJIKQzpKiFnP6DO70QWTGi2eUj9iG-WAdOhPTU"},"url":"https:\/\/acme.zerossl.com\/v2\/DV90\/newAccount","alg":"RS256","nonce":"4M4Zycv7nLVzo1YX_CnhM7fEMIG40OJx3T0jckTnyV8"}}
2022/06/27 17:23:52 [debug] 30427#0: *802 [acme] client.lua:305: acme request: https://acme.zerossl.com/v2/DV90/newAccount response: {"type":"urn:ietf:params:acme:error:unauthorized","status":401,"detail":"The Request URL in the JWS Protected Header does not match the actual Request URL"}

2022/06/27 17:00:02 [error] 28754#0: *163 [kong] handler.lua:118 failed to update certificate: failed to create account: The Request URL in the JWS Protected Header does not match the actual Request URL, context: ngx.timer, client: 205.209.24.227, server: 0.0.0.0:443

Parsing the logs, you can see that the request is going to https://acme.zerossl.com/v2/DV90/newAccount but the information in the protected section of the payload has that the url is https:\/\/acme.zerossl.com\/v2\/DV90\/newAccount.

Is this an error with the jws encoding that is happening? Am I misunderstanding the role of the EAB credentials? What is the recommended approach to generated certificates throug ZeroSSL?

Thank you so much for your help!

[johnfishbein]

This is the invocation of the lua-resty-acme library that the kong plugin is performing. I hope this helps to provide clarity on my approach.

The kong plugin invokes this acme library as follows:
https://github.com/Kong/kong/blob/master/kong/plugins/acme/client.lua#L108

acme_client, err = acme.new({
    account_email = conf.account_email, -- my email
    account_key = account.key,
    api_uri = url, -- "https://acme.zerossl.com/v2/DV90"
    storage_adapter = storage_full_path,
    storage_config = conf.storage_config[conf.storage],
    eab_kid = conf.eab_kid, -- nil
    eab_hmac_key = conf.eab_hmac_key, -- nil
    -- challenge_start_callback = ... 
    preferred_chain = conf.preferred_chain, -- nil
  })

https://github.com/Kong/kong/blob/master/kong/plugins/acme/client.lua#L129

acme_client:init()
acme_client:new_account()
acme_client:order_certificate(key, host)

[fffonion]

Hi @johnfishbein thanks for the detailed report. It does seem the logic to handle predefined eab crendential is wrong. You can let the library to create it for you at present, you should still be able to see the certs in zerossl dashboars as long as you use the corresponding email to login.

The \/ is json's escape logic, it's same as / when decoded. So I'm not sure how/why zerossl returns this error; my previous experience is that zerossl has some hidden "limits" on the newAccount API, it returns sometimes 500 sometimes others, even though a different acme client is used. But you can try swap the account private key, that seems to clear the "limit".

[johnfishbein]

@fffonion Thanks for your response - I will try swapping the account_key as suggested.

[fffonion]

Closing as inactivity, please reopen if needed : )

[johnfishbein]

Ah sorry, forgot to close the loop here - your PR #71 fixed the issue for me since I am now able to use my predefined eab credentials. Thanks for your help!