結局、紙の手帳に逐次記入部門より。
uxi曰く、"今朝、livedoor wiki にログインしようとして気付いたのですが本日 10/20 の 9 時をもって SSL 証明書の有効期限が切れになってしまったらしく、接続時に警告が表示されるようになっていました。
(参考: SSL モードの livedoor ID 登録)
公式CAを通した証明書は、コストもかかりますから無駄に更新するのも馬鹿げていますが、スケジュールを詰め過ぎてしまうと、今回のように有効期限切れの期間が生ずる可能性があるかもしれません。また、スケジュールに相当余裕を見ていたとしても、更新手続きがスムーズに行かず、スケジュール通りに行かない事もあるかもしれません。
経路の暗号化のみを行いたい場合、独自CAによる証明書を使うことも少なくないと思いますし、
有効期限切れになったからと言って、即 SSL の安全性が大きく揺らぐわけではありません。
しかし SSL がどんな物について理解の浅い世間一般の人には困惑の種になるかもしれません。
さて /.er の皆さんは公私に渉って web サイトの保守管理をしている人も多いと思いますが、
SSL の CA やその有効期限の設定、証明書の更新のタイミングはどうされているでしょうか?
SSL 証明書の運用管理に関してこれまでに遭遇したトラブル等、面白い(?)体験談があれば是非お聞かせください。"
有効期限 (スコア:4, 参考になる)
ドメインと一緒で「今の残り期限+1年」のような形で有効期限が追加されますが? 早めに更新するのを妨げる理由は何もありません。
最近のタレコミひどすぎるんですが、ちょっとやそっとデタラメが書かれてた方が突っ込みのコメントで盛り上がるから編集者はスルーしてそのまま掲載する方針にでもなったんですかね。
編集者が無能なだけだとは思いますが。
スルーちからが足りないのでAC
Re:有効期限 (スコア:5, 興味深い)
そこは実運用したことない人がタレコミしているのでしょうかね。私も自分の担当システムで買うまで知りませんでした。
それより、タレコミ人の「有効期限切れになったからと言って、即 SSL の安全性が大きく揺らぐわけではありません。」という部分が問題かと思います(もしかしたら釣りで書いているのかな)。
タレコミ文の「SSL 証明書の運用管理どうしてますか?」に沿った話をすると証明書をかった時点で次回のお金の手当が必要になるので即来年の予算管理簿に載せるので忘れにくいです。
正直SSLの有効期限の為に管理しているのではなくお金の為ですね;-(
親コメント
ネタでしょう (スコア:2, すばらしい洞察)
「有効期限なんて単なる飾りです。偉い人には(ry」
って言うネタ。
There is no spoon.
親コメント
ネタではないのですが、、、 (スコア:2, すばらしい洞察)
タレコミ人として、一応コメントしときます。
まず、有効期限の意味について。
これは 2 つの意味があるはずです。
・暗号強度による信頼性の問題
・CA のビジネス上の問題
暗号強度について現在の暗号は、難解読性に立脚しており、理論的には全ての暗号は総当たり法により有限時間で破られてしまうはずです。
つまり、SSL の有効期限は、公開してから時間が十分経過しましたから、(解読している奴がいたとすれば)そろそろ解読されてしまう危険性が高くなってきてますよと言う警告です。
これは、あくまでも確率的な話であって、最悪の場合、128 bit キーなら 1/2^128 の確率で公開した瞬間に既に暗号が破られてしまっている可能性だって否定できないわけですが、どうせ確率に立脚している暗号なので、まぁ有効期限の間であれば、確率的には実用上問題にならないと言う目安は立つわけです。
ですから、確率的な話で考える限り、有効期限切れで即、確率的にマズイ状況に陥る事は有り得ません。
CA のビジネス上の問題は、まさにこの点です。
確率的な話をする限り、多少有効期限をオーバーしたところで、
CA の署名さえきちんとしていれば、確率的には SSL 証明書は信頼できるはずです。
では、そもそも、SSL 証明書の信頼性は確率的にはどのくらいなのか?
例えば、ランキングトップのスパコンを持って来たとして、単位時間にどれだけの組み合せを試せるのか?
もっと簡単に言えば、本気でアタックされた場合、 1 年経過した 128 bit の SSL 証明書の信頼性は何ビット相当にまで落ちているのか?
コンピュータの進化を無視した場合、
単純な確率的話で考える限り、もし 128 bit で有効期限が 1 年あるのであれば、
256 bit なら有効期限 128 年相当以上の強度がある事になります。
さて、これで CA のビジネスは成り立つでしょうか?
「今の残り期限+1年」の証明書が発行してもらえると言う話については、
もしこのような証明書で数日前から証明書を入れ替えるのであれば、
有効期限が切れてからその日にゆっくり入れ替えたところで、
暗号の信頼性的には全く問題にならないと言う事になると思います。
uxi
親コメント
Re:ネタではないのですが、、、 (スコア:2, すばらしい洞察)
だからといってビジネス上の都合だというのは穿ちすぎで、他に次の理由があるようです。
- 失効リスト管理の都合
- 実在証明を伴う証明書発行の場合、実在性の保証は短い期限にしておかないと信頼性が低下する
ところで、> 128 bit の SSL 証明書の信頼性は...
RSAなら鍵長は 1024ビットとか 2048ビットあたりですよ。
128ビットというのは共通鍵の長さのことですか。
> もし 128 bit で有効期限が 1 年あるのであれば、
> 256 bit なら有効期限 128 年相当以上の強度がある事になります。
かなり計算が間違っているようですよ。その計算が128年になるのは 135ビットのときですね。
親コメント
Re:有効期限 (スコア:4, 興味深い)
有効期限が「残り期限+1年」のようにしてくれるかどうかは利用しているCAに因ります。
僕自身ではいくつかのCAを利用した経験があるだけですが、更新した瞬間から1年後の証明書を与えられるところは少なくないです。
特にベリサイン等の非常に高価なところは使ったことはあまりなく、年間数10~100ドル程度のところが多いのでそうなのかもしれませんが、「残り期限+1年」というのが普通、という意見には疑問を持ちます。
なので自分の少ない経験だけから見た「普通」を根拠に編集者の無能を語るのは、如何なもんかと感じました。
#ここで、料金+更新時の有効期限の扱いを比較したサイトとか示せれば素敵なんだが生憎すぐには思いつかなかった…
親コメント
Re:有効期限 (スコア:4, 参考になる)
・更新後の期限を、残り期限+1年にしてくれる。(これがCAと利用者ともに一番無駄が無い)
・更新後の期限は、更新のタイミングから+1年。(これは余裕を持って運用するほど利用者が損をする)
・1年で取得すると更新時のダブりを考慮して初めから13ヶ月分の期限を付けてくれる。(ある意味CAが損を被ってくれる形でこれもなかなか好印象)
ってとこですかね。(他のパターンもあるかもしれません)
親コメント
Re:有効期限 (スコア:2, 参考になる)
ただこの運用にも問題があって、期限切れ一ヶ月前から受付で
13ヶ月を足すと更新日がどんどん後ろにずれ込んで行きます。
前回は、3月初めだったので、今度更新するのは3月末になって
しまいます。
独法で4月はじめに予算を使えないので、次々回は更新に
問題が出そうです。
親コメント
Re:有効期限 (スコア:4, 参考になる)
自社サーバー:Comodo
自社サーバー:GeoTrust
自宅サーバー:FreeSSL(現RapidSSL)
を使った事がありますが、どこも残り期限+1年~
にしてくれたかと。
逆に「残り期限+1年」にしてくれないCAって
どこなんでしょうか?
親コメント
Re:有効期限 (スコア:2, 参考になる)
他社から乗り換えの時も残り期限+1年にしてくれる乗り換えキャンペーンもたまに見ますしね。
ここ数年は単独のサイトだとほぼ毎年同じ時期に更新作業すればよくなってるんですが、
複数のサイトが別々の時期に更新になるのが(うっかり忘れそうで)面倒です。
できれば全部予算執行しやすい時期にやりたい、けど数か月分を無駄にするのもどうか、という天秤で
お伺いかけるとほぼ却下されてしまう…
親コメント
そりゃ監視でしょ (スコア:3, 参考になる)
しないさせない!スルー力
Re:そりゃ監視でしょ (スコア:2, 参考になる)
echo "" | openssl s_client -connect ホスト名:443 | openssl x509 -enddate -noout | sed 's/notAfter\=//'
みたいにしたら割と簡単に期限のみのチェックできます。
うちでは上とdateコマンド駆使してタイムリミット日数
監視してます。
でもそろそろhobbitに乗り換えようかな?
BBの時と比べるとアホみたいに有効期限監視が簡単にできます。
bb-hostsの第2フィールドに
# https://www.****.jp
するだけで完了
親コメント
cacert (スコア:2, 参考になる)
http://www.cacert.org/ [cacert.org]
もありますよ。
集団になるメリットもデメリットもありますので、皆さんにお勧めというわけではありませんが、面白い試みだと思います。
重要なのはフィンガープリント (スコア:2, すばらしい洞察)
というタレコミの文を見ていると 独自CA = 信頼できない という図式が脳内に成り立っているように思えます.
独自CAにしろそうでないにしろ,重要なのはフィンガープリントですよね.
旅に出ます.(バグを)探さないで下さい.
トレンドマイクロが公式サービスをオレオレ証明書で運用開始 (スコア:2, 興味深い)
ウイルスバスターでお馴染みのセキュリティ会社大手トレンドマイクロ [trendmicro.co.jp]は、ネットワーク層での動的なスパムメール防御を実現するサービス「Trend Micro Network Reputation Services [trendmicro.com]において、この10月から新しく管理用Webポータルをスタート [trendmicro.com]させた。これによると、ログイン画面は https://nrs.nssg.trendmicro.com/ [trendmicro.com] とされているのだが、これをクリックしてみると、オレオレ証明書の警告が現れ、正常にアクセスできない状態だ。使われている証明書の内容は以下の通り。
典型的な自己署名証明書だ。こんな素人同然の会社に私たちや社会の安全を任せられるのか、その対応が問われそうだ。Re:トレンドマイクロが公式サービスをオレオレ証明書で運用開始 (スコア:4, 興味深い)
なのでとてもではないがTrendMicroの(少なくとも)webシステムは信用できるものではないと思っています。
# 製品トラブルやアップグレード関係でサポートに問い合わせても嘘教えてくる事多々あるしね…
# rm -rf ./.
親コメント
ルートも (スコア:1, 興味深い)
使えるルート証明書がなくなるまえにブラウザ更新しないとね。
Re:ルートも (スコア:2, すばらしい洞察)
でも、以外に有効期限が短いものもあるんだよね。
親コメント
Re:ルートも (スコア:2, 参考になる)
FYI: オレオレ証明書とは [hatena.ne.jp]
# rm -rf ./.
親コメント
Re:ルートも (スコア:2, 参考になる)
http://cspssl.jp/support/install.html [cspssl.jp]
親コメント
有効期限切れなんて (スコア:1)
そういった点も考慮してCAを選ぶ方が後のためですよね。
タレコミ子の真意は?? (スコア:1)
SSLの証明書は、90日前から更新を受け付けてくれるCAだってあるし、ぎりぎりまで更新しないことはないですね~(お客さんの環境を含め20コくらい毎年更新してるけど)。
もし、ぎりぎりまで更新しないとしたら・・・
「お財布事情が厳しいから、支払いをぎりぎりまで延ばしたい」という大人の事情とか「忘れ去られたSSL(要は誰もアクセスしていない)で必要性も低い」場合ですかね。
いずれの場合でも、期日前までには更新 or サイトの破棄 を決定しますね。
Re:タレコミ子の真意は?? (スコア:3, 興味深い)
livedoor SSL サービスの一部休止のご案内 [livedoor.com]。
2006年10月20日をもって発行の受付休止です。
だったらなおさら早めに更新しとけばいいのにとも思いますが。
親コメント
Re:職場での話 (スコア:1)
よくやらかす。。orz。
いや、切れる前にさ申請してくれよ!(ぉ
ごめんなさい、ごめんなさい、ごめんなさい。
親コメント
Re:遭遇したトラブル (スコア:2, すばらしい洞察)
独自CAと、サービスに利用する自己署名証明書を混同している気がする
正しく運営している独自CAなら商用CAと技術的には同じですよ?
独自CAを正しく運営するぐらいなら格安証明書買った方が安いとも思ようにもなったけど。
親コメント
Re:遭遇したトラブル (スコア:1, 参考になる)
ここんとこが分かってない意見に、
オレオレ証明擁護派、撲滅派を問わずよく遭遇するね、
いまだにスラドでも。
ブラウザのルート証明書だって、
前もって持っているルート証明書を信用できることが前提なのに。
ブラウザと一緒に手に入れたルート証明書ならブラウザの、
OSと一緒だったらOSの、入手経路が信頼できるかどうか、
オレオレ証明書と同様、よく考えて使わないとね。
親コメント
Re:先生、質問です。 (スコア:2, 参考になる)
> 「mod_ssl」などでは、そういった設定は、可能なのでしょうか?
DHE-RSA-* の設定を選べば使えるんではないですかね。
ざっと調べたところではあまり普及していないようなのですが、なぜなんでしょう? SSLアクセラレータが対応していないとか?
> あと、気になるのは、メールサーバとの通信や LDAP、
> 無線LANの認証の通信などでも SSL を使うと思うけど、
> web 以外の分野でも「おれおれ証明書」などの問題って
> 議論されてるのでしょうか?
同様に問題であるはずですが、メールサーバの場合はオレオレ証明書が使われていても「脆弱性」として指摘する人は今のところいないようですね。元々メールは暗号化なしで送受信しているので、ないよりはましということで済まされてしまうのでしょうかね。もし、ISPがメールサーバを「SSL暗号化通信で安全」と謳っているなら、脆弱性として指摘できるでしょうけども。
親コメント
DH生活 (スコア:2, 参考になる)
>DHE-RSA-* の設定を選べば使えるんではないですかね。
最近のOpenSSLだと暗号化スイートとして DHE-RSA-AES256-SHA 最優先というのが標準設定なので、
サーバapache, クライアント Opera みたいな双方OpenSSL依存プロダクトのような状況であれば
勝手に Diffie-Hellman 鍵交換が使われています。
でも世の中IEの割合が多いわけで、
IE6だと RC4-MD5, IE7ですらAES128-SHA にしかならないのでは
サーバ側ではどうしようもなく普及するわけもなし。
# Opera9 生活中
親コメント