4 ms·

You need a domain name registered. Otherwise what would they issue the certificate for? You could buy a domain though, then have a local dns resolve it to your

by Buge 11y ago

You need a domain name registered. Otherwise what would they issue the certificate for? You could buy a domain though, then have a local dns resolve it to your own machine. Alternatively you could use a self signed cert and sign it to localhost or whatever, then configure all your browsers to trust this certificate.

pkaye 11y ago
Is it possible to do without Chrome complaining about the validity of the self signed cert?
- singlow 11y ago
  If you have a registered domain and get a DV cert from LE or anywhere else, chrome will not complain about the cert. If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device.
  - lucb1e 11y ago
    > If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device. You say it like "any browser will complain unless you modify the device", but in Firefox you can just add it to the local trust store. They manage their own so that works just fine. Many applications actually allow you to permanently accept a certificate (heck, SSH) which then alerts you if it changes. It is actually reasonably secure if you aren't on an insecure network the first time around. Just Chrome keeps complaining annoyingly.
lucb1e 11y ago
> Otherwise what would they issue the certificate for? A subdomain of something like DynDNS or just your IP address. I know you can't for good reasons, but I'm just saying, it would make sense if you never heard it's for domains only.
- pfg 11y ago
  DynDNS works fine. CA/B Baseline Requirements (which all trusted CAs have to follow) forbid issuance of certificates that include internal names. Whether you actually bought the domain or just have control over a subdomain (as with DynDNS) doesn't matter. As long as the domain is on the Public Suffix List (which should be best practice for DynDNS providers), you don't even have to worry about rate limits. AFAIK, certificates for non-reserved IPs would be allowed. Let's Encrypt doesn't support that, however. I imagine proof of ownership would be harder to demonstrate for an IP address (compared to a DNS name).
  - lucb1e 11y ago
    > As long as the domain is on the Public Suffix List Oh, cool, I did not know that this project included stuff like DynDNS! I thought a normal, paid domain was the only way to go (other than dot tk). > AFAIK, certificates for non-reserved IPs would be allowed. Many IP addresses are dynamic though, I know of no CA where you can register an IP address and I'd imagine it being for that reason (and it might be CGNAT and perhaps some other reasons). You can of course self-sign one with an IP address, but I don't expect any CA to sign those.

by Buge 11y ago

pkaye 11y ago

Is it possible to do without Chrome complaining about the validity of the self signed cert?

singlow 11y ago
If you have a registered domain and get a DV cert from LE or anywhere else, chrome will not complain about the cert. If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device.
- lucb1e 11y ago
  > If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device. You say it like "any browser will complain unless you modify the device", but in Firefox you can just add it to the local trust store. They manage their own so that works just fine. Many applications actually allow you to permanently accept a certificate (heck, SSH) which then alerts you if it changes. It is actually reasonably secure if you aren't on an insecure network the first time around. Just Chrome keeps complaining annoyingly.

lucb1e 11y ago

> Otherwise what would they issue the certificate for? A subdomain of something like DynDNS or just your IP address. I know you can't for good reasons, but I'm just saying, it would make sense if you never heard it's for domains only.

pfg 11y ago
DynDNS works fine. CA/B Baseline Requirements (which all trusted CAs have to follow) forbid issuance of certificates that include internal names. Whether you actually bought the domain or just have control over a subdomain (as with DynDNS) doesn't matter. As long as the domain is on the Public Suffix List (which should be best practice for DynDNS providers), you don't even have to worry about rate limits. AFAIK, certificates for non-reserved IPs would be allowed. Let's Encrypt doesn't support that, however. I imagine proof of ownership would be harder to demonstrate for an IP address (compared to a DNS name).
- lucb1e 11y ago
  > As long as the domain is on the Public Suffix List Oh, cool, I did not know that this project included stuff like DynDNS! I thought a normal, paid domain was the only way to go (other than dot tk). > AFAIK, certificates for non-reserved IPs would be allowed. Many IP addresses are dynamic though, I know of no CA where you can register an IP address and I'd imagine it being for that reason (and it might be CGNAT and perhaps some other reasons). You can of course self-sign one with an IP address, but I don't expect any CA to sign those.