「localhost」(および「127.0.0.1」のような同様のアドレス) を証明書のサブジェクト代替名の 1 つとして追加するかどうかを検討しています。 1 つの利点は、ローカル テストが容易になることです。 しかし、欠点はあるでしょうか?
ベストアンサー1
サブジェクト別名に localhost を追加するのは良い考えでしょうか (それとも悪い考えでしょうか)?
それは、従う標準とセキュリティ体制によって異なります。
まず最初に（以下の議論のために）。完全修飾ドメイン名（FQDN）を定義する必要があります。この定義はW. Richard StevenのTCP/IP 図解 第 1 巻: プロトコル（189ページ）：
ピリオドで終わるドメイン名は絶対ドメイン名または完全修飾ドメイン名ドメイン名がピリオドで終わらない場合は、名前を補完する必要があるとみなされます。名前の補完方法は、使用している DNS ソフトウェアによって異なります。
つまり、localhostピリオドを追加することで完全修飾ドメイン名に変更できます。
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
次は標準です。最も人気のあるものの 1 つは、CA とブラウザによって公開されているガイドです。CA とブラウザは、CA/B フォーラムで操作ガイドを公開しています。興味深いガイドは次の 2 つです。
他にもよく知られているものがありますが、これは通常、証明書にリストされているホストの CA/B ガイドを延期します。その標準は IETF の RFC 5280 です。
RFC 5280 では、証明書チェーンを検証する方法や subjectAltName に電子メール アドレスをリストする方法など、他の項目についても説明します。
ベースラインガイド
ベースライン ガイドでは、名前について次のように述べています。
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ガイドには記載されていません。
拡張検証
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ガイドには記載されていません。
MicrosoftはKB315588でこの方法を推奨している。方法: クライアント側証明書を使用して ASP.NET アプリケーションを保護する:
- [サイトの共通名] ページで、「localhost」と入力し、[次へ] をクリックします。
リトルブラックボックス組み込みデバイス用のプライベート SSL/TLS および SSH キーのデータベースです。SQlite3 データベースが付属していますbin/。
証明書は PEM 形式 (つまり、および関連) です-----BEGIN CERTIFICATE-----。次のコマンドですべての証明書をダンプできます。
$ 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 =ファイルから を削除します。
$ sed -e "s|certificate = ||g" certificates.txt > temp.txt
$ mv temp.txt certificates.txt
次に、nawkと を使用してopenssl各証明書をデコードします。
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
私たちがそれらについて知っているなら、悪者もきっとそれらについて知っているはずです。
最後に、セキュリティ体制についてです。上記のことを踏まえて、なぜそれが悪い考えなのかを説明します。ここでセキュリティ体制が重要になります。Peter Gutmann 氏のエンジニアリングセキュリティ（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。
ソフトウェア (ブラウザなど) が に発行された証明書を信頼するとlocalhost、ゲームは終了します。