Do you support dynamic DNS services like No-IP?
1 Like
The protocol as it stands currently is perfectly fine with you getting a certificate for mkoko.dyndns.org. The question is more, should you be allowed to get a certificate for these domains?
I think the answer should be yes, but I’ll leave that up to the LE support to answer. 
that’s an interesting question as for subdomains vs domains in this case - proof of ownership of subdomain doesn’t necessarily mean ownership of the main domain name.
As of now, I don’t know a reason why someone wouldn’t be able to get a certificate for one of these names.
4 Likes
The usual providers don’t support this :(. I think it’s because it’s much less clear what the policies are for a delegated sub-domain. The obvious difference is that “normal” domains are registered in WHOIS database(s), including an expiry date. I wouldn’t just assume letsencrypt can do better.
“Subdomain-only SSL security/availability”
“Implenting an SSL certificate for DynDns”
The other “interesting” thing about sub-domains is the HTTP security model. DynDNS (no longer free) got their domains onto the Public Suffix List. The only other provider that did so was DuckDNS, because I asked them about it :).
If letsencrypt was able to run (or partner with) a DNS sub-domain service as well, that would be great. It’s another lot of work though. If you look at DuckDNS’s support (Google+), they’re constantly taking down malware domains.
But Let's Encrypt supports this. So you don't have to care about your DynDNS service.
BTW if you'd like to get a DynDNS service which also offers DNSSEC and DANE you can use https://desec.io.
We’ve used a paid dyndns account “forever” - but were never able to secure a certificate. I only recently learned certificates were now available (cough,cough) - if we were willing to hand over $60/yr (?).
Now I understand it costs money to maintain infrastructure…but a lot of this stuff looks like “nice work if you can get it”. Perpetual annuities are just ill suited for a decentralized internet.
Unfortunately, my client certificate efforts have come to naught for now 
https://bugzilla.mozilla.org/show_bug.cgi?id=1049176
It’s really, really, difficult for mere mortals to sort these things out. In our case - we’re just trying to secure an old closed family email server. And that’s really, really difficult if you can’t tote around IPsec everywhere: http://www.xoware.com/product/
Being able to provide a certificate for a dyndns subdomain would help us a lot.
What would stop you from creating a self-signed cert and place it’s CA cert on each family members computers? Then you could issue certs for anything and they would trust you / it. Or if they don’t want to give you that level of trust they could just install the specific domain cert. But then again if your family members can’t/don’t trust each other then maybe sharing an email server isn’t/wasn’t such a good idea.
I’ve been using a self-sign cert on my family email server for years. Since the user base is fairly small it’s no big deal to distribute either the domain cert or CA cert to those who need it.
Oh sure, that's reasonable to do for an email server. Not so for a publicly-facing webserver.
Well a family email server is what Reciprocate said they are trying to do. So that is what I addressed.
I’ve registered for the closed beta with a no-ip.org subdomain of mine, and after recieving my invite a few minutes ago tried to generate a certificate for it. Got the following error:
An unexpected error occurred. Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.org Please see the logfiles in /var/log/letsencrypt for more details.
So I guess it (at least with the server settings we have at the moment) only the lucky few first who try will get a letsencrypt certificate for their dynamic dns providers subdomain.
UPDATE: ah, okey, I just found this:
So dynamic dns services that want to allow creation of (more) letsencrypt certificates for subdomains of theirs can request their root domains to be added into this list:
https://publicsuffix.org/list/
UPDATE: I’ve asked the no-ip support and it seems they have no interest to get themselfs on that list, their response sounded more like in their opinion their customers have no right to get issued an SSL certificate by any authority, because only they own their domains.
3 Likes
I asked their support and threatened to switch to another service, they claimed they added themselves to that list after a short time. I could not verify that yet, though.
It seems they requested to be added here: https://github.com/publicsuffix/list/pull/64
It will probably take a few days until publicsuffix.org admins verify their identity by mail check before the pullrequest is merged and then maybe another few days until letsencrypt.org updates their internal copy of the list (and that maybe can only happen after a few days that it might take publicsuffix.org to publish the updated list that you see @ github.com to https://publicsuffix.org/list/public_suffix_list.dat
Thanks for this!
I have just successfully activated and used a certificate for my dedyn.io subdomain.
me@mine:/var/tmp/letsencrypt$ sudo apache2ctl stop
[sudo] password for me:
httpd (no pid file) not running
me@mine:/var/tmp/letsencrypt$ ./letsencrypt-auto --apache --email my@address.used.at.desec
This came as a relief after trying these:
"Error creating new cert :: Too many certificates already issued for: selfhost.eu"
"Error creating new cert :: Too many certificates already issued for: ddns.net"
Yes this seems to be the rate limiting issue already mentioned in this topic.
DeSEC already published a pull request in december for including their domain in the public suffixes list. However it was not merged yet.
If the domain is finally added to the list you will be able to retrieve certificates for it without hitting the rate limit before even getting a single cert.
Currently the only thing you can do is commenting there to push the PR forwards.
I'm one of the maintainers of the PSL. The decision of LE to adopt the list for rate-limiting caused an unexpected rush of submissions, that in most cases are either hard to validate, potentially risky in the long terms or hardly justifiable (like adding 25k domains as part of a single provider).
In general, we're afraid to introduce new domains whose the only intent is to bypass the current Let's Encrypt rate limiting. Not only that can cause a maintenance issue on our side (people requesting to be listed in the future, as soon as they realize the side effects of being listed), but it may potentially cause a disservice to Let's Encrypt since they are relying on the list to avoid a rush of new requests.
That said, commenting the ticket will not push the PR forward as we're currently discussing how to properly proceed, in the light of possible rate-limiting changes as mentioned by @josh, and the override form mentioned by @jcjones in this post.
We're also discussing internally a new validation process for the private domains submissions, as it's getting harder to validate the ownership of these submissions (especially the relationship between the main company identity and the requested suffixes).
We understand the desire to be able to get a free certificate using Let's Encrypt, but if the goal is just to get access to Let's Encrypt, it's probably better to wait for the override form. Of course, if the request still makes sense besides Let's Encrypt and the requestor is fully aware of the implications of being listed, then we'll be happy to add the domain(s) to the list (as soon as possible).
4 Likes
Okay, did not knew this. Thanks for your information.
No problem, my pleasure. 
