Certificates for many user-controlled subdomains

Issuance Policy
3

As far as I know, there are exemptions to that rule for things like localhost/127.0.0.1. See Secure Contexts

  • If origin’s host component is or falls within "localhost." [RFC6761], return "Potentially Trustworthy".
  • If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return "Potentially Trustworthy".

External access can be solved via your own DynDNS (probably using dns-01 challenges).

This leaves a couple of things unsolved:

  • Users will have to use different URLs for internal (http://localhost/) and external (https://userid.yourddns.com/) access. Alternatively, you could use split-horizon DNS (public DNS resolves to your WAN IP, local DNS to 127.0.0.1).
  • Only localhost/127.0.0.0/8 is trustworthy, so this wouldn't work if the server is running on another IP in your LAN. Two possible solutions:
  • Split-horizon DNS, like the previous example, except that your local DNS would resolve to the LAN IP.
  • Use a separate DynDNS domain for LAN access (https://internal.clientid.yourddns.com/). Resolve that IP to the server's LAN IP. Issue a SAN certificate that covers both domains. Note: Some DNS resolvers scrub replies containing private IP addresses.