カテゴリー
everyday life

またやらかしたの?

 なんか, Baidu がまたやらかしたみたいね。☞この件 (すぐ消えると思うから,PDF 版)。

 上記だけではあとで何の事だかわからなくなりそうだから,もう少し関連の記事を貼っておくが,

 しかし,こうたびたびとなると,確信犯としか思えなくなるよね。確信犯という言葉の使い方にも揺れがあるようだが,ここでの意味は,本来の意味ね。☞「道徳的・宗教的または政治的確信に基づいて行われる」
 Baidu は国営ではないから,国家的見地からの確信犯とまで言うと,言い過ぎ&勘ぐりすぎだろうか。それはさておき,私の語感から言うと確信犯という言葉は国家に対抗する意味合いを帯びることが多い気がするので,国家的見地からの確信犯というのは,矛盾をはらんだ用法かもしれない……(アセッ)。

 過去における, Google との争いとか著作権に関してのとかは,単なる市場に対する独占欲からと言ってもいいかもしれないが,今回のこととか, 2013 年の Simeji の件とかはなぁ。

 国家的見地からということになると,どこの国にもありうる話なので,セキュリティの話には敏感にならざるを得ない。と言って, Google や MS のような巨大企業のほうが信用できるという話には,絶対にならないが。

カテゴリー
everyday life

冊子-よくわかるマイナンバー制度

投稿アップデート情報  追記(11/22)

 前に,「回覧板-マイナンバーが通知されます」というのを書いたが,今度は,「よくわかるマイナンバー制度」という冊子が,町報と一緒に配布されてきた。 24 ページにわたる A4 版の冊子なんだけどねぇ。表紙 & 裏表紙はこんなの☟

カテゴリー
everyday life

回覧板-マイナンバーが通知されます。

 今朝,朝刊を取りに行ったら,「マイナンバーが通知されます。」という回覧板が一緒に入っていた。こんなの ↓ 画像上の赤丸は,もちろん,私の仕業である(爆)。
「マイナンバーのお知らせ」回覧板 わが国には,古来,戸籍という制度がある。こんな制度はない国のほうが多いわけで,長寿世界一などと言っても,実は自己申告だけで,なんら客観的証拠が残っていないということがよくあるらしい。

 その昔,エラリー・クイーンの「災厄の町」かなんかを読んだときに,どうしてこんなに重婚が簡単なんだ?と不思議だった。子供心に,戸籍でばれるだろうとか思ったんだが,アメリカには戸籍制度はないんだよね。

 まあ,戸籍制度があっても,戸籍の売買とか偽造とかいろいろあって,身元を詐称しようとすれば,何でもありだとは思うが,そんな制度がない国よりは,ずっと面倒くさいことになると思う。

 でもって,マイナンバーというのは,デジタル時代の戸籍制度と看做せないものでもないが,デジタルデータの一元管理というのが,大きな問題点だ。便利なものは,なんでも両刃の剣だが,「マイナンバー」も例外ではないだろう。

 このデータの公権力による悪用というものは,もちろんありうるだろうが,当面気がかりなのは,そっちじゃなくて,こっちみたいなのの件。例の年金機構の件は言うまでもないが,そういうデータを扱うだろう組織のセキュリティが,こうザルの状態なのに,こんなシステムを導入するというのは,どういうもんなんかね。わかって,やってるのかしら。こんなことをやる以前に,デジタルリテラシーの強化に努めるべきだろう。前に,「普通の人たちの教育を投げてしまったら,日本らしさが消えてしまうと思っています。」と書いたことがあるんだが,その辺はどうなってるんだろう。

 日経の記事にも,「敵は「本気」だ」というのがあったが,こんな情勢の今日,こんなことを始める政府っていうのは,どうも背筋がゾクゾクするというものである。法案の通った 2013 年 5 月 24 日ころと比べても,ザル運用によって生じる恐れのある国民の危険性は,ものすごく増大していると思う。そういえば, APT 攻撃について「速さにたじろぐ。」という記事を書いたのは, 2013 年 11 月 14 日だった。法案通過の半年後だな。

 優れた能力があって権力のある人物は恐ろしいが,適切な能力を持たないのに権力を握っちゃった奴というのはもっと怖いよという悲しい事実が,歴史にはいっぱい転がっているんだよね。日本の防衛に必要なホワイトハッカーがものすごく不足してることをもっと認識して,国内の教育に,力を注いでほしいなぁ。昨今のように,議場で力づくで採決やってる場合じゃないと思うんだが……こういうと,詰め込みを復活させようとする輩がいるけど,その辺は,ちょっと,立ち止まって考えてくださいね m(_”_)m。

 まぁでも,実際問題として,運用が始まれば,避けては通れない。日本在住なんだからね。
 くれぐれも上記リンク先のようなインシデントが起きませんように。クワバラクワバラ。泥縄でも仕方ないから,今からでも足元を見据えて,デジタル面での保安強化に取り組もうよ。それには,まず,教育だと思うよッ。我々成人も含めてのね。

カテゴリー
Vulnerability

本家のお世話-#115。(CVE-2015-1793 に対処のため Apache のアップデート)

The same article in English

 Apache 2.4.12 (httpd-2.4.12-win32-VC14.zip) を 2015.7.9 版にアップデートした。 Alternative chains certificate forgery (CVE-2015-1793) に対処するためである。

 2015.7.9 版は ‘IPv6 Crypto apr-1.5.1 apr-util-1.5.4 apr-iconv-1.2.1 openssl-1.0.2d zlib-1.2.8 pcre-8.37 libxml2-2.9.2 lua-5.1.5 expat-2.1.0′ でビルドされている。そんでもって, Changelog
 この版は, Windows® Visual Studio C++ 2015 RC 別名 VC14 がないと動かない。私は, 6/2 から VC14 版 に替えた。 OpenSSL 1.0.2 系を使うためである。そんなわけで,同版を使われる場合は,前もって忘れずに vc_redist_x64/86.exe をインストールのこと。

 いつもながら, Steffen には,頭が下がる。本当にありがとうございます。

 ところで, phpMyAdmin 4.4.11MariaDB 10.0.20 へのアップデートもやった。

 phpMyAdmin については 2 つばかり気づいたことがある。 4.4.10 からダウンロード先が, sourceforge.net から phpmyadmin.net に変わった。 4.4.11 からは MD5/SHA1 だけでなく, GPG も利用できるようになった。 sourceforge と phpmyadmin 間でなんかあったんかいネ。

カテゴリー
Vulnerability

昨日, FireFox 39.0 がやってきた。

The same article in English

 昨日, FireFox 39.0 がやってきた。

 これで FireFox も Logjam に対応済みになった。どんな脆弱性が修正されたかは,右ページで確認できる ⇒ Fixed in Firefox 39

 見ての通り,いつもながら数個の脆弱性への対応がなされている。そんなわけで,ブラウザってのは,常に新バージョンに更新しておく必要があるんだよね。まぁ,ブラウザに限った話じゃないけどさ (^^;)。

カテゴリー
Vulnerability

(緊急)登録情報の不正書き換えによるドメイン名ハイジャックとその対策について-#2

 昨年, jprs.jp から「(緊急)登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」というのが出て,それについて記事を書いたことがあるのだが,昨日,同件について更新情報が出た。「(緊急)登録情報の不正書き換えによるドメイン名ハイジャックとその対策について(2015年5月26日更新)

 今回の更新情報の目新しいところとしては,
  (2015年5月26日更新)
  (*2)JPドメイン名では2015年1月19日より、レジストリロックサービスの
     提供を開始しました。本サービスの提供方法及び提供範囲は、指定事
     業者によって異なります。詳細はドメイン名の管理指定事業者にお問
     い合わせください。

     レジストリロックサービス
     <http://jprs.jp/about/dom-rule/registry-lock/>

ということで,リンク先に行くと,レジストリロックサービスの具体例がわかる。

 前回のときに,レジストリロックとレジストラロックの違いが分からなくてずいぶん悩んだから,ありがたい。

カテゴリー
Vulnerability

遅ればせながら, Logjam の話。

The same article in English
投稿アップデート情報  追記 追記2(7/7) 追記3(9/2) 追記4(9/5)

 昨日, 8 時くらいに帰宅したのだが,今年,初の蛍を見た。まぁ,時刻的問題もあるから,昨日から飛び始めたとは限らないけど。

Server Test1 で,本題。 21 日に “TLSに脆弱性「Logjam」 – 国家レベルなら1024ビットまで盗聴可能” というのを読んで, Guide to Deploying Diffie-Hellman for TLS に行った。特に何も対策せずに,テストしてみたんだけどさ, 2014.Oct.28 (= OpenSSL で作る SANs 対応かつ SHA256 使用の自前認証局) のままで,右図の結果が出た。んで,「まっ,いいか」となった。

 その夜,くりくりさんから, Logjam についてのコメントをいただいた。そんで「記事。何とか,がんばってみます」と返信したので,今,がんばってるところ。ヘヘッ。

 最初にテストをした時点では,うちのサーバは,下の Cipher Suites をサポートしていた。

  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-CBC-SHA384
  • ECDHE-RSA-AES128-CBC-SHA256
  • ECDHE-RSA-AES256-CBC-SHA
  • ECDHE-RSA-AES128-CBC-SHA
  • DHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-AES256-CBC-SHA256
  • DHE-RSA-AES256-CBC-SHA
  • DHE-RSA-CAMELLIA256-CBC-SHA
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES128-CBC-SHA256
  • DHE-RSA-AES128-CBC-SHA
  • DHE-RSA-SEED-CBC-SHA
  • DHE-RSA-CAMELLIA128-CBC-SHA

 実のところ,ほとんどいらないんだよね,こいつら。だって,うちの SSL サーバのユーザは私だけで,私は,最新のブラウザしか使わんのだもん。ホンでもって,使ってるのは ECDHE-RSA-AES128-GCM-SHA256 だけなんス。この際, SSLCipherSuite を下に書き換えることにした(爆)。
   SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256
 当たり前だけど,このコンフィグは,ほかの人の役には立たない。現実的にコンフィグを知りたい人は, Guide to Deploying Diffie-Hellman for TLS を見に行ってくだされ。 Apache 2.4.8 以降と OpenSSL 1.0.2 以降を使っている場合は, SSLOpenSSLConfCmdor ディレクティブで,直接 DH params ファイルを指定できる。そうでない場合には, SSLCipherSuite と SSLProtocol を代わりに使ってやって, Logjam attack を回避することになる。

Sever Test2 実のとこ, ApacheLounge の HTTPD はいまだに OpenSSL 1.0.1 なんだよね。というわけで, SSLOpenSSLConfCmd は使えんかった。まぁ, SSLCipherSuite が上記のようにキチガイじみてる(汗)ので,変更後のテスト結果は,右図のような感じになった。

Another Test   別の Logjam Attack チェッカーでやってみたら,⇒みたいになった。

 おまけだけど, Apache 2.4 で OpenSSL 1.0.1 以降を使ってる場合は, SSLProtocol all は +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 の意味になる。 Apache 2.4.7 以降を使っている場合は, aNULL, eNULL and EXP ciphers are always disabled になっているんだそうだ。

 いつもながら piyolog さんのまとめが出てましたね。「Logjam Attackについてまとめてみた

追記:
 The Logjam Attack page には, Google Chrome (含 Android ブラウザ), Mozilla Firefox, Microsoft Internet Explorer, 及び Apple Safari はすべて Logjam attack に対して修正を配備と書いてあるのだが,現時点でも (午前 9:45),当該ページに FireFox 38.0.1, Google Chrome 43.0.2357.65 あるいは SeaMonkey 2.33.1 でアクセスすると Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser が出る。 Good News! Your browser is safe against the Logjam attack が戻ってくるのは, Internet Explorer 11.0.19 でアクセスしたときだけである。
注意) この件,他のブラウザおよびバージョンではチェックしていない。

追記2(7/7):
 昨日, FireFox 39.0 になりましたね。でもって, Good News! Your browser is safe against the Logjam attack になったでアリンス。

追記3(9/2):
 しばらく,チェックを忘れてて,今日, Google Chrome の 45.0.2454.85 が来たのでチェックしてみたら Good News! Your browser is safe against the Logjam attack になっていた。ウーン,いつなったんだろ,ワカンネ!!

追記4(9/5):
 今 5 日になったばかりだが,久々に SeaMonkey のアップデートが来て, 2.35 になった。でもって,やっと Good News! Your browser is safe against the Logjam attack が出るようになった。

カテゴリー
Vulnerability

(緊急)登録情報の不正書き換えによるドメイン名ハイジャックとその対策について

投稿アップデート情報  追記(11/7)

 昨日,「(緊急)登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」というのが出ていたので,慌てて, NetowleNom を見に行った。見たのは, Netowl のレジストラロックがしっかりかかっているかと,両方の登録データが変わっていないかだけだが。パスワードは,もともとかなり複雑にして使っているので,変えても仕方ないだろうし。変えるタイミングもあるし。レジストラロックというのは,レジストラが提供しているわけで, Netowl のレジストラロックは Netowl が提供しているわけだ。 com ドメインの場合, Netowl はリセラーでレジストラとしては行動しないようだが,その場合でも,ロックは効くんだと思う。判断理由は, Value-Domain のときも Value-Domain はリセラーでレジストラは Key-Systems だったんだが,そのときも同じシステムだったからだ。それに eNom の設定では, Netowl がリセラーとして管理している私のドメインについては,そういう項目はなかったし。もっとも,確認はとっていないから,私が勝手に推測しているだけだ(汗)。
 ところで,「(緊急)登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」で記述のあるロックは,レジストリロックだ。これがよくわからない。記事を書いた時点(11/6)では,脳ミソが勝手に「リ」を「ラ」と読んでいた(滝汗)。レジストリロックというと,レジストリ側でロックをかけるという意味だろう。 com のレジストリというと, InterNIC ですかね。 jp だと, jprs だよな。 jp はともかく com って膨大な数だよ。実際の管理がレジストリ自体で可能なのかね。実は,レジストラやリセラーに管理委託しているとかなるんじゃないのか。
 レジストラロックていうのは,多分, clientTransferProhibited の状態のことだと思うんだけど,レジストラロックとレジストリロックってどう違うんですかね。アチコチ読んでもすっきりと納得がいかない。
 どなたか,ご指導よろしくお願いいたします m(_”_)m。

 この件に関しては,ユーザにできることは限られているから,レジストラや権威 DNS サーバの運営者や CDN サービスなどにしっかりしてもらわないとどうしようもない。今年, eNom に移管するとき,過去の事件が頭をよぎったりしたのだが, jp 国内のドメインでもこういうことの起こる時代になったんだな。狙われるようになったら,国内には危ないところが,いっぱーーいあるんだろうと,戦々恐々である。

 「速さにたじろぐ」のときにも書いたが,我が国は結構蚊帳の外だったからねぇ。ありがたくないけど,このあたりもグローバル化の時代を迎えたわけだ。

 こんなことなくても,白物家電がゾンビ PC 化したり, USB の設計そのものが悪用されたりと,なんか無力感が甚だしいのになあ。

 しかし,関連で名前挙がっている企業がおっきいとこだねえ。大きいとこはピンポイントで狙われるだろうから,その企業が特に弱いということではなく,強度については,どこも変わらんのだろうなあ。

追記(11/7):
 上の追記で,レジストリロックとレジストラロックについて,
> どなたか,ご指導よろしくお願いいたします m(_”_)m。
と書いたのだが,くりくりさんが,「登録情報の誤りによるドメインの停止措置について」というページを教えて下さった。なるほど,これがレジストリロックなんですね。よくわかる。

 レジストラロックは,あくまで, Transfer Prohibited ,つまりドメイン移管禁止だもんね。当然ながらユーザが ON/OFF できる(リセラーに頼んで変えてもらうということも含めて)。レジストリロックは,ドメインの期限切れではないのに registrar hold にされることなんだ。ということは,移管どころか,ドメインの使用自体ができなくなってしまうわけだ。対応が遅れるとドメインが削除される可能性もあると。なるほど。

 くりくりさん,ありがとうございました m(_”_)m。

カテゴリー
everyday life

Trusteer Rapport をインストールしてみた。

 初めに,余談つうか,本日のメインイベント(呵呵大笑)。

 鷹くーん。日本一ーー\(^o^)/。

 今年一,というか,今年初のいい出来のセッツンを見せてもらったし。しかし,すっきりしない決まり方だったワイ。サファテは,来季は大きな試合に投げさせたらいかんね。いや,こんな日に文句を言ったらいけません。
 鷹のみなさま,おめでとうございます。今季もありがとうございました。

 さらに,余談。
 笑っちゃった。出演の黒ニャンコ,かわいい!! 関係ないか (^o^)。
 「iPhone 6 Plus」「iPad mini 3」のTouch IDを偽造指紋で突破、ついでに猫の肉球でも認証OK。 本文に,「あくまでパスワード入力を省くための便利なツールの 1 つとして考えたほうがよさそうとのことです。」とあるが,その程度のもんなんだねぇ。

 ところで,表題の件。
 三菱東京UFJ銀行のダイレクト(インターネットバンキング)を使っている。ふと思い立って,UFJが前からおすすめの「無料のウィルス対策ソフト」を入れてみた。実体は IBM の Trusteer Rapport だった。「他のセキュリティソフトウェアとの互換性」となっているが, Rapport は基本的にネットバンキングでの危険性回避に特化しているようなので,他のセキュリティソフトウェアとの併用が望ましいらしい。我が家でのインストール時は,特に特別な操作は必要なかった。

Trusteer Rapport
Trusteer Rapport

カテゴリー
Windows

OpenSSL で作る SANs 対応かつ SHA256 使用の自前認証局。

The same article in English
投稿アップデート情報  追記(10/28)

 今回の騒ぎ“Qualys SSL Labs – Projects / SSL Server Test” をやったとき,テスト結果にやらオレンジやらが乱舞していた (^_^;)。
 
||赤いの||

  1. Trusted : No NOT TRUSTED <<---- これは,自前認証局を使っているせいなので,自信をもって無視する(笑)。
  2. IE 6 / XP No FS 1 No SNI 2 : Protocol or cipher suite mismatch : Fail3 <<---- うちの SSL サーバのユーザは私だけで,私は IE 6 / XP なんぞ使わないので,これも無視。
  3. Fail3 “Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.” なんだそうだ。うちの SSL サーバはより低レベルのプロトコルは受けつけないが,これも別に問題なし。
  4.  というわけで,赤いのについては何もやらなくてよし。

||オレンジの||

  1. Prefix handling : Not valid for “www.o6asan.com” :CONFUSING
  2. Signature algorithm : SHA1withRSA : WEAK
  3. Chain issues : Contains anchor <<---- Ivan Ristić“Chain issues Contains anchor” で書いていたことを根拠に,無視。
  4. Not in trust store <<---- これも自前認証局のせいなので,無視。
  5. Downgrade attack prevention : No, TLS_FALLBACK_SCSV not supported
  6. Forward Secrecy : With some browsers

 オレンジのについては, 1, 2, 5, 6 について対処する必要がありそうだ。まずは, 5 と 6 から。 1 と 2 は証明書そのものを作り変えないといけないので,後回し。

  1. Apache 2.4.10 (httpd-2.4.10-win32-VC11.zip) を 10/20 バージョンにアップデートした。この版は openssl-1.0.1j を使ってビルドされてて,1.0.1j は TLS_FALLBACK_SCSV をサポートしたから。
  2. httpd-ssl.conf において, SSLHonorCipherOrder on をアンコメントし, SSLCipherSuite Directive の値を変更。
    HIGH:MEDIUM:!aNULL:!MD5

    EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
    EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256
    EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP
    !PSK !SRP !DSS

       参考 : Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
    ↓ RC4 関連で, 12/23 に下記に変更した。
    EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
    EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH
    EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

       Ref : RC4 in TLS is Broken: Now What?

    SSL サーバがモバイルや旧世代の OS/browser をサポートしなくてはいけない場合は,それらに合わせた設定もする必要が生じる。うちのは,関係ないけど。
  3. この作業後,テストしたら, “Downgrade attack prevention : Yes, TLS_FALLBACK_SCSV supported”“Forward Secrecy : Yes (with most browsers) ROBUST” に変わった。

 次は, 1 と 2。
 1 は自前認証局の Common Name が o6asan.com だけだからだ。で,新しいのは, o6asan.com も www.o6asan.com もサポートさせないといけない。しかし,我が家の SSL サーバ用の IP は,一つしか割り当てる気がないよという問題がある。これに対処するために, SNI(Server Name Indication) を使う。 8 月ごろに,くりくりさんが取り組まれていた。まあ,まだすべての OS/browser がサポート完了しているわけではないが……それでも,かなりましになってきたのは確か。ワイルドカード証明書か SAN かということになるが, SANs で行くことにした。だって,うちの SSL サーバに任意のサブドメインを受け入れさせる必要はないでしょ。これについては Apache からも制限できるとはいえ,必要のない扉を大きく開けるのはポリシーに反する。
 2 は前の証明書を作ったときに OpenSSL の default を使ったからである。デフォルトだと,今もかわらず SHA1 を使うようになっている。今回は, default_md = sha256 にして,こさえるワ。
 28 日,改めて Server Name Indication を読み込んでいたのだが, SNI と ワイルドカード証明書か SAN は次元の違う話のようだ。難しいなぁ。

 openssl.cnf (← この標準の名称のままで行く) を Apche24conf から c:openssl-1.0.1x-winxxssl (← OpenSSL をフルでインストールすると,ここがデフォルト) にコピーして,以下のようにカスタマイズする。

    一行アンコメントし,いくつか値を変更する。

  1. dir = ./demoCA —->> dir = X:/demoCA <<----絶対パス
  2. default_crl_days = 30 —->> default_crl_days = 365
  3. default_md = default —->> default_md = sha256
  4. default_bits = 1024 —->> default_bits = 2048
  5. # req_extensions = v3_req —->> req_extensions = v3_req
    何行か追加する。
  1. [ v3_req ] のエリアに subjectAltName = @alt_names を追加。
  2. [ v3_ca ] エリアの直前に以下を追加。
    [ alt_names ]
    DNS.1 = example.com
    DNS.2 = www.example.com

     
    必要なドメインを DNS.1, DNS.2, DNS.3, … のように追加できる。
  3. クライアント証明書も必要な場合は, openssl.cnf の最後に以下を追加する
    [ ssl_client ]
    basicConstraints = CA:FALSE
    nsCertType = client
    keyUsage = digitalSignature, keyEncipherment
    extendedKeyUsage = clientAuth
    nsComment = "OpenSSL Certificate for SSL Client"

 さて,新自前認証局の作成をしよう。(参考 : 本家のお世話-#68)

    ||自前 CA 作成||

  1. X:/ に myCA フォルダを作る。
  2. private と newcerts という 2 つのフォルダと index.txt を myCA に作る。
  3. cmd.exe を 管理者として実行。
    pushd X:myCA
    echo 01 > serial
    openssl req -new -keyout privatecakey.pem -out careq.pem
    openssl ca -selfsign -in careq.pem -extensions v3_ca -out cacert.pem
    copy cacert.pem (Drive_SV):Apache24confssl.crt
    copy cacert.pem my_ca.crt

      注)(Drive_SV) というのは,自宅サーバ上のサーバウェア用パーティションである。

    ||Server 証明書作成||

  1. pushd X:myCA
    openssl genrsa -out server.key 2048
    openssl req -new -out server.csr -key server.key
  2. 次のコマンドで CSR 内の SANs を確認する。(中にちゃんと ‘Subject Alternative Name’ があるかな?)
    openssl req -text -noout -in server.csr
  3. openssl ca -in server.csr -out server.crt -extensions v3_req
    copy server.key cp_server.key
    openssl rsa <cp_server.key> server.key
    copy server.key (Drive_SV):Apache24conf
    copy server.crt (Drive_SV):Apache24conf
    ||Client 証明書作成||

  1. pushd X:myCA
    openssl req -new -keyout client.key -out client.csr
    openssl ca -policy policy_anything -extensions ssl_client -in client.csr -out client.crt
    openssl pkcs12 -export -in client.crt -inkey client.key -out clientcert.p12

   SANs 作成参考リンク : FAQ/subjectAltName (SAN), Multiple Names on One Certificate.

 やっと,「 SANs 対応かつ SHA256 使用の自前認証局」が出来た。満足じゃ!!