
SSL 証明書の運用管理どうしてますか? 83
ストーリー by GetSet
結局、紙の手帳に逐次記入 部門より
結局、紙の手帳に逐次記入 部門より
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ビットのときですね。
すみません、、、 (スコア:1)
ですね。おもいっきりボケてました、、、orz
1 bit 増える毎に強度が 2 倍になるので、128 倍なら +7 bit で十分ですね。
uxi
Re:ネタではないのですが、、、 (スコア:1)
解析速度が一定ならそうなりますが、
ムーアの法則によれば18ヵ月で処理速度が倍になるラシイので、128年後は2^85倍の速度になるのでそれを加味する必要があるかと。
#ムーアの法則は崩れかけてますが、Dual/QuadコアとかCELLとかそっち方面にいってるので「1CPUあたりの処理速度」ではなくたとえば「(物価補正後)100万円あたりの処理速度」で考えればしばらく当てはまるのではないかと
Re:有効期限 (スコア:1, 参考になる)
ドメインが同時に切れたとしても取得しなおすにも日数は置かないといけないし、まぁ、実用的なところでいうと即揺らがせるのは不可能ではないが難しい。不安なのには違いない。
電子メール(S/MIME)の場合は有効期限切れ近くで出したメールはあとから読むとき有効期限が切れていることもあるから、署名用の証明書の期限はサーバ用より長くしたり、どうにかならないものかな。
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年にしてくれる乗り換えキャンペーンもたまに見ますしね。
ここ数年は単独のサイトだとほぼ毎年同じ時期に更新作業すればよくなってるんですが、
複数のサイトが別々の時期に更新になるのが(うっかり忘れそうで)面倒です。
できれば全部予算執行しやすい時期にやりたい、けど数か月分を無駄にするのもどうか、という天秤で
お伺いかけるとほぼ却下されてしまう…
Re:有効期限 (スコア:1, すばらしい洞察)
Re:有効期限 (スコア:1, すばらしい洞察)
比較したサイトもいいですが、実際にあなたが利用したCAへのリンクを紹介するだけで十分意味があるのではないですか?
そりゃ監視でしょ (スコア: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
するだけで完了
Re:そりゃ監視でしょ (スコア:1)
ハードウェア障害なんかと違って、いつ期限切れになるかはわかってるんだし。
Re:そりゃ監視でしょ (スコア:1)
一括申請してたもんだから10サイトくらい同時に切れる直前に遭遇。
大慌てでGeoTrustの担当にメール直撃した記憶があります。
証明書関連はドキュメント残しておいて欲しいです。orz
... from rakehelly programmer.
cacert (スコア:2, 参考になる)
http://www.cacert.org/ [cacert.org]
もありますよ。
集団になるメリットもデメリットもありますので、皆さんにお勧めというわけではありませんが、面白い試みだと思います。
Re:cacert (スコア:1)
CACertを皆さんにお勧めしているわけではありません。
オレオレ証明で遊んでいる人には、良いおもちゃがあるよ、と紹介してみたのです。
「証明書の運用管理」とはオフトピだったかもしれませんね。すみませんでした。
Re:cacert (スコア:1, 興味深い)
ImportRootCert [cacert.org] には RootCert の正当性を確認する方法としてのフィンガープリントの入手方法がいくつか載ってる。例えば「GPGでサインされたメール(GPGサインの正当性はWOTで確認)」「CACertのイベントでの確認」「(ドイツの?)Linux Magazinなどの印刷物」といった感じ。Debian ではパッケージでも配布されている(信頼性はほかのDebianパッケージに準じる)。
個別ユーザの信頼性はPGPみたいな信頼の輪モデル(WOT)や信頼できるサードパーティ(TTP)などを応用したポイントシステム [cacert.org](CAP)でやっているようだね。ある程度以上のレベルには Photo ID の提出も必要みたい。
個人的には、自分が信用できないオレオレ証明書をいくつも受け入れるよりは、こういう「一箇所確認すれば済む」ものを使ったほうがましな気はする。
現時点ではクライアント側でも RootCert の信頼性を自分で確認できるレベルの人じゃないとお勧めできないし、WOT/CAP がどの程度正しく運用されているかどうかは分からないけどね。でも素人集団というのは無いと思うよ。
Re:cacert (スコア:1)
みんなのために1枚だけ買う、その費用さえ出費できないんですかね。
それとも、自分達だけで完結することが目的なんですかね。(なんのために?)
あるいは、サイトが改竄されたりサーバ証明書の鍵が流出する危険があるから必ず紙で確認するべきだ、といった考え方なんでしょうかね。
重要なのはフィンガープリント (スコア:2, すばらしい洞察)
というタレコミの文を見ていると 独自CA = 信頼できない という図式が脳内に成り立っているように思えます.
独自CAにしろそうでないにしろ,重要なのはフィンガープリントですよね.
旅に出ます.(バグを)探さないで下さい.
Re:重要なのはフィンガープリント (スコア:1)
フィンガープリントが信頼できるなら独自CAでも信頼できるよね,といいたいだけです.
旅に出ます.(バグを)探さないで下さい.
Re:重要なのはフィンガープリント (スコア:1, すばらしい洞察)
独自CAのフィンガープリントが?
勝手に後半部分を切らないでくださいよ。
Re:重要なのはフィンガープリント (スコア:1)
それでも,さすがに秘密鍵の流出などを考えるとフィンガープリントだけではどうしようもないですね.
旅に出ます.(バグを)探さないで下さい.
Re:重要なのはフィンガープリント (スコア:1)
不特定多数に対する責任を負うには経費がかかりすぎるので
それなりの認証局に発行依頼した方がコストがかからないって事になります
公開鍵の流通ルート/確認の為のフィンガープリントの流通ルート/各鍵管理を含めて保証するのは大規模になればなるほど一苦労です
フィンガープリントにしても、偽の証明書と偽のフィンガープリントがペアで出回ったら終了になりますからねぇ
トレンドマイクロが公式サービスをオレオレ証明書で運用開始 (スコア: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:ルートも (スコア:1)
>使えるルート証明書がなくなるまえにブラウザ更新しないとね。
ブラウザごと更新しなくても、
ルート証明書だけを入れ替える方法もありますね。
やっぱり面倒ですか?
Re:クラッカーの独り言 (スコア:1)
もっと別のやり方をもっていて
既に使わなくなった手口を
公開しているだけかも知れません。
Re:ルートも (スコア:1)
--
私もスルー力が足りないなぁ...。
Re:ルートも (スコア:2, 参考になる)
FYI: オレオレ証明書とは [hatena.ne.jp]
# rm -rf ./.
Re:ルートも (スコア:1)
いわゆるHTTPSで証明書を使う場合、サーバ証明書に中間証明書を付加して配布(というか登録・設定)できるのですか?
具体的な方法が探せなかったので、御存知の方お願いします。
# それが可能なら、署名ツリーを検証できて嬉しいのだけど。
Re:ルートも (スコア:2, 参考になる)
http://cspssl.jp/support/install.html [cspssl.jp]
Re:ルートも (スコア:1)
apacheの設定の項を見ただけですが、理解できました。
中間証明書をサーバ証明書のファイルにくっつけるだけなんですね。
失礼しました。
有効期限切れなんて (スコア:1)
そういった点も考慮してCAを選ぶ方が後のためですよね。
タレコミ子の真意は?? (スコア:1)
SSLの証明書は、90日前から更新を受け付けてくれるCAだってあるし、ぎりぎりまで更新しないことはないですね~(お客さんの環境を含め20コくらい毎年更新してるけど)。
もし、ぎりぎりまで更新しないとしたら・・・
「お財布事情が厳しいから、支払いをぎりぎりまで延ばしたい」という大人の事情とか「忘れ去られたSSL(要は誰もアクセスしていない)で必要性も低い」場合ですかね。
いずれの場合でも、期日前までには更新 or サイトの破棄 を決定しますね。
Re:タレコミ子の真意は?? (スコア:3, 興味深い)
livedoor SSL サービスの一部休止のご案内 [livedoor.com]。
2006年10月20日をもって発行の受付休止です。
だったらなおさら早めに更新しとけばいいのにとも思いますが。
Re:職場での話 (スコア:1)
よくやらかす。。orz。
いや、切れる前にさ申請してくれよ!(ぉ
ごめんなさい、ごめんなさい、ごめんなさい。
Re:職場での話 (スコア:1)
Re:遭遇したトラブル (スコア:2, すばらしい洞察)
独自CAと、サービスに利用する自己署名証明書を混同している気がする
正しく運営している独自CAなら商用CAと技術的には同じですよ?
独自CAを正しく運営するぐらいなら格安証明書買った方が安いとも思ようにもなったけど。
Re:遭遇したトラブル (スコア:1, 参考になる)
ここんとこが分かってない意見に、
オレオレ証明擁護派、撲滅派を問わずよく遭遇するね、
いまだにスラドでも。
ブラウザのルート証明書だって、
前もって持っているルート証明書を信用できることが前提なのに。
ブラウザと一緒に手に入れたルート証明書ならブラウザの、
OSと一緒だったらOSの、入手経路が信頼できるかどうか、
オレオレ証明書と同様、よく考えて使わないとね。
Re:遭遇したトラブル (スコア:1)
Re:遭遇したトラブル (スコア:1, 興味深い)
> 騙される人続出
なのは間違いないですね。LinuxディストリビューションのISOイメージなんかも仕込み放題じゃないですか?
それにこれだけシステムが証明書の検証に依存するようになってくると、hostsファイルの次はルート証明書ストアを勝手に書き換えるスパイウェアが出てくるのは時間の問題だと思います。
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 生活中