Certificate options in a distributed network

[NemesisFLX]

My domain is: senseering.net

I ran this command: greenlock get domain

It produced this output: The api is rate limited for exact domain

This is a similar question like the one here.

We are developing a distributed network where every participant should be able to share and sell data to other participants. Anyone who wants to join the network should be able to get a valid https connection to the centralized marketplace. Our current approach is to create subdomains like device-name.user-name.senseering.net that points to the correct ip address and afterwards let the software on the participants device itself retrieve the certificate via greenlock/lets encrypt.

As stated in the linked thread this will be rate limited heavily until the system is not usable anymore. So we also tried to go with direct ip-address verification, but this did not work with lets encrypt.

Currently i am out of ideas where we can get more then 50 certificates per week without hitting the rate limit and without the participants needing its own domain. Is there a workaround to solve this or is there some way to work together with lets encrypt on a solution?

Regards
Felix

[JuergenAuer]

Hi @NemesisFLX

Our current approach is to create subdomains like device-name.user-name.senseering.net that points to the correct ip address and afterwards let the software on the participants device itself retrieve the certificate via greenlock/lets encrypt.

there is a simple solution. Add the domain name senseering.net to the Public Suffix List.

https://publicsuffix.org/list/public_suffix_list.dat

Then

user-name.senseering.net 

is a domain name, not a subdomain name. So every user-name can have max. 50 new certificates per week. Should be enough

PS: But I don’t know how much time is required to add a new entry to the PSL.

[NemesisFLX]

That sounds awesome! Thank you very much !

[cpu]

Hi @NemesisFLX, welcome to the community forum

Currently i am out of ideas where we can get more then 50 certificates per week without hitting the rate limit and without the participants needing its own domain. Is there a workaround to solve this or is there some way to work together with lets encrypt on a solution?

I recommend you complete our rate limit adjustment request form. Please complete it as fully as possible. We often don’t have the time to follow-up on incomplete requests. We can likely help you out with this rate limit.

there is a simple solution. Add the domain name senseering.net to the Public Suffix List.

I don’t recommend folks pursue being added to the PSL strictly for Let’s Encrypt rate limiting.

In fact the Public Suffix List maintainers specifically call this out in their documentation as not being sufficient justification for an amendment request:

• We do not accept entries whose sole purpose is to circumvent Let’s Encrypt rate limits. They have a form you can use.

There are other reasons that being added to the PSL may make sense in this case (e.g. cookie scoping) but Let’s Encrypt rate limits can’t be the only one.

PS: But I don’t know how much time is required to add a new entry to the PSL.

I can’t speak for the maintainers but I watch that repo closely and would estimate that on average it takes longer to have a PSL entry addition processed than it does to complete a rate limit adjustment via our form.

Hope that helps!

[JuergenAuer]

In fact the Public Suffix List maintainers specifically call this out in their documentation as not being sufficient justification for an amendment request:

Ah, thanks, good to know.

[NemesisFLX]

Hi @cpu,

I think i have a problem with this solution. I can try to change the rate limit, but this will help for just a bit until we hit another bottleneck. Currently everytime a new participant joins the network he gets one certificate. As we are not big right now we probably are not hitting any real rate limits ( I discovered it by registering to many in the process of developing the software ). The thing is that the moment we are hitting the rate limit we wont have the time to make requests and this would probably make the service unavailable.

Is there a way to handle the requests to lets encrypt similar to what @JuergenAuer said, but without making a change to the psl?

I currently see no good solution that scales well…

[NemesisFLX]

I thought about this. And i think cookie security is also a good reason, because the website will be run by other people and is quite modular or can even be changed completely. So we are going for the PSL inclusion.

This solves a problem i didn’t even thougth about until now.

[JuergenAuer]

@NemesisFLX

And i think cookie security is also a good reason, because the website will be run by other people and is quite modular or can even be changed completely.

Yes, the Cookie argument is relevant if different users are able to create cookies with the main domain name.