Own-Mailbox, Let's encrypt, and subdomain limitations

Client dev
1

I’m the main developer of Own-Mailbox, a small self-hosted, privacy-protecting, plug and play, e-mail server. (see www.own-mailbox.com ).

We would like to thank you for listing our project here: https://letsencrypt.org/docs/client-options/

We are releasing an alpha testing version in one week. If people from Let’s encrypt would like to test it it would be with great pleasure.

Unfortunately we just discovered a major problem related to the use of Let’s encrypt within the Own-Mailbox project: the number of certificate that Let’s encrypt accepts to issue for sub-domains of .omb.one is limited. And we are giving these sub-domains to our users, that use them as their main domain. This means only a small fraction of them will be able to generate certificates, for their HTTPs server

Could you give the exact limitation. How exactly does let’s encrypt determine
whether too many certificates were issued or not?

This problem really is a shame:

1)Because until we discovered this problem Own-Mailbox configuration was almost magical of simplicity, and having the webmail accessible in the browser, with a correct certificate, after a very simple configuration process was so great!

2)Because soon I may have hundreds, or even thousands users, that will be hosting an https server, in self-signed mode… (Which I think Let’s encrypt wanted to eradicate)

3)It actually makes its impossible to self-hosting a proper HTTPS with certificate for free AND in an automatic/user-friendly way. Because people will have to pay for a Top Level Domain and mess with TLD resellers.

I don’t know to what extend I can dream that this problem can be over-come in the future.

Thanks in advance for your answers,

Pierre.

2

The rate limits are documented here. This is the one that's probably relevant for you:

Certificates/Domain limits how many certificates can be issued that contain a single registered domain. This is limited to 20 certificates per domain per week. [...]

If I understand your use-case correctly, you "delegate" subdomains of omb.one to your users. This is a typical use-case for the Public Suffix List. Let's Encrypt uses this list to determine on which level the rate limits should be applied, so that if omb.one were a public suffix, the rate limit would apply separately for every subdomain of omb.one, with no overall limit. Browsers also use this list determine allowed cookie scope, among other things, which is why it's probably a good idea to get the domain added anyway. The site has details describing the process for getting added to the list.

Note that the process is far from instantaneous. It might take a couple of months until your domain actually makes it to the copy of the PSL that Let's Encrypt uses. There's no real short-term solution here, other than maybe encouraging users to get free TLDs in the meantime (which is definitely not as easy as the solution you currently have, but could be better than nothing).

1 Like
3

Hi thanks a lot for your message!

I did not know about that public Suffix List. I will have a look at it.

But I should precise that the way we actually give these domains to our users is a bit particular. Actually, to enhance privacy, and to make it possible to have a user-friendly, plug-and-play, self-hosted server, we decided that Own-Mailboxes will only connect to the tor network. (Actually there are iptables that prevent them to access anything else than the local network and the tor network). Own-Mailboxes host tor hidden services, which can be done behind a NAT, and on almost any unfiltered Internet connection (even without a public IP, or ability to open ports).

In order to be accessible from outside of the tor network we maintain a proxy server. When a client access https://test.omb.one, he actually accesses our proxy server, which based on the SNI will redirect the connection to the right Own-Mailbox (through tor). Of course encryption is still done end-to-end between the Own-Mailbox’s HTTPs server and the client, and our proxy server cannot decrypt the traffic.

So the way we give subdomains, is not a traditional way to delegate domain names. Do you think we still have a chance to enter in the Public Suffix List?

4

I think you would still qualify for the PSL with that use-case, yes. Delegating was the wrong word here, it’s enough to give control over the contents of your subdomains to untrusted parties. github.io is on the PSL, and they don’t technically delegate subdomains either.

5

Ok great! We will try to follow the process to get added ASAP! Thanks again for your quick and very useful answer.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.