WordPress 3.7 から ca-bundle.crt が含まれるようになったんだが，その後，「Upgrade Network」のときにエラーが出るようになった。ところで，「Warning! Problem updating https://SITENAME.」というのを１つのサイトだけおかしいんだと勘違いしていたのだが，一番初めに調べたサイトでエラーが出てるんだから，あとは調べてないわけだよな（汗）。
はじめのエラーは，「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」。これに２か月以上手を焼いていたが，本日，やっと，解決した ＼(^o^)／。
振り返ってみると，結局のところ３つのポイントがあったようだ。
[ 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
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）」をどうぞ。
エラーが消えたよ。満足じゃ。パチパチ!!
This website uses cookies.
View Comments
解決できてよかったですえね！！
解決出来たときの喜びはなんともいえない嬉しさがあるとおもいます。また、自分は解決できないと風呂や散歩中。あれならどうだろうとかこれならどうだろうとかついつい睡眠時間削ってしまいます。
関係あるかもをみるとwordpressのログイン関係でsslを使ってるらっしゃるのですかね？
仕事でもVPSもssl自体つかわないので＾＾；
くりくりさん，こんばんは。
> 解決できてよかったですえね！！
ありがとうございます。ほんっと，嬉しいですよねぇ!!
今回のハマりポイント，大きなのは３つでした。他にも，チョコチョコとありましたが，その辺もまた補足で書くかもしれません。
クライアント認証のときは，エクステンションに ssl_client がいるという話は，そこここで見るんですが，ブラウザから使う場合は，保管場所を手動で設定できるせいか， ssl_client がなくても，バッチリ，クライアント認証できてたんですよ。で，ここで，だいぶ長らくハマりました。初めは，「ssl_client ないけどエラーでてないじゃん」とか思ってましてね。でも，コマンドラインでチェックすると，確かにエラーが出てました。
WordPress は PHP から cURL で通信してまして，cURL では P12 フォーマットを使えないので， PEM にしたのですが，これをどうやって WordPress に渡すのかっていうのに，一番悩みました。当初，できるだけ，WordPress のコアスクリプトは弄るまいという方針だったもので。
ネットワークアップデートは管理画面からブラウザで行うので， PEM もブラウザに持たせてやるのでいいのかと思ったんですが，１回，PHP に行ってしまうと，ブラウザの情報は見てくれないので，これは，結局無理なようです。後で思えば，当たり前といえば，当たり前ですが。それと，クライアント認証関係で，有名どころのブラウザは（IE や FireFox など）， PEM は受けつけてくれませんでした。
おはようございます。
opensslの脆弱性がまたでたみたいですね。
http://jvn.jp/vu/JVNVU94401838/
くりくりさん，こんにちは。
「CVE-2014-0160って？」関連ですね。今回の告知はFUJITSUの製品ですか。ものがモノだけに，影響大で，長引きますねぇ。OpenSSL 1.0.1 から 1.0.1f までが，HeartBleedの影響を受けると書いてありますが，すでに本家では，対応済みのg，hまで出てはいます。しかし，バンドルの製品が膨大ですから，なかなか更新が追い付いていないでしょう。
どっかで，深く静かに潜航しているHeartBleed みたいな記事を読んだので，探してみました。これでした。
Heartbleedはまだ生きている、多くの零細サイトが無手当のまま
怖いですよね。
スマホがらみの話も，もっ一回ここに貼っておきますね。ググって来る方のお役に立つかもしれませんし。
スマホにも“Heartbleed”脆弱性、検査アプリをTrend Microが公開
昨今は，日用品でもかかわりがありそうなのが，怖いです。
おはようございます。
sslを実装します。
他のドメインで自分なりの証明書をつくってうまくいきましたので、
1000円くらいの証明書買って試してみようかなと思います。
しかし、今度は俺がsslで悩むとは・・・。
まさか思いもしませんでした。
くりくりさん，こんにちは。
そちらのほうは台風11号の影響の大雨で，停電しているようなところもあるようなニュースを見ましたが，くりくりさんのところは，大丈夫ですか。
> しかし、今度は俺がsslで悩むとは・・・。
まぁねぇ。今後，そっち方向に流れていくのは，やむを得ないでしょうから，勉強は，しておかないといけないです。すべての情報を暗号化して流すような時代が来て，私が墓掃除に行ったということまで， SSL レベルで流すことになりそうです。個人的には，そこまで行くと，過剰反応だと思うんですけどねぇ。あんまり何もかも取り込んで守ろうとすると，一番守る必要のあることへの注意が抜けてしまうというのは，リアルでもありがちな話です。
とはいえ，仕事で使う場合は， SEO への影響や顧客の要求が強くなれば，実装せざるを得ないでしょうが……今のところは，実際のスコアには，ほとんど影響ないように思います。
全員が SSL 実装となれば，ちゃんとした発行会社の証明書も，もう少し安くなってくれるかもしれません。でないと，零細なサイト運営者は，それだけでインターネットからはじき出されてしまいます。
ところで，ネット上で見る自前認証局の作り方の日本語情報は，あまり新しくなっていない気がします。書かれた日付は新しくても，実際は昔のサイトの引き写しのことが多くて，私が本記事の件で苦労したのも，そのせいです。英文情報はいささかましなのですが，それでも，周知のこととして書かれていて，実際にはどうやるかという話が少なかった気がします。業界の情報を外に漏らさないようにしているのか，などと，勘ぐってしまいました。したがって，オフィシャルのドキュメントをまじめに読む羽目になりました。これが当然なんですが，かなり読み込まないとどこに書いてあるかさえ分からないので，つい安直にネットで同じことをやった人を探してしまいますよねぇ（滝汗）。
作成した証明書は，Qualys SSL Labs - Projects / SSL Server Testとか設定状況や信頼性がわかる！SSLチェックツール｜GMOグローバルサインを使って，強度を調べてます。ここで， SSL の新しい情報を知ったりする場合もありますので，その意味でも助かります。
実は，SSLチェックツールも，元はQualys SSL Labsのものです。検索エンジンが，実はGoogleのものを利用しているとかと，同じような関係です。で，SSLチェックツールは日本語でレポートしてくれるので助かるのですが，自前認証局だと，それだけで撥ねてしまうところがあって，暗号強度なんかのチェックをリポートしてくれません。SSL Server Testのほうは，その辺も教えてくれるので，併用しています。現在のSSL Server Testでの我が家のテスト結果は，自前というところだけ無視すれば，「A」になっています。
すごく長くなってしまいました。悪しからず。
こんにちは。
いやーなかなかうまくいきませんね。
いきなり秘密キーをこわしちゃいました。再発行方法を聞いて再度挑戦。csrを送りつけてssl証明書(Web Server CERTIFICATE？)と中間証明書を発行してもらいました。
nginxはapacheと違う所がありまして中間証明書のディレクティブがないのでSSLサーバ証明書、中間証明書をひとつにまとめたファイルにします。
でサーバー側のほうでもエラーはでませんでしたが、
ie11やfirefoxでアクセスすると証明書が信用できないとか
エラーがでます。ここまでたどり着きました。
原因がわからないのですが、
sslチェックツールでなんかわかるかもしれませんね。
おまけ、無料のstar-ssl
http://qiita.com/k-shogo/items/870b6d3939dd08da2de4
くりくりさん，こんばんは。
サーバで大丈夫で，ブラウザでエラーが出るんだと，この辺の話でしょうか。
SSL 連鎖証明書
記事にありますように，コマンドラインで接続すると，かなり細かくメッセージが見れます。私の本記事の問題の解決にも，
openssl s_client -connect o6asan.com:443 -cert client.crt -key client.key -CAfile cacert.pem
がずいぶん役に立ってくれました。
ところで，当初の「Error message: SSL certificate problem: self signed certificate in certificate chain」はca-bundle.crt に我が家の CA 情報が含まれていないために起こりました。実際に私以外の不特定多数に向けて SSL を使わせるならこの辺に対処する必要があります。そんなわけで，お書きの
> おまけ、無料のstar-ssl
> https://www.startssl.com/
のようなのを使ってみようかなと思いました。そのとき，調べてみたのは，
CAcert
で，上記の Oiram が使っていたところです。ただ，うちの場合，サーバは公開ですが，現時点で SSL は私専用なので，通信が暗号化できればいいだけですから，その必要はないと思い，自前のままです。
こんにちは実装成功しました。
>サーバで大丈夫で，ブラウザでエラーが出るんだと，この辺の話でしょうか。
サイト表示がおかしい現象はリバースプロキシーが原因（urlでキャッシュを保存するのでhttpsとhttpで保存方法の整合性がとれない？)ぽいのでリバースプロキシーの設定を解除と証明書云々はwordpressのサイトアドレス (URL)とwordpressアドレスをhttpからhttpsに変更。
>openssl s_client -connect o6asan.com:443 -cert client.crt -key client.key -CAfile cacert.pem
ここまでいけませんね。まだまだ勉強不足です。証明書のほうもまだ完璧なような気がしないのでトラブルチェックするつもりです。
無料のsslがあったのでご存じなければと思い書きました。
また、無料のやつはサーバー用のドメインでやるときテストでつかうつもりです。
くりくりさん，こんばんは。
> こんにちは実装成功しました。
おめでとうございます。リバースプロキシとかも関係するんですね。
１ページを表示する場合に，中に一つでも http で始まるリンクが含まれていれば，ページ全体は，混在として認識されますから，実際に運用となれば，リンク先すべて https に対応している必要がありますね。自サイトだけなら可能でしょうが，いまのところ厳しい気がします。また，httpとhttpsの両方に対応させる場合，最初から相対アドレスで書いておくと楽かもしれません。
うちのサイトの場合だと，他の人でもうちのCAを導入してもらえば https でつながると思うのですが，現在の設定では，さらに必ずclient認証を求めるようにしてありますので，そのための証明書を私が発行して，閲覧者にも導入してもらわないといけません。
また，TODOSの場合だと，xsrv.jpそのものはhttpsに対応しているので，証明書を受け入れてやればつながりはするのですが，TODOSのサイトそのものはhttpsプロトコルに未対応なので，404が出ます。
> 無料のsslがあったのでご存じなければと思い書きました。
ありがとうございます。
OpenSSLそのものもオープンソースなのですから，無料と言ってもバカにしたものではないのかもしれません。ただ，無料の中にもピンからキリまであるでしょうから，変なものには引っかからないようにしないととは思っています。
追記です。
> 最初から相対アドレスで書いておくと楽かもしれません。
ちょっと勘違いされやすいかなと思ったので。
ここでの相対アドレスとは，
href="http://example.com"やhref="https://example.com"をhref="//example.com"と書いておくという意味です。こんばんは
>おめでとうございます。
ありがとうございます。あんだけ苦労したリバースプロキシーをあっさり捨てfastcgiキャッシュにしました（笑）
>中に一つでも http
http://support.microsoft.com/kb/2625928/ja
自分が遭遇したのはwordpressの設定がhttpになっていたのとリバースプロキシーが8080にhttpで通信するから？なのかな。後はwp-to-topというプラグインが影響しました。
今の所コンテンツのブロックはありません。
＞自サイトだけなら可能
トラブルだらけだし・・・。運用も面倒になりそうだしまだまだ早いのかもしれませんね。それになんかipv6みたくなりそ。
＞最初から相対アドレスで書いておくと楽かもしれません。
わざわざありがとうございます。
これは偶然SEOのブログで質問がでていたのをみました。
＞変なもの
ただほど高いものはないとかならないようにしないといけませんね。
くりくりさん，こんばんは。
> あっさり捨てfastcgiキャッシュにしました（笑）
お疲れさまですねぇー。
最近どっかで，fastcgiというのをApacheがらみで見たなと思ったんですが，これでしたね。いまだに，FastCGIがよくわかっていない私です。まぁ，よくわかっているもののほうが少ないので，ちっとも珍しくないですが，使ったことのないものは，余計わからないですワ。でもって，FastCGIはいまだにその類。
> wp-to-topというプラグインが影響しました。
WordPressといえば，なんでもプラグインのあるWordPress，WordPress HTTPSなんてのもあるようです。使ったことないですが，ドメインマッピングの機能もあるらしいです。みんな，そんなのも楽にできたらいいなとか，思うんでしょうね。
> ただほど高いものはないとかならないようにしないといけませんね。
はい，「安物買いの銭失い」と並んで，昔から言われてることですから，肝に銘じてないと!! しかし，高いからと言って信用できるわけでないから，困るんですよ（溜息）。