You will never be issued a proper https cert for localhost. It is strictly forbidden. Because reasons.
In short:
Misconfigured devices actually exist, in the wild, that wait for lookups before resolving localhost from /etc/hosts
If a router defines localhost.foo.local it may cause localhost to resolve incorrectly (you've probably seen this class of error before)
You can create a root certificate and then create a so-called "self-signed" certificate, signed by the root ca you created. You'll still get the ugly warning screen, but it'll work.
The solutions below still apply, but caddy can make them even easier.
It can create root certificates that plug into your OS keychain, and there's a DuckDNS plugin so you could have public certs on a public or private IP via DNS validation, etc.
localhost.YOURSITE.com (points to 127.0.0.1)
In lieu of actual localhost certs, I do what Eugene suggests - create a 127.0.0.1 record on a public domain.
You can get free HTTPS certificates for localhost.YOURSITE.com via Let's Encrypt via https://greenlock.domains. Just choose the DNS option instead of the HTTP File Upload option
Point your localhost.MY-SLD.MY-TLD to 127.0.0.1
Purchase a *.localhost.example.com cert and issue each installation a secret xyz.localhost.example.com (and include it in the public suffix list to prevent attacks on example.com)
sessions, localstorage, indexeddb, etc are shared by domain
changing the port does not change their sharedness
Be Your Own Root Certificate
Update: with things like greenlock that use ACME / Let's Encrypt, this is no longer particularly relevant.
This is probably a really bad idea because we don't want users becoming accustomed to installing Root CAs willy nilly (and we know how that turned out for Lenovo), but for corporate / cloned machines it may be a reasonable low-budget option.
另一种有点棘手的情况是当用户尝试使用 Citrix 或终端服务时。您必须确保每个用户的 Web 服务器在不同的端口上运行，然后将端口号告知远程 Web 服务器，以便在服务器上生成的页面将具有正确的端口号。幸运的是我们还没有遇到这种情况。现在似乎越来越多的人使用虚拟机而不是 Citrix。
您找到更好的方法了吗？
I had this same requirement. So the reason why you have to use SSL is because just about every browser now barfs if you use https and try to connect to an http resource even if the http resource is on localhost which is silly to me.
Because of JS SOP our localhost web server serves up a js file and then the JS inside the webapp can make calls to this localhost webserver.
So we made local.example.com point to 127.0.0.1 and actually bought an SSL certificate for this hostname. We then ship the private key inside this web server which gets installed on the user's computer. Yes, we're crazy.
All of this actually works quite well. We're been running like this with a few hundred users for about 6 months now.
The only problem we sometimes run into is that this doesn't work right when a user is using a proxy server. The requests are sent to the proxy server and it tries to connect to 127.0.0.1 at the proxy server which obviously doesn't work. The work-around is to add an exclusion to the proxy server config so that it bypasses the proxy server for requests to local.example.com
Another scenario where it will get a little tricky is when users try to use Citrix or Terminal Services. You have to make sure the web server for each user is running on a different port and then inform your remote web server of the port number so that pages generated on the server will have the right port number. Fortunately we haven't run into this yet. It also seems like more people are using virtual machines these days instead of Citrix.
也许您可以向我们介绍GlobalSign 提供的这项服务（其他 CA 也提供类似的服务） ）。简而言之，该产品让您拥有一个由 GlobalSign 证书签名的 CA 证书（并为 localhost / 注册最终用户证书）。不过，成本可能会很高（我相信他们会根据具体情况确定）。
Probably you can make us of this offering by GlobalSign (other CAs offer comparable services). In brief, the offering lets you have a CA certificate (and enroll end-user certificates for localhost / whatever ) which will be signed by GlobalSign certificate. The cost can be significant though (I believe they determine it on case by case basis).
PS: I just don't know how sustainable this is, because someone with a similar scenario had their key revoked by the CA as if the key had been compromised.
发布评论
评论（5）
localhost
您永远不会获得 localhost 的正确 https 证书。 严格禁止。因为原因。
简而言之：
/etc/hosts解析本地主机之前等待查找localhost.foo.local它可能会导致localhost解析不正确（您以前可能见过此类错误）您可以创建一个根证书，然后然后
2023 更新：caddy
下面的解决方案仍然申请，但 caddy 可以让它们变得更容易。
它可以创建插入操作系统钥匙串的根证书，并且有一个 DuckDNS 插件，因此您可以通过 DNS 验证等在公共或私有 IP 上拥有公共证书。
127.0.0.1）
localhost.YOURSITE.com （指向 实际的 localhost 证书，我按照尤金的建议进行操作 - 在公共域上创建 127.0.0.1 记录。
您可以通过 Let's Encrypt 通过 https://greenlock.domains 获取
localhost.YOURSITE.com的免费 HTTPS 证书。只需选择 DNS 选项而不是 HTTP 文件上传选项将 localhost.MY-SLD.MY-TLD 指向 127.0.0.1
*.localhost.example.com证书并为每个安装颁发一个密钥xyz.localhost.example.com（并将其包含在公共后缀列表中以防止对 example.com 的攻击）如果您没有包含在 PSL 注释中那：
成为您自己的根证书
更新：使用诸如 greenlock 使用 ACME / Let's Encrypt，这不再特别相关。
这可能是一个非常糟糕的主意，因为我们不希望用户习惯于随意安装根 CA（而且我们知道 为 Lenovo 设计），但对于企业/克隆机器来说，它可能是一个合理的低预算选择。
localhost
You will never be issued a proper https cert for localhost. It is strictly forbidden. Because reasons.
In short:
/etc/hostslocalhost.foo.localit may causelocalhostto resolve incorrectly (you've probably seen this class of error before)You can create a root certificate and then create a so-called "self-signed" certificate, signed by the root ca you created. You'll still get the ugly warning screen, but it'll work.
2023 Update: caddy
The solutions below still apply, but caddy can make them even easier.
It can create root certificates that plug into your OS keychain, and there's a DuckDNS plugin so you could have public certs on a public or private IP via DNS validation, etc.
localhost.YOURSITE.com (points to 127.0.0.1)
In lieu of actual
localhostcerts, I do what Eugene suggests - create a 127.0.0.1 record on a public domain.You can get free HTTPS certificates for
localhost.YOURSITE.comvia Let's Encrypt via https://greenlock.domains. Just choose the DNS option instead of the HTTP File Upload optionPoint your localhost.MY-SLD.MY-TLD to 127.0.0.1
*.localhost.example.comcert and issue each installation a secretxyz.localhost.example.com(and include it in the public suffix list to prevent attacks on example.com)If you do not get included in the PSL note that:
Be Your Own Root Certificate
Update: with things like greenlock that use ACME / Let's Encrypt, this is no longer particularly relevant.
This is probably a really bad idea because we don't want users becoming accustomed to installing Root CAs willy nilly (and we know how that turned out for Lenovo), but for corporate / cloned machines it may be a reasonable low-budget option.
我有同样的要求。所以你必须使用 SSL 的原因是因为如果你使用 https 并尝试连接到 http 资源，几乎每个浏览器都会拒绝，即使 http 资源位于 localhost 上，这对我来说很愚蠢。
由于 JS SOP，我们的本地主机 Web 服务器提供了一个 js 文件，然后 Web 应用程序内的 JS 可以调用此本地主机 Web 服务器。
因此，我们使 local.example.com 指向 127.0.0.1，并实际上为此主机名购买了 SSL 证书。然后，我们将私钥发送到安装在用户计算机上的网络服务器内。是的，我们疯了。
所有这些实际上都效果很好。我们已经像这样与数百名用户一起运行了大约 6 个月。
我们有时遇到的唯一问题是，当用户使用代理服务器时，这无法正常工作。请求被发送到代理服务器，并尝试连接到代理服务器上的 127.0.0.1，但这显然不起作用。解决方法是在代理服务器配置中添加排除项，以便绕过代理服务器向 local.example.com 发出请求。
另一种有点棘手的情况是当用户尝试使用 Citrix 或终端服务时。您必须确保每个用户的 Web 服务器在不同的端口上运行，然后将端口号告知远程 Web 服务器，以便在服务器上生成的页面将具有正确的端口号。幸运的是我们还没有遇到这种情况。现在似乎越来越多的人使用虚拟机而不是 Citrix。
您找到更好的方法了吗？
I had this same requirement. So the reason why you have to use SSL is because just about every browser now barfs if you use https and try to connect to an http resource even if the http resource is on localhost which is silly to me.
Because of JS SOP our localhost web server serves up a js file and then the JS inside the webapp can make calls to this localhost webserver.
So we made local.example.com point to 127.0.0.1 and actually bought an SSL certificate for this hostname. We then ship the private key inside this web server which gets installed on the user's computer. Yes, we're crazy.
All of this actually works quite well. We're been running like this with a few hundred users for about 6 months now.
The only problem we sometimes run into is that this doesn't work right when a user is using a proxy server. The requests are sent to the proxy server and it tries to connect to 127.0.0.1 at the proxy server which obviously doesn't work. The work-around is to add an exclusion to the proxy server config so that it bypasses the proxy server for requests to local.example.com
Another scenario where it will get a little tricky is when users try to use Citrix or Terminal Services. You have to make sure the web server for each user is running on a different port and then inform your remote web server of the port number so that pages generated on the server will have the right port number. Fortunately we haven't run into this yet. It also seems like more people are using virtual machines these days instead of Citrix.
Did you ever find a better way?
也许您可以向我们介绍GlobalSign 提供的这项服务（其他 CA 也提供类似的服务） ）。简而言之，该产品让您拥有一个由 GlobalSign 证书签名的 CA 证书（并为 localhost / 注册最终用户证书）。不过，成本可能会很高（我相信他们会根据具体情况确定）。
Probably you can make us of this offering by GlobalSign (other CAs offer comparable services). In brief, the offering lets you have a CA certificate (and enroll end-user certificates for localhost / whatever ) which will be signed by GlobalSign certificate. The cost can be significant though (I believe they determine it on case by case basis).
由于您位于本地主机，因此您可以告诉浏览器信任您想要的任何证书。
为本地主机创建一个自签名证书，并告诉您的浏览器信任它。
Since you're on localhost, you can tell your browser to trust any certificate you want.
Make a self-signed certificate for localhost, and tell your browser to trust it.
由 CoolAJ86 提供的 CoolAJ86 提供的解决方案“将 localhost.MY-SLD.MY-TLD 指向 127.0.0.1”工作正常，您可以在这里看到更详细的解释：
PLEX 如何为其所有用户提供 https 服务
PS：我只是不知道这有多可持续，因为有人有类似的情况他们的钥匙被撤销了CA 就好像密钥已被泄露一样。
The solution "Point your localhost.MY-SLD.MY-TLD to 127.0.0.1" provided by provided by CoolAJ86 works fine, and you see a more detailed explanation here:
How PLEX is doing https for all its users
PS: I just don't know how sustainable this is, because someone with a similar scenario had their key revoked by the CA as if the key had been compromised.