カテゴリー
Vulnerability

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

The same article in English

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

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

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

カテゴリー
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 が出るようになった。

カテゴリー
Windows

本家のお世話-#113。(Apache2.4.12へアップデート)

The same article in English

 Apache HTTP Server 2.4.12 が出た。 CVE-2014-3583, CVE-2014-3581, CVE-2014-8109, CVE-2013-5704 のパッチが入ってる模様。 httpd-ssl.conf に下記の行が追加されている。 2.4.11 はリリースされず,欠番になった。

  • # OCSP Stapling (requires OpenSSL 0.9.8h or later)
    #
    # This feature is disabled by default and requires at least
    # the two directives SSLUseStapling and SSLStaplingCache.
    # Refer to the documentation on OCSP Stapling in the SSL/TLS
    # How-To for more information.
    #
    # Enable stapling for all SSL-enabled servers:
    #SSLUseStapling On

    # Define a relatively small cache for OCSP Stapling using
    # the same mechanism that is used for the SSL session cache
    # above. If stapling is used with more than a few certificates,
    # the size may need to be increased. (AH01929 will be logged.)
    #SSLStaplingCache “shmcb:c:/Apache24/logs/ssl_stapling(32768)”

    # Seconds before valid OCSP responses are expired from the cache
    #SSLStaplingStandardCacheTimeout 3600

    # Seconds before invalid OCSP responses are expired from the cache
    #SSLStaplingErrorCacheTimeout 600

 このバージョンは, openssl-1.0.1l とともにビルドされているので, OpenSSL Security Advisory [08 Jan 2015] 関連の問題も対処済みになった。

 VC11 用の httpd-2.4.12-win32-VC11.zip を我が家用 ( Windows7 x86 ) にダウンロード。 Apache 2.4.x conf 情報が必要な方は,「Windows7上にWamp系WebServerを建てる-#1。」を見てください。

カテゴリー
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 使用の自前認証局」が出来た。満足じゃ!!

カテゴリー
WordPress

カールはプードル飼ってるのかな?

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

 前記事で, “POODLE” の件を書いた。その後, SSLv3 fallback attack POODLE というのを読んで, WordPress 上の cURL のことが気になりだした。

 curl_setopt( $handle, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1); というオプションを curl_setopt で見つけたが, WordPress Core Scripts のどこに入れるのが一番いいのかがわからない。で, WordPress Forums に topic を建ててきた。現在,回答待ちです。

追記(10/26):
 cURL が確かに TLSv1.2 を使っていることを確認できたので,さっき, topic を [resolved] にしてきた。 Apache の SSL のログに %{SSL_PROTOCOL} を入れて調べた。 class-http.php に CURL_SSLVERSION_TLSv1 on the file を入れる必要はないようだ。サーバのコンフィグがちゃんと出来てれば,クライアントは安全にアクセスできるんだね。もちろん,クライアントのソフトが TLS に対応してないとかじゃ話にならんけど。

 何はともあれ,(*´▽`*)。

カテゴリー
Windows

覚え書-#20。

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

 もう, “POODLE” 問題(つまり, CVE-2014-3566)には,対処した? OpenSSL のオフィシャルでも, OpenSSL Security Advisory [15 Oct 2014] が出てる。

 サーバ管理者としては下記のことをやった。
 今のところ, 1.0.1j でビルドされた Apache Lounge 版の Zip が手に入らないので, “SSL v3 goes to the dogs – POODLE kills off protocol” にあった回避策をやった。

 httpd-ssl.conf に SSLProtocol All -SSLv3 を書き加えて, httpd.exe をリスタートした。やる前は, SSL Server Test で “This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C” だったが,回避策後は, “This server is not vulnerable to the POODLE attack because it doesn’t support SSL 3” になった。実のところ,うちでは, Apache 2.4 と OpenSSL 1.0.1 を使っているので,うちの mod_ssl の場合, ‘SSLProtocol all’ は ‘SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2’ ということになる。これは SSLProtocol Directive に記述がある。

 ユーザとしては,ブラウザで SSLv3 を停めた。
 やり方は,これも How to protect your browser にあった。英文だが,図もあってわかりやすい。日本語のサイトでは, IE, FireFox, Chrome の 3 つともの説明があるところを見つけられなかった。

追記(10/18):
 PHP 5.6.1 —>> PHP 5.6.2 ChangeLog.
 phpMyAdmin 4.2.9.1 —>> phpMyAdmin 4.2.10 ChangeLog.

カテゴリー
Vulnerability

Android 版 Kindle の SSL サーバ証明書検証不備脆弱性。

 表題の件,我々一般人には,一見関係なさそうに見えるが,怪しいアプリをうかつに使わないとか,メールアカウントやパスワードの管理をしっかりするとかいうことでは,同じなんじゃないかと思う。

 そういえば,昨日,「ネット競売、消せぬ情報 大手3社、履歴・カード番号保存 利用者「流出が心配」」というのもあったな。えって,思うかもしれないけど,結構そういうとこ多い。だって,登録させる側からいえば,データの不正使用をする気はなくても,ユーザ側の無料版の反復利用を防ぐためだけでも,元情報は必要なわけだから,良心的であっても,罰則がないなら,データを保持するほうが妥当だと思う。どのくらい保持するとかで口を拭ってる様子は感じられるが……。知識の欠如から対応がいい加減なところもあるにはあるけどね。

 登録データの削除については,簡単/困難/不能をまとめたこんなサイトがある。 justdelete.me
 このサイトは, bitly.com (有名どころだが,日本語対応がないみたいなので, twitter そのものの短縮リンクが向上してからは,使うのをやめようとしたのだ) のアカウントを削除しようと四苦八苦しているときに発見した。
 まぁ, justdelete.me の一覧を見ると,サイトの性質から考えても, HARD あるいは impossible で当然だなと思うところもたくさんあるけど……。 justdelete.me ,日本語でも似たものがあるのかな。

 やっと,本題。
 29 日に JVN から Android 版アプリ Kindle における SSL サーバ証明書の検証不備の脆弱性というのが出ていて,セキュリティホール memo さんが「そのうち徳丸さんから解説が出るだろう」と書いておられた解説が出た。「Android版KindleにおけるSSLサーバ証明書の検証不備の脆弱性CVE-2014-3908」。読んでみたけど,難しくて,よくわからん。

 証明書を作るときに「コモンネームをちゃんとやってねー」というのはよく聞く。一致してない場合は,アクセスさせてくれないからだと,理解していた。これは,自前証明局の話ね。

 でも,奥さんの記事「SSL/TLSライブラリの正しい使い方(もしくは、コモンネームの検証について)」を読むと,多数の人がアクセスするアプリの場合,コモンネームの検証の実装はそれほど単純なものではないみたいだ。うちの自宅サーバレベルは蚊帳の外みたい(爆)。

 徳丸さんの解説は難しくて 100% 理解しているとはいいがたいのだが,それでも「コモンネームの検証が漏れてる場合があるって,超ヤバいじゃん」ということくらいは十分わかる。

 8月初めには,「App Storeのアプリが盗まれた」って話もあったし,スマホが一気に普及して,それ関係の悪事も花盛りだな。

 徳丸さんの記事の件は,実際に悪用されてるかどうかは現時点で不明なようだが,持っている方は,既に対応バージョンが出ているようだし, 「Kindle – Google Play の Android アプリ」でアップデートしておこう。

 「App Storeのアプリが盗まれた」の件については,セキュリティホール memo さんによると,いたのくまんぼうさんとこが,有用みたい。「注意喚起:アプリ乗っ取り犯の手口判明。ITCアカウントの入力を求めるアプリには注意!

カテゴリー
Windows

覚え書-#18。

The same article in English
投稿アップデート情報  追記(8/28)
  1. PHP 5.6.0 GA の正式リリースの時期が, RC4 の記事に書いてあった。とーっても楽しみ。 wow!
  2. Apache 2.4.10 (httpd-2.4.10-win32-VC11.zip) を openssl-1.0.1i のものに,アップデートした。 OpenSSL Security Advisory [6 Aug 2014] のせいなんだが, Steffen が Jan-E に “Coming days the builds here at Apache Lounge are going to be upgraded. It has not that priority and severity ~” と回答していたので,焦らずに待っていたのだ。
  3. Windows Update 2014 年 8 月はトラブル続出だったみたいだね。うちのパソコンは幸いにも1台も引っかからなかったんだが,現時点で特に問題がなくても KB2982791, KB2970228, KB2975719 and KB2975331 をアンインストールしたほうがいいということらしいので,探し出してアンインストールした。以下の通り。
    • NJ2100 上の Windows8.1(x86)
      KB2982791
      KB2975719
    • CF-J10 上の Windows7 SP1(x64)
      KB2982791
      KB2970228
    • xw4200 上の Windows7 SP1(x86)
      KB2982791
      KB2970228
    • KeyPaso 上の Windows Vista SP2(x86)
      KB2982791

    昔は, Windows update というとほぼ毎回不具合があって,少し落ち着くまで更新を控えたりしたものだが,今回のドタバタは久しぶりだった気がする。皆さんはどう思われますか? (^_~)

追記(8/28):
 MS14-045 関連の不具合更新プログラム, KB2993651 が出てますな。詳しくは,[MS14-045] 更新プログラム 2982791 の問題を解決する更新プログラム 2993651 を公開

カテゴリー
WordPress

WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決。

The same article in English

 WordPress 3.7 から ca-bundle.crt が含まれるようになったんだが,その後,「Upgrade Network」のときにエラーが出るようになった。ところで,「Warning! Problem updating https://SITENAME.」というのを1つのサイトだけおかしいんだと勘違いしていたのだが,一番初めに調べたサイトでエラーが出てるんだから,あとは調べてないわけだよな(汗)。

 はじめのエラーは,「Error message: SSL certificate problem: self signed certificate in certificate chain」というので,これは自前認証局を使ってるせいだったんだが, Oiram の教えてくれた通り, ca-bundle.crt に自前の CA のデータを書き加えてやったら,よくなった。

 で,次が「“Error message: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure」。これに2か月以上手を焼いていたが,本日,やっと,解決した \(^o^)/。

 振り返ってみると,結局のところ3つのポイントがあったようだ。

  1. うちの client.crt には ssl_client extension を使っていなかった。で, client.crt を ssl_client extension 付きで作り直した。参考にしたのは, “sslv3 alert handshake failure when using SSL client auth”
    まず, openssl.cnf に次の行を追加した。

    [ ssl_client ]
    basicConstraints = CA:FALSE
    nsCertType = client
    keyUsage = digitalSignature, keyEncipherment
    extendedKeyUsage = clientAuth
    nsComment = “OpenSSL Certificate for SSL Client”

    でもって, ssl_client extension を使って client.crt を作り直した。
    >openssl ca -config openssl.cnf -policy policy_anything -extensions ssl_client -in client.csr -out client.crt

    • 古いほうの client.crt で “openssl s_client -connect o6asan.com:443 -cert client.crt -key client.key -CAfile cacert.pem” をやると,下の2つのエラーが出ていたが,新しいのだと出なくなった。
    • error:14094418:SSL routines:SSL3_READ_BYTES: ~
      error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure: ~
    • 当然ながら, clientcert.p12 も作り直した。
  2. WordPress は「Upgrade Network」のときに cURL を利用しているのだが, cURL は P12 format certificates を受用しないので, PEM format に直さなければ使えない。
    • clientcert.p12 から clientcert.pem を作る
      >openssl pkcs12 -in clientcert.p12 -nokeys -clcerts -out clientcert.pem
    • clientcert.p12 から clientkey.pem を作る。
      >openssl pkcs12 -in clientcert.p12 -nocerts -out clientkey.pem
       
      clientkey.pem のコピーを作り, pass phrase を削除する。
      >copy clientkey.pem cp_clientkey.pem
      >openssl rsa <cp_clientkey.pem> clientkey.pem
  3. WordPress に client 証明書の場所を教えてやる
    • class-http.php の「curl_setopt( $handle, CURLOPT_CAINFO, $r[‘sslcertificates’] );」行の直前に,以下の2行を書き加える。

      curl_setopt( $handle, CURLOPT_SSLCERT, 'clientcert.pem の絶対パス' );
      curl_setopt( $handle, CURLOPT_SSLKEY, 'clientkey.pem の絶対パス' );

      WordPress の core スクリプトを書き換えるのは嫌なので,何とかほかの方法でやろうと頑張ったのだが,どうしてもうまくいかなくて,結局, class-http.php をいじることにした。

      clientcert.pem と clientkey.pem をサーバ上のどこか,外部のものがネット経由でアクセスできない,より安全な場所にコピーする。

    参考サイトは, Client URL Library

 自前認証局の作り方は,「本家のお世話-#68。(WordPress SSL ログイン-#1)」をどうぞ。

 エラーが消えたよ。満足じゃ。パチパチ!!

カテゴリー
Windows

本家のお世話-#104。(OpenSSL Security Advisory [6月5日] に対処のため Apache のアップデート)

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

 OpenSSL Security Advisory [6月5日] になんかいろいろと挙がっていて,どうするかなと思っていたら,さっそく Steffen が対処してくれたので, Apache 2.4.9 の 2014 5 Jun version を落として,アップデート。

 新バージョンは, ‘IPv6 Crypto apr-1.5.0 apr-util-1.5.3 apr-iconv-1.2.1 openssl-1.0.1h zlib-1.2.8 pcre-8.34 libxml2-2.9.1 lua-5.1.5 expat-2.1.0’ と openssl-1.0.1h でのビルドとなっている。

 アップデートのやり方自体はいつもと同じ。そんでもって,Changelog

 いつも, Steffen への感謝の念に堪えない m(_”_)m。

追記(6/9):
 こんなんあったんで,貼っときます。
ハートブリード脆弱性から 2 か月で公開された OpenSSL の重大な脆弱性修正パッチ