自社のCMSサイト「すぐ使えるCGI」 では、Chrome でアクセスすると SSL（https）になった時に以下のエラーで表示ができなくなってしまう。
2011年の1月頃から発生し、サーバを引越ししてもクライアントマシンを変更してもやはり同じ問題が出る。お客さまからも問い合わせいただく。

Chrome がバージョンアップし「SSL False Start」という通信高速化技術の実装とともに起こったと思うのだが、詳細は不明。

英語のエラーメッセージ 「Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.」で検索すると、2011年末になっても問題が発生している事が分かる。

サイトではCMSの販売までをしているので以下のように案内しているのだが、どうもかなり機会ロスをしているようなので解決方法が無いか調べてみた。
CMS「すぐ使えるCGI」の顧客への案内： Chrome をお使いの方へ【アクセスできない場合】

ちなみに、Chromeのバージョンアップにより上のページで紹介している設定の変更による問題回避はできなくなっている。

いくつか分かった事

SSL証明書の問題ではない

同じSSL証明書ファイルをほぼ同様の Apache 環境に入れてみるとテスト環境ではうまくいくので、今回の場合はSSL証明書やサーバのバージョンが問題では無い。

ちなみに DigiCert のワイルドカード証明書です。GlobalSign のクイック認証SSLでも同じ問題が出ていました。

ServerName の問題ではない

VirturalHost の ServerName の設定を変えたらうまくいったという記事もあったので試してみたが、これは効果が無かった。
http://code.google.com/p/chromium/issues/detail?id=91905

• NG設定１：ServerName をSSL証明書（ワイルドカード証明書）と同じ *.hogehoge.net にして、アクセスするホスト名は ServerAlias に myhost.hogehoge.net と指定する。
• NG設定２：www.sugutsukaeru.jp を ServerName に指定し、アクセス用の sugutsukaeru.jp は ServerAlias にする。
• NG設定３：同じIPの ポート 80 と 443 でデフォルトの ServerName が同じになるように の記載順番を変更。

Googleにお願いというパターン

とりあえず「SSL False Start を使わないサイトのリスト」というものを Chrome は保持しているらしく、そこに入れて下さいと頼むことができる。らしい。
一応「ツール」→「問題の報告」からコメントしてみた。

しかしこれで解決するかは不明。感触としてはNGな気がする（それ以外の問題がある…）。
http://www.google.com/support/forum/p/chrome/thread?tid=4d6386d45dea0dc9&hl=ja

ちなみに、 chrome://net-internals/ からアクセスできるテストツールでは、Fetch https://xxxx/ の行に「FAILED」 「EMPTY_RESPONSE(-324)」と表示される。

ハードウェアとの相性

上と同じURLで言及されているが、ハードウェアにも問題がある場合があるらしい。
（再掲） http://www.google.com/support/forum/p/chrome/thread?tid=4d6386d45dea0dc9&hl=ja

ハードウェアの名前と推奨ファームウェアバージョン情報。（上のページで紹介されている。）
http://www.imperialviolet.org/2011/08/31/falsestartupgrade.html

Brocade ？

上のリンクにも名前が挙がっている、Brocade というハードウェア（すみませんよく分かってません）を使っている時に Chrome が “1/n-1 record splitting” という方式でデータを分割して送るのが問題らしい（すみませんよく分かってません）、という見解あり。
–disable-ssl-false-start で問題が出なくなるのは、TLS False Start 自体の仕様や実装が悪いわけではなく、その時にだけこの方式を採用しているから（すみませんでもよく分かってません）。

http://code.google.com/p/chromium/issues/detail?id=100163

openssl-1.0.0e だとこれには対応していない。（2011年10月13日現在）
http://www.mail-archive.com/openssl-dev@openssl.org/msg29771.html

changelog も見たが、2011年12月4日現在だと対応の記録なし。orz
http://www.openssl.org/news/changelog.html

なんとなくこれがビンゴかなあと思いここで今回の調査終了。サーバサービス会社にハードウェアについて問合せ。

2011-12-18 自サバにおける問題解決

上で「ハードウェアの問題がビンゴか」などと書いていたが、この勘は全く当っていなかった。実際、同じハードウェアで VPS ホスティングされている SSL サイトにアクセスしてみると問題が起きない。

あまりにやいのやいの質問したので、レンタルサーバ会社の方がテストマシンを1週間提供してくれることになった。

サーバ管理ツールと deflate モジュールの衝突

問題の起きているホストは NTT Communications 系の Verio という会社が提供している VPS サービスを最終的に利用しているのだが、そのサービスには CPX という Web インターフェースのホスト管理ツールがある（Webmin みたいなもの）。

CPX は使わなくてもよいのだが（実際ほとんど使っていない）、万一のトラブルに備えて一応 Web の口も開けておこうという発想で有効にしてある。

この CPX 関連のモジュールを httpd.conf でロードしているのだが、これと deflate_module のロードがぶつかるらしい。
ただ、使用そのものに問題があるのではなく、以下の1行を CPX モジュールロードの後に移動してやればOK。

なお、上記の件については再現性があるが、テスト中は httpd.conf を書き換えた前後の内容、再起動の仕方によっては問題発生状況が変わることがあったので、これで本当に解決かどうかはまだ分からない。

独自モジュールとの相性に問題がある事は分ったものの本質的な問題が何なのか辿り着いていないが、それに関してはおそらく情報提供されないので、とりあえずは一息。