X.509证书:在“使用者备用名称"中添加localhost是一个好主意(或不好的主意)? [英] X.509 certificate: Is it a good idea (or bad) to add localhost in Subject Alternative Name?

问题描述

我们正在确定是否应将"localhost"(以及类似的地址，如"127.0.0.1")添加为证书中的主题替代名称之一.一种好处可能是促进本地测试.但是会有什么缺点吗?

We are deciding whether "localhost" (and similarly address like "127.0.0.1") should be added as one of the subject alternative names in the certificate. One benefit might be to facilitate local testing. But will there be any drawback?

推荐答案

在使用者备用名称"中添加localhost是个好主意吗?

Is it a good idea (or bad) to add localhost in Subject Alternative Name?

这取决于您遵循的标准和安全状态.

It depends on the standards you follow and your security posture.

首先(对于下面的讨论).必须定义一个完全合格的域名(FQDN).该定义来自W. Richard Steven的 TCP/IP插图集I :协议(第189页):

First things first (for the discussion below). A Fully Qualified Domain Name (FQDN) must be defined. That definition is taken from W. Richard Steven's TCP/IP Illustrated Volume I: The Protocols (p. 189):

以句点结尾的域名称为绝对域名或完全限定域名.如果域名没有以句号结尾，则认为该名称需要完成.名称的完成方式取决于所使用的DNS软件.

A domain name that ends with a period is called an absolute domain name or a fully qualified domain name. If the domain name does not end in a period, it is assumed that name needs to be completed. How the name is completed depends upon the DNS software being used.

这意味着我们可以通过添加句点将localhost更改为完全限定的域名:

That means we can change localhost into a fully qualified domain name by appending a period:

localhost.

这是一个小实验:

$ hostname
debian-q500

$ hostname --fqdn
debian-q500

$ dnsdomainname 
$

$ ping debian-q500.
ping: unknown host debian-q500.
$ ping debian-q500.local
PING debian-q500.local (172.16.1.26) 56(84) bytes of data.
64 bytes from debian-q500.home.pvt (172.16.1.26): icmp_req=1 ttl=64 time=0.040 ms
64 bytes from debian-q500.home.pvt (172.16.1.26): icmp_req=2 ttl=64 time=0.035 ms
...

$ ping localhost.
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.037 ms
...
$ ping localhost.local
ping: unknown host localhost.local
$ ping localhost.localdomain
ping: unknown host localhost.localdomain

---

接下来是标准.最受欢迎的一种是由CAs ad Browsers发布的指南. CA广告浏览器在CA/B论坛上发布其操作指南.这两个有趣的指南是:

---

Next is standards. One of the most popular is the guides published by the CAs ad Browsers. The CAs ad Browsers publish their operations guides at the CA/B Forums. They two guides of interest are:

• 发布和管理受信任证书的基本要求
• 扩展验证证书的发布和管理指南

• Baseline Requirements for the Issuance and Management of Trusted Certificates
• Guidelines For The Issuance And Management Of Extended Validation Certificates

还有另一种流行的方法，但是它通常会延迟证书中列出的主机中的CA/B指南.该标准是IETF的RFC 5280:

There's another popular one, but it generally defers CA/B guides in hosts listed in the certificates. That standard is RFC 5280 from the IETF:

• Internet X.509公钥基础结构证书和证书吊销列表(CRL)配置文件

RFC 5280将标注其他项，例如如何验证证书链以及如何在subjectAltName中列出电子邮件地址.

RFC 5280 will call out other items, like how to validate a certificate chain and how to list email addresses in the subjectAltName.

基准指南

《基准指南》中有关于姓名的说法:

The Baseline guide has this to say about names:

9.2.1 Subject Alternative Name Extension    
Certificate Field: extensions:subjectAltName
Required/Optional: Required

Contents: This extension MUST contain at least one entry. Each
entry MUST be either a dNSName containing the Fully-Qualified
Domain Name or an iPAddress containing the IP address of a
server. The CA MUST confirm that the Applicant controls the
Fully-Qualified Domain Name or IP address or has been granted
the right to use it by the Domain Name Registrant or IP address
assignee, as appropriate.

Wildcard FQDNs are permitted.
...

还有

9.2.2 Subject Common Name Field 
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address or
Fully-Qualified Domain Name that is one of the values contained in
the Certificate’s subjectAltName extension (see Section 9.2.1).

最后，

11.1.3 Wildcard Domain Validation   

Before issuing a certificate with a wildcard character (*) in a
CN or subjectAltName of type DNS-ID, the CA MUST establish and
follow a documented procedure† that determines if the wildcard
character occurs in the first label position to the left of a
"registry-controlled" label or "public suffix" (e.g. "*.com",
"*.co.uk", see RFC 6454 Section 8.2 for further explanation).

If a wildcard would fall within the label immediately to the left
of a registry-controlled† or public suffix, CAs MUST refuse
issuance unless the applicant proves its rightful control of the
entire Domain Namespace. (e.g. CAs MUST NOT issue "*.co.uk" or
"*.local", but MAY issue "*.example.com" to Example Co.).

所以localhost可以，只要它是完全限定的域名即可.实际上，指南中甚至没有提到localhost.

So localhost is fine as long as its a fully qualified domain name. In fact, localhost not even mentioned in the guide.

扩展验证

9.2.2 Subject Alternative Name Extension
Certificate field: subjectAltName:dNSName
Required/Optional: Required

Contents: This extension MUST contain one or more host Domain
Name(s) owned or controlled by the Subject and to be associated
with the Subject’s server. Such server MAY be owned and operated
by the Subject or another entity (e.g., a hosting service).
Wildcard certificates are not allowed for EV Certificates.

9.2.3 Subject Common Name Field
Certificate field: subject:commonName (OID: 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single Domain
Name(s) owned or controlled by the Subject and to be associated
with the Subject’s server. Such server MAY be owned and operated
by the Subject or another entity (e.g., a hosting service).
Wildcard certificates are not allowed for EV Certificates.

所以localhost可以，只要它是完全限定的域名即可.实际上，指南中甚至没有提到localhost.

So localhost is fine as long as its a fully qualified domain name. In fact, localhost not even mentioned in the guide.

Microsoft鼓励KB315588中的做法，如何:使用客户端证书保护ASP.NET应用程序的安全:

Microsoft encourages the practice in KB315588, HOW TO: Secure an ASP.NET Application Using Client-Side Certificates:

• 在您的站点的公用名"页上，键入localhost，然后单击下一步".

littleblackbox 是用于嵌入式设备的专用SSL/TLS和SSH密钥的数据库.它在bin/中带有一个SQlite3数据库.

littleblackbox is a database of private SSL/TLS and SSH keys for embedded devices. It comes with a SQlite3 database in bin/.

证书采用PEM格式(即-----BEGIN CERTIFICATE-----和朋友).您可以使用以下方法转储所有证书:

The certificates are in PEM format (i.e.,-----BEGIN CERTIFICATE----- and friends). You can dump all the certificates with:

$ sqlite3 lbb.db 
SQLite version 3.8.3 2013-12-17 16:32:56
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .mode line
sqlite> .out certificates.txt
sqlite> SELECT certificate FROM certificates;
sqlite> .q

下一步，从文件中删除certificate =:

Next, remove the certificate = from the file:

$ sed -e "s|certificate = ||g" certificates.txt > temp.txt
$ mv temp.txt certificates.txt

现在使用nawk和openssl来解码每个证书:

Now use nawk and openssl to decode each certificate:

nawk '
v{v=v"\n"$0}
/----BEGIN/ {v=$0}
/----END/&&v{
  print v > "tmp.cert"
  close("tmp.cert")
  system("openssl x509 -in tmp.cert -inform PEM -text -noout")
  v=x}' certificates.txt

如果我们了解他们，那么坏家伙肯定会了解他们.

If we know about them, the bad guys surely know about them.

最后，它的安全状态.综上所述，这就是为什么它是个坏主意的原因.这就是安全状况的来源.摘自Peter Gutmann的

Finally, its security posture. With all of that said above, here's why its a bad idea. This is where the security posture comes in. From Peter Gutmann's Engineering Security (p. 45):

In practice CAs seem to issue certificates under more or less any
name to pretty much anybody, ranging from small-scale issues like
users buying certificates for the wonderfully open-ended mail [237]
through to the six thousand sites that commercial CAs like Comodo,
Cybertrust, Digicert, Entrust, Equifax, GlobalSign, GoDaddy,
Microsoft, Starfield and Verisign have certified for localhost,
with no apparent limit on how many times a CA will issue a
certificate for the same name [238].

这里的问题是是我的本地主机还是您的本地主机".因此，与其说是颁发证书和信任您的localhost问题，不如说是无意中信任外国localhost的问题.

The problem here is, "is it my localhost, or is it your localhost". So its not so much a question of issuing certficate for and trusting your localhost - its more a problem of inadvertently trusting a foreign localhost.

一旦您的软件(例如浏览器)信任发给localhost的证书，它的游戏便结束了.

Once your software (such as a browser) trusts the certificate issued to localhost, its game over.

这篇关于X.509证书:在“使用者备用名称"中添加localhost是一个好主意(或不好的主意)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！