mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
buypass.com support? #415
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @romanrm on GitHub (Jun 24, 2019).
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:
Certbot works fine with it.
@sigio commented on GitHub (Jun 25, 2019):
Yup... also just tried this (being amazed that there are more acme providing CA's now) ... and ran into this same issue.
@lukas2511 commented on GitHub (Jul 4, 2019):
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 commented on GitHub (Jul 4, 2019):
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 commented on GitHub (Jan 27, 2020):
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:
dc70f92568but it seems, at least, advanced so far.@sigio commented on GitHub (Jan 27, 2020):
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 commented on GitHub (Jan 28, 2020):
oops.. Did I gave up too early?
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 commented on GitHub (Jun 30, 2020):
I think the reason why
dehydratedfails with Buypass is quite simple:dehydratedcan'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 becausebashcan't split on anything. In the enddehydratedsends a completely brokencurlrequest with multiple comma-separated URLs in one request.@romanrm commented on GitHub (Jun 30, 2020):
@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:
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 commented on GitHub (Jul 1, 2020):
I think parsing JSON with
sedand regular expressions is a more fundamental problem that makesdehydratedinherently unstable. It should at least optionally use something like jq where you could simply pipe the result throughjq -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,sedetc. is probably not the best choice to implement an ACME client...@romanrm commented on GitHub (Jul 1, 2020):
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.
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 commented on GitHub (Jul 1, 2020):
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 commented on GitHub (Jul 1, 2020):
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 commented on GitHub (Jul 2, 2020):
@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 commented on GitHub (Jul 3, 2020):
jq available in many distros
@lukas2511 commented on GitHub (Jul 4, 2020):
@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 commented on GitHub (Jul 4, 2020):
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 commented on GitHub (Jul 5, 2020):
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 commented on GitHub (Jul 11, 2020):
Buypass works as well with the branch, I'm happy with the result.