Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL fails on non-standard TLD's such as those from Handshake #50

Open
GrimblyGorn opened this issue Jan 29, 2022 · 6 comments
Open

SSL fails on non-standard TLD's such as those from Handshake #50

GrimblyGorn opened this issue Jan 29, 2022 · 6 comments

Comments

@GrimblyGorn
Copy link

This is the error that gets thrown when trying to generate the SSL certificates using a Handshake TLD.

Create new order error. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rejectedIdentifier",
"detail": "Error creating new order :: Cannot issue for "superadmin.handshaketld": Domain name does not end with a valid public suffix (TLD)",
"status": 400
}
[Sat Jan 29 10:49:42 UTC 2022] Please add '--debug' or '--log' to check more details.
[Sat Jan 29 10:49:42 UTC 2022] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

While this is a failing point for Acme and not SuperAdmin it would be helpful to have some idea as to how I could get around the acme based SSL and use my own. I found a tool called Handout that was able to generate appropriate DANE-based SSL certs for the TLD but now I'm not sure how to make SuperAdmin recognize and use them.

Any suggestions would be appreciated :)

@petersirka
Copy link
Collaborator

Hi @GrimblyGorn,
sorry for delay.

Can you send me your domain name? I need to test it locally what SuperAdmin will send.

@GrimblyGorn
Copy link
Author

Hi @petersirka,
Thanks for the reply, and for this very nice framework :)

The domains I used were super.sikuli and superadmin.sikuli. I changed the A record for .sikuli to point to the docker container hosting the superadmin for both domains but then I get the error mentioned above and haven't gotten past that still. Sikuli is the Handshake TLD I was using for these tests but I have dozens of these TLDs I was hoping to put into production for various sites, services, and apps I was planning to make. I was successful at connecting to both through HTTP so the A record and the connection points in question were correct in my tests, but the SSL certs never succeeded to generate, and eventually, I noticed those errors finally and realized why it wasn't succeeding.

Hopefully, this helps you some. If there's any additional info you may need or if you'd like me to set up a TLD for you to test with directly just let me know. I can easily point one of these wherever you'd like for a while if you provide the A, CNAME, TXT, MX, NS, DS, or ALIAS records you need me to fill in for your testing. In my case, I only used the A records so far but I'm happy to help out and lend one of these for testing whatever else you may wish to test as well.

@GrimblyGorn
Copy link
Author

@petersirka A few more quick notes for you :)

On something of a side note it does occur to me that having native support for Handshake TLDs, domains, and sub-domains could be fairly advantageous considering there is little to no options currently for TLD or domain owners and with over 1 million TLDs sold already, half a dozen well-known registrars offering them, and official browser support through opera on the way it's only a matter of time before large hordes of people start looking around for a way to secure their new sites and use them. That IMO sounds like a nice scenario for any platform to embrace.

There are other blockchain-based TLDs these days like ENS and such but those fall short every time compared to Handshake. I think this article from HackerNoon did a nice job of explaining in more detail why that is and why Handshake will ultimately continue its march forward as well.

In case you'd like to dig in a bit more here are a few more links you may find helpful.
https://github.com/handshake-org/
https://hsd-dev.org/

Also, if you were asking in your initial response for me to literally send you the TLD then I can accommodate that as well if you need. I have a very large pile of these and could gift you one through Namebase if you would like. Then you can play around with it directly and do whatever you'd like with it. No need to return it. It'll be my gift to you for your time. Though I can't promise it'll be an especially useful TLD it should at least offer some utility value for you.

If you would like me to send you one just let me know the email you used for the Namebase account and it's super simple to send it over after. Though it should be noted that it could take a couple of weeks for you to actually have ownership over the TLD cause I think it has to go through some long process being confirmed on the blockchain each time they change hands. After the confirmation period, it's all yours, and doing it through Namebase may actually bypass that wait. I can't recall for sure offhand :)

Anyway, just let me know either way and I'll help how and where I can :)

@GrimblyGorn
Copy link
Author

I'm just guessing with this, but it seems like during the installation if this Handshake SPV node was used it could quickly check if the TLD was a standard one or a Handshake version and switch between the current method or the Handout method of generating SSL certs accordingly.

Just a thought.

@petersirka
Copy link
Collaborator

@GrimblyGorn thank you a lot for the significant info. This problem is bigger than I thought, and I'm thinking about how I can help you. As you wrote, the problem is in ACME.SH, but I'll try to analyze your points more with my colleagues (I'm not at home on this topic).

For now - maybe a better solution will be to use your own SSL certificates for your domain (or try to generate certificates via certbot).

@GrimblyGorn
Copy link
Author

@petersirka Thanks for looking into this and the response. Sorry to have thrown such a large complication your way. It was never stated that SuperAdmin could achieve this, so it's quite alright that it doesn't. The platform you've made is still very impressive.

I will look into your advice more and see if I can come up with a workaround. If I do find one, I'll be sure to mention that here for anyone else that may need such a solution.

I do still think that natively supporting Handshake TLDs across your platform could be a huge advertisement for you and would basically serve up that whole community to you on a platter at this point. I'm not saying that has to become your top priority as I'm sure there are already plenty of things on your plate to contend with and work on. But, having the keys to a whole community is usually a short-lived opportunity for capitalizing on. On the plus side, nobody is first yet and that's the real seat to be in usually for such things. So, grabbing that would likely persist favorably long after and make you the most likely choice even after others begin supporting Handshake natively as well. Might be worth looking into at least.

Additionally, I do have a few other ideas on how you could capitalize even more off Handshake if you're interested. While I can't say for sure if these ideas would be of any interest to you I do feel they may be better shared in private. The email you've linked on GitHub should be sufficiently private enough to chat more on that subject if you'd like. Just let me know and I can send all that over for you. If you have no interest in my nonsense notions that's perfectly alright too :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants