是否可以为 IP 地址而不是域名提供 SSL 证书?

发布于 2024-08-17 07:27:07 字数 1818 浏览 5 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

缱绻入梦 2024-08-24 07:27:07

根据这个答案,这是可能的,但很少使用。

至于如何获得它:我倾向于简单地尝试向您选择的提供商订购一个,并在订购过程中输入 IP 地址而不是域名。

然而,对我来说,在 IP 地址上运行站点以避免 DNS 查找听起来就像是不必要的微优化。每次访问最多可以节省几毫秒,因为 DNS 结果会在多个级别上进行缓存。

从优化的角度来看,我认为你的想法没有意义。

According to this answer, it is possible, but rarely used.

As for how to get it: I would tend to simply try and order one with the provider of your choice, and enter the IP address instead of a domain during the ordering process.

However, running a site on an IP address to avoid the DNS lookup sounds awfully like unnecessary micro-optimization to me. You will save a few milliseconds at best, and that is per visit, as DNS results are cached on multiple levels.

I don't think your idea makes sense from an optimization viewpoint.

一影成城 2024-08-24 07:27:07

简短的回答是肯定的,只要它是公共 IP 地址即可。

不允许向保留的 IP 地址颁发证书,并且自 2016 年 10 月 1 日起,之前向保留的 IP 地址颁发的所有证书均已撤销。

根据 CA 浏览器论坛,IP 地址的证书可能存在兼容性问题,除非该 IP 地址是在 commonNamesubjectAltName 字段中。这是由于旧版 SSL 实现不符合 RFC 5280,特别是 Windows 10 之前的 Windows 操作系统。


来源:

  1. 证书中 IP 地址指南 CA 浏览器论坛
  2. 基准要求 1.4.1 CA 浏览器论坛
  3. (很快是)不太常见的名称 unmitigatedrisk.com
  4. RFC 5280 IETF

注意:此答案的早期版本表示所有 IP 地址证书将于 2016 年 10 月 1 日撤销。感谢 Navin 指出错误。

The short answer is yes, as long as it is a public IP address.

Issuance of certificates to reserved IP addresses is not allowed, and all certificates previously issued to reserved IP addresses were revoked as of 1 October 2016.

According to the CA Browser forum, there may be compatibility issues with certificates for IP addresses unless the IP address is in both the commonName and subjectAltName fields. This is due to legacy SSL implementations which are not aligned with RFC 5280, notably, Windows OS prior to Windows 10.


Sources:

  1. Guidance on IP Addresses In Certificates CA Browser Forum
  2. Baseline Requirements 1.4.1 CA Browser Forum
  3. The (soon to be) not-so Common Name unmitigatedrisk.com
  4. RFC 5280 IETF

Note: an earlier version of this answer stated that all IP address certificates would be revoked on 1 October 2016. Thanks to Navin for pointing out the error.

路弥 2024-08-24 07:27:07

是的。 Cloudflare 将其用于其 DNS 说明主页:https://1.1.1.1

Yep. Cloudflare uses it for its DNS instructions homepage: https://1.1.1.1

佞臣 2024-08-24 07:27:07

我想答案是肯定的。例如,检查此链接

向公共IP地址颁发SSL证书

SSL 证书通常颁发给完全限定域名 (FQDN),例如“https://www.domain。 com”。但是,某些组织需要颁发给公共 IP 地址的 SSL 证书。此选项允许您指定公共 IP 地址作为证书签名请求 (CSR) 中的公用名。然后,颁发的证书可用于保护直接与公共 IP 地址的连接(例如,https://123.456.78.99。 )。

The answer I guess, is yes. Check this link for instance.

Issuing an SSL Certificate to a Public IP Address

An SSL certificate is typically issued to a Fully Qualified Domain Name (FQDN) such as "https://www.domain.com". However, some organizations need an SSL certificate issued to a public IP address. This option allows you to specify a public IP address as the Common Name in your Certificate Signing Request (CSR). The issued certificate can then be used to secure connections directly with the public IP address (e.g., https://123.456.78.99.).

一指流沙 2024-08-24 07:27:07

答案是肯定的。简而言之,它是一个使用者备用名称 (SAN) 证书,其中包含您通常会在其中看到 DNS 条目的 IP。证书类型不限于公共 IP - 该限制仅由签名机构而非技术施加。我只是想澄清这一点。我怀疑您真的只是想摆脱内部网站和设备上令人讨厌的不安全提示,而无需为它们提供 DNS 名称,然后每年或两年支付 CA 颁发证书的费用和麻烦。您不应该试图让全世界相信您的 IP 地址是一个信誉良好的网站,并且人们应该放心地提供他们的付款信息。现在我们已经确定为什么没有信誉良好的组织愿意颁发此类证书,让我们自己使用自签名 SAN 证书来颁发此类型的证书。在内部,我有一个部署到所有主机的受信任证书,然后我用它签署这种类型的证书,所有设备都会变得受信任。在这里这样做超出了问题的范围,但我认为这与讨论相关,因为问题和解决方案是齐头并进的。简而言之,以下是如何生成带有 IP 地址的个人自签名 SAN 证书。扩展 IP 列表以包含您的整个子网,并使用一个证书来处理所有事情。

#!/bin/bash
#using: OpenSSL 1.1.1c FIPS  28 May 2019 / CentOS Linux release 8.2.2004

C=US ; ST=Confusion ; L=Anywhere ; O=Private\ Subnet ; [email protected]
BITS=2048
CN=RFC1918
DOM=company.com
SUBJ="/C=$C/ST=$ST/L=$L/O=$O/CN=$CN.$DOM"

openssl genrsa -out ip.key $BITS

SAN='\n[SAN]\nsubjectAltName=IP:192.168.1.0,IP:192.168.1.1,IP:192.168.1.2,IP:192.168.1.3,IP:192.168.1.4,IP:192.168.1.5,IP:192.168.1.6,IP:192.168.1.7,IP:192.168.1.8,IP:192.168.1.9,IP:192.168.1.10'

cp /etc/pki/tls/openssl.cnf /tmp/openssl.cnf
echo -e "$SAN" >> /tmp/openssl.cnf

openssl req -subj "$SUBJ" -new -x509 -days 10950 \
    -key ip.key -out ip.crt -batch \
    -set_serial 168933982 \
    -config /tmp/openssl.cnf \
    -extensions SAN

openssl x509 -in ip.crt -noout -text

The answer is yes. In short, it is a subject alternative name (SAN) certificate that contains IPs where you would typically see DNS entries. The certificate type is not limited to Public IPs - that restriction is only imposed by a signing authority rather than the technology. I just wanted to clarify that point. I suspect you really just want to get rid of that pesky insecure prompt on your internal websites and devices without the cost and hassle of giving them DNS names then paying for a CA to issue a cert every year or two. You should NOT be trying to convince the world that your IP address is a reputable website and folks should feel comfortable providing their payment information. Now that we have established why no reputable organization wants to issue this type of certificate, lets just do it ourselves with a self signed SAN certificate. Internally I have a trusted certificate that is deployed to all of our hosts, then I sign this type of certificate with it and all devices become trusted. Doing that here is beyond the scope of the question but I think it relevant to the discussion as the question and solution go hand in hand. To be concise, here is how to generate an individual self signed SAN certificate with IP addresses. Expand the IP list to include your entire subnet and use one cert for everything.

#!/bin/bash
#using: OpenSSL 1.1.1c FIPS  28 May 2019 / CentOS Linux release 8.2.2004

C=US ; ST=Confusion ; L=Anywhere ; O=Private\ Subnet ; [email protected]
BITS=2048
CN=RFC1918
DOM=company.com
SUBJ="/C=$C/ST=$ST/L=$L/O=$O/CN=$CN.$DOM"

openssl genrsa -out ip.key $BITS

SAN='\n[SAN]\nsubjectAltName=IP:192.168.1.0,IP:192.168.1.1,IP:192.168.1.2,IP:192.168.1.3,IP:192.168.1.4,IP:192.168.1.5,IP:192.168.1.6,IP:192.168.1.7,IP:192.168.1.8,IP:192.168.1.9,IP:192.168.1.10'

cp /etc/pki/tls/openssl.cnf /tmp/openssl.cnf
echo -e "$SAN" >> /tmp/openssl.cnf

openssl req -subj "$SUBJ" -new -x509 -days 10950 \
    -key ip.key -out ip.crt -batch \
    -set_serial 168933982 \
    -config /tmp/openssl.cnf \
    -extensions SAN

openssl x509 -in ip.crt -noout -text
御弟哥哥 2024-08-24 07:27:07

这完全取决于颁发证书的证书颁发机构。

就 Let's Encrypt CA 而言,他们不会在公共 IP 地址上颁发 TLS 证书。
https://community.letsencrypt.org/t /certificate-for-public-ip-without-domain-name/6082

要了解您的证书颁发机构,您可以执行以下命令并查找下面标记的条目。

curl -v -u <username>:<password> "https://IPaddress/.."

输入图像描述这里

It entirely depends upon the Certificate Authority who issuing a certificate.

As far as Let's Encrypt CA, they wont issue TLS certificate on public IP address.
https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082

To know your Certificate authority , you can execute following command and look for an entry marked below.

curl -v -u <username>:<password> "https://IPaddress/.."

enter image description here

起风了 2024-08-24 07:27:07

C/A 浏览器论坛设置证书中的有效内容和无效内容,以及 CA 应拒绝的内容。

根据他们的基准要求

发行及管理
根据公开信任的证书
文件,自 2015 年起,CA 不得颁发通用名称或通用备用名称字段包含保留 IP 或内部名称的证书,其中保留 IP 地址是 IANA 列为保留的 IP -其中包括所有 NAT IP - 内部名称是无法在公共 DNS 上解析的任何名称。

可以使用公共 IP 地址(并​​且基线要求文档指定 CA 必须执行哪些类型的检查以确保申请人拥有 IP)。

The C/A Browser forum sets what is and is not valid in a certificate, and what CA's should reject.

According to their Baseline Requirements
for the
Issuance and Management of
Publicly-Trusted Certificates
document, CAs must, since 2015, not issue certificats where the common name, or common alternate names fields contains a reserved IP or internal name, where reserved IP addresses are IPs that IANA has listed as reserved - which includes all NAT IPs - and internal names are any names that don't resolve on the public DNS.

Public IP addresses CAN be used (and the baseline requirements doc specifies what kinds of checks a CA must perform to ensure the applicant owns the IP).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文