我正在为一个系统设置一个网络服务器，该系统需要在内部网络上仅通过 HTTPS 使用（无法从外部世界访问），
现在我已经设置好了使用自签名证书，它工作得很好，除了所有浏览器都会启动的令人讨厌的警告，因为用于签名的 CA 机构自然不受信任。
访问由本地 DNS 服务器上解析的本地 DNS 域名提供（例如：https://myapp.local/） ，将该地址映射到 192.168.xy
是否有某些提供商可以向我颁发用于内部域名 (myapp.local) 的正确证书？ 或者是我在真实域上使用 FQDN，然后将其映射到本地 IP 地址的唯一选择？
注意：我想要一个不需要在每个浏览器上将服务器公钥标记为可信的选项，因为我无法控制工作站。
I'm setting up a webserver for a system that needs to be used only through HTTPS, on an internal network (no access from outside world)
Right now I got it setup with a self-signed certificate, and it works fine, except for a nasty warning that all browsers fire up, as the CA authority used to sign it is naturally not trusted.
Access is provided by a local DNS domain name resolved on local DNS server (example: https://myapp.local/), that maps that address to 192.168.x.y
Is there some provider that can issue me a proper certificate for use on an internal domain name (myapp.local)? Or is my only option to use a FQDN on a real domain, and later map it to a local IP address?
Note: I would like an option where it's not needed to mark the server public key as trusted on each browser, as I have not control over workstations.
发布评论
评论（7）
您有两个实用的选择：
建立您自己的 CA。 您可以使用 OpenSSL 来完成此操作，并且有大量 Google 信息。
继续使用您的自签名证书，但将公钥添加到浏览器中的受信任证书中。 如果您位于 Active Directory 域中，则可以使用组策略自动完成此操作。
You have two practical options:
Stand up your own CA. You can do it with OpenSSL and there's a lot of Google info out there.
Keep using your self-signed cert, but add the public key to your trusted certs in the browser. If you're in an Active Directory domain, this can be done automatically with group policy.
我执行了以下操作，这对我来说效果很好：
我获得了 *.mydomain.com 的通配符 SSL 证书（例如，Namecheap，廉价提供此证书）
我创建了一个 CNAME DNS 记录，将“mybox.mydomain.com”指向“mybox” 。当地的”。
我希望这会有所帮助 - 不幸的是，您需要为您的域名支付通配符证书的费用，但您可能已经拥有了。
I did the following, which worked nicely for me:
I got a wildcard SSL cert for *.mydomain.com (Namecheap, for example, provide this cheaply)
I created a CNAME DNS record pointing "mybox.mydomain.com" at "mybox.local".
I hope that helps - unfortunately you'll have the expense of a wildcard cert for your domain name, but you may already have that.
你必须向典型的认证人员询问这一点。 为了便于使用，我会使用 FQDN，您可以使用已注册的子域： https://mybox .example.com
另外，您可能想查看通配符证书，为（例如）https://*.example.com/ 提供一揽子证书 - 甚至可用于虚拟托管，如果您需要的不仅仅是这个一张证书。
认证 FQDN 的子域或子子域应该是标准业务 - 也许不适合那些以在短短 2 分钟内提供证书而自豪的点击式大佬。
简而言之：要使证书受到工作站的信任，您必须
这就是您的全部选择。 选择你的毒药。
You'd have to ask the typical cert people for that. For ease of use I'd get with the FQDN though, you might use a subdomain to your already registered one: https://mybox.example.com
Also you might want to look at wildcard certificates, providing a blanket cert for (e.g.) https://*.example.com/ - even usable for virtual hosting, should you need more than just this one cert.
Certifying sub- or sub-sub domains of FQDN should be standard business - maybe not for the point&click big guys that proud themselves to provide the certificates in just 2 minutes.
In short: To make the cert trusted by a workstation you'd have to either
That's all your choices. Choose your poison.
我本想将其添加为评论，但它有点长。
这并不是对您问题的真正答案，但在实践中我发现不建议使用 .local 域- 即使是在您的“本地”测试环境中，使用您自己的 DNS 服务器。
我知道当您安装 DNS 时，Active Directory 默认使用 .local 名称，但即使是 Microsoft 的人也说要避免使用它。
如果您可以控制 DNS 服务器，则可以使用 .com、.net 或 .org 域 - 即使它只是内部和私有域。 这样，您实际上可以购买内部使用的域名，然后购买该域名的证书并将其应用到您的本地域。
I would have added this as a comment but it was a bit long..
This is not really an answer to your questions, but in practice I've found that it's not recommended to use a .local domain - even if it's on your "local" testing environment, with your own DNS Server.
I know that Active Directory uses the .local name by default when your install DNS, but even people at Microsoft say to avoid it.
If you have control over the DNS Server you can use a .com, .net, or .org domain - even if it's internal and private only. This way, you could actually buy the domain name that you are using internally and then buy a certificate for that domain name and apply it to your local domain.
我有类似的要求，让我们公司的浏览器信任我们的内部网站。
我不希望我们的公共 DNS 为我们的内部站点发布公共 DNS，因此我发现实现这项工作的唯一方法是使用内部 CA。
这是对此的评论，
https://medium.com/@mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af
I had a similar requirement, have our companys browsers trust our internal websites.
I didnt want our public DNS to issue public DNS for our internal sites, so the only way to make this work that I found was to use an internal CA.
Heres the writeup for this,
https://medium.com/@mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af
仅用于开发目的
此 docker 映像解决了问题（感谢 local-ip.co）： https:// /github.com/medic/nginx-local-ip。
它在端口 443 中启动反向代理，并使用可与任何
*.my.local-ip.co域配合使用的公共证书。 例如。 您的本地 IP 是 192.168.10.10 → 192-168-10-10.my.local-ip.co 已经指向它（它是公共域）！ 假设应用程序在您的计算机中的端口 8080 上运行，您只需执行此命令即可代理传递您的应用程序并将其公开在 URL https://192-168-10-10.my.local-ip.co：使用您在设备中配置的任何公共 DNS 解析该域您想要访问应用程序，但您的流量在应用程序和客户端之间保持本地（通过代理），因此您甚至可以使用它与同一 LAN 网络内的设备连接，而无需任何流量传至互联网，所有流量都是本地的。
对开发最有用的原因是任何人都可以使用相同的证书启动应用程序，因此并不真正安全，但当您在开发或测试时需要使用 HTTPS 公开您的应用程序时很有帮助（例如，Android 中加载的 HTML5 应用程序）与网络视图）。
Development purpose only
This docker image solves the problem (thanks to local-ip.co): https://github.com/medic/nginx-local-ip.
It launches a reverse proxy in the port 443 with a public cert that works with any
*.my.local-ip.codomain. Eg. your local IP is 192.168.10.10 → 192-168-10-10.my.local-ip.co already points to it (it's a public domain)! Assuming the app is running in your computer at the port 8080, you only need to execute this to proxy pass your app and expose it at the URL https://192-168-10-10.my.local-ip.co:The domain is resolved with any public DNS you have configured in the devices where you want to access the app, but your traffic keeps local between your app and the client (through the proxy), so you can even use it to connect with devices within the same LAN network, without any of the traffic going out to internet, all the traffic is local.
The reason that is mostly useful for development is that anybody can launch an application with this same certificate, so is not really secure, but helpful when you need to expose your app with HTTPS while developing or testing (e.g. HTML5 apps in Android that are loaded with Webview).
我认为答案是否定的。
开箱即用的情况下，浏览器不会信任证书，除非它最终由浏览器中预编程的人员（例如 verisign、register.com）进行验证。
您只能获得全球唯一域的经过验证的证书。
因此，我建议您使用 myapp.local.yourcompany.com 而不是 myapp.local，只要您拥有 yourcompany.com，您就应该能够获得证书。 你想，每年要花几百美元。
另请注意，通配符证书可能只会下降到一级 - 因此您可以将其用于 a.yourcompany.com 和 local.yourcompany.com，但可能不能用于 bayourcompany.com 或 myapp.local.yourcompany.com，除非您支付更多费用。
（有谁知道，这是否取决于通配符证书的类型？主要浏览器是否信任子子域？）
i think the answer is NO.
out-of-the-box, browsers won't trust certificates unless it's ultimately been verified by someone pre-programmed into the browser, e.g. verisign, register.com.
you can only get a verified certificate for a globally unique domain.
so i'd suggest instead of myapp.local you use myapp.local.yourcompany.com, for which you should be able to get a certificate, provided you own yourcompany.com. it'll cost you thought, several hundred per year.
also be warned wildcard certificates might only go down to one level -- so you could use it for a.yourcompany.com and local.yourcompany.com but maybe not b.a.yourcompany.com or myapp.local.yourcompany.com, unless you pay more.
(does anyone know, does it depend on the type of wildcard certificate? are sub-sub-domains trusted by the major browsers?)