相変わらず世界の支配者google様ですから、「どうせ馬鹿にはわかるまいから簡単に言うとだな」的な抽象的なエラーメッセージしかお示しくださいませんので詳細は不明です。
*** 2017/4/27 追記***
エラーとなる根拠がわかりました。
以下に記述したようなワイルドカードが理由ではなく、subjectAltNameがないことが理由でした。
以下の記事ではSANを利用してみる気になったので偶然解決したように見えただけで、ワイルドカードかどうかに関わりなく、以後ホスト名の証明にはCNではなく必ずx509v3の別名(subjectAltName)を利用した証明書でなければChromeが警告を出すようになりました。
以下の記事は本ブログの趣旨である恥の記録として残しておきたいと思いますが、エラーとなる理由は今回追記した通りで以下の内容は間違っておりますのでご注意ください。
*** 追記ここまで***
2014年に署名アルゴリズムをsha256に、ビット長を2048へ変更して以来(あの時もchromeが文句を垂れるためでした)、またgoogle様によって作業を強いられることになりました。
優渥かつ寛大で親切なgoogle様に教えてもらったエラーメッセージでは詳細な原因が不明なので類推するしかありませんが、可能性としては証明書でCommon Nameにワイルドカードを指定していることが原因ではないかとあたりをつけました。
ワイルドカード証明書が使えたおかげで個別に作っていたものが一つになって大変便利だったのですが、また以前のようにサーバ毎に証明書を発行するのが最も確実だろうとは思いますが、大昔は対応するﾌﾞﾗｳｻﾞやメーラががほとんどなくて導入を断念した経験のあるsubjectAltName(SAN)を試してみることにしました。
結論から言うと、CNにワイルドカードを指定せずにSANにDNSを定義した証明書で無事chrome様が接続してくださるようになりました。
しかし・・・RFC2818では、ワイルドカードの使用が認められているはずなので、もしかしたら私の勘違いで他に問題があるのかもしれません。あるいは、自己認証局に対してだけ厳しくしているのかもしれません。
結局のところ、エラー表示があまりに不親切なので真相は闇の中です。
ちなみにopensslを使用したSAN対応証明書生成手順は以下の通りです。
- 設定ファイルにSANを定義する
- [req]エントリに
req_extensions = v3_req
を追加 - [v3_req]エントリに
subjectAltName=alt_names
を追加 - [alt_names]エントリを追加し、
DNS.1=www.domain
DNS.2=mail.domain
のように証明したいサーバ名を追加
- [req]エントリに
- 署名要求(CSR)の発行時のコマンドラインに -reqexts v3_req を追加
例えば、
署名アルゴリズム: SHA256
設定ファイル名: $CFG
有効期間: 1万日
秘密鍵ファイル名: $KEY
署名要求ファイル名: $CSR
とした場合は以下になります。
openssl req -sha256 -config $CFG -reqexts v3_req -new -days 10000 -key $KEY -out $CSR - 認証局での署名時のコマンドラインに -extensions v3_req を追加
例えば、
認証局の秘密鍵ファイル: $CA_KEY
認証局の証明書ファイル: $CA_CERT
署名済み証明書: $CRL
とした場合は以下になります。
openssl ca -config $CFG -extensions v3_req -in $CSR -keyfile $CA_KEY -cert $CA_CERT -out $CRL
それにしても、この件に限りませんが、単に例外として認めてくれればいいところを、あまりに自分が何をしているのかわからない人が多すぎて、こうしてプログラム側で例外を認めず制限をかけてユーザを保護,言い換えれば自由を奪わざるを得ない風潮は加速する一方ですねえ。
ユーザの裾野が広がるほどそうせねば顧客が離れるのですから仕方がないのでしょうが、どうも過激なくらい過保護になっている気がしないでもない今日この頃です。
ユーザの裾野が広がるほどそうせねば顧客が離れるのですから仕方がないのでしょうが、どうも過激なくらい過保護になっている気がしないでもない今日この頃です。
0 件のコメント:
コメントを投稿