カテゴリー
Windows

覚え書-#26。

The same article in English

 HTTP/2 にかまけているけれども, MariaDB 10.1.8 のインストールについても書いておこう。アップデートではないよ。 PHP5.6.15,phpMyAdmin4.5.1,ActivePerl-5.20.2.2002 も昨日まとめて面倒見たので,それについても触れておく。

  • MariaDB 10.0.21 —>> MariaDB 10.1.8 Changelog

    まずは,全データのバックアップ。特に, MariaDB と MyDB ね。その後,普通にアップデートしたのだが,こんなエラーが出て, SQL サーバは起動しなかった。見ての通り, ‘x:MyDBbinmysqld.exe: ready for connections.’ という行もあるのだが……。くりくりさんも同様のエラーが出たことをブログに書いておられた。ほかにも 10.0.21 から 10.1.8 へのアップデートでは,同じ経験をした人が複数いるようだ。 ☞ MariaDB 10.1.8 crashes at startup

    そんなわけで, MariaDB と MyDB を削除して, MariaDB 10.1.8 を新規にインストールすることにした。起動すると,今度はエラーもなくスタートでき,シャットダウンもうまくいった。エラーログに ‘Dumping buffer pool(s) not yet started’ という一文があったので,下記の 2 つを my.ini 上で ON にした。 ☞ Dumping and restoring the buffer pool

    • innodb_buffer_pool_load_at_startup = ON
    • innodb_buffer_pool_dump_at_shutdown = ON

    ON にしたら,エラーログに InnoDB: Buffer pool についての記述が増えた。

    再度,サーバを起動。 root のパスワードを設定するために, cmd.exe でサーバに接続する。

    1. mysql -u root
    2. SET PASSWORD FOR root@localhost=PASSWORD('password');
    3. quit

    phpMyAdmin から root として,ログオン。この時点では, phpMyAdmin からの control user 関連のエラーが出ているかもしれないが,以下の操作を行えば,それらは消えるはずなので,気にする必要はない。

    1. 前サーバと同じユーザを作る。各ユーザの特権は,バックアップした sql ファイルからインポートする。
    2. phpmyadmin データベースを作り,バックアップファイルからデータをインポートする。これは, control_user を前サーバ時と同じにするための作業である。
    3. ほかのデータベースも作成し,データをインポートする。うちの場合は, WordPress 用が 1 つあるだけなんだけどね。
  • PHP5.6.14 —>> PHP5.6.15 (Changelog)
  • phpMyAdmin4.5.0.2 —>> phpMyAdmin4.5.1 (Changelog)
  • ActivePerl-5.20.2.2001 —>> ActivePerl-5.20.2.2002

 MariaDB 10.1.8 以外のものについては,何もトラブルはなかった。

 以上。

 そういえば, 10/22 ごろに o6asan.com を Chrome’s HTTP Strict Transport Security (HSTS) preload list に入れてくれるように hstspreload.appspot.com からリクエストを送った。順番待ちリストに入りますということだったのだが,本日,リスト上で o6asan.com を発見したよ。

「覚え書-#26。」への8件の返信

おはようございます。

おお、一気にやったんですね。
来週あたりにphp7とwordpressの対応バージョンでますからこちらものこっていますね(笑)

まぁでもphp7のRC6でwordpressをためしましたが、
まったく表示できなくなると本当にwordpress大丈夫かどうか不安です。アルファバージョンはある程度のエラーですんだんですが、RCバージョンは全然ですからね。

くりくりさん,こんにちは。

> おお、一気にやったんですね。
こっちのほうは,あっさり終りましたけどね。 HTTP/2 のほうが未だしです。

くりくりさんのところは, Chrome’s HTTP Strict Transport Security (HSTS) preload list に登録してないみたいですね。登録すると,削除してもらうときにまた面倒かなと思いましたが,勢いで登録してしまいました(汗)。 max-age=63072000; は長すぎるでしょうか。ほぼ 2 年です。

ところで, preload list は別として, HSTS を設定すると, SSL LABS のサーバテストは, A+ になるんですね。昨日やったら,こんな感じでした。それから Certification Paths の Path #1: Trusted のところに Weak or insecure signature, but no impact on root certificate が出てるんですが, Windows10 x86 上の Google Chrome はこれも判断に使うのか,カギマークが出ないんです。 Windows10 x64 のほうだと,ちゃんとカギが出てくるんですが,どういう仕様の違いなんだろう??? SHA1withRSA が使われているのは,一番上の ROOT のみたいです。

> アルファバージョンはある程度のエラーですんだんですが、
> RCバージョンは全然ですからね。
WordPress のほうも 4.4 が出るようですから,それで改善するかも……。

おはようございます。

HSTSはnginxのconfファイルに設定してあるので
特には何もしていません。後は勝手にブラウザがhttpsで接続するのできにしてませんでした。
googleもhttpsにした場合はHSTSを有効化を推奨していますしね。

>ちゃんとカギが出てくるんですが,どういう仕様の違いなんだろう???

期限ぎれの証明書、脆弱性が暗号ハッシュ、混在コンテツンツと色々httpsで問題があるサイトも多いのですがユーザーの方が混乱するらしく鍵マークの警告を色々いじってるみたいです。最終的には2週類くらいにするとかそんなchrome開発者の記事をよみました。なんかやっているのかもしれませんね。

>SHA1withRSA が使われているのは,一番上の ROOT のみたいです。

私の記事をお読みだと思いますが、
sha1証明書の使用期限は来年いっぱいですが
それは中間証明書と末端証明書の話。
root証明書は独自の検証してるらしく問題ないとのことです。

>WordPress のほうも 4.4
11/12にphp7対応バージョンをとかいっていたんですが4.4のメジャーバージョンで対応させるのかな?
4.4は12月に出すみたい話をmake.wordpress.orgで前読んだんですけどどうなるんだろ。

来年の乗り換えで会社のサーバーの方もいっきにphp7にしたいのですが、結構バージョンアップしていないwordpressもあるみたいなのでバージョンアップをまた煽らないといけないかな。
php7のバージョンアップができない。
wordpressの管理できないのなら消せばいいのに。

くりくりさん,こんにちは。

> googleもhttpsにした場合はHSTSを有効化を推奨。
ええ,だから勢いで, Chrome’s HTTP Strict Transport Security (HSTS) preload list に登録しちゃったんですよね。bootstrap MITM vulnerability対策になるらしいし。

> なんかやっているのかもしれませんね。
何をやっているんでしょうか。

> root証明書は独自の検証してるらしく問題ないとのことです。
これは, SSLLABS でも Weak or insecure signature, but no impact on root certificate となっててそうらしいです。結局,表示の違いにかかわっているのは,中間証明書のようです。しかし,実際に,ブラウザで表示される証明書のチェーンを見てみるとなかなか不思議なものです。

Windows10 x86 上の Chrome カギが表示されないWindows10 x86 上の Chrome カギが表示されない Windows10 x64 上の Chrome 緑色のカギWindows10 x64 上の Chrome 緑色のカギ
Windows10 x86 上の Firefox 緑色のカギWindows10 x86 上の Firefox 緑色のカギ Windows10 x64 上の Firefox 灰色のカギWindows10 x64 上の Firefox 灰色のカギ

上記だけを見るとカギが表示されなかったり,灰色になったりする理由は納得いく気がするのですが,問題は,自鯖に載っている中間証明書は一種類ということなんですよね。どうしてこんな違いが出るんでしょうか。検証方法が違っているんでしょうか。

> wordpressの管理できないのなら消せばいいのに。
本体にしろ,プラグインにしろ,旧いのが交じっているとアップグレードが骨ですからねぇ。

今晩は

>証明書のチェーンを見てみるとなかなか不思議なものです

会社はwindows7 32bitpro,家は64bitproです。
やはり、chromeで同じ現象がでていましたが、
いつの間にか直っています。

特にどうこうしたことはありません。
ルート証明書はかわらず
クロスルート証明書なんかよんでいるのかな???
なかなか不思議な現象ですね。
自分は警告マークが紛らわしいのでchromeの鍵アイコンを2種類くらいにするという記事をよみました
その影響かなとおもったんですけどね。
https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1

あんまり意味ないかもしれないけど、他のインストールチェッカをためしてみるのもいいかもしれません?
http://valuessl.net/support/checker.php

くりくりさん,こんばんは。

ありがとうございます。
実は,何故だかを,見つけました \(^o^)/。
夕食後,くりくりさんのお返事も気づかぬまま,自分の書いた「検証方法が違っているんでしょうか。」という文言にインスパイアされて,ネットを調べておりましたのですが,どんぴしゃりのものを発見しました \(^o^)/x2。 ☞ Chrome uses SHA1 intermediate from Microsoft trust store instead of SHA2 sent by the server, results in false “outdated security settings”

Chrome の仕様が問題のようです。上記表題は,”outdated security settings” となっていますが,今回の場合は期限切れではなく, SHA1/SHA2 の問題でして,ブラウザのストアを調べたら, SHA1 の sub.class1.server.ca.pem がありました。サーバが SHA2 の中間証明書を送っているにもかかわらず, Chrome がこれを見ていたために,先の事態が起こったものです。この SHA1 を削除したら,ちゃんとカギが出ました。

x64 の Firefox も似たようなことのようで,何種類もの StartCom Class 1 Primary Intermediate Server CA が認証局証明書のストアにあり,本来は新しい SHA2 のものを使ってくれないといけないのに,どうしても SHA1 が使われてしまっていました。結局,すべての StartCom Class 1 Primary Intermediate Server CA を削除し, Windows10を再起動したのち,改めて o6asan.com にアクセスしたら,やっと, SHA2 のものを使ってくれるようになりました。

中間証明書の形式は,過渡期ですよね。 Apache2.4.8 から「SSLCertificateChainFile is deprecated」となっていたので,今回は, Apache でも連鎖証明書を作りました。しかし,まだまだ,中間証明書は,別に送られ,あるいは,ブラウザのキャッシュが優先されるということが多いのでしょう。

中間証明書だけが,汚染されるということは,十分あり得る話だなと,今回の経験で感じましたよ。しかも,気づかないかもしれません。連鎖証明書のほうが安全と言われる所以ですね。

ふと,思いましたが,無料の証明書はやはり対応が遅れるとか悪いとかが,ブラウザベンダーにもあるのかもしれません。

おはようございます。

解決して何よりです。

来年あたりにsha1がおわるのでそのときまた問題になりそうですね。でも、エンドユーザーの方はきがつかないまま終りそうな問題ですけどね。

>無料の証明書
wordpress4.4も常時sslサイトを加速させるよ仕様だし、バリュードメインもSNI対応とかなってるので無料を使う人がおおくなるでしょう。
startssl,会社サーバーでも使用しようと思ったんです。しかし、怖くて使えないんですよね。
サーバー用のホストネームにつかってるけど、俺しか使わないので問題ないんですが、いつつかえなくなるかわからないしhttpsからhttpにリダイレクトするのみつかってるくらいです。

くりくりさん,こんばんは。

> エンドユーザーの方はきがつかないまま終りそうな問題ですけどね。
これがある意味怖いですね。気づかないままで今回のようなことが起こると,自分では strong な鍵を使っているつもりなのに,実は weak なままの古い鍵がつかわれたりして。

ところで,この件を追記に書きました。ここです。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です