[2017/10/20 時点の話] ApacheLounge 2.4.x 版でも mod_md が使えるようになったので、 dehydrated ( 旧 Letsencrypt.sh) の代わりに、今はこれを使っている。この件に関する記事→「Let’s Encrypt 証明書の更新方法を dehydrate から mod_md に」。
========================================================
10/7 に SSL Server Test でテストをやったとき，「OCSP Must Staple Not Supported」という項目があるのに気付いた。古いテスト結果を見直してみたら，そこにもすでに「OCSP Must Staple Not Supported」があった。この話をコメント欄でくりくりさんとしたのだが，話は広がって， Extended Validation(EV), CHACHA20, Certificate Transparency(CT) なんちゅうことも話した。しかし，この 3 つは今のところ，自鯖では不可能。まず， EV は高い（笑）。 CHACHA20 は，公式の Apache ではすでにサポートされているのだが， Apache Lounge の 2.4.23 ではまだなのだ。使いたかったら，サポートバージョンを自力でビルドしないといけないのだが，私にとって Windows 上のビルドは相変わらず難しい。 CT はまだ Apache でサポートされていない。
とはいえ， TLS の環境をいくつか弄ったので，それについて書いておく。
[1 OCSP_MUST_STAPLE]
dehydrated (旧名 letsencrypt.sh) は config に ‘OCSP Must Staple’ オプションがあったので，そこを直して，証明書を force-renew した。
書き換えるところ。
#OCSP_MUST_STAPLE="no" ↓ OCSP_MUST_STAPLE="yes"
LetEncryptsh.bat の下記の行を書き換えて使ってやると，楽チン。
bash --login -i -c "/usr/local/letsencrypt.sh/letsencrypt.sh -c" ↓ bash --login -i -c "/usr/local/letsencrypt.sh/letsencrypt.sh -c -x"
でもって， LetEncryptsh.bat を走らせる。終わったら，上記の行は元に戻しておく。
このついでに， ‘ECDHE-RSA-AES256-SHA’ を SSLCipherSuite から削り， SSLProtocol のサポートも TLS1.2 だけにした。この時点の SSL Server Test 結果。
[2 ECDH (Elliptic curve Diffie–Hellman)]
dehydrated の config を見直しているときに， public key algorithm のオプションがあり secp384r1 が含まれているのに気付いた。そんなわけで，鍵交換に ECDH を使うことにした。
始める前に，自鯖の OpenSSL が secp384r1 をサポートしているかのチェック。
cmd.exe を起動。
>pushd /pathto/Apache24/bin
>openssl ecparam -list_curves
(snip) secp384r1 : NIST/SECG curve over a 384 bit prime field (snip)
config の変更点。
#KEY_ALGO=rsa ↓ KEY_ALGO=secp384r1
LetEncryptsh.bat を走らせて force-renewal。
ちゃんと ECDH 証明書ができたか確認しておこう。 cmd.exe を起動。
>pushd /pathto/Apache24/bin
>openssl ec -in /pathto/server.key -text
read EC key Private-Key: (384 bit) priv: (snip) pub: (snip) ASN1 OID: secp384r1 NIST CURVE: P-384 writing EC key -----BEGIN EC PRIVATE KEY----- (snip) -----END EC PRIVATE KEY-----
この時点の SSL Server Test 結果と SSLCipherSuite。
[3 Cipher Strength は少なくとも 256-bit]
SSLCipherSuite を変更。 Mozilla modern profile を下記のように変更してみた。
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 ↓ SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384
Apache をリスタート。
この時点の SSL Server Test 結果。
[4 ECDH kx 384-bit かつ Cipher Strength は少なくとも 256-bit]
以下の 2 行を ssl.conf に加える。
SSLOpenSSLConfCmd ECDHParameters secp384r1 SSLOpenSSLConfCmd Curves secp384r1
Apache をリスタート。
この時点の SSL Server Test 結果と SSLCipherSuite。
[5 ECDH kx 384-bit]
SSLCipherSuite を下記のように変更。
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256
下記の 2 行は ssl.conf に追加したまま。
SSLOpenSSLConfCmd ECDHParameters secp384r1 SSLOpenSSLConfCmd Curves secp384r1
Apache をリスタート。
この時点の SSL Server Test 結果。
で，この 5 番目のコンフィグを今使っている。
「Windows で Letsencrypt.sh を使う-#4」への15件の返信
これ結構大変だったんじゃないですか？
自分のためにブログに100点取る方法をのせておいたのですが、やるきがなくてそのままです。
bindやvsftpもコードからインストールに変更しようとおもうのですがこちらもやるきが・・・。
sslでもえつきちゃいました。
そこそこです。 SSLLABS の結果の時間を見てもらうと分かりますが， 3 ・ 4 時間の仕事です。 HTTP から HTTPS に移行するのときに，一気にやるのだったら，大変でしょうけど，うちにしても，くりくりさんのところにしても，あらかた済んでますから。もっとも， 100 点のコンフィグは，営業サーバでは現実的でないです。 Test_o6asan_com6 のときに，「赤がいっぱいありますけど」とくりくりさんが心配されてたような事態になりますから。 Test_o6asan_com9 の場合も 6 と傾向は違いますが，締め出しの数は似たようなものですから。
どの辺を制限してやったら， 100% になるかということについては，参考 URL に挙げている 2. の Matthias Wächter と 3. の Rob Moss の書き込みがありがたかったです。
くりくりさんも触れてらしたようですが， CT について， Announcement: Requiring Certificate Transparency in 2017 が Google から出ましたね。有料のところでは，今のところ，「CTの仕組み」にあった X.509v3 Extension とかホワイトリストで， CT に対応してるんでしようね。
Google のアナウンスが出ると Dev の方はスピードが上がりますから， Apache なんかも 2.5 のリリースが早くなるんじゃないですか？まだ， 2.4 すらあまり普及してないのに（苦笑）。
そういえば， Ivan がこんなこと書いてました。こちらも近々なんでしょうか？
おはようございます。
CTの件は正直まいっています。
let`s encryptで対応してもらえるのならそれが一番楽かな。tls extensionになるとこっちが大変だからやめてほしい。
>2.5 のリリースが早くなるんじゃないですか？
2.2がマイナーバージョン31。
2.4が23と結構でています。
2.2の終わりが2017年6月30。パッチ提供が年末。
その辺をしっていてchromeが発表しているのかもしれませんな。まーた覚えることが増えそうだ。
>Ivan
次にRFC化して実装はRFC化半年後くらいでしょうな。
来年には使えるようになるとおもいます。
こっちもまた勉強しないとｗ
くりくりさん，こんばんは。
急に寒くなりました。そちらはいかがですか？
> let`s encryptで対応してもらえるのならそれが一番楽かな。
どうなんでしょうかねぇ。今のところ，こういうスタンスですよね。この対応があるから， nginx-ct や mod_ssl_ct で TLS extension が使えるわけですし。でも， Certificate Transparency を読むと， TLS extension の格納の方が，過去の実装との違和感が少ないように思えませんか？今後，どうなるんでしょうか？
おはようございます。
こちらも急に寒くなりましたよ。
風邪ひかないように注意しないと・・・。
ほとんど証明書の拡張機能をつかって
tls extensionはかなりレアになるとおもいますよ。
サーバー管理者を対象としてるし、ct-submitコマンドも必要だし、俺は自分のサイトとgoogleしかみたことありません。
ocspステイプリングなんか存在するのかな？
くりくりさん，こんばんは。
ついに，炬燵を出しました。お山の紅葉も見に行ってみましたが，未だし，という感じでした。見ごろは，来週くらいかな？
> tls extensionはかなりレアになるとおもいますよ。
まぁ，今のところ， nginx-ct にしろ mod_ssl_ct にしろ，自前でビルドしないといけないわけですし， EV が EV として Chrome に認めてもらえないと困る大手が早々と対応しているんでしょうけど， nginx-ct や mod_ssl_ct が Core に含まれるようになれば，状況は変わってくるんじゃないですか？ Google は EV じゃないとこにも CT を求めようとしてるわけだから。
ところで， TLS Extension は私もくりくりさんとこと， Google と certificate-transparency.org でしか見てません。もっとも， certificate-transparency.org は Google みたいなものですね。 OCSP Stapling は, 1 か所だけ見つけました。 ritter.vg です。 Tom Ritter のサイトみたいです。全然知りませんでしたが，著名な方のように見えます。
おはようございます。
>炬燵
うちも灯油かってこないといけません。
じわじわと油の値段があがってきていますのでね。
早めにほぞんしておかないと
>見ごろは，来週くらいかな？
うちのほうはまだですよ。11中旬くらいかな。
日光とか有名どころが終ったり始まったりしています。
>状況は変わってくるんじゃないですか?
個人的にはすごーくやりたくないんですけど・・・。
どうなるのか不安だー。
そして、chromeの発表にたいするapacheやnginxのリアクション。反応があってしかるべきだとおもいます。
chromeの仕様もきになります。
どのくらいの警告なのか？
これは7月か8月くらいのカナリアをみるしかないのかな。
個人的にはあのふたりがやめてくれればいくらでもTLS extensionやってもいいんですけどね(笑)
>OCSP Stapling
すげえええええ。OCSPとかいてる。
よくみつけましたね。
くりくりさん，こんばんは。
いい天気でしたが，今日も，寒かったです。
> じわじわと油の値段があがってきていますのでね。
ガソリンもだんだん上がってますよねぇ。
> これは7月か8月くらいのカナリアをみるしかないのかな。
なんか，スズキさんのところでカナリア絡みでチラと読んだ気がしますが……日本語の例は出てなかったんでしたっけ。
> OCSPとかいてる。
でしょ。ブログの記事も興味深かったです。難しすぎでいまいち理解不能なところが多かったですが。
I-O DATA のポケドラの話とか， Windows カーネルにおける未修正の脆弱性の話とか， 一般ユーザにも関係ありそうな脆弱性が目白押しですね。ハ～ア。
ところで，おまけですが， Gigazine でこんなのみて，すごいなぁとか思いましたヨ。
おはようございます。
昨日調べてみたら
スズキさんの所はsslにしなかった場合の警告。
CTについては特に。
EVSSLが緑じゃなくなった例をみるとなんかしらのやるんでしょう。
>windows
windowsの対応に
googleが遺憾とかいってました。googleが使うのはじめてみました。
>Gigazine
ファーストサーバーもここに依頼したらなおったかも？ｗ
くりくりさん，こんにちは。
> sslにしなかった場合の警告。
あっ，そうでしたか。うろ覚えで書いてごめんなさい。なるほど，こちらを見ると EV 関連ですね。しかし，これも，だんだん DV, OV についても求められて来て，似たような警告が出るようになるんでしょうか？
> ファーストサーバー
ありましたねぇ，そんなのが。改めて調べてみたら， 2012.6 ですね。ついでに， ASCII の特集記事で，「データ消失事故から2年！ファーストサーバ、再生への第一歩」というのを見つけました。特集自体がすでに 2 年くらい前のものですが，大変，自身の啓蒙になりました。ナショナルジオグラフィックチャンネルの番組で，「メーデー!」というのがありますが，何か起きたときの対応状況のドキュメンタリーって，他山の石となすべき情報に満ち満ちてますね。
おはようございます。
教えて頂いたの試してみたんですが
会社はwin7の32bitなんでvmplayerが古いバージョンしか対応してません。それにインストールすると上手く動かない。
isoファイルを持って帰って試すしか方法ないみたいです。
>警告
SEOのほうはモバイルが検索の主体になるからhttpsもきびしくなるんだろうな。これもその一環になるだろうけど、
時間をかけてゆっくりでしょうね。
追記、mariadb10.1.19が来ていましたよ。
それに博多駅前の陥没事故すごいです。
うちみたい田舎じゃ地下鉄ないからいい所下水がどうとかの程度です。
まぁこれを書いてる今現在。
海外のデータセンターにつないである上位キャリアでネットワークの障害が発生。
こちらじゃなんもできません。
自体の推移を見守るだけです。
昨日の書き込みには，返信せずじまいですみません。
昨日は，お山に紅葉狩りに行ってきました。全山紅葉とはいきませんでしたが，そこそこ，色づいていました。画像は，銅鳥居の横の木を撮影したものです。
> 博多駅前の陥没事故
うちも田舎ですから，地下鉄の工事など関係がありませんが，そういう工事って，大概用心しいしい作業しているでしょうに，何があったんでしょうか？死傷者がいなかったようなのは，不幸中の幸いでした。しかし，水道・ガス・IT など，地下に埋まっているものはたくさんですから，復旧に時間がかかりそうですね。
> ネットワークの障害が発生。
それは!? 解決しましたか？結構，時間を要するものかもしれませんが。
まりあちゃん，ありがとうございます。帰宅したら，頑張ってみます。
おはようございます。
紅葉きれいですね。
うちののほうも色づき始めました。
しかし、この寒さでもう紅葉の秋より寒さの冬です。
障害はこちらではどうにもならんし仕方ないです。
そして、WoSignとStartComは駄目になってしまいました。
WoSignの方はブログに注意書きしておかないと。
くりくりさん，こんばんは。
> この寒さでもう紅葉の秋より寒さの冬です。
そうですか，うちの方もここのところ， 10℃前後です。
> WoSignとStartComは駄目になってしまいました。
Firefox が準備中のアナウンスをしたのが 9/27 ごろでしたから， 1 か月ちょっとですね。 DigiNotar 事件を思い出しますが，沃通(WoSign) はハッキングで悪用されたとかじゃないですからねぇ。 CAブラウザーフォーラムの基本要件に違反とか，他のフォーラム員も看過できないですよね。