buypass.com support?

[romanrm]

Hello,

Did anyone try to use the CA at https://www.buypass.com/ssl/products/acme ?

I'm doing everything seemingly right, but get this error:

+ Generating account key...
+ Registering account key with ACME server...
  + ERROR: An error occurred while sending post-request to https://api.buypass.com/acme/new-reg (Status 400)

Details:
HTTP/1.1 100 Continue

HTTP/1.1 400 Bad Request
Date: Mon, 24 Jun 2019 21:36:01 GMT
X-Buypass-Internal-Error-Detail-Code: MALFORMED_BAD_REQUEST
Content-Type: application/problem+json
Replay-Nonce: NmE4NTExOTMtZjczNi00NzlhLWFjM2UtOGM3ZWE4NTk2MWIz
Cache-Control: no-store
Content-Language: en
Access-Control-Allow-Origin: https://www.buypass.no
Access-Control-Allow-Headers: Content-Type,Authorization,X-Requested-With,Content-Length,Accept,Origin,X-Buypass-Session-Id,X-Buypass-Locale
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET,HEAD,POST
MDC-correlationId: caa82b71-95bd-4664-918f-f734213b526f
Content-Length: 153

{"code":400,"message":"MALFORMED_BAD_REQUEST","details":"HTTP 400 Bad Request","type":"urn:ietf:params:acme:error:malformed","detail":"INVALID_JSON_JWS"}



Error registering account key. See message above for more information.

Certbot works fine with it.

[sigio]

Yup... also just tried this (being amazed that there are more acme providing CA's now) ... and ran into this same issue.

[lukas2511]

I'm not entirely sure what's happening here.

It throws a signature error on account registration, but that is very standardized and if there would be an issue with dehydrated it shouldn't even work on Let's Encrypt servers... so that's very confusing...

[romanrm]

As I mentioned it works with Certbot. Maybe a simple way to diagnose would be to capture what request Certbot sends, and compare it to what Dehydrated sends.

[imhfg0ar]

Bypass seems fixed they error message - now it clearly says what they simple don't accept registrations without email (and default for dehydrated is undefined).

Now it accepts registrations, but strangely dislike it then trying to actually make cert. @lukas2511 - may you look at it another time?

uacme have other problem with them: ndilieto/uacme@dc70f92 but it seems, at least, advanced so far.

[sigio]

Buypass works for me ..... with current git dehydrated...
Both wildcards (on their test instance) and regular certs (on prod).
(This was both based on dns-01 validations, didn't test http-01)

[imhfg0ar]

oops.. Did I gave up too early?

• Checking domain name(s) of existing cert... unchanged.
• Checking expire date of existing cert...
• Valid till Jan 29 03:45:57 2020 GMT (Less than 30 days). Renewing!
• Signing domains...
• Generating private key...
• Generating signing request...
• Requesting new certificate order from CA...
• Received 1 authorizations URLs from the CA
• ERROR: An error occurred while sending post-request to https://api.test4.buypass.no/acme-v02/authz/Vt9mjauBd6EV2K_7Kgo5pCw28KyfgudczukGnvdPyK8, (Status 404)

Details:
HTTP/1.1 100 Continue

HTTP/1.1 404 Not Found
Date: Mon, 27 Jan 2020 10:03:18 GMT
X-Buypass-Internal-Error-Detail-Code: NOT_FOUND
Content-Type: application/problem+json
Replay-Nonce: ZjU2ZjgxZTktYWZlNS00MjdhLTg1ZDMtOWRkNWZhMjI1NDA0
Cache-Control: no-store
Content-Language: en
Access-Control-Allow-Origin: https://www.buypass.no
Access-Control-Allow-Headers: Content-Type,Authorization,X-Requested-With,Content-Length,Accept,Origin,X-Buypass-Session-Id,X-Buypass-Locale
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET,PUT,POST,OPTIONS,HEAD,DELETE
MDC-correlationId: 655be0c0-130a-40fe-860e-68bf408c890c
Content-Length: 97

{"code":404,"message":"NOT_FOUND","details":"Authorization, matching client's request not found"}

no access to .well-known in my server logs, so it seems not the problem with challenge.
Possible dns-01 will work, because client registration finishes ok after providing email.

[sekrause]

I think the reason why dehydrated fails with Buypass is quite simple:

• The official Let's Encrypt API returns pretty printed JSON.
• Buypass returns minified JSON.
• dehydrated can't deal with completely minified JSON because it uses simple regular expressions to parse the response.

The problem is in this line: When the "authorizations" list in the result contains multiple items with no spaces between them, the next for-loop doesn't work correctly because bash can't split on anything. In the end dehydrated sends a completely broken curl request with multiple comma-separated URLs in one request.

[romanrm]

@sekrause cheers for digging into it. The "perl" package on my system has a program called "json_pp" which "converts between some input and output formats", noting that "the default input format is json and the default output format is json with pretty option". Adding that into a pipe at the line you pointed to, simply like so:

order_authorizations="$(echo ${result} | json_pp | get_json_array_value authorizations)"

let me successfully register an account and request a certificate. Too bad my experiments domain (.hk) was rejected as "high risk" by buypass, and a brief attempt with a production one failed with an error message that "Client doesn't have a valid authorization for identifier: " (one of the subdomains). Perhaps there are more places where adding json_pp in the same way would help.

[sekrause]

Perhaps there are more places where adding json_pp in the same way would help.

I think parsing JSON with sed and regular expressions is a more fundamental problem that makes dehydrated inherently unstable. It should at least optionally use something like jq where you could simply pipe the result through jq -r ".authorizations | .[]" to extract all JSON array values separated by a newline.

Personally after having a look at the code I'm now more inclined to simply switch to another client. Using bash, sed etc. is probably not the best choice to implement an ACME client...

[romanrm]

I think parsing JSON with sed and regular expressions is a more fundamental problem

Oh sure. I did not intend that as an official fix (adding one more dependency on an unrelated external program), just musings on what we could try "right now" for a quick workaround.

Using bash, sed etc. is probably not the best choice to implement an ACME client...

I love it exactly for what it is, that all code is contained in a single shell-script and can be easily (for some definitions of) and quickly audited even by a single person. I don't want to install complex pieces of software with tons of dependencies, which think they "know better" and try to do everything, including mess with my server configs and restart system services. So for me the existence of this client is the main reason I got on board with the whole Let's Encrypt idea in the first place.

[txr13]

The fact that this client is all shell-script is exactly why I use it. I don’t want to have to install (and document and maintain) a client with more dependencies than absolutely necessary. And if those dependencies are provided by default with the system, so much the better.

[lukas2511]

Yea, JSON parsing is a big problem but for me it's one of the great things that dehydrated doesn't need weird dependencies that are not available on many distros. I have bad time management and was surprisingly busy over the last few months and I hope to be able to invest more time into dehydrated in the coming days. Rewriting the JSON parser (or integrating JSON.sh) is one of the main things on my TODO list...

[imhfg0ar]

@sekrause - thank you for at least finding the case of the problem which nobody bothered and/or had the skill before! just pretty-printing of the compressed json is not so hard to write with bash and sed/cut (if one timely understands what it's a finite state machine algo and really wish to do), but jq is definitely more appropriate solution if you stick to bash and system utilities - sooner or later you will need it anyway in the modern world.

For others I suggest migration to acme-tiny: it really tiny indeed, it requires only python (no extra dependencies except of openssl binary - so no uglier or unsafer than bash+tons of old-good unix utils, just another interpreter available even on smallest embedded platforms, with native support for json), it can be understood and modified if needed even if you are not python programmer. It's also left almost unmaintained, but few issues on it's page easily can be read and followed (or ignored if it's not for your specific case).
The dehydrated way of handling json is certainly wrong and insane (and possible insecure - because we stumbled upon the place where it makes wrong assumption about external data and breaks on it).

[Supme]

jq available in many distros

[lukas2511]

jq available in many distros

@Supme Yea, in "many" distros. But dehydrated is actually used on tons of different systems, some embedded, some very old, some with jq only being available from experimental / 3rd-party repos. As soon as I'd introduce that dependency I'd have dozens of requests to remove the dependency again as dehydrated would be unusable on those systems. I'm not willing to do that as long as there are alternatives (e.g. JSON.sh).

[lukas2511]

I now have an experimental jsonsh branch (https://github.com/dehydrated-io/dehydrated/tree/jsonsh) with which I was able to successfully receive a buypass.com certificate.

It's to be considered extremely experimental as I'll have to check every part of the code that touches JSON values, and will have to test support over various systems before merging it to master.

[sekrause]

I can confirm that the jsonsh branch works with the main Let's Encrypt API. I'll test Buypass as soon as I'm not rate-limited there anymore (have played around too much with certificates the last few days).

[sekrause]

Buypass works as well with the branch, I'm happy with the result.