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 = ONinnodb_buffer_pool_dump_at_shutdown = ON
ON にしたら，エラーログに InnoDB: Buffer pool についての記述が増えた。
再度，サーバを起動。 root のパスワードを設定するために， cmd.exe でサーバに接続する。
mysql -u rootSET PASSWORD FOR root@localhost=PASSWORD('password');quit
phpMyAdmin から root として，ログオン。この時点では， phpMyAdmin からの control user 関連のエラーが出ているかもしれないが，以下の操作を行えば，それらは消えるはずなので，気にする必要はない。
- 前サーバと同じユーザを作る。各ユーザの特権は，バックアップした sql ファイルからインポートする。
- phpmyadmin データベースを作り，バックアップファイルからデータをインポートする。これは， control_user を前サーバ時と同じにするための作業である。
- ほかのデータベースも作成し，データをインポートする。うちの場合は， 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 以外のものについては，何もトラブルはなかった。
以上。
「覚え書-#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 となっててそうらしいです。結局，表示の違いにかかわっているのは，中間証明書のようです。しかし，実際に，ブラウザで表示される証明書のチェーンを見てみるとなかなか不思議なものです。
上記だけを見るとカギが表示されなかったり，灰色になったりする理由は納得いく気がするのですが，問題は，自鯖に載っている中間証明書は一種類ということなんですよね。どうしてこんな違いが出るんでしょうか。検証方法が違っているんでしょうか。
> 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 なままの古い鍵がつかわれたりして。
ところで，この件を追記に書きました。ここです。