I’m using a DDNS service to make my home server available at a fixed domain name. I currently use a self signed certificate, but like to change to let’s encrypt. I have a general question regarding the security with DDNS:
Let’s say I got a lets encrypt certificate for my domain my.ddns.com , but for some reason (my server crashed etc.) I don’t update the IP at my DDNS service provider (after i got a new IP from my ISP), so that the DNS record still contains the old IP address.
Let’s also assume, that some other evil guy (lets call him eve) now gets the IP address assigned that previously was assigned to me and eve (for some reason) knows, that this IP is attached to my.ddns.com.
Is there any security mechanism, that prevents eve from also issuing a letsencryp certificate for my.ddns.com (or even any other provider of free ssl certificates)?
In terms of preventative mechanisms there aren’t any options available to you today that I can think of (other than trying to make sure the IP address is always correct). In terms of reactive mechanisms you could revoke Eve’s certificate once you’ve fixed the A record for the DDNS domain to point to an IP you control. You would need to follow the “Using a different authorized account” approach from this documentation page. The other two revocation options wouldn’t apply (Only Eve has the certificate private key and private key for the owning ACME account).
If you are able to set CAA records with the DynDNS provider for my.ddns.com (I suspect this may not be supported ) you might be able to use a new security feature in the near future when it becomes available in production as a preventative control.
RFC 8657 (“Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding”) lets you set an accounturi value in the CAA record. Let’s Encrypt wouldn’t let any ACME accounts except the one listed issue certificates for the domain without updating the CAA record first, even if they could otherwise prove control of the domain (e.g. because of the stale IP address). You could use an accounturi CAA record to restrict issuance to your own ACME account and Eve’s account wouldn’t be authorized.
Let’s Encrypt has support for RFC 8657 in staging, but it isn’t yet supported in production. Support is pending some procedural work with the CA/Browser Forum that’s on the go now.
Hope that helps. Thanks for the question, it was interesting to noodle about
If you’re able to set CAA records you could use a RFC 6844 CAA record that sets an "issuer" policy that only allows the CAs you use (e.g. Let’s Encrypt) to issue for the domain. Our CAA docs have more info. Other CAs are required to check these CAA records and refuse to issue if they are not included as an issuer. This would prevent Eve from using a different SSL certificate provider than ones you allow.
In the situation you describe, eve legitimately controls, through your negligence, my.ddns.com. He shouldn’t, but he does. You should not expect favorable outcomes when you give your adversaries advantages like this.
When you get back the control of your domain via updating the DNS record to point your current IP, the certificate issued by “Eve” could not even be used practically. Clients will not connect to the old IP address, so the malicious certificate will not be presented to them.
Hi 
) you might be able to use a new security feature in the near future when it becomes available in production as a preventative control.