■CALENDAR■
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31     
<<前月 2019年12月 次月>>
■LOGIN■
現在のモード: ゲストモード
USER ID:
USER PW:
■ADMIN■
ADMIN ID:
ADMIN PW:
■NEW ENTRIES■
■RECENT COMMENTS■
■RECENT TRACKBACK■
  • 吉本隆明の死去に寄せて - 反「反核」ということ
  • 2010 年の釣り - 2010~11 シーズン開幕! 肝和えの素(カワハギ)
  • 震災後の復興を考える
  • 夏本番ですが ・・・ 水の事故を防ぐために
  • 2011 年の釣り - 遅ればせながらシーズン開幕 東京湾のマゴチ
■CATEGORIES■
■ARCHIVES■
■PROFILE■
■POWERED BY■
BLOGN(ぶろぐん)
BLOGNPLUS(ぶろぐん+)
■OTHER■

自己証明書(オレオレ証明書)サイトを Chrome 70 で「この接続は保護されています」と言わせる方法
 わきたは Google Chrome のバージョンがある程度上がってからは、自己証明書(オレオレ証明書)サイトでは Chrome に「この接続は保護されています」と言わせることは出来なくなったと諦めていました。
 ところが、別件でネットをググっていたところ、Chrome の最新バージョンでも自己証明書サイトを「保護されている」と言わせることができるということが判りました。
 その方法を、自分自身の備忘録を兼ねて、以下に書き留めておきます。

【そのキモ】
 Chrome 最新バージョンに自己証明書サイトを「保護されている」と言わせるキモは、以下の3点に尽きます。

① 証明書の DN 情報に SAN の記述があること
② 証明書の署名ハッシュアルゴリズムが SHA2 であること
③ 上記証明書を Chrome にインポートさせること

1.DN 情報に SAN の記述がある証明書の作成(署名ハッシュは SHA2 による)
 サイト証明書には、そのサイトの識別名 DN(Distinguish Name)情報が含まれています。
 ブラウザはサイト証明書の DN 情報と、いまアクセスしているサイトの URL が一致していることをもって、そのサイトが正真正銘の(なりすましではない)そのサイトである、と判断します。
 Chrome の過去のバージョンでは、URL を照合する DN 内のフィールドとして CN(Common Name)を参照していました。ですから自己証明書作成を解説した古いドキュメントでは、「CN フィールドに正しい URL を記載すれば良い」とされていました。
 ところが Chrome 58 あたりから、従前の CN ではなく、SAN(Subject Alternative Name)フィールドを、正しい URL として参照するようになったようなのです。
 なので、新しい Chrome に「保護されている」と言わせるためには、この SAN フィールドに正しい記述がある証明書を作らなくてはなりません。
 なお、証明書の署名ハッシュアルゴリズムは、従前許されていた SHA1 ではなく SHA2 とすることも、「保護された」の条件となりました。

 以下、この証明書を openssl で作る方法です。

 ※ root ユーザで作業し、すべてのファイルをカレントワーキングディレクトリに作成するものとしています。必要ならば、証明書 or 秘密鍵ファイルをストアするためのディレクトリを mkdir して、そこに cd してから、作業を行ってください。

1)まず、予め DN 情報を記述した config ファイルを用意しておきます。これは、以下のようなテキストファイルです(ファイル名を csr.conf とします)。

=== csr.conf 下の行から ==>
[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = v3_req

[ req_distinguished_name ]
C = JP
ST = Tokyo(都道府県名)
L = Xxxx-shi(市町村名)
O = yyyyyyyy(組織名)
OU = zzzzzzzz(部署名:なくても可)
CN = www.example.com(サイト URL)

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.1 =www.example.com(1つめの SAN = CN)
DNS.2 =www2.example.com(2つめの SAN )
DNS.3 =example.com(3つめの 〃)
<== 上の行まで csr.conf ==

 これまでの CN と違って SAN は複数指定することができますので、1つの証明書で複数サイトを証明できるというメリットもあります。

2)次に秘密鍵ファイルを、乱数発生器を使用して生成します(パスフレーズを含まない秘密鍵ファイルです)。
 [root]# openssl genrsa -rand /dev/urandom -out ./pky.pem 4096 ↓

3)証明書ファイルを生成します。
 わきたはこれまで openssl の req コマンドで csr(証明書リクエスト)ファイルを作り、それを元に x509 コマンドで crt(証明書)ファイルを作っていました。
 ところが今回、req コマンドで -x509 オプションを使えば、csr ファイルを作ることなく一足飛びに crt ファイルが作れることを知りました。
 csr ファイルは、オーソライズされた認証局に正式なサイト証明書を発行してもらう際のリクエストファイルですから、自己証明書を作るのであれば特に必要ありません。
 そこで今回はこの方法で証明書ファイルを直接生成してみます(前述した DN 情報ファイルも、このことを前提とした内容となっています)。
 なお、署名ハッシュアルゴリズムは SHA2 256 bits、証明期間は 365 日としています。

[root]# openssl req -new -config ./csr.conf -key ./pky.pem \
-sha256 -days 365 \
-x509 -out ./crt.pem ↓

 これで、SAN 記述のある DN 情報を含み、署名ハッシュアルゴリズムとして SHA2 を使ったサイト証明書 crt.pem が生成されました。
 あとは /etc/httpd/conf.d/ssl.conf のなかで、証明書ファイルの絶対パス名を SSLCertificateFile ディレクティブに、また秘密鍵ファイルの絶対パス名を SSLCertificateKeyFile ディレクティブに、それぞれ設定して httpd を再起動すれば、サーバ側での作業は終了です。

 以下、ssl.conf 当該箇所の記述例です(CentOS7 のディレクトリ構造に合わせ、証明書ファイルと秘密鍵ファイルは、それぞれ別ディレクトリに置いたときの記述)。

SSLCertificateFile /etc/pki/tls/certs/crt.pem
SSLCertificateKeyFile /etc/pki/tls/private/pky.pem

< この項、書きかけ >
| http://blog.wakita.cc/index.php?e=95 |
| サーバ・Linux::ネットワーク | 10:29 AM | comments (0) | trackback (0) |










http://blog.wakita.cc/tb.php/95
PAGE TOP ↑