5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【ベリサイン】VeriSign 【証明書】

1 :名無しさん@お腹いっぱい。:04/01/09 17:04
VeriSignとは何か、証明書とは何か、SSL通信と
どう関係してくるのか、どんな問題があるのかを
ここで色々勉強しよう。今回のノートンの件もあるし。

VeriSign
http://www.verisign.com/
日本ベリサイン
http://www.verisign.co.jp/

2 :名無しさん@お腹いっぱい。:04/01/09 17:06
バージン

3 :名無しさん@お腹いっぱい。:04/01/09 17:07
>>1市ね

4 :名無しさん@お腹いっぱい。:04/01/09 17:07
2

5 :名無しさん@お腹いっぱい。:04/01/09 17:07
いやー今回の件で勉強になったよ

6 :名無しさん@お腹いっぱい。:04/01/09 17:08
本家は自演で荒らされてる
以後300はこちらで自演してくださいW*88


7 :名無しさん@お腹いっぱい。:04/01/09 17:11
未だによく分からん

8 :名無しさん@お腹いっぱい。:04/01/09 17:12
で、結局エンドユーザはどうすりゃいいの?
待ってりゃなおるの?

9 :名無しさん@お腹いっぱい。:04/01/09 17:15
正直全く分からん

10 :名無しさん@お腹いっぱい。:04/01/09 17:17
ベリサインは塞ぐ必要ないって事でok?

11 :名無しさん@お腹いっぱい。:04/01/09 17:22
ノートンに関しては、電子署名の期限切れた時の処理が
DoSまがいの阿呆仕様だったのが原因でほぼFAかと。

証明書関係のファイル取りに行って応答待ちになるから
それを最初から遮断するって意味では塞ぐのは正解。
但し証明書関係の処理が怪しくなるから
セキュリティ的には不正解。


12 :名無しさん@お腹いっぱい。:04/01/09 17:31
>>10
ふさいじまったら永久に治らん
もう更新できるので最初の1回繋ぎに行けば治る

13 :前スレ300 ◆w795LO9.Wo :04/01/09 17:40
ジエーン!と参上しますた。

オレ自身、電子認証とかは勉強始めたばっかでまだにんともかんとも。

ただ、有効性確認のやり方がまずいと
なんかの契機にトラフィック増大というか爆発というか
今回のようなことが起きるんではないか?
みたいな懸念はなんとなくあった。

これから公的個人認証とか始まったら、どうなるんだろう。

このあたりのテーマ、もっと適切なスレや板、
ご存知の方居たら教えてっちょ。

14 :名無しさん@お腹いっぱい。:04/01/09 17:52
>>13
http://news4.2ch.net/test/read.cgi/news/1073616416/


15 :名無しさん@お腹いっぱい。:04/01/09 18:18
別スレで↓のやりかたで直った人がいるらしいが?

http://www.verisign.co.jp/server/help/faq/110089/index.html

16 :名無しさん@お腹いっぱい。:04/01/09 22:05
https://digitalid.verisign.com/cgi-bin/Xquery.exe?Template=authCertByIssuer&form_file=../fdf/authCertByIssuer.fdf&issuerSerial=e3e43e7c71626ccdfce18569b13a0829

17 :前スレ300 ◆w795LO9.Wo :04/01/09 22:23
http://www.ipa.go.jp/security/pki/index.html
PKI 関連技術解説
PKI は、Public Key Infrastructure の略であり、公開鍵基盤と訳されます。これは、「公開鍵(暗号技術)」による「基盤(インフラ)」を表しています。この技術を用いることで、暗号化、デジタル署名、認証といった様々な 情報セキュリティ対策を実現できます。

これ、オレが今まで見た中で、日本語でタダで読めるものの中では一番いいんだけど
あまりに敷居が高くてまだまたげない。

改めて取り組んでみるか。

18 :名無しさん@お腹いっぱい。:04/01/09 23:32
>>17
まだまだだねw

5分で絶対に分かるPKI
http://www.atmarkit.co.jp/fsecurity/special/02fivemin/fivemin00.html

19 :前スレ300 ◆w795LO9.Wo :04/01/10 02:26
NIS2003スレと敢えてマルチ。
あっちはトップリ付け忘れてたよ。

以下はあくまでオレの拙い理解&推測なので誤解なきよう。
間違えている可能性は大いにあります。
くわしいひと、間違いがあったら指摘してっちょ。

○そうではないかと思われること
・証明書が期限切れで無効=そのファイルが無効、というわけではない。
(証明書の確認が出来ないだけ。改竄は確認できる。)
・証明書失効リスト(CRL)は、常に定期的に取得するもので、個々の証明書の期限切れとは直接は関係ない。
 →「ある証明書の期限が切れた」から慌てて取りに行くものではない。
・証明書が無効になる条件は、
 (1) 有効期限切れ(証明書内に明記されている)
 (2) 失効(失効リストに載っている)
・有効期限内の証明書は、失効していないか確認する必要がある。
 →失効リストに載ってないか調べる。
・有効期限切れのものは、その時点で無効である。
 →失効リストを調べるまでもない。
・有効期限外の証明書に関する失効リストは、そのうち発行されなくなるかもしれない。

○オレとしての原因邪推・多分最終版
・有効期限切れの証明書の、期限切れの失効リストをわざわざ更新しようとして、取りに行こうとしている大バカモノがいるのではないだろうか?
・それがもう発行されていなくて、まさかそうだと思わずにタイムアウトするまで一所懸命リトライしている大バカモノがいるのではないだろうか?

○おまけ:調べてわかったこと
・NAVは、改竄された電子署名済ファイルがあっても別に何もしてくれない。
(これはちょっとビックリ!)


20 :前スレ300 ◆w795LO9.Wo :04/01/10 02:30
>>18 さんのご紹介先から参考文献を。
紹介ありがとう。一応、それも知ってたよ。
そのものズバリではなく、その記事の関連からです。

http://www.atmarkit.co.jp/fsecurity/rensai/pki05/pki01.html
PKI基礎講座 第5回 証明書の有効性


21 :前スレ300 ◆w795LO9.Wo :04/01/10 02:40
ある環境で
[発行元証明書の取り消しを確認する] のチェックをはずす
=取り消しリストの取得をやめる
で軽くなるんだったら、
まさしくその環境が「異常な数の「証明書失効リスト」のダウンロードを要求」していたんだと思うが。

22 :前スレ300 ◆w795LO9.Wo :04/01/10 02:43
さすがにもう祭りも終わりかぁ。
>>6 さんの許可が出ているので
ここで一人でジエーンすっか。


23 :前スレ300 ◆w795LO9.Wo :04/01/10 03:14
オレの推理がもし正しいのなら

・証明書ストア内のローカルの証明書とかは一切関係ない。
・もし問題の失効リストが発行再開されれば直ってしまう。

てことなんだがな。


24 :前スレ300 ◆w795LO9.Wo :04/01/10 03:45
>証明書ストア内のローカルの証明書とかは一切関係ない。

やっぱ、これは断言しない方がいいかもな。
ちょっと自信が揺らいできた。

でも、ルート証明書更新しても直らなかったと思うんだがなぁ。
それに、古い署名のルートはもちろん古いルート証明書のはずだし。


25 :前スレ300 ◆w795LO9.Wo :04/01/10 03:55
http://service1.symantec.com/SUPPORT/sharedtech.nsf/docid/2004010810205113

本家アメリカのドキュメントでは

>Solution:
>To fix this problem, you must obtain the updated version of Verisign's Root Certificate Authority.
>A full set of instructions is available on this page to walk you through the installation.

>解決:
>この問題を解決するために、あなた、ねばならない Verisignの根認証機関の最新バージョンを得ます。 .
>指示の十分なセットは、設置によってあなたを歩かせるこのページで利用可能です。

って断言してるなぁ。
明日にはこれが日本語訳されるんかな。

でもほんとか?これ。
ベリサインの協力で「勝手に直った」ちゃうんか??

26 :前スレ300 ◆w795LO9.Wo :04/01/10 03:57
我ながら見事な一人芝居だ。
虚しくなってきた。
もう寝よう。

明日起きたら、
なんだかすっかり直ってて
きっと何も無かったことになってるんだろうな。

まあいいや。
あの祭りの楽しい日々は忘れないよ。

おやすみなさい。さようなら。


27 :名無しさん@お腹いっぱい。:04/01/10 04:38
>>26
君にとってはこの問題発見の瞬間が人生のピークだったってことか・・・
残りにつまらない人生を生きろw

28 :名無しさん@お腹いっぱい。:04/01/10 13:40
まとめ
IEのv5.0以降でSSL接続した際に発生する証明書期限切れに関する対処法
http://www.forest.impress.co.jp/article/2004/01/09/verisign.html

□日本ベリサイン
http://www.verisign.co.jp/
□日本ベリサイン(中間CA局証明書の有効期限切れに関するページ)
http://www.verisign.co.jp/server/cus/rootcert/gsid_intermediate.html
□グローバル・サーバIDの中間CA局証明書の有効期限確認について
http://www.verisign.co.jp/server/help/faq/110089/

29 :前スレ300 ◆w795LO9.Wo :04/01/10 13:53
まとめていただいたけど、
ノートン激重の直接の原因は

「グローバル・サーバIDの中間CA局証明書」の期限切れ

じゃないと思う。

だから対策も

中間CA証明書の取り直し

ではないと思うんだ。


30 :名無しさん@お腹いっぱい。:04/01/10 23:50
>>25

>この問題を解決するために、あなた、ねばならない Verisignの根認証機関の最新バージョンを得ます。 .
>指示の十分なセットは、設置によってあなたを歩かせるこのページで利用可能です。

これはショッピングサイトなんかのサーバー認証の場合の
説明だと思う。この場合サーバーに認証鍵置くからね。

パソコンにインストールされているソフトの認証の場合は、その
ソフトの署名をやり直さない限り直らないと思うのだが・・・

いま復旧したように見えるのは、ベリサインのサーバー側で
何らかの対処(一時的にダミーの応答させるとか)してるん
じゃないかと推測してる。

現にIEのキャッシュ削除したら、またベリサインへ繋ぎに
いこうとするみたいだしね。



31 :名無しさん@お腹いっぱい。:04/01/11 00:32
>>1=前スレ300

オナニーレスはやめましょう。

32 :名無しさん@お腹いっぱい。:04/01/11 01:04
証明書失効リストのダウンロード要求集中で、
Norton AntiVirus 2003ユーザーのPCが動作不安定に
シマンテックのウイルス対策ソフト
「Norton AntiVirus 2003」の2004年1月7日付ウイルス定義ファイル更新後、
Microsoft WordやExcelが起動できないなど
動作不安定になる現象が起こっていると報告されていたが、
原因はベリサインのサーバに対し異常な数の
「証明書失効リスト」のダウンロード要求が行われためだったという。
同社のWebサイトで原因と一時的回避法が紹介されている(1月9日20:00現在)。
同Webサイトによると、Norton AntiVirus 2003など
シマンテック製品はプログラムのセキュリティ維持のため、
定期的にシステムコンポーネントの整合性を確認する作業を行っている。
1月7日から1月8日にかけては、ベリサインのサーバに対する
「証明書失効リスト」のダウンロード要求が異常な数に達し、
ベリサインのサーバ処理効率が低下、
整合性の認証を行うことができなくなっていたという。
そのため、ユーザーのPCの動作が異常に遅るなどの現象を引き起こしていた。
この現象は、Internet Explorer(IE)の
インターネットオプションを変更することで一時的に回避できると、
同Webサイトは説明している。
インターネットオプションを変更するには、
IEのツールバーにある「ツール」をクリックし、
「インターネットオプション」を選択。
「詳細設定」タブを選択し、
「発行元証明書の取り消しを確認する」のチェックを外す。
その後、コンピュータを再起動する。
現在シマンテックは、ベリサインなどと協力して
この問題の解消に取り組んでいるとしている。
www.itmedia.co.jp/enterprise/ (ITmediaエンタープライズ)

33 :前スレ300 ◆w795LO9.Wo :04/01/11 02:49
>>27
ほんとだねー。
オレもそう思うよw

名無しに戻っておとなしくするか。


34 :名無しさん@お腹いっぱい。:04/01/11 02:52
http://www.verisign.co.jp/press/2004/pr_20040110.html

ベリサインさん、ご苦労さん。

http://service1.symantec.com/SUPPORT/INTER/navjapanesekb.nsf/jp_docid/20040108142217958

これと併せて読むとさらに趣き深い。


35 :名無しさん@お腹いっぱい。:04/01/11 02:55
http://www.verisign.co.jp/press/2004/pr_20040110.html
ベルサイン謝罪



ノートン先生は被害者でつ

36 :名無しさん@お腹いっぱい。:04/01/11 02:55
>>34
Windows XPおよびそれ以前のオペレーティングシステムにおいて、MS CAPIベースで動作するサードパーティ製品のセキュリティパッチの一部には、
2004年1月7日で有効期限が切れる特定のCRL(Class3SoftwarePublishers.crl)が含まれており、crl.verisign.comからその更新版を取得しようとした結果、急激なダウンロード要求の増加につながったものと思われます。
 ↓
ある製品のセキュリティパッチに、期限切れのCRLが含まれており…
 ↓
誰だ(笑)?







37 :名無しさん@お腹いっぱい。:04/01/11 03:13
>>34

Please note that this situation is unrelated to the Intermediate CA expiration issue discussed at http://www.verisign.com/support/vendors/exp-gsid-ssl.html

この状況が http://www.verisign.com/support/vendors/exp-gsid-ssl.html で議論された「中間CA局証明書期限切れ問題」と無関係であることに注意してください。

あ。なぜこの一番大事なところを訳さん?>日本ベリサイン
リンク先が米サイトだからか?
ここんとこが一番混乱を読んでるんでしょうが。



38 :名無しさん@お腹いっぱい。:04/01/11 03:15
VeriSignのニュースリリースを読んだ…
暗に批判してるなぁ脳dを…

39 :名無しさん@お腹いっぱい。:04/01/11 03:18
明にベリサインになすくりつけるシマンテック
暗にシマンテックを批判するベリサイン

興味深い構図です。

40 :名無しさん@お腹いっぱい。:04/01/11 03:20
金払ってるのがノートンで
貰ってるのがベリサインだからな

悪いのはベリだろ

41 :名無しさん@お腹いっぱい。:04/01/11 03:27
>>40
でも
金払ってるんのがユーザーで
貰ってるのがシマンテックだから

シマンテックも悪いんじゃないか?w

42 :名無しさん@お腹いっぱい。:04/01/11 03:40
>>34

CRLをダウンロードできなかった場合、CRLを失効情報として取り扱う多くのアプリケーションにおいて以下の2つのうちどちらかの方法がとられることが一般的です。

(1) よい子
いくつかのアプリケーションは動作しつづけ、以前にダウンロードされ、かつ有効なCRLを参照します。このようなアプリケーションでは今回影響はありません。

(2) あほな子
ローカルにキャッシュされたCRLを利用しないその他のアプリケーションでは、crl.verisign.comにアクセスを要求します。

今回、アクセスが集中し、CRLをダウンロードしにくくなった原因として、後者のアプリケーション動作によるものと考えられます。

あほな子は誰だ?


43 :名無しさん@お腹いっぱい。 :04/01/11 03:42
ベリはなんで1/7だけ多くなった?
脳dもベリだけのせいにはできんでしょ
WやEが立ち上がらなくなる必要はない
つくりがワルイ
警告出せばいいじゃんか

44 :名無しさん@お腹いっぱい。:04/01/11 03:43
【ノートン】インターネットセキュリティ Ver.36【2004】
http://pc.2ch.net/test/read.cgi/sec/1073627059/667
http://pc.2ch.net/test/read.cgi/sec/1073627059/670


45 :名無しさん@お腹いっぱい。:04/01/11 03:45
みんな、いらいらしているかもしれないが
気分転換にこれをクリックして、みんなでばんじゃーいしてみてくれ。
ttp://pink.jpg-gif.net/bbs/18/img/5337.jpg
誰が作ったんだよ、こんなもの・・・。∩( ・ω・)∩ ばんじゃーい

46 :名無しさん@お腹いっぱい。:04/01/11 03:49
>>43
期限切れCRL入りパッチを撒いた奴がいるからだ、と
ベリは暗に言っていますよ。


47 :名無しさん@お腹いっぱい。:04/01/11 03:50
>>44
りがと&すまそ

48 :名無しさん@お腹いっぱい。:04/01/11 04:05
46>>
要するに仲たがいですな
あるいは、クロスカウンタとでもいうか
スマソ

49 :名無しさん@お腹いっぱい。:04/01/11 04:07
>>48
レスポンス低下で困っちゃったよ
        vs
レスポンス低下時の処理がマヌケ

というカウンターの打ち合いも。

クロスカウンタのAA欲しいところだ。

50 :名無しさん@お腹いっぱい。:04/01/11 04:12
>>34
さらに「MS CAPIベースで動作するサードパーティ製品」
で、MS CAPI = Microsoft Crypto API をわざわざ出すことにより、
さりげなくM$巻き込みの布石も。

だって、Office遅くなったり
ieのオプション設定で直ったりするんだもんねw


51 :名無しさん@お腹いっぱい。:04/01/11 04:22
>>44
667も670も微妙に間違い。

ある目的の証明書は1個だけとは限らない。
どれかの期限が切れたからといって
CRLの更新をやめていいわけがない。

http://www.verisign.co.jp/repository/root.html

http://www.verisign.co.jp/repository/crl.html

でも、そこをミスッた可能性は否めない。

Class3SoftwarePublishers.crl の日付が1/9なのも謎のまま。


52 :名無しさん@お腹いっぱい。:04/01/11 04:42
窓の杜の方、いきなり古い証明書を削除しろって書いてあるけど
バックアップくらいさせれよ

53 :名無しさん@お腹いっぱい。:04/01/11 05:12
【いいこと】ばんじゃーい【わるいこと】
http://hobby4.2ch.net/test/read.cgi/bike/1073757543/
∩( ・ω・)∩ ばんじゃーい

54 :名無しさん@お腹いっぱい。:04/01/11 10:11
結局こういうことだよね

脳豚が期限切れのCRLをアップデートしないまま配布

その結果1/7以降CLRダウンロード要求が大量発生

ベリのサーバーがあぼーん

ここで警告なり出して古いCLRで動作すればいいものを、いつまでも
ダウンロード要求

やっぱり脳豚が一番悪いような・・・


55 :名無しさん@お腹いっぱい。:04/01/11 12:28
http://www.verisign.co.jp/
重要なお知らせ
ベリサイン CRL配布サイトのレスポンス遅延について

しっかしまあちっちゃく書いてるなあ。
普通なかなか気が付かないぞ。
一応「重要」とは書いてあるけど。

シマンテックの方はトップページに書いてないし。

56 :名無しさん@お腹いっぱい。:04/01/11 12:46
1、プログラムの電子署名って何なの?

 ソフトウェア開発者が、自分とこの作ったプログラムとかが、確かに自分らが作ったものであること、自分らがリリースしてから後、改竄がされてないことを、利用者が確認できるための仕組みだ。

 これは開発者側が気が向けばお金を払ってやる仕組みで、絶対にやらないといけないとかいうわけじゃない。

 このプログラムの電子署名サービスとして代表的なのに、ベリサインの「コードサイニング証明書」(Code Signing)てのがある。(っていうか他はちょっと聞いたことない)

http://www.verisign.co.jp/codesign/index.html




57 :名無しさん@お腹いっぱい。:04/01/11 12:52
>>56
2、プログラムの電子署名ってどんなもん?見えるの?

 例えば、ノートンのアレ、CCAPP.EXE を見てみよう。

C:\Program Files\Common Files\Symantec Shared\CCAPP.EXE

これを右クリして(もう右クリ、大丈夫だよね:-)、プロパティを出そう。「デジタル署名」というタブがあるファイルは、電子署名がされてるんだ。出てこないものはされてない。

 「デジタル署名」をクリックすると、このファイルにある署名の一覧が出る。たいてい一個しかないので、それを選んで「詳細」を押す。
 
 すると、デジタル署名の詳細が表示される。

署名者の情報

名前 Symantec Corporation
電子メール 利用不可  (署名の情報としては公開してないだけ)
署名時刻 2003年12月2日 16:38:47
(これは見るファイルによって違うはずだけど、ファイルの更新日時とわずかな誤差のはず)

これでとりあえず、このファイルがシマンテックによって作られたもの、ということが確認できるわけだ。



58 :名無しさん@お腹いっぱい。:04/01/11 13:09
>>56
>>57
3、ちょっと待て。だれがそれを保証してくれるんだ?

 それはベリサインです。(ベリサインのサービスを使ってる場合)

 確かに署名にはシマンテックの名前があるが、それは誰が証明してくれるのか?

 普通のはんこの場合だと、みとめ印じゃなくて実印の場合は、押捺した書類と一緒に「印鑑証明書」を付ける。

 これには、印影と登録者の情報が載ってて、押された印影と、証明書の印影を比べて同じなら、「登録者が押したもの」と推定できる、という仕組みね。車買ったことのある人とかだと、慌てて印鑑登録はしたことあるはず。

 電子署名も似たような仕組みになってて、一緒に電子署名の証明書ってのが付いてきてるんだな。


59 :名無しさん@お腹いっぱい。:04/01/11 13:11
>>56
>>57
>>58
4、じゃあその電子証明書ってのを見せてみろ
 「デジタル署名の詳細」タブの「証明書の表示」を押すと、この署名についての電子証明書が表示されます。

証明書の情報
この証明書の目的:
  ・ソフトウェアがソフトウェア発行者の送信であるか確認する
  ・公開後のソフトウェアを変更から保護する
・詳細は、証明期間のステートメントを参照してください。
  発行先: Symantec Corporation
  発行者: VeriSign Class 3 Code Signing 2001 CA
  有効期間: 2003/11/13 から 2004/11/22

 「発行者」ベリサインが「発行先」シマンテックを認証している、というわけだ。

 このへんの仕組みはは詳しく説明するのが面倒なので、興味のある人は「PKI」てのを説明したもんとかを見て欲しい。

5分で絶対に分かるPKI
http://www.atmarkit.co.jp/fsecurity/special/02fivemin/fivemin00.html

インターネット時代のセキュリティインフラを理解しよう
PKI基礎講座
http://www.atmarkit.co.jp/fsecurity/index/indexfiles/index-serial.html#pki

PKI 関連技術解説
http://www.ipa.go.jp/security/pki/index.html

60 :名無しさん@お腹いっぱい。:04/01/11 13:36
>>56-59
5、おいおいオレのって期限切れだよ。もう使えないのか?

 この電子署名による証明は、あくまで証明書にかかれているとおり、
  ・ソフトウェアがソフトウェア発行者の送信であるか確認する
  ・公開後のソフトウェアを変更から保護する
という2点だけ。「これは○○が作りました」「パッチとかクラックとかされてません」ってことね。

 それをベリサインが証明してくれる期間がその「有効期間」ってことで、それが切れたからといってそのファイルやプログラムそのものの有効期限が切れたり、使えなくなったりするわけじゃない。

 そもそも電子署名のされてないプログラムは結構あるし、昔はそんなものなかたし。

 利用期間を設定や制限しているアプリが時々あるけど(笑)、これもプログラム署名によって制御しているわけじゃない。署名の有効期限と、プログラムやファイルの有効期限は別物です。

 それに証明の期間は切れてても、少なくとも署名の妥当性=改竄とかされてないか?てのは確認できるんだ。

 確認できないのは「ソフトウェアがソフトウェア発行者の送信であるか確認」なんだけど、そもそも一度は正しく署名されているものについて、これが変わるのは
「これは誰かがうちをかたってリリースしたもんだ。うちのじゃないぞコラ!」って場合か、
今は社名が変わっちゃったりしてる場合くらいか。


61 :名無しさん@お腹いっぱい。:04/01/11 13:45
>>56-60
6、カイネズミされてないってなんでわかるんだよ?

 とりあえずカイネズミじゃなくてカイザンです。

 デジタル署名の詳細に「このデジタル署名は問題ありません。」と表示されていれば、改竄がない、ってことです。

 ちなみに、ファイルを改竄してからデジタル署名の詳細を確認すると、「このデジタル署名は有効ではありません。」っていわれて、OSによっては赤シイタケ付き書類のアイコンが表示されます。

 実験方法を書くとナニなので、言われなくてもやり方がわかる人は試してみてください。やる人は必ず、コピーしたファイルでやってね。オリジナルをカイネズミせぬよう。


62 :名無しさん@お腹いっぱい。:04/01/11 13:55
>>56-61
7、おいおい期限切れなのに無問題かよ!?

 証明書の期限が切れているデジタル署名の詳細を表示しても、「このデジタル署名は問題ありません。」と表示されてしまいます。

 これは厳密には「このデジタル署名自体に問題はありませんが、証明書の期限が切れています。」くらいのはずです。

 でも、うっかりここに「問題ない」以外を出したり、黄色ビックリなんかを出したりすると、「おいおいオレのヤベエよ」とか慌てる人が出てくるので、わざとそうしている、とここはゲスカンしておきます。っていうか何も考えてないのかもしれなない。

 「署名自体の有効性」ってのと「署名の証明の有効性」ってのは別物で、前者が改竄がないことの確認、後者が身元の確認って感じではないかと。

 いくら証明書が有効でも、署名自体が無効=改竄されていればそいつはアウト。

 署名自体が有効であれば、少なくとも改竄はされていない、ってことね。


63 :名無しさん@お腹いっぱい。:04/01/11 13:57
どっちにしてもユーザーはシマンテックに金払ってるんだから
ノートンでの不具合はシマンテックが詫びるべき、と考える。

64 :名無しさん@お腹いっぱい。:04/01/11 14:09
>>56-62
8、ニセ証明書とかあったらどうすんのよ?

 乱暴に言うと、デジタル署名は「秘密鍵」ってのを使ってするんだけど、それを盗まれたら誰かが勝手に使って「オレオレ署名」しちゃうかもしれない。

 それに、部外者が不正にある会社の秘密鍵を取得する、なんて事も起きないとは限らない。ていうか、実際に起きてる。

http://www.microsoft.com/japan/technet/treeview/default.asp?url=/japan/technet/security/bulletin/MS01-017.asp

 M$かよ(笑)。

 クレジットカードの場合は、もし盗まれたりした場合には、持ち主がカード会社に申告してカードを無効にしてもらうよね。

 デジタル署名も同じで、秘密鍵を盗まれたり、部外者に不正に秘密鍵を取得された時には、持ち主がベリサインに申告して、その秘密鍵による署名を無効にしてもらうわけだ。


65 :名無しさん@お腹いっぱい。:04/01/11 14:13
良スレ!

66 :名無しさん@お腹いっぱい。:04/01/11 14:19
>>56-62
>>64
9、どうやって不正な署名を無効にするんだ?

 署名はかならず証明書とセットなので、証明書自体を無効にする=失効させます。代表的な方法としては以下の2つがあります。
(1) CRL モデル ……無効な証明書のブラックリストを作って公開する
(2) OCSP モデル ……そのつど証明書が有効かどうかをどっかに問い合わせる。

 CRL=ブラックリスト方式には、失効が行き渡るまでにタイムラグが生じる、という欠点があるし、OCSP=毎回問い合わせ方式だと毎回通信が発生する、という欠点があります。

 というわけで、現在では CRLモデルでの失効確認が広く用いられているようです。

http://www.ipa.go.jp/security/pki/044.html
http://www.ipa.go.jp/security/pki/041.html#_Toc3020781


67 :名無しさん@お腹いっぱい。:04/01/11 14:33
署名鍵が盗まれた場合、文書を改ざんした後に再署名されると
改ざんを検出することは不可能となります。(電子公証とか使えばよいが今は普及していない)

証明書には有効期間がありますので、盗難にあった署名鍵が悪用される
期間は証明書有効期間に限定させることができるといえます。
(そのためには、検証アプリケーションが正しい動作をしなければいけませんが)

鍵の正当な所有者は、署名鍵が悪用されていると感じたら、証明書を
失効させることができます。
しかし、今日、一般的に使用されている失効手段であるCRLの場合は、
利用者証明書の有効期間が切れると、その証明書の失効情報
はCRLから削除されます。(これはX.509やRFCで規定された仕様です)
つまり、利用者が認証局に失効を申請して、失効情報がCRLにのったとしても、
その利用者証明書の有効期間がすぎると、自動的にCRLからエントリが削除されます。
これは、CRLのサイズを増大させないための処置です。
また、有効期間をすぎた証明書は一律に無効とすることで対処可能である
という考え方があるからです。

したがって、有効期間がすぎた証明書は、失効されていたかどうかは、
過去のCRLを参照しないと判断できなくなります。。
CRLで失効を運用している場合は、そのことに注意する必要があります。

68 :名無しさん@お腹いっぱい。:04/01/11 14:40
>>67
>しかし、今日、一般的に使用されている失効手段であるCRLの場合は、
>利用者証明書の有効期間が切れると、その証明書の失効情報
>はCRLから削除されます。(これはX.509やRFCで規定された仕様です)

おお、どなたか存じませぬがありがとうございます。
偉そうに書いてますけど
オレもいろいろわからないところばっかなんですよ。

怪しいところ、間違ってるところありましたら
ツッコミおねがいします。


69 :名無しさん@お腹いっぱい。:04/01/11 14:47
>>67
でもそうなると、

(1) 事実
Verisign のコード署名の証明書のルート
Class 3 Public Primary Certification Authority
(シリアル番号:00E4 9EFD F33A E80E CFA5 113E 19A4 2402 32)
の有効期限が 2004年1月8日 8:59:59 に切れた。

(2) 推測
だから、Verisignは、そいつ絡みの失効リスト、
Class3SoftwarePublishers.crl
を新たに更新しなかった。
もしくは削除した。
もしくは無効にした。

(3) 事実
Verisign は
有効開始日  2004年1月9日 9:00:00
次の更新予定 2004年4月10日 8:59:59
の、Class3SoftwarePublishers.crl を
09-Jan-2004 16:31 に公開した。
(それまで更新がなかったかどうかは定かでない)



70 :名無しさん@お腹いっぱい。:04/01/11 15:02
>>68 訂正

でも、そうなると以下の可能性も否めないわけだ。

(1) 歴然たる事実
Verisign のコード署名の証明書のルート
Class 3 Public Primary Certification Authority
(シリアル番号:00E4 9EFD F33A E80E CFA5 113E 19A4 2402 32)
の有効期限が 2004年1月8日 8:59:59 に切れた。

(2) 推測
だから、Verisignは、X.509の仕様にのっとって
そいつ絡みの失効リスト、Class3SoftwarePublishers.crl を
2004年1月8日 9:00:00 に削除した。

(3) 推測
2004年1月8日 9:00:00 以降にも
特定のアプリからX.509の仕様を無視した
Class3SoftwarePublishers.crl
へのアクセスが継続した。

(4) 事実
Verisign は
有効開始日  2004年1月9日 9:00:00
次の更新予定 2004年4月10日 8:59:59
の、Class3SoftwarePublishers.crl を
09-Jan-2004 16:31 に公開した。
(それまで公開/更新がなかったかどうかは定かでない)


71 :名無しさん@お腹いっぱい。:04/01/11 15:05
CRLから削除される件については、verisign の CPS上で明記されているけど、
どうも、実際は削除されていなかったかもしれません。

https://www.verisign.co.jp/repository/CPS2.0/CPS2_0.pdf
---------------------
4.4.9 証明書失効リスト(CRL)の発行頻度
・・・・
有効期間が経過した証明書は、証明書失効リストから削除される。
---------------------


72 :名無しさん@お腹いっぱい。:04/01/11 15:08
>>67 さん
X.509のそのへんの仕様って
どれのどのへんみたらわかりますか?

教えてくんですんません。


73 :名無しさん@お腹いっぱい。:04/01/11 15:14
>>67-71

あー、激しく誤読してた。

>利用者証明書の有効期間が切れると、その証明書の失効情報
>はCRLから削除されます。(これはX.509やRFCで規定された仕様です)

CRLの発行をやめる、とは書いてませんよね。
失効情報が削除される、と。

(2) 推測
だから、Verisignは、そいつ絡みの失効リスト、
Class3SoftwarePublishers.crl
を失効後対応の、失効リストが空のものに更新した。

てことかな。

74 :名無しさん@お腹いっぱい。:04/01/11 15:48
失効後に参照されるべき次バージョンの証明書の名前を変えた上に
配布鯖まで変えてしまったから、参照元が混乱したってのもあるのでは?

75 :名無しさん@お腹いっぱい。:04/01/11 15:54
>>74
え、それどういうことでしょうか。

76 :名無しさん@お腹いっぱい。:04/01/11 16:30
鈴木さんに連絡取りたいのに結婚して佐藤さんになって引っ越してしまってて手がかりなしたって事だよ。

77 :名無しさん@お腹いっぱい。:04/01/11 18:12
>>74
そんな事実はないと思うんだが。
具体的に説明して欲しい。

78 :名無しさん@お腹いっぱい。:04/01/11 18:18
>>56-62
>>64
>>66
10、CRLてのは今回の激重事件の犯人だよな?

 犯人っていうか、原因の中核ではあるけど、CRLという仕組みそのものが犯人というわけじゃない。

http://www.ipa.go.jp/security/pki/042.html
PKI 関連技術解説 - 4.2 CRL モデル

 を超訳してみよう。

・失効された証明書の一覧を「CRL (証明書失効リスト)」という。
・CRL は、証明書を発行した CA が発行する。
・CRL は、リポジトリっていうサーバーで公開する。
・利用者は、定期的にリポジトリから CRL を取得する。

 このCAというのはARCserve出してる会社ではなくて、Certification Authority(認証局、認証機関)という意味です。ベリサインとかね。そこが失効された証明書の一覧(CRL)を所定の場所に公開する。

 実際には、所定の場所は証明書自身に書かれているので、利用者がそこから取ってくる、というわけだ。


79 :名無しさん@お腹いっぱい。:04/01/11 18:42
>>56-62
>>64
>>66
>>78
11、じゃあ、そのCRLってのをひとつ見せてみろや。

 それじゃあ、ひとつ実際に見てみましょうか。その前に、まずはCRLの場所を探すところから。
 例として、navapsvc.exe っていうプログラムがあるんですが、これって多分名前からすると、NAV の AP の SVC なんでしょうね。タスクマネージャで見てもシステム上に居座ってます。
 C:\Program Files\Norton AntiVirus\navapsvc.exe あたりにあるんかな。あ、ノートン入ってない人のところには、もろちんありませんし、NIS とかではどうなってるかはわかりません。
 こいつを右クリして、プロパティ→デジタル署名→詳細→証明書の表示ですね。

○NAV2004の人はこちら
 証明書の有効期限自体は2003/11/20に切れちゃってますね。
 「詳細設定」タブを選択して、上のリストの中から「CRL 配布ポイント」って項目を探してクリックしてください。下の窓に CRL のありかが表示されます。
 あなたのは ttp://crl.verisign.com/Class3CodeSigningCA2001.crl にあるようです。

○NAV2003の人はこちら
 あらあら。署名時刻は 2002年11月20日 13:06:43 なのに、証明書の有効期限自体は2002//11/24に切れちゃってますね(笑)。4日間の命の署名だったんですねー。
 「詳細設定」タブを選択して、上のリストの中から「CRL 配布ポイント」って項目を探してクリックしてください。下の窓に CRL のありかが表示されます。
 あなたのは ttp://crl.verisign.com/Class3SoftwarePublishers.crl にあるようです。あらあら。どっかで見たような場所と名前ですねー(笑)。
 どうも、NAV2003の世代のコンポーネント多く(タイムスタンプが2002年のもの)は、この古い証明書で署名されているようです。2002/11/24 に有効期限が切れたという(笑)


注:上記の内容は、お使いの環境によって異なる可能性があります。


80 :名無しさん@お腹いっぱい。:04/01/11 19:02
>>56-62 >>64 >>66 >>78-79
12、さっさとCRL見せてみろや。

注:よほどの物好きの人以外はやんなくていいです。

○NAV2004の人はこちら
ttp://crl.verisign.com/Class3CodeSigningCA2001.crl

○NAV2003の人はこちら
ttp://crl.verisign.com/Class3SoftwarePublishers.crl

 それぞれのアドレスをieのアドレス欄に貼って「移動」すると、ファイルの保存のダイアログが出るので、どっかに保存してからWクリで開いてみてください。これが CRL です。

 多分、ttp:// のままで貼っちゃう人もいるかもしれませんが、その人はラッキーにも応答遅延を経験できるかもしれません(笑)。

 Class3SoftwarePublishers.crl 、デカイですねー。なんなんでしょうね。


81 :名無しさん@お腹いっぱい。:04/01/11 19:32
*:.。..。.:*・゚(n‘∀‘)η゚・*:.。..。.:*!!!☆
生暖かく見守ってまつ。VeriSignガンバレ〜!

82 :名無しさん@お腹いっぱい。:04/01/11 20:43
>>70
(1) 歴然たる事実
Verisign のコード署名の証明書のルート
Class 3 Public Primary Certification Authority
(シリアル番号:00E4 9EFD F33A E80E CFA5 113E 19A4 2402 32)
の有効期限が 2004年1月8日 8:59:59 に切れた。

これは確かに用途に「コード署名」のある証明書だけど
NAV2003 に関わりのあるルート証明書はこっちだね。

Verisign のコード署名の証明書のルート
VeriSign Commercial Software Publishers CA
(シリアル番号:03C7 8F37 DB92 28DF 3CBB 1AAD 82FA 6710)
の有効期限が 2004年1月8日 8:59:59 に切れた。

どっちにしろ、2004年1月8日 8:59:59 に切れてるんだけどね(笑)。


83 :名無しさん@お腹いっぱい。:04/01/11 20:49
有効期限切れの証明書は、そもそもCRL引くまでもなく期限切れで無効。

なのにCRLわざわざ引く、ってのは無駄なだけじゃないのかな。

CAはこの先、期限切れの証明書のCRLを永遠に提供しつづけなければいけないのかな。

CRL 配布ポイントが指定されているからっといって、必ず即座にそこからCRLが取れる、とは限らない。

最新のCRLが取れなかった場合の大域的な処理を考えんといかんのだろうね。


ところで期限切れ証明書のCRLを取りに行こうとしているのは
ノートンなんだか。MS-CAPIなんだか。
どっちなんでしょうね。

84 :名無しさん@お腹いっぱい。:04/01/12 00:08
NAV2002/NIS2002はどの証明書で署名されてるんだろ?
恐れ入りますが、誰か調べてみてくんない?

85 :蕪木ら某 ◆Googl8RmwA :04/01/12 00:30
>>84
NAVW32.EXE
> 名前:     Symantec Corporation
> 電子メール: 利用不可
> 署名時刻:  2002年3月1日 18:27:42

> [1]CRL Distribution Point
>  Distribution Point Name:
>   Full Name:
>    URL=h(牛)p://crl.verisign.com/Class3SoftwarePublishers.crl

86 :名無しさん@お腹いっぱい。:04/01/12 00:35
>>85
あがとりい。
ついでに有効期限と「シリアル番号」ってのも教えてくんない?
いや
電子証明書のね。

でも見に行ってるCRLは2003と同じっぽいな。
2002で起動遅いって人は、
ieの「発行元証明書」のとこはどうしてるんだろう。


87 :名無しさん@お腹いっぱい。:04/01/12 00:39
>>85
あと、
ノートン関連でタイムスタンプが2001年のEXEかDLLがあれば
それの証明書も確認していただければ。

88 :蕪木ら某 ◆Googl8RmwA :04/01/12 01:04
>>84-87
> 有効期限と「シリアル番号」

> 有効期間の開始: 2001年10月31日 9:00:00
> 有効期間の終了: 2002年11月24日 8:59:59
> シリアル番号:   06 bd 7a 76 61 72 e1 ef 44 f1 9f 35 d5 e8 2b 34


> タイムスタンプが2001年のEXEかDLLがあればそれの証明書も...
SBServ.exe (ScriptBlocking registration) 2001年8月13日、23:18:36
> 名前:     Symantec Corporation
> 電子メール: 利用不可
> 署名時刻:  2001年8月14日 15:16:23

([1]CRL Distribution Point 記載なし)

> 有効期間の開始: 2000年11月17日 9:00:00
> 有効期間の終了: 2001年11月18日 8:59:59
> シリアル番号:   15 5a f1 a4 d9 a7 1d 52 14 a2 7e f6 9c 0f 9a 6a



Microsoft Windows XP Home Edition Version 2002 Service Pack 1
Norton AntiVirus 2002 for Windows 98/Me/NT4.0/2000/XP

89 :名無しさん@お腹いっぱい。:04/01/12 01:14
>>88
本当にありがとう。
2002年の署名の方は2003と同じ証明書ですね。
ということは、署名されたプログラムが出てくる局面によっては
2003と同じ問題が起きていた可能性はあります。

でも、今はその証明書のCRLもスムーズに取れるみたいだから
NIS2002が今なお起動が重い、という問題とは関係なさそうです。

2001年の署名の証明書はCRL配布ポイントなしですか。
じゃあ関係なさそうだ。
これが(多分)最後のお願いです。
その署名のルート証明書のシリアル教えてもらえませんか?
すんまそん。

90 :蕪木ら某 ◆Googl8RmwA :04/01/12 02:23
>>84-89
> ルート証明書のシリアル

NAVW32.EXE
> 発行者:    VeriSign Commercial Software Publishers CA
> シリアル番号: 03 c7 8f 37 db 92 28 df 3c bb 1a ad 82 fa 67 10
1996年4月9日 9:00:00 - 2004年1月8日 8:59:59

SBServ.exe
> 発行者:    VeriSign Commercial Software Publishers CA
> シリアル番号: 03 c7 8f 37 db 92 28 df 3c bb 1a ad 82 fa 67 10
1996年4月9日 9:00:00 - 2004年1月8日 8:59:59


> 証明のパス(P)
> □VeriSign Commercial Software Publishers CA  ←??
> └□Symantec Corporation

91 :名無しさん@お腹いっぱい。:04/01/12 02:55
>>90
ありがとさんです。
どっちもルートは同じ証明書で
同じタイミングに切れてますね。

シマンテックのコード署名の証明書のルートは、
2001年,2002年のが
シリアル: 03 c7 8f 37 db 92 28 df 3c bb 1a ad 82 fa 67 10
2003年のが
シリアル: 00 e4 9e fd f3 3a e8 0e cf a5 11 3e 19 a4 24 02 32
であると。

ご協力に感謝します。

でも、両方とももう切れてるんだよね。

92 :名無しさん@お腹いっぱい。:04/01/12 03:31
すがる思いでここに辿り着きますた_| ̄|○

http://www.verisign.co.jp/server/help/faq/110089/index.html
ここを見ながら証明書の更新とやらをしようと思ったんですけど
[Step 2:グローバル・サーバID導入サイトへの接続確認]のBの通りに
[証明書]ボタンをクリックしても、警告音?とともに
【この種類のドキュメントには、セキュリティ証明書がありません】という
メッセが出るだけで、Cに進めません…なぜなんでしょう?
因みに、1/7までの証明書のバックアップを取らずに削除してしまったので
現在、証明書が入ってない状態です。

このスレは全部読みましたが私には全くチンプンカンプンです。
お手数ですが、どなたか対処法か、または解決法が分かる場所への誘導
おながいします。

93 :名無しさん@お腹いっぱい。:04/01/12 05:50
>>92

 URL の頭は http:// じゃなくて、https:// 。
 s が抜けてる予感。


94 :92:04/01/12 06:26
>>93
そうでした(>▽<)ゞ テヘ!

私の不注意でお手数おかけしてすいません、ホントすいません、生まれて
すいません_| ̄|○

95 :名無しさん@お腹いっぱい。:04/01/12 12:00
SSLについて。

http://www.verisign.co.jp/repository/faq/SSL/

乱暴に言えば「ハガキじゃなくて封書で文通する」ってことかな。
http// だと生で行き来するデータを
https// ではPKI使って暗号化する、と。

96 :前スレ300 ◆w795LO9.Wo :04/01/12 12:21
!要注意!

「グローバル・サーバID用の中間CA局証明書の1/7期限切れの問題」ってのは、

SSL通信にベリサインのグローバル・サーバIDを用いている『サーバー』は
サーバー上に新しいグローバル・サーバID用の中間CA局証明書をインストールしておかないと
たとえ自分とこのグローバル・サーバIDの期限が切れていなくても
1/8 9:00 から https:// での暗号通信が出来なくなる、というもの。

これはあくまで「サーバー側の問題」です。
サーバーは側がきちんと対処していれば
本来、われわれユーザー側には一切関係ない問題。

万一、サーバ側がこれをちゃんとやってないと
証明書の期限切れで、SSL通信がちゃんと出来なくなる。

ttp://www.playonline.com/home/info/040108.html

これなんかが多分そうなんじゃないかな。

だから、


本 来 は ユ ー ザ ー は 何 も し な く て も い い 。


97 :名無しさん@お腹いっぱい。:04/01/12 12:28
>>96

「グローバル・サーバID用の中間CA局証明書」ていうのは
Windowsマシンの場合、ローカルに持っていたりもする。

そこにマシン上に有効なグローバル・サーバID用の中間CA局証明書があれば
たとえサーバー側がちゃんと更新してなくても自己解決で問題回避できる。


逆に、マシン上のグローバル・サーバID用の中間CA局証明書が古いままでも
ちゃんと更新しているサーバーには、なんの問題もなくアクセクできる。

(これは実際に確認してみた。)


ユ ー ザ ー 側 で の 更 新 は あ く ま で 保 険 的 な 自 己 防 衛 。

98 :前スレ300 ◆w795LO9.Wo :04/01/12 12:31
>>96-97
この件についての窓杜のニュース

http://www.forest.impress.co.jp/article/2004/01/09/verisign.html

を、よ〜く読んでもらえば、ちゃんとそう書いているはず。

IEのv5.0以降においては、標準で証明書がインストールされているが、
古い証明書のみインストールされているWebサーバーにアクセスすると、
証明書の有効期限切れを示す警告ダイアログが表示されたり、
https://”で始まるURLのWebサイトではアクセスが拒否される問題が発生する。
本来はWebサーバーの管理者が証明書を更新して問題を対処するが、
IE内の証明書を更新することで問題を解決することも可能だ。


99 :前スレ300 ◆w795LO9.Wo :04/01/12 12:37
>>96-98
!重要!

証明書は目的が同じでも別のものが存在するから
新しいものをインストールしても、古いものは上書きされない。
新しい証明書と古い証明書は共存できる。
わざわざ削除しておく必要はない。

ていうか、SSL以外に関するルート証明書は
古いものを削除してしまうと
古い署名の検査が出来なくなってしまうから


古 い ル ー ト 証 明 書 は 絶 対 に 削 除 し て は い け な い 。

100 :前スレ300 ◆w795LO9.Wo :04/01/12 12:56
>>96-99
>>92 さんが見ていた
http://www.verisign.co.jp/server/help/faq/110089/index.html は、窓杜の記事からも参考でリンクされているけど、

このドキュメントは本来、サーバー側の管理者が自分とこのサーバーの中間証明書がきちんと最新になっているのか、を確認するための手順書。

ユーザー側が中間証明書を更新するための手順書ではない。

でも、この手順書にしたがって
例にあるとおりのhttps://www.verisign.co.jp に接続すれば、
必ず最新の中間証明書が帰ってくる。そりゃベリサイン自身だもの(笑)。
ここは本来はサイト管理者が自分のとこのアドレス入れるんだけどね。

で、手順書とおりに作業を進めていって
5.の[証明書の表示]の表示で、新しい証明書を確認したら
手順書にはないけど[証明書のインストール(I)]を押してそのままデフォルトでどんどん進めれば最新の中間証明書を自分のマシンにインストールできる。手順書にはないけどね。
あくまで本来はサーバー管理者向けのドキュメントだから。

さらに、一番下あたりの
中間CA局証明書の更新方法については、以下のサイトを確認してください。
中間証明書の置き換え方法
ってリンクは、サーバー側での作業手順。
だから、IISとかApacheとかしか例に出てこない(笑)

ただ、これのIIS 4.0のとこの手順でも、ローカルマシンの証明書、更新できるんだよね。
ちょっと面倒だけど。上の手順のほうが簡単。

まぁ、なんにしろ

ユ ー ザ ー 側 が 必 須 の 作 業 で は な い 。

101 :前スレ300 ◆w795LO9.Wo :04/01/12 13:04
>>96-99
!最重要!

最後に。
「グローバル・サーバID用の中間CA局証明書の1/7期限切れの問題」ってのは、
SSL通信時の問題であって、今回のノートン激重とは直接関係ない。
だから、ノートンのユーザーがあわててこれに対処する必要はない。

逆に、慌てていろいろルート証明書を削除したりとかは
絶対にしてはいけない。

期 限 切 れ の 証 明 書 は 削 除 す る 必 要 は な い 。
逆 に 、 絶 対 に 削 除 し て は い け な い。


ご清聴ありがとうございました。ジエン終了(笑)

102 :名無しさん@お腹いっぱい。:04/01/12 16:55
もう消したよ 

103 :前スレ300 ◆w795LO9.Wo :04/01/12 17:53
なんか大変なことに気付いたような。
悪いのはマイクロソフトじゃないか?

NETにつながってるけどNAV入ってない機械見ると、CRLなんか一個もキャッシュされてなかった。
だから、以下の試験をしてみた。

まず、ノートンの署名期限切れのDLLを元に以下の2つのテストファイルを作る。
TEST.CER nav2003の navshex.dll からシマンテックの証明書を抜いてきたもの。
TEST.DAT nav2003の navshex.dll を単にリネームしたもの。

CERをWクリして表示させた証明書と
DATのプロパティから表示させた証明書と、明らかに表示が違うんだよ。
前者はきっちり無効になってるけど、後者は有効なんだ。

おまけに、ここからが大事。
「ルートの証明書の期限が切れてからでないとCRLを取りに行かない」
それも後者の手順で表示させた時にしかキャッシュにCRLが出てこないんだ。
これは明らかにおかしい。

ってことは、それまではぜーんぜん何もやってなかったのに
2004/01/08 9:00 になって初めて世界中で一斉にCRL参照しに行ってるんじゃないか?

さらに、日付いろいろ変えて試験してみたけど
証明書が有効期限内でも、CRL参照に行ってないんだよ。
少なくとも、キャッシュにCRLファイルが出てこない。


これって結局、きっかけはシマンテックとベリサインだけど

本 当 に 悪 い の は マ イ ク ロ ソ フ ト じ ゃ な い か ! ?

104 :名無しさん@お腹いっぱい。:04/01/12 18:28
>103
そりゃ、あんた、証明書のキーがレジストリの何処にあるか見りゃ一目瞭然でしょ。
Microsoftの下にあるのよ、Verisignの下じゃなくってさ。
おまけにルート証明、中間証明はそれぞれ個別のファイルじゃなく、
OS(IEかも)の1ファイルとして一纏めになってるんだから。

#このファイルをregsvr32で登録すると削除した期限切れ証明書も復活します。

105 :前スレ300 ◆w795LO9.Wo :04/01/12 18:33
>>104
オレが言いたいのは
「ルート証明書の期限切れになって初めてCRL取得に行く」
って動作が明らかにおかしいんじゃないか?
ってことなんだけど。

106 :名無しさん@お腹いっぱい。:04/01/12 18:52
>105
期限切れにならなきゃCRLに載らない訳だから、
その動作は正しいんじゃないの?

切れる前に更新版が確実に出てるはずなんだから、
それを前もって取り込んでおけば、ある程度は回避出来たはず。


107 :名無しさん@お腹いっぱい。:04/01/12 18:55
>>106
期限切れはCRL見るまでもなく無効。
だからCRLには載せる必要ない。

CRLは「期限内だけど失効させたい証明書」のブラックリスト。

本来は有効期限内に見ないといけないもの。

108 :92:04/01/12 19:58
難しいお話中すいません92です。

>>100:前スレ300さんの予想通り、窓の杜の記事↓を見て今回のことを
http://www.forest.impress.co.jp/article/2004/01/09/verisign.html
知りました。で、お陰で新証明書も取得できたんですが、その後もここを
ROMってたら…

>!注意!本来ユーザーは何もしなくて良い_| ̄|○
>!重要!古い証明書は絶対に削除してはいけない_| ̄|○
>#このファイルをregsvr32で登録すると削除した期限切れ証明書も復活
>します
           相変わらずチンプンカンプン…ララァ、私を導いてくれ_| ̄|○

結局、サーバー管理者ではなく・ユーザー側で・古い証明書を削除済みで・PC
の知識も無い私は今後どうすれば、、、。

109 :名無しさん@お腹いっぱい。:04/01/12 20:20
スマンテック社員が責任転嫁に必死なスレはここですね。

110 :名無しさん@お腹いっぱい。:04/01/12 20:23
別に削除する前に証明書をバックアップしてるなら、いつでも戻せるだろ。

111 :名無しさん@お腹いっぱい。:04/01/12 21:04
>105
> 「ルート証明書の期限切れになって初めてCRL取得に行く」
> って動作が明らかにおかしいんじゃないか?
NAVの件で言えば、
「持ってたCRLの有効期限が切れたので新しいCRLを取得に行った」です。



112 :名無しさん@お腹いっぱい。:04/01/12 21:12
そいで、CRLを持ってたのはWindowsだと思う。
スナップインで見てみると
VeriSign Commercial Software Publishers CA が発行して
次回更新予定日が1月8日のCRLがあるのが分かる。

スナップインについて↓
ttp://www.microsoft.com/windows2000/ja/server/help/sag_CMprocsStartCM.htm

113 :名無しさん@お腹いっぱい。:04/01/12 21:15
あと、更新した中間CA証明書についてですが、
公開鍵とサブジェクトが同じだからクライアント側の動作には
特に問題ないのかなぁとも思ったりする。
そして、証明書を更新するのに鍵ペアは更新しないっていう
VeriSignはどうかと思う。
中間CAに限らず、ルートCA証明書の更新についても同じ扱いだね。ベリ。

114 :92:04/01/12 21:23
(゚д゚)エー!? 期限切れ証明書、削除しちゃいけなかったの!?

115 :前スレ300 ◆w795LO9.Wo :04/01/12 22:16
>>111-113
なるほどー。
例の「発行ミス証明書」対応かなんかで
最低限それに関わるCRLだけデフォルトで持たせてる
ってことかな?

しかしそれだと2001/03/24〜2004/01/08の間に失効したかもしれない
他の証明書は一切チェックできないわけだよね。

でも、勉強になりました。ありがとうございました。

116 :名無しさん@お腹いっぱい。:04/01/12 22:18
つまりユーザー側はwindowsUpdateでルート証明書の更新をしさえすればいいというわけですか?
つーことわアンインストールしてweb見れる隙に更新し、それから再インストールでもいいわけですか?

つーか俺、httpsのところしか見れなかったんだけど、そういうのもあり?

117 :名無しさん@お腹いっぱい。:04/01/12 23:36
 ∩_ ∩
( ・ ω ・ )


118 :名無しさん@お腹いっぱい。:04/01/12 23:38
 ∩  ∩
( ・ ω ・ )


119 :名無しさん@お腹いっぱい。:04/01/12 23:40
 ∩_ ∩
( ・ ω ・ )
し     つ
 |   |   

120 :名無しさん@お腹いっぱい。:04/01/12 23:46
 ∩_ ∩
( ・ ω ・ )
と     つ
 |    | 

121 :名無しさん@お腹いっぱい。:04/01/12 23:55
 ∩_ ∩
( ・ ω ・ )  。
と     つ目゚
 |    |

122 :名無しさん@お腹いっぱい。:04/01/12 23:56
 ∩_ ∩
( ・ ω ・ )  。
と     つ目゚
  |  |

123 :名無しさん@お腹いっぱい。:04/01/12 23:56
 ∩_ ∩
( ・ ω ・ )  。
と     つ目゚
 |   |

124 :名無しさん@お腹いっぱい。:04/01/12 23:57
 ∩_ ∩
( ・ ω ・ )  。
と     つ目゚
 |   |


125 :前スレ300 ◆w795LO9.Wo :04/01/12 23:58
>111-115

http://support.microsoft.com/default.aspx?scid=kb;ja;293811
VeriSign 発行の不正な証明書を無効にするアップデート

こんなん発見。
スナップインから見えるのと同じCRLが中に verisignpub1.crl って名前で入ってますね。

中身には当然ながら

https://www.verisign.co.jp/press/alert/security_alertert20010321.html
コードサイニング証明書の不正取得が発覚

で警告されている、2つの不正所得証明書
Serial number is 1B51 90F7 3724 399C 9254 CD42 4637 996A
Serial number is 750E 40FF 97F0 47ED F556 C708 4EB1 ABFD
ともう1つ、それ以前に失効した証明書のエントリの計3つだけあります。
(それ以前に失効したものは他にもいくつかあるのに…)

きっと以降のIEは、標準でこのCRLを持っている、ってことでしょう。

大きな謎が一つ解けました。111さん、ありがとう。

126 :前スレ300 ◆w795LO9.Wo :04/01/13 02:01
92さん、まだ見てますか?

少なくともルート証明書については
WindowsUpdate でルート証明書を最新に更新すれば
削除された古いものも復旧するみたいですよ。

127 :名無しさん@お腹いっぱい。:04/01/13 03:24
本件はやっぱりNAV2003に落ち度があるなあぁ。
コードサイニングに使われた秘密鍵に対応する公開鍵の証明書、
(要するにベリからシマンテックに発行された証明書。>>85 のやつ。)には
CDPが書いてあるので、都度CRLを取得することを狙ったのかもしれない。
でもOSのパッチのせいで、取得しようとしているCRLが強制的にOSに永続的に保持されていた。
そしてNAVアプリは、OSが持ってるCRLがまた有効期間内なのでそれを使うかぁ
と思って取りに行かなかったのだろう。

ただ、OSのバッチが発表されたのが2001年3月28日。
NAV2003の発売までかなり時間があるのに、対策をしなかったNAVが悪い。

ちゃんとした仕様で作っていれば、NAV2003の販売数が増えるごとに
ベリへのアクセスが増えていくから、ベリも「なんかアクセス増えてきたからサーバ増強しよっか」
と思えたはず。
今回OSに保持されているCRLの有効期限が切れたことで、今までベリが想定していなかった
全世界のNAV2003ユーザからCRL取得のアクセスがあり、あぼーんしてまったということだ。

そして、現行のCRLの次回更新予定日(2004年4月10日)にはまた
全世界のNAV2003ユーザからCRL取得のアクセスがあり、あぼーんしてしまうのだろうか。

128 :名無しさん@お腹いっぱい。:04/01/13 03:50
>>127
ということは、やはり本件はSymantec側のテスト不足 or 仕様が糞のどちらかでFAでしょうか

129 :名無しさん@お腹いっぱい。:04/01/13 03:58
ごめん。
よく考えてみると、どこぞのあほうに騙されて証明書を発行したベリが一番悪い。
それが本件の根本的な原因。
対応し切れなかったNAVも悪いが、まぁ被害者と言えなくもないと思う。

130 :名無しさん@お腹いっぱい。:04/01/13 04:00
( ゚Д゚)ハァ ベリでつか?
https://www.netsecurity.ne.jp/article/1/4367.html

131 :92:04/01/13 05:27
>>126
見てます。スルーされても仕方ないようなところ、ワザワザありがdございますた

132 :前スレ300 ◆w795LO9.Wo :04/01/13 12:17
>>127

>>103 に書いたけど、オレ、ノートンない環境で
コード署名の確認だけでCRL取得に行くの確認したつもりなんだ。

ノートン自身も独自でCRL取得してるのかもしれないけど
少なくとも、右クリックの遅延は

右クリックされた時点で、Windowsがノートンの対応モジュール
NAVSHEXT.DLL のコード署名を確認しようとしてCRL取得が発生

と分析しました。

NAVSHEXT.DLL は 2002 では署名なし、2004では別のCRL配布ポイントなのと
絶対数が2003より少ないので、
被害が2003に集中したのでは?と。

まだ疑念だらけの推理ですけどね。
ご意見など頂ければ幸いです。

オレは、誰が悪いのか、ってのより
新の原因は何なのか?の方に興味があって粘着してます。



133 :前スレ300 ◆w795LO9.Wo :04/01/13 12:19
>>132
アホや。

「真の原因」やね。

まあ、

>>129 名前:名無しさん@お腹いっぱい。[] 投稿日:04/01/13 03:58
>ごめん。
>よく考えてみると、どこぞのあほうに騙されて証明書を発行したベリが一番悪い。
>それが本件の根本的な原因。
>対応し切れなかったNAVも悪いが、まぁ被害者と言えなくもないと思う。

これには全面的に同感です。


134 :名無しさん@お腹いっぱい。:04/01/13 17:29
1/8事件では結局その日のうちに対応してしまったんだが
いまだに調査中で根本対応ができてないのがMSとSymantecなのはどうかと
祭りが面白くて当日は明け方まで貼りついていた自分って

135 :名無しさん@お腹いっぱい。:04/01/13 17:42
タスクトレイのノートンとスタート右クリのエクスプローラで
アウポがどうするか聞いてくるんだがどうすりゃイイ?

136 :名無しさん@お腹いっぱい。:04/01/13 18:16
好きにすれ

137 :前スレ300 ◆w795LO9.Wo :04/01/13 18:20
>>134
祭りが終わった今でも、オレ的にはいろいろ新発見が続いてるんだけど
もう祭りは終わってるから…。

でも、この5日ほどで過去一年分以上勉強した気がするよ。

138 :名無しさん@お腹いっぱい。:04/01/13 18:33
*アクセス制限中に他所の板に書いた内容をここにもコピペしとこうかね

VeriSign中間証明書の取得で判り易そうなところ − 窓漏り
http://www.forest.impress.co.jp/article/2004/01/09/verisign.html

----- ついでに今回のまとめ(FW使える人向け)-----

crl.verisign.comのIP/Mask(かなり流動的)
12.158.80.0/255.255.255.0
64.94.110.0/255.255.255.0

【証明書使うなら】
2011/10/25期限のV3を取得してから
上記IP/Maskを全アプリに許可(*)
TCP(out)、ローカルポート1024-5000、リモートポート80
ネット詳細プロパの発行元証明書取消確認をOn

(*)起動時navw32.exeだけじゃなく右クリ時explorer.exeとか
色んなアプリから呼ばれるから、あえて特定しないほうが簡単

【証明書使いたくないなら】
上記IP/MaskをFWかルータで遮断して
ネット詳細プロパの発行元証明書取消確認をOff

これで起動時に勝手にネット接続は防げる
代わりにモジュール改竄のリスクを負うが
MD5とか覚えてるFWならあまり気にすることはない

----- こんなもんでしょうか -----


139 :前スレ300 ◆w795LO9.Wo :04/01/13 18:58
>>137

・問題の Class3SoftwarePublishers.crl に対応するCRLを、Windowsがこっそり内蔵していた。
・おまけに↑の有効期限は2001/03/24〜2004/01/08 8:59:59(JST)という長大なもの。
・右クリだけでCRL取りに行くには2003のみ。2002と2004では起きない。
・そもそも2002の構成ファイルの多くは電子署名されていない。
・どうもWindowsのコード署名の確認では、証明書の有効期限が切れていてもCRLを取りに行く事があるようだ。

てあたりが祭り以降にわかったこと。

140 :名無しさん@お腹いっぱい。:04/01/13 19:00
2002でも署名確認するモジュールをLiveUpdateで仕込まれてるらしい

141 :前スレ300 ◆w795LO9.Wo :04/01/13 19:06
>>140
>2002でも署名確認するモジュールをLiveUpdateで仕込まれてるらしい
ていうことですよね。

であれば、今まだ続いているらしい
NIS2002の起動/終了時にCRL取得が飛ぶ、
って問題も説明がつく。

ただわからんのがなんで毎回見に行くのか、ということ。
通信を許可してやれば、ちゃんとCRL取得して
有効なものがキャッシュに残ってたら見に行かないはずなのに。

キャッシュ強制的に消したりしてるのかな?

142 :名無しさん@お腹いっぱい。:04/01/13 19:17
NAV2003でつが、一応KPFでVeriSign許可してログ取ってまつ
ログ見てみると、1日1回程度の頻度でNMAIN.EXEがアクセス
20分置きぐらいの間隔でEXPLORER.EXEがアクセス(右クリの頻度とは関係なさそう
VeriSign遮断して取消チェック外しても実際何の支障もないので、いずれ遮断することになるでしょう

143 :前スレ300 ◆w795LO9.Wo :04/01/13 19:24
>>142 さん
なんてファイル持ってきてるかまでわかります?
例の Class3SoftwarePublishers.crl ですか?

144 :名無しさん@お腹いっぱい。:04/01/13 19:49
>>143
多分ブラウザキャッシュに残ってるこれらではないかと
http://crl.verisign.com/Class3InternationalServer.crl
http://crl.verisign.com/Class3SoftwarePublishers.crl

145 :前スレ300 ◆w795LO9.Wo :04/01/13 19:59
>>144
上のは始めてみる名前だけど、700Kもあるで。おいおい。
下のはやっぱ例の奴ですな。

でも、どっちも現状有効期限内なのに
実際取り直しているのなら、ちょっとアホっぽい。

ピーガー・モデムやPHSカードで通信している人には辛いっぽい。


146 :142=144:04/01/13 19:59
あるときNAV2003がLiveUpdateで仕込まれてから、勝手にVeriSignに接続しるようになったわけで
CDから再インスコし直しても、レジスト時に現行モジュールに書き換えられるようでつ
NISスレで見た限りでは、2002もごく最近同じものを仕込まれたそうで

147 :名無しさん@お腹いっぱい。:04/01/13 20:05
普通はHTTP Headメソッド辺りで属性見るところを
HTTP Getで内容全部取ってるのではなかろうかと

148 :前スレ300 ◆w795LO9.Wo :04/01/13 20:11
>>146
「あるとき」ってのは2004/01/08 9:00よりも前のあるときですか?

149 :名無しさん@お腹いっぱい。:04/01/13 20:21
>>148
原本のCD-ROMの最終タイムスタンプは2002/12/10かそこら(発売日よりは前のはず
\Program Files\Common Files\Symantec Sharedにある、現在のcc*.exeの最終タイムスタンプが2003/05/23
つまり2003/05/23以後に仕込まれたということですな

150 :前スレ300 ◆w795LO9.Wo :04/01/13 20:21
>>146
http://service1.symantec.com/support/INTER/nisjapanesekb.nsf/jp_docid/20030606122656947
LiveUpdate を実行後、プログラムが自動的に verisign.com に接続する



Date Created: 2003/06/05

だから、ずっと昔からなんだろうなあ。

Class3CodeSigningCA2001.crl の方を取りに行ってるんだったら、まだわかるんだが。

151 :名無しさん@お腹いっぱい。:04/01/14 01:19
ノートンの不具合、原因はベリサインの期限切れ証明書
http://japan.cnet.com/news/ent/story/0,2000047623,20063615,00.htm

152 :前スレ300 ◆w795LO9.Wo :04/01/14 02:09
シマンテックがコード署名に使っているっぽい証明書たち。

(1)2002年あたりの署名に使用している証明書
発行者:VeriSign Commercial Software Publishers CA
シリアル番号:06BD 7A76 6172 E1EF 44F1 9F35 D5E8 2B34
有効期間の開始:2001年10月31日 9:00:00
有効期間の終了:2002年11月24日 8:59:59 (期限切れ)
CRL配布ポイント:http://crl.verisign.com/Class3SoftwarePublishers.crl

(2)2003年の11月あたりまでの署名に使用している証明書
発行者:VeriSign Class 3 Code Signing 2001-4 CA
シリアル番号:7F4B A50B F997 0FCC A0B2 4217 9E96 4657
有効期間の開始:2002年11月19日 9:00:00
有効期間の終了:2003年11月20日 8:59:59 (期限切れ)
CRL配布ポイント:http://crl.verisign.com/Class3CodeSigningCA2001.crl

(3)2003年12月あたりからの署名に使用している証明書
発行者:VeriSign Class 3 Code Signing 2001 CA
シリアル番号:7680 3206 4730 C030 3744 BFFD 0E6F 3B90
有効期間の開始:2003年11月13日 9:00:00
有効期間の終了:2004年11月22日 8:59:59 (現時点で有効)
CRL配布ポイント:http://crl.verisign.com/Class3CodeSigning2001.crl


153 :前スレ300 ◆w795LO9.Wo :04/01/14 02:11
>>152
(3)は現在有効の証明書。現時点でのCRLの有効期限は約10日間で、しかも毎日更新されている。
(2)は1年程度前に切れた証明書だが、CRLは(3)と同様の期間と頻度で更新されている模様。

しかし2年程度前に切れた、(1)の現時点でのCRL(問題のやつ)の有効期限は約3ヶ月間で、少なくとも今見えるもの(有効期限開始 2004年1月9日 9:00:00)に更新されてから、今日まで更新がない。

(2)と(3)は有効10日間のCRLが毎日更新されているので、きちんと有効期限を見て取りなおすとしたら、それぞれの環境で10日おき。そのタイミングが10日間に分散することになる。

だが(1)がこのまま4/10まで更新されないとしたら、またまたNAV2003のマシンが2004/04/10 10:00から一斉にCLRを取りに行くことになる。

ほんまに大丈夫なんかいな?

154 :前スレ300 ◆w795LO9.Wo :04/01/14 02:42
>>151
CNET の報道も、シマンテックとベリサインの発表を解説しているだけですね。
ただ日本語訳がわけわからん感じ。一方的にシマンテックの言い分だけ。
原文のほうは両者の言い分の違いにもう少しちゃんと触れているように見える。

一応ちゃんと「グローバルサーバーID中間証明書の期限切れとは別問題だ」
という主旨と思われることも書かれているけど、訳がメロメロ。

かたや調査中、かたや事実上の終息宣言
てのには論及されてないし。

ベリサインの過去の証明書誤発行とリンクしている報道はまだ見たことない。

155 :名無しさん@お腹いっぱい。:04/01/14 04:10
>>152 それってNAV2003のコードサイニングに使われてる証明書?
だとすると、1月8日以前は(2)と(3)のCRLだけ取得しに行ってたのが、
1月8日以降、(1)のCRLも取得しに行ったと。
(2)が40KB、(3)が75KB。で(1)が119KB。
今までのトラフィックの倍やね。。

156 :名無しさん@お腹いっぱい。:04/01/14 04:20
>>144-145
上のは別件の「1月8日に有効期限が切れた中間CA証明書」のものだ。
要するにコードサイニング用証明書ではなく、SSL通信用サーバ証明書のCRL。

157 :名無しさん@お腹いっぱい。:04/01/14 08:41
今日は水曜日な訳だが、LiveUpdateでノートン2003の右クリ問題修正パッチマダー?チン☆⌒ 凵\(\・∀・)

>>150
それがDate Created: 2003/06/05マジかよ?
少なくとも俺の環境では04/01/08に手動でLiveUpdateするまでアクセスに行ってないように思われるが・・

158 :前スレ300 ◆w795LO9.Wo :04/01/14 09:45
http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20040113/138211/
Norton AntiVirusなどにパソコンの動作を遅くする問題

これはなかなか立派な記事。

・まず「ノートンの問題」として書かれている。
・次に「原因はピーク時のベリサインの応答力不足」と説明。
・証明書の期限切れと、CRLの期限切れとをちゃんと区別している。
・だが、シマンテック者製品以外では確認されていらしいことを説明。
・ベリサインは一応の終結宣言を出していることに論及。
・シマンテックは調査中のままであることを暗に説明。

ちょっと怪しいのが
・Class3SoftwarePublishers.crl だけがコードサイン証明書のCRLであるかの誤解を与えかねない。

ここで触れられていないこととしては
・Class3SoftwarePublishers.crlは特定のコード署名証明書のCRLであること。
・次回更新2004/01/08のClass3SoftwarePublishers.crl がWindows自身に内蔵されていたこと。
・これは2001年3月に発行した、ベリサインの証明書発行ミス(自身は「不正取得」と主張)への、MS側の対応処置であること。
・2004/01/07まではこれを内部参照するので、CRLをベリサインまで更新に行かないこと。
・このため、2004/01/08になると、初めてベリサインに新しいのが出てないか確認に行こうとすること。

かな。勝村 幸博=IT Proさん、後追い調査キボンヌ(笑)

159 :名無しさん@お腹いっぱい。:04/01/14 12:22
>>158
分析乙。参考になった。

160 :名無しさん@お腹いっぱい。:04/01/14 12:29
13日付のウィルス定義うp団子で治ってるみたいだぞ。

161 :前スレ300 ◆w795LO9.Wo :04/01/14 12:48
>>160 マルチごめん。

今日、LiveUpdateで共通ファイルとNAVのファイルの更新がかかった。
共通ファイルはccなんとかがごっそり2003/05/23付けのものに入替えられた。
でもまだまだタイムスタンプが2002年の.dllがごろごろ残ってるし。
とりあえず手持ちで新しいのがある奴だけ入れ換えたかな?(邪推)

これで少なくともccなんとかの署名は別のものになったんだけど
NAV2003で試験してみたらやっぱりまだ右クリで Class3SoftwarePublishers.crl を読みに行く。
レジストリから右クリからのノートン呼び出し殺したら読みに行かない。

根本解決には至っていないと思う。

あ、13日付の定義ファイルのほうも見てみます。

162 :名無しさん@お腹いっぱい。:04/01/14 12:58
 1/8みたいな劇重はならないにしても、NAV2003で時々右クリが遅かったり、NIS2002の起動終了が遅かったりする件に付いては、

仕様なのですまん。2004にしてくれ。

と開き直られるかもしれんヨカン。

163 :名無しさん@お腹いっぱい。:04/01/14 13:45
http://www.verisign.com/corporate/news/2004/pr_20040112.html

あ、ベリの発表に更新あり。

164 :名無しさん@お腹いっぱい。:04/01/14 13:50
http://www.verisign.co.jp/press/2004/pr_20040113.html

日本語版も出てた。
完全に履歴を残すべりはとりあえずシマンテックよりえらい。

165 :前スレ300 ◆w795LO9.Wo :04/01/14 14:04
あーっ!オレ大変な誤読してた。

Windows XPおよびそれ以前のオペレーティングシステムにおいて、
MS CAPIベースで動作するサードパーティ製品のセキュリティパッチの一部には、
2004年1月7日で有効期限が切れる特定のCRL(Class3SoftwarePublishers.crl)が含まれており、
crl.verisign.comからその更新版を取得しようとした結果、急激なダウンロード要求の増加につながったものと思われます。

ここでいう「セキュリティパッチ」って

http://support.microsoft.com/default.aspx?scid=kb;ja;293811
VeriSign 発行の不正な証明書を無効にするアップデート

これの事じゃんか!

オレはここはノートンを暗に叩いているものだという先入観で読んでたから、
他の情報からの刷りこみで、「セキュリティパッチ」ってのは、ノートンの1/7付けウイルス定義ファイルだと誤読してた。

よく考えてみたら、ウイルス定義ファイルはセキュリティパッチじゃないし
中に署名済みのファイルはあっても、CRLが生では入っていない。
ここの理解が誤ってたので、「おいおいベリ何言ってんだよ」と思ってたんだけど。

あー。やっと大きなもやもやが晴れたよ。
ベリの発表にはノートンの「ノ」の字も、シマンテックの「シ」の字も出てこない。


ごめん。「シ」は出てきてるな。


166 :名無しさん@お腹いっぱい。:04/01/14 14:11
結局どうすりゃいいん?
FWが五月蠅いです。

167 :名無しさん@お腹いっぱい。:04/01/14 14:17
>>166

>>138 を参照のこと。

168 :名無しさん@お腹いっぱい。:04/01/14 14:21
>>164

一番先頭の状況説明が

2004年1月9日時点で、米国ベリサイン社(以下、ベリサイン)では、crl.verisign.comへのトラフィックが、2004年1月7日以前の通常のレベルに戻りつつあることを確認しました。
Windowsベースのクライアントによる証明書失効リスト(Certificate Revocation List: CRL)のダウンロード要求の急激な増加を認識してから、ベリサインはこれらの処理に対処するためにサーバの処理能力を10倍に増強しました。
状況が完全におさまるまで、ベリサインは引き続き処理能力の増強を実施します。

に変わってる。後の部分は同じ。

激重は解消されていると思うけど
NAV2003で右クリが時々稍重なのは、まだそのままのはず。

169 :名無しさん@お腹いっぱい。:04/01/14 16:38
家のXP Proはここに書かれている状況ですが
会社の98SEは全く何事もないんですがなぜ?
NAVが入ってて定義ファイル1月7日なんですが。

170 :名無しさん@お腹いっぱい。:04/01/14 17:09
>>169

98SEマシンのIEのバージョンはいくつくらいですか?

171 :名無しさん@お腹いっぱい。:04/01/14 17:33
>>170
6.0.2800.1106 です。

172 :名無しさん@お腹いっぱい。:04/01/14 18:00
http://headlines.yahoo.co.jp/hl?a=20040114-00000208-yom-soci

173 :名無しさん@お腹いっぱい。:04/01/14 19:32
>>169-171
うーん。会社のほうは会社が crl.verisign.com をブロックしているのかも。

ご自宅のほうの「ここに書かれている状況」ってのは
具体的にはどうですか?右クリ重とか?
基本的には激重は解消していて、
時々右クリがやや重いことあり、てな感じだと思うけど。今は。


174 :前スレ300 ◆w795LO9.Wo :04/01/14 20:00
http://www.microsoft.com/japan/technet/security/bulletin/fq01-017.asp
マイクロソフト セキュリティ情報 (MS01-017) : よく寄せられる質問

うわー、これ改めて読むとなんかすげえな。
今回の核心に迫ることがいくつか書かれているし。

もう一回よく読んでみるか。

175 :前スレ300 ◆w795LO9.Wo :04/01/15 02:02
今日わかったこと。

オレの >>103 は間違いだらけ。
>CERをWクリして表示させた証明書と
>DATのプロパティから表示させた証明書と、明らかに表示が違うんだよ。
>前者はきっちり無効になってるけど、後者は有効なんだ。

これは正しい動作。
前者は証明書自身の有効性チェック。
後者はコード署名のチェック。

コード署名の場合、タイムスタンプというのを設定すると、署名にベリサインが認証した署名日時(タイムスタンプ)が同時に記録される。

これがあれば「いつ署名したのか」というのをベリサインの証明で特定できるので、
「コンピュータの日付を変えて署名する」などの方法で、署名日を偽装することが出来なくなる。

コード署名に関しては「証明書の期限が切れても、署名自体は有効」という仕様らしい。

というわけで、オレの >>103 での実験は、通常の証明書自身の有効期限と、コード署名の有効期限の違いを知ることが出来る実験だったわけだ。

○参考
http://www.verisign.co.jp/codesign/help/faq/210004/index.html
タイムスタンピング・サービスとは何ですか
http://www.verisign.co.jp/codesign/help/faq/210015/index.html
タイムスタンプを設定した場合証明書の有効期限が切れると署名済みのファイルはどうなりますか


176 :前スレ300 ◆w795LO9.Wo :04/01/15 02:15
ついでにもうひとつ >>103 のオレの間違いについて。

>おまけに、ここからが大事。
>「ルートの証明書の期限が切れてからでないとCRLを取りに行かない」
>それも後者の手順で表示させた時にしかキャッシュにCRLが出てこないんだ。
>これは明らかにおかしい。

これは、ルートの証明書の期限とは関係なく
>>125 あたりの事情で「内蔵されていたCRLが切れたので、新しいCRLを取りに行った」ということ。たまたまルート証明書の期限切れと、内蔵されていたCRLの次回更新予定日とが一致していただけ、ということのようだ。
(でも、これはきっと「たまたま」ではないだろう)


177 :前スレ300 ◆w795LO9.Wo :04/01/15 02:18
今日わかったことのまとめ。

・コード署名は、タイムスタンプがあれば証明書の有効期限切れ後でも有効という仕様。
・だから、証明書の期限切れ後にCRLを参照するのも仕様通りの動作。
・ベリサインは、証明書の有効期間内はCRLを毎日更新する。
・CRLでは「有効期間の終了日」ではなく「次の更新予定日」。
(一度失効したものが復活することはない。次の更新予定日を過ぎれば「新しいCRLがあること」が期待できるということで、内容自体が無効になるわけではない。)
・だ か ら 「CRLが失効」 す る わ け で は な い。
・X.509の仕様では、CRLは次の更新予定日までにちゃんと出さないといけないことになっている。


178 :前スレ300 ◆w795LO9.Wo :04/01/15 02:20
相変わらずオレのジサクジエンというか一人相撲というかジイコウイ爆発!だけど

一応スレタイ通りの内容になってはきているような。

179 :名無しさん@お腹いっぱい。:04/01/15 09:37
>>173
自宅のは、
@PC起動時NAVがタスクトレイ(通知領域)に載るのが遅い。
Aスタート右クリ→エクスプローラでアウポ(FW)のポップアップが出る
(許可or遮断かルール設定)
です。


180 :前スレ300 ◆w795LO9.Wo :04/01/15 11:09
>>179

ならば、とりあえず >>138 の対策ですかね。
CRL確認自体は「正しい仕様」なので
ちゃんと通信を通してやるか
リスクを理解した上でCRL確認自体を止めるか、でしょうね。



181 :138書いた本人が修正しときまつ:04/01/15 16:46
VeriSign中間証明書の取得で判り易そうなところ − 窓漏り
http://www.forest.impress.co.jp/article/2004/01/09/verisign.html

----- ついでに今回のまとめ(FW使える人向け)-----

crl.verisign.comのIP/Mask(かなり流動的)
12.158.80.0/255.255.255.0
64.94.110.0/255.255.255.0

【どっちにしても中間証明書は更新しとくのが望ますい】

2011/10/25期限のV3を取得してから、上記IP/Maskを全アプリに許可(*)
TCP(out)、ローカルポート1024-5000、リモートポート80

(*)起動時navw32.exeだけじゃなく右クリ時explorer.exeとか
色んなアプリから呼ばれるから、あえて特定しないほうが簡単

【証明書使うなら】
ネット詳細プロパの発行元証明書取消確認をOn

ログイン時とエクスプローラ右クリで「ときどき」認証に逝ってFWのログに残る
常時接続だと問題ないだろうけど、右クリ時にもたつくのが気になる場合がある
当然ダイアルアップの人には許せないだろう

【証明書使いたくないなら】
ネット詳細プロパの発行元証明書取消確認をOff

これで上記IP/Maskを遮断してもしなくても勝手に認証に逝くことはない
ログイン時とエクスプローラ右クリ時に、勝手に認証逝くのを防げて右クリ時のもたつきも皆無
代わりにモジュール改竄のリスクを負うが、MD5とか覚えてるFWならあまり気にすることはない

----- こんなもんでしょうか -----

182 :138書いた本人が連続カキコ:04/01/15 16:51
ちなみにMTT-ME BA6000、Kerio PFW 2.1.5、NAV2003の条件下の話でつ

183 :名無しさん@お腹いっぱい。:04/01/15 17:17
しかしアンチウィルスのモジュールが書き変えられる条件って割れ以外に考えられないが
本当に外部から改竄されるようじゃ、セキュリティ以前の問題じゃなかろうか
あ!LiveUpdateで改竄されたな、実際(w

184 :前スレ300 ◆w795LO9.Wo :04/01/15 17:29
138書いた本人さん乙。

ところで、シマンテックとMS以外で、どこがコード署名使ってるんだろう?と
いろいろ探してるんですが、今見てるのが古めの環境のせいか、ちっとも見当たらない。
というか全然見当たらない。みなさんのお手持ちの .exe .dll .ocx なんかで

・シマンテック、MS以外の署名
・ベリサイン以外の証明書

のものありませんか?

確認方法は、

プロパティに「デジタル署名」タブががある場合に
デジタル署名→詳細→証明書の表示で証明書を表示

です。これで表示した証明書が

(1)発行先がシマンテック、マイクロソフト以外のもの
(2)発行元がベリサイン、マイクロソフト以外のもの
を見つけたら、

(1)発行先:
(2)発行元
(3)ファイル名:

を教えて頂けないでしょうか。

このオナスレをどれくらいの人がワッチしているかはわかりませんが
こういう調査は「数」がパワーを発揮するので。よろしくおながいします_o_。


185 :前スレ300 ◆w795LO9.Wo :04/01/15 18:03
現在、ソフトウェア・ベンダーは、Authenticode で以下のファイルに署名することができます。

.cab files
.cat files
.ctl files
.dll files
.exe files
.ocx files

http://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/intro_authenticode.asp
冒頭当たりを超訳

186 :前スレ300 ◆w795LO9.Wo :04/01/15 22:34
>>184-185

協力依頼あげ。

187 :名無しさん@お腹いっぱい。:04/01/15 23:15
協力したいが、目ぼしい所でIntelやApple、
はたまたVeriSignの物まで署名付きの物は見つからない。

188 :前スレ300 ◆w795LO9.Wo :04/01/15 23:23
あ、この調査の狙いは
「コード署名なんて実際にはノートン以外にはめったにないのではないか?」
という仮説立証のための情報収集です。

だって、コード署名って証明書一つに付き年間9万円かかるんだよ。年間。

おまけにベリは

http://www.verisign.co.jp/codesign/help/faq/200019/index.html
Q>コードサニング証明書はどのような単位で取得する必要がありますか。

A>部門(Division)および製品などの単位で取得してください。
コードサイニング証明書を申請する際には、証明書の情報として 組織名(Organizational)及び 部門(Division)を指定します。
部門・部署単位等、証明書の管理責任を負える単位で取得してください。

などと仰っているし。






189 :前スレ300 ◆w795LO9.Wo :04/01/15 23:30
特定アプリについての「なかった報告」も募集。

メーカー/ソフト名/バージョン/グレード等
なかった。

てな感じ。

190 :前スレ300 ◆w795LO9.Wo :04/01/15 23:36
あらあら経済産業省(笑)

(注意喚起)Web版ITEM2000Version2.0.0の動作環境としてJRE1.4.1_05以前をご使用の申請者の方へ

平成16年1月13日
経済産業省
e-METI推進室

平成15年12月1日にリリースした「経済産業省電子申請システム 申請者用ソフト Web版ITEM2000Version2.0.0」は
JREのコード署名を利用しており、JREに含まれるコード署名用のルート証明書「verisign class 3 ca」が平成15年1月8日に有効期限切れとなりました。
このため、ITEM2000(Web)Version2.0.0の起動時に有効期限切れを示すメッセージが表示される場合があります。
JRE のバージョンが「1.4.1_05以前」の場合には、最新バージョンである「1.4.1_06」に変更することで、有効期限切れのメッセージは出力されなくなり、正常に動作することを確認しております。
このため、JREのバージョンが「1.4.1_05以前」の場合には、「JRE1.4.1_06」へアップグレードすることをお勧め致します。
詳細についてはサン・マイクロシステムズのセキュリティ情報(http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436)をご参照ください。


http://www.meti.go.jp/application/chui6.html

191 :名無しさん@お腹いっぱい。:04/01/16 00:49
>>177
> ・コード署名は、タイムスタンプがあれば証明書の有効期限切れ後でも有効という仕様。
> ・だから、証明書の期限切れ後にCRLを参照するのも仕様通りの動作。

失効した証明書の有効期限が切れたらCRLから削除するポリシーのベリ。

192 :名無しさん@お腹いっぱい。:04/01/16 00:53
>>188
> コード署名って証明書一つに付き年間9万円かかるんだよ。年間。

サーバ証明書って12万くらいかかるでしょ。年間。

193 :前スレ300 ◆w795LO9.Wo :04/01/16 01:09
>>192
>> コード署名って証明書一つに付き年間9万円かかるんだよ。年間。
>
>サーバ証明書って12万くらいかかるでしょ。年間。

ううむ、上がっているようです。
http://www.verisign.co.jp/server/products/

商品の違いがいまいちよくわからんな。

194 :蕪木ら某 ◆Googl8RmwA :04/01/16 01:23
>>183
http://service1.symantec.com/SUPPORT/INTER/navjapanesekb.nsf/jp_docid/20031016210645958
...
http://service1.symantec.com/SUPPORT/INTER/navjapanesekb.nsf/jp_docid/20030704143549958
...

http://www.symantec.com/region/jp/news/year02/020919.html
...

???

195 :名無しさん@お腹いっぱい。:04/01/16 01:24
http://crl.verisign.com/Class3SoftwarePublishers.crl
このCRLの次回更新日は、今年の4月10日だよね。
べりサインは、4月10日までにCRLを更新するんでしょうかね?
しないと、また、1月8日の騒ぎが再発しそうですね。
ということは、タイムスタンプありのコード署名をやっている場合は、
CA局の運用をやめたとしても、一生CRLを出し続けないと
いけないってことですか?
地獄ですね・・・

196 :名無しさん@お腹いっぱい。:04/01/16 02:05
NAV2002ですが、以下の手順で crl.verisign.com へのアクセスを行うことを確認できます。

(1) NIS2002などで、crl.verisign.com へのアクセスを監視するように設定
(2) IE でインターネット一時ファイルを削除
(3) NAV2002 のタスクトレイアイコンをダブルクリック

これで crl.verisign.com へアクセスします。
一度アクセスすれば、再度、タスクトレイアイコンをダブルクリックしても
インターネット一時ファイルにキャッシュされているCRLを使用しますので、
アクセスには行きません。
インターネット一時ファイルを削除した後、(3) をすれば、また、アクセスにいきます。

197 :名無しさん@お腹いっぱい。:04/01/16 02:26
>>196
この件で、たとえば、4月10日までにベリサインがCRLを更新しなかった場合
どうなるかというと、

(1) 4月11日に NAV2002のタスクトレイアイコンをダブルクリック
    ↓
(2) Windows はキャッシュのCRLが、次回更新日時を過ぎていることを
確認すると、そのCRLは使用せず、新しいCRLを取得しようとします。
Windowsは、ベリサインのサイトからCRLを取得してキャッシュに入れます。
しかし、次回更新日時を過ぎたままです。
    ↓
(3) 再度、タスクトレイアイコンをダブルクリック。
    ↓
(4) (2) の動作が再び実行。

という感じになります。
NAV2003の場合は、ダブルクリックが右クリックになるわけですね。

198 :前スレ300 ◆w795LO9.Wo :04/01/16 02:55
今日思ったこと。
・Windows自体は、コード署名の確認は、WEBから持ってきた実行可能ファイルを実行したり、直接インストールしようとした時にくらいしかチェックしていないっぽい。
・だってFW入れてる人。ノートンの特定のファイルからしかcrl呼び出し無いんでしょ?
・だから、システム内での通常の動作でコード署名が確認されているのなら、それはOSじゃなくアプリ自身がやっている可能性が高いんじゃないか?
・例えば、自分とこのモジュールだけど、別実行ファイルや別DLLになっているものを呼ぶときに、時々自分でチェックしている、とか。
・例えば、システムの起動時とか、終了時とか。なぜか右クリックの時とか(笑)。
・でもって、改竄とかされてると >>194 で紹介されているようなメッセージが出たりとかするのでは?
・(モジュール改竄テストはやってみたんだけど、うまくエラーが起こせなかった。)
・これがいわゆる
『プログラムのセキュリティ維持のため、シマンテック製品は定期的にシステムコンポーネントの整合性を確認する作業を行っていますが』
ってやつなのかな?と。

・コード署名のCRLなんか無視してもよさそうだけど、サーバー証明書は話が別!

・ならいっそ、CRLテストは有効にして、コード署名のルート証明書消しちゃうか(暴論)?



199 :前スレ300 ◆w795LO9.Wo :04/01/16 02:57
>>197

コンピューターの時計を4月10日以降に進めると、遅延発生が実験できますよ。
オレやってみたけど。
NAV2003だと、なつかしの右クリ重が。
あの日ほどの激重ではないけど
クリるたび反応が重い。

2ちゃんねるを見ているよい子は絶対に真似しちゃだめだよ。
Don't try this at home.

200 :前スレ300 ◆w795LO9.Wo :04/01/16 03:01
>>195
少なくとも2003は、今日のLiveUpdateでccと名の付くモジュールの署名は別のものになったので
そいつは、現在も毎日更新されているCRLを見に行きます。

ベリがパワーを10倍に増やした、というのを信じれば(笑)
1/8ほどひどいことにはならないかもしれません。

あと、4/10は土曜日なので
閉まっているオフィスも多いかも。

201 :前スレ300 ◆w795LO9.Wo :04/01/16 03:04
今、自動的に指定フォルダ以下から、署名のあるファイルを見つけてくるスクリプトを構想中。
本当は署名の内容まで確認できればいいんだけど。
どっとねっとだとできるんかな?


202 :前スレ300 ◆w795LO9.Wo :04/01/16 03:12
>>190
java関連の署名は、MS仕様のコード署名とは別の、
ベリサインが言うところの「オブジェクト署名」ってのを使うようです。
これにはタイムスタンプ機能が無いため、
オブジェクトの署名の有効期限=証明書の有効期限
ってことになっちゃうみたいですね。

電子政府関係も、いまのところ各省庁の足並みがバラバラで
java使うところも、省ごとで指定のJREのバージョンが違ってたり平気でします。

おまけに、法務省の登記情報閲覧サービスなんか
なんと今やレア・アイテム化したMSVM限定です。
なんとさらにSUNのVMには未対応です(笑)


203 :前スレ300 ◆w795LO9.Wo :04/01/16 03:15
MS仕様のコード署名について
タイムスタンプをサポートしているのはベリサインだけ
と豪語してますから、MSのコード署名を使うなら、ふつーベリサイン
ってことにしかならないかも。
だって署名の有効期限を気にしなくていいわけだから。

でも、WEBから直、実行ファイルを撒くという
本来コード署名が想定している使い方以外で
わざわざ金払ってコード署名使おう、なんて奇特な人も少ないかも。
シマンテックぐらいか(笑)

でもさらに。.net framework では、システムにインストールするモジュールには
すべて署名が入ってないといかんそうです。
そりゃ大変だ。もういっつも証明書の有効性確認しまくりかも。
(ここいらは事実誤認の危険性あり。)

204 :名無しさん@お腹いっぱい。:04/01/16 03:18
> おまけに、法務省の登記情報閲覧サービスなんか
> なんと今やレア・アイテム化したMSVM限定です。
> なんとさらにSUNのVMには未対応です(笑)
クライアント端末には極力なにもインストールさせたくないという
要件があるんでしょう。

205 :前スレ300 ◆w795LO9.Wo :04/01/16 03:23
>>204
>クライアント端末には極力なにもインストールさせたくないという
>要件があるんでしょう。

多分最初の主旨はそうだったんでしょうけど、今では転じて災いとなり、
自分の機械の出荷状態が WindiwsXP SP1a の人は、
幻のアイテム、MSVMを探してこないと利用できない、という有様です。

http://www1.touki.or.jp/GFAQ.html#Q14A2

206 :名無しさん@お腹いっぱい。:04/01/16 03:38
すねてないでMSVM続投してくださいよ>MS
サポート終了が延期されてほっとした人たち多数だと思います。

あと、>>190を見るとどうもSunJVMはCAPI未対応らしい。
なので、1月8日問題は起こらなかったが>>190みたいな事が起こると。
どっちもどっちだと思いたいよ私は。

207 :前スレ300 ◆w795LO9.Wo :04/01/16 03:40
あ、もしかしてMSVM継続配給のために
Windows98/Meのサポート延長したのか(笑)?
(んなわけはない。)

まあ裁判からみだから仕方あんめえなぁ>MSVM終了

208 :名無しさん@お腹いっぱい。:04/01/16 03:43
> どうもSunJVMはCAPI未対応らしい。
ごめん。対応してた。ttp://java.sun.com/products/plugin/1.2/docs/ja/nsobjsigning.html
有効期限切れ警告が出た人たちは証明書自動更新パッチをあててなかった人たち?


209 :名無しさん@お腹いっぱい。:04/01/16 03:46
MS:みんながぶーぶー言うならMSVMなんてもうやめてやらぁあほー
みんな:急にやめられたら対応しきれねぇだろー。(違う意味でぶーぶー)
MS:(それみたことか)じゃサポートだけはちょっと伸ばしてやるぞよぞよ。
みんな:ちょっと安心
MS:でも再配布なんてしてやらんもんねー。
みんな:(やれやれ)

210 :前スレ300 ◆w795LO9.Wo :04/01/16 03:51
>>208
Solaris サポートなし サポートなし

わははは。

CAPI対応=Authenticode対応、というわけではないのね。
ちょっと早とちりしてた。

211 :名無しさん@お腹いっぱい。:04/01/16 03:54
> CAPI対応=Authenticode対応、というわけではないのね。
> ちょっと早とちりしてた。
わしも。

Authenticode ってのは、あなたが言うところの「MS仕様のコード署名」だね?
まぁ、、あんま知らんでもいい知識か?>Authenticode

212 :名無しさん@お腹いっぱい。:04/01/16 04:04
>>177
> ・X.509の仕様では、CRLは次の更新予定日までにちゃんと
> 出さないといけないことになっている。
おぉ、まじで?
以下RFC3280
CRL発行者は,以前のすべてのCRL と比較して等しいか
遅いnextUpdate 時刻を持つCRL を発行すべきである.
「べき」では?

213 :名無しさん@お腹いっぱい。:04/01/16 14:07
Request for Comments: 3280

5.1.2.5 Next Update

This field indicates the date by which the next CRL will be issued.
The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date.
CRL issuers SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs.

http://www.ipa.go.jp/security/rfc/RFC3280-05EN.html#5125


214 :前スレ300 ◆w795LO9.Wo :04/01/16 22:12
>>212-213
しまったー!英語読むのが面倒だったので、これ
http://www.ipa.go.jp/security/rfc/RFC2459JA.html#05125
(注:RFC2459だけど、この部分の原文はRFC3280と同じ)
をネタにしたんだけど、これの訳では

次の CRL は示された日付以前に発行されても構いませんが、示された日付後に発行することはできません。
CA は以前のすべての CRL 以後の nextUpdate 日付の付いた CRL を発行すべきです。

になってたんですわ。

原文では、親切にも MUST(…ねばならない) と SHOULD(…すべきだ) は、
全部大文字で強調されてて、出てくる場所がよくわかるんだけど、
問題の部分の前段には MUST も SHOULD も付いてない。
「発行することはできません」は、ちょっと誤訳っぽい。


215 :名無しさん@お腹いっぱい。:04/01/16 23:00
https://www2.jcsinc.co.jp/repository/rfc3280-j.pdf
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/crypto/default.asp
http://csrc.nist.gov/pki/twg/y2000/presentations/twg-00-35.pdf
http://csrc.nist.gov/pki/twg/presentations/twg-99-12.pdf


216 :前スレ300 ◆w795LO9.Wo :04/01/17 01:19
>>215
おお、いろいろと情報が。
一番最初の、JCSIのRFC3280日本語訳はオレも見つけてました。
そこでは「5.1.2.5 次回更新(Next Update)」は

次のCRL は,示された日付より前に発行され得るが,
示された日付より僅かでも遅れて発行されることはないだろう.
CRL 発行者は,以前のすべてのCRL と比較して等しいか遅いnextUpdate 時刻を持つCRL を発行すべきである.

となってますな。



217 :前スレ300 ◆w795LO9.Wo :04/01/17 01:25
あら、Class3SoftwarePublishers.crl 更新だ。

有効開始日:2004年1月9日 9:00:00
更新予定日:2004年4月21日 8:59:59

ってのが 15-Jan-2004 18:35 に出てる。
この妙な更新時刻は一体なんなんだろう。

どうせなら、有効期限3年くらいのCRL出せよな。MS向けに。


218 :名無しさん@お腹いっぱい。:04/01/17 14:22
あの、1月7日問題での対処法で「確認を取り消す」にしたまま
ネットで買い物しても平気なんでしょうか?

219 :名無しさん@お腹いっぱい。:04/01/17 16:07
>>218
超危険。

220 :前スレ300 ◆w795LO9.Wo :04/01/17 19:19
試しにCRLの日付をパッチしてみた。
Wクリで表示できたので「やった!」と思って
組み込んで確認してみたら…だめだった。
そりゃ署名入ってたら改竄できんわなぁ、普通…。


221 :前スレ300 ◆w795LO9.Wo :04/01/17 19:23
>>218
とにかく慎重にいくのであれば
重くても我慢して「確認する」で使うか。
https:// のサイトで買い物する前後で手動でON/OFFするか、
でしょうな。

セキュリティに関しては「大丈夫」とか「危険はほとんどない」とか
他人には、さしたる根拠も無しには言えないからなあ。
あくまで自分の判断で
わかんなければ安全な方に振るしかない。

とりあえず一番安全なのは、重くても我慢して「確認する」で使う
もしくはパソコンの電源を入れない。



222 :名無しさん@お腹いっぱい。:04/01/17 21:09
買い物専用のユーザアカウント立てるよろし
セキュ最優先で、余計な権限は与えない

223 :名無しさん@お腹いっぱい。:04/01/17 21:37
人間の証明

224 :前スレ300 ◆w795LO9.Wo :04/01/17 21:41
>>222
>買い物専用のユーザアカウント立てるよろし
>セキュ最優先で、余計な権限は与えない

あ、それいいアイディアですね。
お気に入りも買い物系はそっちだけに登録して。


225 :名無しさん@お腹いっぱい。:04/01/17 21:41
>>223
帽子でもなくされましたか?

226 :前スレ300 ◆w795LO9.Wo :04/01/18 01:29
>>218 >>221
訂正。
サーバー証明書の取り消しを確認する (再起動が必要)
 →SSL通信時の証明書のCRL確認

発行元証明書の取り消しを確認する
 →プログラム署名(Authenticode)の証明書のCRL確認

だと思うから、後者をOFFにしても通信には影響ない
はずだと思う…。

ていうか、前者はデフォルトでOFFのようなんだが。

227 :前スレ300 ◆w795LO9.Wo :04/01/18 03:11
「2004年1月8日事件」についてまとめてみました。

http://app.memorize.ne.jp/d/14/00211/2004/01/18/18/0000000002
長いです。


228 :前スレ300 ◆w795LO9.Wo :04/01/18 11:55
今日わかったこと
・マイクロソフトのコード署名 Authenticode は、元々は、webページの閲覧時に、webから出所の明らかでないActiveXコントロールが勝手にシステムに組み込まれることを防ぐための技術である。
・Windows2000以降では、デバイスドライバーのインストール時に、ドライバーの署名の有無をチェックする機能が追加されている。
・さらに将来的には、マシンで実行されるすべてのコードに対して署名の有無をチェックする機能を追加する予定らしい。

http://yougo.ascii24.com/gh/28/002870.html
ASCII24 > デジタル用語辞典:Microsoft Authenticode

http://www.itmedia.co.jp/news/0011/21/e_whistler.html
「Whistler」に署名なしのコードを遮断する機能

http://www.itmedia.co.jp/news/0011/28/e_whistler.html
懸念渦巻く「Whistler」の署名技術活用計画

229 :前スレ300 ◆w795LO9.Wo :04/01/19 17:33
結局は誰か「だけ」が悪かったのではないのだろう。

しかし「セキュリティならなんでもかんでもPKI!」で本当にいいのか?

あるプログラムを「どこの誰が、いつ作ったのか?」を確認する技術を
自分自身のプロダクトの改竄チェックに利用したのは、果たして適切だったのだろうか。
自分ところのモノかどうかだけのチェックなら、PKIのような大袈裟な仕掛けではなく、
もっと簡単にチェックする方法はなかったのか?
(ノートンのウイルス・チェックは、改竄された書名済みファイルをエラーにしないんだよ)

PKIの実運用上の効率とかをちゃんと検証せず
とりあえず在って使えるもの(Authenticode)を利用しただけじゃないのか?

なんかシマンテックの論調は一方的にベリサインに責任を押し付けてるように感じられるけど
シマンテックにも問題はあったんじゃないか?
(証明書期限切れのプログラムを更新しなかった、という話じゃないよ。)

参考:
http://blog.japan.cnet.com/kenn/archives/000947.html
ベリサインの混乱から透けて見えたPKIの問題点
[江島健太郎 / Kenn's Clairvoyance]


230 :前スレ300 ◆w795LO9.Wo :04/01/20 02:27
1/8事件について、シマンテックの日本のサイトは1/12更新のままだけど
アメリカ側の発表が15日に更新されている。

http://service1.symantec.com/SUPPORT/sharedtech.nsf/docid/2004010810205113
After January 7, 2004, your computer slows down and Microsoft Word and Excel will not start

At this time we have not received any reports that Symantec Enterprise products are affected by this problem.
現時点では、私たちは、シマンテック社製品がこの問題によって影響されるという報告を受けていません。

って解釈が正しいなら、事実上の終結宣言ということなんだろうか。
一時回避策の「発行元証明書の取り消しチェックを外す」の記述もなくなってるし。

でも、日本のシマンテックの発表では、いまだに「ベリサイン社と協力してこの問題の解消に取り組んでいます」
らしいぞ(笑)


231 :前スレ300 ◆w795LO9.Wo :04/01/21 10:50
そろそろ机上の調査だけでは煮詰まってきちゃったな。

コード署名はどっちかというと開発者寄りの話題だし
SSLの方は自分で大規模サービスのサーバーを立てる人くらいじゃないと
利用者として単に使うだけなら理屈はさして用はないかもしれないし。

いっそのこと、ひとつAuthenticode対応デジタルIDでも買ってみるかな(笑)



232 :前スレ300 ◆w795LO9.Wo :04/01/22 13:23
とりあえず、MSが仕込んでるCRL自体と同じ内容で、
期限をさらに3年間くらい延長したものを出してはもらえないか、
ダメモトでベリサインのサポートにメールしてみるよ。

だって、発行元:VeriSign Commercial Software Publishers CA の証明書での
コード署名は、2004/01/08 9:00 まで正しくCRLチェック出来てなかったわけだし、
それで今まで特に目立った不具合や不都合はなかったわけだし。

最近のコード署名は、発行者が VeriSign Class 3 Code Signing 2001-4 CA とか
別の名前になっているみたいだから、最近のコード署名のチェックには影響ないだろうし。

「時々ベリサインに接続に行く」こと自体は「仕様です」で済まされそうだからなぁ。
1/8以前の挙動に戻すには、有効期限の長いCRLを内蔵するしかないように思う。
(時計を戻す、は別ね。できるけど現実的ではない。)
CRLの偽造にもチャレンジしてみたけど、さすがに駄目だったし。

なんとかしてくれないかなぁ……。

233 :名無しさん@お腹いっぱい。:04/01/24 11:39
NIS2002起動遅延の改善テスト

準備編(1)〜「証明書」ツールの起動アイコン作成

(1) [ファイル名を指定して実行]で mmc と入力して起動。
(2) [コンソール]→[スナップインの追加と削除]を選択する。
(3) [追加]から、一番下あたりにある「証明書」を選択する。
(4) デフォルトの[ユーザーアカウント]のままで[完了]を選択する。
(5) [OK]でスナップインの追加と削除を終了する。
(6) コンソールルート配下に「証明書」が追加されていることを確認する。
(7) [コンソール]→[名前を付けて保存]で、デスクトップに「証明書.msc」を選択する。
(8) デスクトップに「証明書.msc」という金鎚アイコンが出来ていれば準備完了。

#WinXPで実行する際、(2)と(7)の [コンソール] は [ファイル] に読み替えです。

234 :名無しさん@お腹いっぱい。:04/01/24 11:39
準備編(2)〜インストール済CRLのバックアップ&削除
(1) 「証明書.msc」を実行して証明書ツールを起動する。
(2) [中間証明機関]の[証明書失効リスト]を開く。
(3) 「VeriSign Commercial Software Publishers CA」というのが1つだけあるはずなのを確認する。
(4) それを右クリックして[すべてのタスク]→[エクスポート]を選択し、適当な名前でエクスポートする。(例えば verims040107.crl とか。)
(5) きちんとエクスポートできているのを確認したら、証明書ツール上のさっきのCRLを右クリックメニューから削除する。

235 :名無しさん@お腹いっぱい。:04/01/24 11:39
入替え編〜新しいCRLを取得&インストール
(1) http://crl.verisign.com/Class3SoftwarePublishers.crl にアクセスして、名前を付けて保存する。
(2) 保存した Class3SoftwarePublishers.crl をダブルクリックで開いて「次の更新予定」が2004/04くらいなのを確認して[OK]で閉じる。
(3) 保存した Class3SoftwarePublishers.crl を右クリック→[インストール]で、言われるがままにデフォルトでインストールする。
(4) 証明書ツールで、新しい有効期限のCRLが登録されていることを確認する。
(5) システムを再起動して、起動時間が改善したかどうか確認する。


236 :名無しさん@お腹いっぱい。:04/01/24 12:17
233-235をやってみた所元に戻ったようだ。
DLしたClass3SoftwarePublishers.crlは
各ユーザごとにインストールする必要があるかも?

237 :前スレ300 ◆w795LO9.Wo :04/01/24 12:53
>>236

ご指摘のとおりです。
今のやり方だとアカウント固有になっちゃいます。
各ユーザーごとにイントールする必要があります。
少しやり方を考えてみます。

あと、ずっと直るわけではなく、
インストールしたCRLの次回更新日までの命なので、ご注意を。

238 :前スレ300 ◆w795LO9.Wo :04/01/24 12:55
>>232
>とりあえず、MSが仕込んでるCRL自体と同じ内容で、
>期限をさらに3年間くらい延長したものを出してはもらえないか、
>ダメモトでベリサインのサポートにメールしてみるよ。

というわけで、本当にメールしました。

どうなるかな。

239 :名無しさん@お腹いっぱい。:04/01/24 13:33
次回更新 2004年4月28日
この日が過ぎたらもう一度>>233-235の作業が必要。

240 :名無しさん@お腹いっぱい。:04/01/24 18:44
98SE、NAV2003だとどうするか、だれか知りませんか〜

241 :前スレ300 ◆w795LO9.Wo :04/01/24 19:18
誰か自己解凍&実行CABファイルから中身を取り出す
なるべく簡単な方法知りませんか?

242 :名無しさん@お腹いっぱい。:04/01/24 19:25
実行形式はWinRARで展開できることがあるけど
シェアで試用期間あったかどうだか

243 :名無しさん@お腹いっぱい。:04/01/24 19:35
>>234
>(2) [中間証明機関]の[証明書失効リスト]を開く。
個人だの中間証明機関とかあるとこの一番下の方が
文字化けして読めないのは自分だけですかね

なんか気になるのでだれか教えてください。

244 :名無しさん@お腹いっぱい。:04/01/24 19:38
FPRESS
http://www.vector.co.jp/soft/win95/util/se149414.html
フリーウェア
他に解凍レンジなんかが手軽かも(解凍前に内容確認のオプション入れてないと
全部解凍してしまうが)

245 :前スレ300 ◆w795LO9.Wo :04/01/24 19:59
OS共通・超簡略化バージョン

(1) http://crl.verisign.com/Class3SoftwarePublishers.crl にアクセスして、名前を付けて保存する。(ファイル名はそのまま、場所は C:\ に。)
(2) コマンドプロンプト(MS-DOSプロンプト)を立ち上げる。
(3) updcrl -r C:\Class3SoftwarePublishers.crl と入力して[ENTER]
(「updcrl -r 」まで入力しておいて、保存した Class3SoftwarePublishers.crl をエクスプローラーでドラッグ&ドロップしてくると簡単。もろちんここからコピペしたのでもよい。)

これだけでどうだ!
(3)はバッチにしとくと後で便利だね。


246 :前スレ300 ◆w795LO9.Wo :04/01/24 20:05
>>244
ありがとうございました。
結局、使わなくていい方法を見つけました。

最初はくそ真面目に
http://www.microsoft.com/downloads/release.asp?ReleaseID=28888
から crlupd.exe をダウンロードしてきて、そこから updcrl.exe を抜き出して…
という手順を考えてたんですが、

よく考えてみれば、1/8を境に遅くなった環境であれば、
たぶん crlupd.exe は自動的に実施済じゃないかな?と思って。

もし updcrl -h とやっても、ヘルプが出ずにエラーになる人は、
http://www.microsoft.com/downloads/release.asp?ReleaseID=28888
から crlupd.exe をダウンロードしてきて、それを一度実行してから
もう一度試してみてください。


247 :前スレ300 ◆w795LO9.Wo :04/01/24 20:07
>>240
> 98SE、NAV2003だとどうするか、だれか知りませんか〜

>>245-246 を試してみて、結果を教えていただけませんか?


248 :前スレ300 ◆w795LO9.Wo :04/01/24 20:12
>>243
どんな具合に化けてますか?
http://www.verisign.co.jp/server/help/install/iis5_import.html
の図のような感じで出ているのであればOKだと思うんですが。

249 :243:04/01/24 22:10
>>248
こんな感じです↓
http://v.isp.2ch.net/up/b015e0d2ce2d.jpg

レジストリでみても文字化けしてるみたいです
HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates

困ったな

250 :240:04/01/24 23:17
遅レスすみません。
前スレ300 ◆w795LO9.Woさん、いろいろありがとうございます。
ご指示のとおりやってみましたが、残念ながら、コマンドエラーとなります。
crlupd.exeをダウンロード・実行しても同じでした_| ̄|○
今日のところは、もう寝ます。
明日また試してみます。うまくいったら、また報告しますので。


251 :前スレ300 ◆w795LO9.Wo :04/01/25 00:16
>>249
本当だ。化けてますね。
証明書ストアが壊れてるんだろうか。
IEの修復セットアップとかしたら直るのかなぁ。

ちょっと見当がつかないや、ごめんなさい。

252 :前スレ300 ◆w795LO9.Wo :04/01/25 00:35
>>245
OS共通・超簡略化バージョン・改

(1) http://crl.verisign.com/Class3SoftwarePublishers.crl にアクセスして、名前を付けて保存する。(ファイル名はそのまま、場所は C:\ に。)
(2) コマンドプロンプト(MS-DOSプロンプト)を立ち上げる。
(3) c:\windows\system\updcrl -r C:\Class3SoftwarePublishers.crl と入力して[ENTER]
(「updcrl -r 」まで入力しておいて、保存した Class3SoftwarePublishers.crl をエクスプローラーでドラッグ&ドロップしてくると簡単。もろちんここからコピペしたのでもよい。)

メモ
・MSのパッチで使っている updcrl.exe というツールで、CRLを強制登録する。
・この方法だとCRLを先に削除しておかなくても更新できる。
・mmcを使わないので、98系のOSでも実施できる。
(mmcを使ったほうが、有効期限の確認とかが出来る分、便利。)
・(3)はバッチにしとくと後で便利。
・もし、あなたのシステムに c:\windows\system\updcrl.exe がない場合は、
http://www.microsoft.com/downloads/release.asp?ReleaseID=28888
から crlupd.exe をダウンロードしてきて、それを一度実行すれば現れるはず。
・元に戻したい人も、crlupd.exe をダウンロード&実施。

253 :前スレ300 ◆w795LO9.Wo :04/01/25 00:38
>>250
> ご指示のとおりやってみましたが、残念ながら、コマンドエラーとなります。
> crlupd.exeをダウンロード・実行しても同じでした_| ̄|○

すんません。Windows98はデフォルトでは Windows\System にはパス通ってませんでした。
だからフルパスでコマンド叩く必要があります。

>>252 が改訂版ですんで、また試してみてください。

254 :前スレ300 ◆w795LO9.Wo :04/01/25 01:06
もしベリサインが(事実上の)無期限CRL出してくれたら

(1) http://www.microsoft.com/downloads/release.asp?ReleaseID=28888
の crlupd.exe の中身を一度取り出す。
(2) verisignpub1.crl をその無期限CRLと差し替える。
(Class3SoftwarePublishers.crl →verisignpub1.crl にリネーム)
(3) もう一度 crlupd.exe を作り直す。

これで「ノートン2002&2003稍重解消パッチ」が作れるはずなんだよね。


255 :前スレ300 ◆w795LO9.Wo :04/01/25 01:14
>>254
自己解凍&実行CABを作るツールって、
実はWindows2000以降だと密かに標準で持ってるみたいなんだよね。

http://support.microsoft.com/directory/worldwide/ja/kblight/T006/2/08.asp
自動的に展開される圧縮ファイルを作成するには

もっと詳しい資料としては、IEAKの中のヘルプ ieakhelp.chm がある。
ちゃんと日本語だし。在り処は
http://download.microsoft.com/download/ie6sp1/finrel/6_sp1/W98NT42KMeXP/JA/ieak6.exe

でもinfファイルを使ったインストールCABパッケージって作ったことがないので
今から予習しておこう。ベリサインが無期限CRL出してくれるのに備えて(笑)

256 :240:04/01/25 02:00
>>254さん
起きていてよかった。ありがとうございます。<(_ _)>
どうやらうまくいきました。
ついでに貴サイトにもうかがいました。
なんつうか…巨大ベンダー三竦みって感じですかね…( ;^^)へ..
どれが蛇かな…

ついでに254、255もコピペして保存させていただきました。
無期限CRL、スパッとだして欲しいもんすね…
とにかくありがとうございました。


257 :前スレ300 ◆w795LO9.Wo :04/01/25 02:11
>>256
>>240 さん。うまくいきましたか。よかったよかった。

「充分に長い期限のCRL」(例えば2049年12月31日まで)とかがもし出れば
これはもう事実上無期限と言ってかまわんだろう、ということで
勝手に「無期限CRL」と呼んでいます。
ノートン自身やWindowsの寿命のことを考えると、
実際にはあと3年位でも大丈夫かな?と思います。

>>254-255 は、まだ単なる自分自身への覚え書きです。
「(3) もう一度 crlupd.exe を作り直す。 」と簡単に書いてますが
具体的な手順はワタシ自身まだちゃんと見えてません。

普通に使う分には、わざわざパッチを作らなくても
例のCRLインストールの手順で、無期限CRLをインストールすれば
それでOKになります。

無期限CRLの偽造にもチャレンジしてみましたが、やはり無理でした。
そんなことが出来るようでは、セキュリティじゃないですからね。


258 :名無しさん@お腹いっぱい。:04/01/25 09:34
>無期限CRLの偽造

……あはは……

259 :前スレ300 ◆w795LO9.Wo :04/01/25 10:14
(1) 最も望ましいのは原因側による正しい対応。
(プログラムのアップデート等)
(2) 次に望ましいのは原因側による有効な対応。
(動作に関連する環境の変更等)
(3) どちらもダメなら自己解決。

というわけで、

(1) シマンテックが問題個所を直す
(2) ベリサインまたはMSが内蔵CRLの期限を延長する
(3) うまくいく設定や手順を探す

の(3)の一環です>偽造にチャレンジ
でも、あくまでこれは緊急避難です。
(1)か(2)が実施されれば必要ないわけですから。


すみません。わたくし嘘を申しておりました。
面白そうだからやってみました。



260 :名無しさん@お腹いっぱい。:04/01/25 11:34
wwww


261 :名無しさん@お腹いっぱい。:04/01/25 12:53
NAS以外の製品に乗り換えるのが一番だろう。

262 :名無しさん@お腹いっぱい。:04/01/25 14:22

(4)パッチ当て

という奥の手も…


263 :名無しさん@お腹いっぱい。:04/01/26 01:46
いや久々にhacking魂を見せてもらった気がする。
乗りかかった船なもんでしょうがねえってんで
挙句「面白そうだからやってみました」。
惚れるねえ。


264 :前スレ300 ◆w795LO9.Wo :04/01/26 02:00
いやいや、「しょうがえ」ってな義務感だけでは出来ないですよ。
「面白い」という気持ちがないと続かない。
実際、面白かったですから(笑)

だから、自分としてはもう困っていないので
飽きたらやめちゃうかもしれない。

少なくとも、ベリからなんらかの返事貰うまではやめませんけど。

でも本当に勉強になりましたよ。
ベリのCPSは読むわ
X.509の仕様は読むわ
いくつか頑張って英文ドキュメント読むわ

仕事もこれくらい真面目にすれば……ねぇ(苦笑)

265 :前スレ300 ◆w795LO9.Wo :04/01/26 02:05
全然スレ違いだけど、さらにそんな合間に
Windows Services for UNIX (SFU) 3.5
なんてのをインストールして動かしたりしてるし。

http://www.microsoft.com/japan/windows/sfu/
Services for UNIX 3.5 ホーム

あははは。オレのマシンのWindows2000proで
Korn Shell 動いて perl v5.6.1 動いてるよ(笑)

266 :名無しさん@お腹いっぱい。:04/01/26 11:36
>仕事もこれくらい真面目にすれば……ねぇ(苦笑)

まったくですねwww
なぜこういうことには、スイッチが入るのか?
ついでにこれも究明してほすいwww


267 :蕪木ら某 ◆Googl8RmwA :04/01/26 11:56
>>265
http://pc.2ch.net/test/read.cgi/unix/1015676742/l50
(w

268 :前スレ300 ◆w795LO9.Wo :04/01/26 18:16
>>238
> >>232
> というわけで、本当にメールしました。
> どうなるかな。

さっき見たら、ベリサインからメールが来てました!

件名:【日本ベリサイン】『実践ハッキングおよび防衛術習得トレーニング』のお知らせ

【注】本メールは、ベリサインからの情報配信を希望されたお客様にのみお送りしています。

ああああ。そういやだいぶ前に希望してた事あったような気がする。
とはいえ、すげえタイミングで来たもんだな(笑)。

CRLをハックしようとしてたのがバレたか!?


269 :名無しさん@お腹いっぱい。:04/01/26 18:26
>268
( ・∀)人(∀・ )通報しますた!

270 :前スレ300 ◆w795LO9.Wo :04/01/27 01:22
>>268
いえいえ。実はそのメールの前に、ちゃんと一次回答が来てました。
カスタマーサービスの方からで、簡単にまとめれば

・担当者が詳細の確認をする。
・担当から返信がある。
・時間はかかる。

というような内容でした。
問い合わせ番号も付いてました。
とりあえずは、見てはもらった、と言うことですね。

これからどうなるのかが楽しみです。


271 :前スレ300 ◆w795LO9.Wo :04/01/27 01:22
>>269
あはは。通報されちゃったよ(笑)

272 :前スレ300 ◆w795LO9.Wo :04/01/29 02:23
Class3SoftwarePublishers.crl 27-Jan-2004 17:43 119k

27日に更新あり。
もしや?と思いダウンロードして開いてみるが
次回更新日が5月1日になってるだけ。
なーんだ。

273 :前スレ300 ◆w795LO9.Wo :04/01/29 02:25
しかし Class3SoftwarePublishers.crl は
なんでいつも半端な時間に更新してるんだろう。

他が午前3時でほぼ揃っているだけに、なんか気になる。


274 :名無しさん@お腹いっぱい。:04/01/29 02:31
>273
無効になったり期限が切れたりする証明書が出たときに、
その都度出してるんじゃないの?

てか、Liveうpだてみたいに自動でcrlうpだてしてくれるスクリプトでも作った方がいくない?

275 :前スレ300 ◆w795LO9.Wo :04/01/29 02:53
>>274
> >273
> 無効になったり期限が切れたりする証明書が出たときに、
> その都度出してるんじゃないの?

現在、当方の調査によると、
http://crl.verisign.com/Class3SoftwarePublishers.crl は、
次回更新日まで約3ヶ月後のものが、ほぼ1週間ごとに更新されていたようです。
ですけど今回は、24日→27日と、それより短い間隔で出ました。

> てか、Liveうpだてみたいに自動でcrlうpだてしてくれるスクリプトでも作った方がいくない?

それは考えてはいます。
今後ベリサインがなんも対応しなかったら
真剣に作ろうと思ってます、はい。


276 :名無しさん@お腹いっぱい。:04/01/29 04:11
>275
>次回更新日まで約3ヶ月後のものが、ほぼ1週間ごとに更新されていたようです。
>ですけど今回は、24日→27日と、それより短い間隔で出ました。
この3日間で緊急を要する失効があったとか。

>今後ベリサインがなんも対応しなかったら
>真剣に作ろうと思ってます、はい。
作りがアレでDoSツールになってしまうワナw

277 :名無しさん@お腹いっぱい。:04/01/29 05:01
窓の杜を見て、あっさりバックアップも取らずに証明書を削除して入れ直したのですが、
「www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign」と、その一つ上のClass 2〜と言うのも一緒に削除してしまいました。
前者は日本ベリサインから入れ直す事ができましたが、後者は名前もはっきりせず、
どれを入れ直せばいいのやらわかりません。
どなたか教えてください・・。orz

278 :前スレ300 ◆w795LO9.Wo :04/01/29 06:14
>>276
> この3日間で緊急を要する失効があったとか。

サイズが同じで変わってません。
コンペアもかけてみましたが
どうやら同じ内容と思われます。

> 作りがアレでDoSツールになってしまうワナw

わはは。それはあるかもw


279 :前スレ300 ◆w795LO9.Wo :04/01/29 06:18
>>277

ルート証明書じゃなくて中間証明機関なら
無くても特に致命的ではないかも。

ルート証明書なら、「ルート証明書の更新」で
古いものも元に戻ったと思う。

別のマシンがあるなら、
そいつから無さげなやつをエクスポートしてきて
インポートするといいです。

コピー&ペーストが「コピペ」なら
エクスポート&インポートは「Xインポ」?

280 :前スレ300 ◆w795LO9.Wo :04/01/29 06:22
>>279
> ルート証明書なら、「ルート証明書の更新」で

正確にはWindiws Update の
「ルート証明書のアップデート」ね。

281 :277:04/01/29 07:46
>>279-280
レスありがとうございます。
別のマシンも持ってない為、ベリサインからそれらしい物をDLしてインポートしてみたり、
IEの再インストールもやってみましたが復活しません・・・。
色々検索してみた結果、ルート証明書ではなく、
中間証明書の「VeriSign Class 2 CA Individual Subscriber-Persona Not Validated」っぽい気がします。
期限が件の中間証明書と近い2004/01/07あたりだったのを理由に削除したのですが、
もう必要ない物だったんでしょうか?


282 :名無しさん@お腹いっぱい。:04/01/29 08:32
>>277
VeriSign Class 2 CA - Individial Subscriber
Class 2 Public Primary Certification Authority
2004/01/07 <すべて>

漏れの環境では上のようになってたけど。

283 :名無しさん@お腹いっぱい。:04/01/29 12:07
Class 2 の Ind.〜は元々期限切れで必要無いかと。
またアメリカとカナダの住民しかインストールできないとか。

284 :名無しさん@お腹いっぱい。:04/01/29 16:16
3か月分の奴しか出してくれないのかよ。
ケチだなぁ、ベリ公。

285 :名無しさん@お腹いっぱい。:04/01/29 18:26
今日、接続時に↓こんなの拾いますた。
RSASecureServer.crl

286 :名無しさん@お腹いっぱい。:04/01/29 21:44
ようやく日本尿豚が証明書更新しろと言ってるらしい
ttp://service1.symantec.com/SUPPORT/INTER/navjapanesekb.nsf/jp_docid/20040108142217958
一体いくつインポートすりゃええんじゃ!

287 :名無しさん@お腹いっぱい。:04/01/30 01:05
>>284
薬みたいな言い方だね

288 :名無しさん@お腹いっぱい。:04/01/30 01:09
オトモダチの薬剤師のお姉さまが、向精神薬とか処方する度に同じようなこと言われるそうだ

289 :名無しさん@お腹いっぱい。:04/01/30 02:29
漏れの知ってるおばちゃん(!)の薬局には
かなりキてるそうなあんちゃんが「ブロン」箱買いに来るらしい

290 :277:04/01/30 06:32
>>282
あー、やっぱりそんな感じの名前の奴ですよね。

>>283
では、特に気にしなくていいのかな・・・。
普段あんまりいじらない所なのでさっぱりで。

お二人ともレスありがとん。
上の方で期限が切れた物も必要とかなんとかってレスがあったので少し気になってましたが、
そんなに気にしなくていいのかな。


291 :名無しさん@お腹いっぱい。:04/01/30 13:07
>>286
これ2028/08/02まで、一気に期限が延びたね。

292 :名無しさん@お腹いっぱい。:04/01/30 13:29
>>286の適用も済ませて、NAV2003の本日付けLiveUpdate動かしたところ、Common Client更新が入ってた
一応受け入れたら、また違う失効リスト取りに行くようになってる
とりあえず失効リストに以下の2つを追加しとく
http://crl.verisign.com/Class3CodeSigning2001.crl
http://crl.verisign.com/pca3.crl

いったいどれだけ失効リストが増えるんだろう…

293 :名無しさん@お腹いっぱい。:04/01/30 19:50
NIS2002ユーザーですが、有効な証明書をインストール出来ず困って
います。

日本べリサイン(tps://)から証明書をインストールしたら「中間証明機関」
ではなく、「ほかの人」にインストールされてしまいます。
又、その証明書の詳細を確認すると「内容不明でエラー」となっていました。

NIS2002で有効な証明書のインストールに成功された方、手順を教えて
頂けないでしょうか。 お願いします。

294 :名無しさん@お腹いっぱい。:04/01/31 06:30
このスレいつまで続くの?

295 :名無しさん@お腹いっぱい。:04/01/31 08:35
NAVのウイルス定義に含まれるDLLから証明書をインポートしてもいいかも。
もちろん最新版(現在インテリの1/30付けが最新)からね。

296 :名無しさん@お腹いっぱい。:04/02/01 00:04
>>293
今回インストールされた証明書は
中間証明機関でも、失効でもなくて
信頼された証明書としてインストールされてるよ。

Liveupdateや、シマンテックの説明通りにインストールしたなら大丈夫だろ。

297 :名無しさん@お腹いっぱい。:04/02/01 03:09
未だに何の問題も解決出来ていないのは漏れだけなのでしょうか…
>>286のURLの通りに証明書をインポートしたもののまったく何の変化もなし。
相変わらずWordはファイル開こうとすると落ちるし、
Norton AntiVirus 2003の定義ファイルもエラーのまま…などなど。

本当にNortonが原因かも怪しく思えてきた。ワケワカンネーヨ。・゜・(/Д`)・゜・。

298 :名無しさん@お腹いっぱい。:04/02/01 09:43
>286の方法、acceptをクリックした後ダウンロードできませんと言われてしまう...
IE使用、FW停止、IEセキュリティ設定甘めでもだめぽ。

299 :名無しさん@お腹いっぱい。:04/02/01 11:49
ttp://misttimes.cocolog-nifty.com/blog/2004/01/post_7.html
↑こういう方法もある。
ためしてみそ

300 :名無しさん@お腹いっぱい。:04/02/01 14:31
>299の方

おかげで中間証明機関にインストール出来ました。
大変有用な情報提供、有難う御座いました。

ただし、NIS2002で「起動激重」「通知領域からアイコン消滅」等の
現象は改善されませんでした。

NIS2002で改善に成功された方、手順を教えて頂けませんでしょうか。



301 :名無しさん@お腹いっぱい。:04/02/01 15:26
>>300
OSはなんだろう(?.?)
http://pc.2ch.net/test/read.cgi/sec/1075381423/
こっちのほうの頭のレスあたりをみれば解決するかも。
がんがれ


302 :297:04/02/02 07:45
>>299の方法も試してみたが変化なしだった。
ちゃんとインストールできていないんだろうか。
何が悪いんだろう…ついにエクスプローラーもうまく動かなくなってきたよ。
もうダメぽ・゜・(/Д`)・゜・


303 :名無しさん@お腹いっぱい。:04/02/02 11:21
IEの詳細設定で「発行証明書の取り消しを確認する」のチェックを外してもダメ?
もしそうなら、セーフモードで立ち上げて
アンインスコしてみる?もし正常にアンインストールできない場合は、こちら
http://service1.symantec.com/SUPPORT/INTER/nisjapanesekb.nsf/jp_docid/20020416202403947

これでまともに動けば、ノートン先生のせいだろうし、そうでなければ、別の原因が考えられる。

304 :名無しさん@お腹いっぱい。:04/02/02 12:00
>>300
NIS2003ですが、私も同じ状態です。
「起動激重」
「タスクトレイに、スタートアップ登録のアイコンが表示されず」

OSはXPです。

305 :前スレ300 ◆w795LO9.Wo :04/02/02 12:47
おひさし。

激重なみなさん。まず、
IEの詳細設定で「発行証明書の取り消しを確認する」のチェックを外してもダメ?
これやっても激重だとすれば、他に原因があるかも。

それで直るならCRL関連が原因だから
>>233-236>>252 をお試しあれ。

306 :前スレ300 ◆w795LO9.Wo :04/02/02 12:56
>>286
> ようやく日本尿豚が証明書更新しろと言ってるらしい

今更何を寝ぼけたことを(苦笑)>シマンテック日本

1/7事件に関するアメリカ本国版のアナウンスでは
最初から証明書更新しろ、と言っているので
ようやくそれを足したのかも。

しかし再三ここで言っているように
1/7事件の真の原因は特定のCRLなので
証明書更新したって改善なんかするわけない。

307 :前スレ300 ◆w795LO9.Wo :04/02/02 13:15
>>238
>>268

日本ベリサインから正式な回答が1/29に来てました。
要約すると、

・この度の貴重なご意見は、米国ベリサインにフィードバックする。
・CRLの配布はCPSに基づき提供しており、特別なものは現時点では具体的な対応の予定はない。
・何か進展があったらウェブサイト等で連絡する。

完全に予想通りの回答です。
「CRLの配布はCPSに基づき提供しており」って、2001年のMSへの対応はどうなんだ?と。

まぁ、日本法人に言ってもしゃあないよね。
回答してきたのはマーケティング部の課長だし。
頑張って英訳して、米ベリサインに直接突撃するしかないか。
まんどくさい。

308 :304:04/02/02 14:53
>>305
「発行証明書の取り消しを確認する」のチェックを外しても激重です。

マウ筋なぞは、アイコンが表示されていないのに正常に動作したり、
スタートアップ関連に問題がありそうです。
Atokパレットが表示されないのが痛かったが、
ジャストシステムのサイトで解決できた。

とりあえず、プログラム→スタートアップ登録はランチャのみでしのぎます。


309 :前スレ300 ◆w795LO9.Wo :04/02/02 15:06
>>308
じゃあCRLとは関係ない事象だろうね。

http://service1.symantec.com/SUPPORT/INTER/nisjapanesekb.nsf/jp_docid/20031021155842947
OS 起動時に Norton Internet Security の読み込まれるタイミングを変更する方法

これ調整しても変わんないかな?

あと、「発行証明書の取り消しを確認する」のチェックはアカウント固有だから
administrator も外しておくとよいかも。
(これは全然見当はずれかもしれんけど)

310 :304:04/02/03 01:06
>>309
ありがとうございます。

酔眼では厳しそうなので、明日にでも試してみます。


311 :名無しさん@お腹いっぱい。:04/02/03 09:00
NT系OSの場合、中間証明書は、ユーザー毎のストアにいれずに、
ローカルコンピュータのストアに入れて、ユーザーごとのストアは削除しましょうね

312 :名無しさん@お腹いっぱい。:04/02/03 17:49
> ローカルコンピュータのストアに入れて、ユーザーごとのストアは削除しましょうね
詳しく

313 :名無しさん@お腹いっぱい。:04/02/03 20:18
>312
ここの過去レスを参考にしてMMCの証明書ツールを開いている状態から
追加で対象がローカルコンピュータの証明書ツールを作る。
そうすると両者がツリー状に表示されるから
ユーザー側の証明書をD&DでローカルPC側にコピる。
削除するか?って聞かれたらNOにしておいた方がいいと思う。

314 :304:04/02/03 23:52
>>309
改善しました。

OS再インスコも思慮していただけに、感謝。

315 :前スレ300 ◆w795LO9.Wo :04/02/03 23:55
>>314
> >>309
> 改善しました。

結局どっちが効いたの?
組み込みタイミングの調整の方かな?


316 :前スレ300 ◆w795LO9.Wo :04/02/04 00:08
>>313
証明書ツールの起動アイコン作成法を改版しました。

「証明書」ツールの起動アイコン作成(XP,2000等NT系OS用)

(1) [ファイル名を指定して実行]で mmc と入力して起動。
(2) [コンソール]→[スナップインの追加と削除]を選択する。
(3) [追加]から、一番下あたりにある「証明書」を選択する。
(4) デフォルトの[ユーザーアカウント]のままで[完了]を選択する。
(5) もう一度[追加]から「証明書」を選択する。
(6) 今度は[コンピュータカウント]を選択して[次へ]を押す。
(7) デフォルトの[ローカルコンピュータ]のままで[完了]を選択する。
(8) [OK]でスナップインの追加と削除を終了する。
(9) コンソールルート配下に「証明書 -現在のユーザー-」と「証明書 (ローカル コンピュータ)」が追加されていることを確認する。
(10) [コンソール]→[名前を付けて保存]で、デスクトップに「証明書.msc」を作成する。
(11) デスクトップに「証明書.msc」という金鎚アイコンが出来ていれば準備完了。

# WinXPで実行する際、(2)と(10)の [コンソール] は [ファイル] に読み替えること。

# 保存先は別に「管理ツール」のままでもよい。その場合、[スタート]→[プログラム]→[管理ツール]→[証明書]というルートでの起動となる。


317 :前スレ300 ◆w795LO9.Wo :04/02/04 00:38
>>96-101
!最重要!

改めて。
「グローバル・サーバID用の中間CA局証明書の1/7期限切れの問題」ってのは、
SSL通信時の問題であって、今回のノートン激重とは直接関係ない。
だから、ノートンのユーザーがあわててこれに対処する必要はない。

逆に、慌てて中間証明書ではなくルート証明書を削除したりとかは 絶対にしてはいけない。

期 限 切 れ の 証 明 書 は 別 に 削 除 す る 必 要 は な い 。
(不要なものがわかる人がわかって削除するのはかまわないけど)

中間証明書は、なくてもそんなに困ることは無いかもしれないけど
ルート証明書は不用意に削除してはいけない。
もし削除してしまった場合は、Windows Updateの「ルート証明書のアップデート」をやるべし。
(重要な更新ではなくWindowsの方なので注意)

既に一度やっている人は、もう一度できないみたいなので…(直リン発掘)
http://www.download.windowsupdate.com/msdownload/update/v3-19990518/CabPool/rootsupd_882A0A0D36FE385B042EDEC58E1F0E7715BDA1BB.exe

ノートン激重の対策としてではなく、一般論として
ルート証明書のアップデートはやっておいたほうがいいと思う。

中間証明書は、なくてもそんなに困ることは無いと思うよ、実際。
(大きな間違いがあればご指摘ヨロ。)

318 :名無しさん@お腹いっぱい。:04/02/04 00:53
スマンテック掲載の証明書の更新を手順通りにやってみたんだけど
途中のhttps://getca.verisign.com/update.htmlでダウンロードダイアログにて
勝手に名前を付けて保存が選ばれるんだけどこのままDLしてファイル右栗インストでいいのか?

319 :前スレ300 ◆w795LO9.Wo :04/02/04 00:59
>>318
それでもいいし
男らしくいきなり「開く」から「証明書のインストール」してもかまわない(笑)。

何度も書くが、シマンテックはそんなこと書いているけど
ベリサインのルート証明書の失効は
今回の件とは全く関係ないと思うよ。

まぁ更新自体はやっておいたほうがいいと思うけど。

320 :304:04/02/04 01:05
>>315
スタートアップ、タスクトレイ表示の不安定に関しては、
「組み込みタイミングの調整」が有効でした。
NIS2003の起動が遅くなった件は、改善していません。

当該PCは、EPSON製Me→XPにUPしたもの。
ただし、少なくとも1月某日以前は不具合なし。

似たような使い方をしている、XPノートPCは、
某日以後、同様に不調となったものの、
このスレの情報等により、
NIS2003の起動を含め、漸次復調。



321 :前スレ300 ◆w795LO9.Wo :04/02/04 20:13
>>320
304さん。
気が向いたら、以下確認してみてくんない?

1、時計戻したら直りますか?
 →直るようなら、やはり証明書かCRLの期限切れが原因。

2、crl.verisign.com への通信を止めていませんか?

3、ノートン関連のコンポーネントからの通信を遮断していませんか?

4、ノートン関連のコンポーネントが、どっかと通信しているようですか?
 →と聞くのは簡単だが、どうやって調べよう?

5、「発行元証明書の…」はAdministratorでも確実にオフになってますか?
 →XPのばやい、Administrator でログインするのは少々テク要。
  特にHomeEdition では。



322 :304:04/02/05 01:29
>>321

>1、時計戻したら直りますか?
すっきり治りました、が、現在に戻すとまたNISの起動が遅くなります。
因みに、
現在このコンピュータにインストールしてあるシマンテック製品とコンポーネントのすべては最新版です。
とのこと。

>2,3.4
詳しいことはわかりませんが、FWにあやしぃ設定はしてないはず。
妙な通信の兆候はなし。

>5
「発行元証明書の…」は、1とのandとorを試したが、関係なし。
Xp-Homeですが、アマガエルは私のみ。




323 :304:04/02/05 01:36
訂正
orは間違い。

324 :前スレ300 ◆w795LO9.Wo :04/02/05 16:29
>>322
> >1、時計戻したら直りますか?
> すっきり治りました、が、現在に戻すとまたNISの起動が遅くなります。

ということはやはりシステム遅延の原因は内蔵CRLの失効だな、多分。
でも「発行元証明書の…」をオフにしても効果なし、ということは
やはりその設定をしている箇所が適切でない、と見るべきか。

じゃあ、以下のを試してみてもらえますか?

1、セーフモードで起動する。
http://support.microsoft.com/default.aspx?scid=kb;ja;315222

2、アカウント「Administrator」でログオンする。

3、IEのオプション「詳細設定 - セキュリティ」の「発行元証明書の取り消しを確認する」をオフにする。


325 :304:04/02/05 22:43
その手順で、
「発行元証明書の取り消しを確認する」をオフにしても、
NISの起動は遅いです。

システムの復元を試したところ、
「復元ポイントの選択」で、
<をクリックしても前月(1月)にならない。
いよいよダメかな?

326 :名無しさん@お腹いっぱい。:04/02/05 23:11
博多っ子は
ばりサイン
じゃけのう

327 :名無しさん@お腹いっぱい。:04/02/05 23:35
>>301の方
ずいぶん遅くなって申し訳ありません。OSはXPです

ディスククリーンアップの中の[WebClient/Publisherの一時ファイル]が一連
の不具合以前は32KBだったのですが、現在は152KBになっています。
何か関係があるのでしょうか?

ファイル内容が解れば良いのですが、MSのサポート技術情報418438に
よると製品の問題で「表示ダイアログ」が表示されないとの事です。



328 :301:04/02/06 00:25
WebClient/Publisherの一時ファイルは、たんなるキャッシュなので
さほど問題じゃないかも。
消せなくなる問題は、確かにあるみたいですけどね。

"前スレ300 ◆w795LO9.Wo" さんが、いろいろ有益な情報をカキコしてらっしゃるので、
そのあたりをお試しアレ。


329 :前スレ300 ◆w795LO9.Wo :04/02/06 01:17
>>325
「日付を戻すと直る」んだよなぁ。
でも >>233-236 やっても直らないんだよね?

なんでだろう。
オレもテスト環境作ってみようかな。
でもそこまでやると逆に
そもそも再現しなかったりして。

わからん。気になる。

330 :前スレ300 ◆w795LO9.Wo :04/02/06 12:30
今日のLiveUpdateで、2003 の共通ファイルのccなんとかが8つほど一気に
今年の1/7付けのものに入れ替わった模様。

いずれも署名は今年の1/7付けで、
当然ながら書名に用いた証明書は元とは別のもの。
CDP(CRL配布ポイント)の指しているファイル名も
http://crl.verisign.com/Class3CodeSigning2001.crl
に変わっている。

単に署名だけではなく、
プログラム自体の署名チェックの契機自体にも手が入ったのなら
もしかして右クリ問題の根本解決の可能性も期待できるかも。

今は忙しいからすぐには試せないけど
後で試してみよう。

あんまし期待せんほうがええかなぁ…。



331 :名無しさん@お腹いっぱい。:04/02/06 13:17
>>330
豚汁のスレで治ったと言う報告あり。

332 :名無しさん@お腹いっぱい。:04/02/06 18:34
>>330
中間証明書の失効リスト
VeriSign Commercial Software Publishers CA
2004/04/28迄、ってのがもう一回インストールされてて
前にインストールしてた人は2つになってると思う。

1つは消してもいいのかな?
ローカルコンピュータの方にもインストールしてたんだけど
こっちは要らなかったのかな?

333 :名無しさん@お腹いっぱい。:04/02/06 19:12
>332
ローカルPCにも入れると2つに見えるから、消すならユーザー側を消しなされ。

334 :名無しさん@お腹いっぱい。:04/02/06 20:10
>>333
どうもです。
ユーザー側に2つ、ローカルに1つの状態だったんで
ユーザー側を1つ削除して、両方とも1つづつにしました。

335 :名無しさん@お腹いっぱい。:04/02/07 21:47
NISって何もしなくてもcrl.microsoft.comとcrl.verisign.comのパケット通すようになってるんだね。
レジストリ見て分かったよ。

336 :名無しさん@お腹いっぱい。:04/02/08 15:57
そろそろライブアップデートでNAVをアップデートしても大丈夫なんかな(w

337 :名無しさん@お腹いっぱい。:04/02/08 16:45
>>335
プログラム制御の
Symantec Norton Personal Firewall Security Statistics
を見てみれ。

338 :名無しさん@お腹いっぱい。:04/02/08 20:05
>>335
どこのキーですか?

339 :名無しさん@お腹いっぱい。:04/02/09 23:53
ウッキキー!お猿さんだよ〜

340 :前スレ300 ◆w795LO9.Wo :04/02/14 13:15
ここんとこ特にというか全然動きはない。

皆さんのところの右クリは正常化してますか?

341 :名無しさん@お腹いっぱい。:04/02/14 14:18
PFWのログ見るとたまにVeriSignアクセスに行ってる
期限切れ証明書のURLをキャッシュから拾ってまとめてダウソ
ユーザからローカルコンピュータに移動しておしまい

342 :前スレ300 ◆w795LO9.Wo :04/02/17 18:43
なんかもうすっかり寂れちゃいましたな。

1.8事件の元凶は、CRLへのアクセス過多。
アクセス過多自体の原因は、キャッシュされていたCRLの期限切れだったが、
それによりレスポンス低下を招いてしまったのは
ベリサインがCRLの配布のプロトコルに主に HTTP を使っていた、というのも
大きな要因だったのではないか?と思う。

そりゃまあHTTPでCRLの在処をURLで書いてあれば
普通はその一点にアクセスが集中するわな。

例の
http://www.verisign.co.jp/press/2004/pr_20040110.html


>また、業界のリーダー、パートナー様とともに、
>オンライン証明書ステータス確認プロトコル
>(OCSP、Online Certificate Status Protocol)の利用など、
>その他の仕組みを広げるよう努めてまいります。

とは言うてるけど、それだと突出したピークが発生するのは防げても
(あの右クリ稍重のように)常にクライアント側に負荷がかかるんじゃないのか?

343 :名無しさん@お腹いっぱい。:04/02/18 01:14
> とは言うてるけど、それだと突出したピークが発生するのは防げても
> (あの右クリ稍重のように)常にクライアント側に負荷がかかるんじゃないのか?
なんで?

344 :名無しさん@お腹いっぱい。:04/02/18 01:40
鯖側はDDoS攻撃を避けられてもクライアント側の改善は何らされる訳ではないって事でしょ。
パケット垂れ流しするのは変わらないんだから。

345 :前スレ300 ◆w795LO9.Wo :04/02/18 01:56
>>343
> > とは言うてるけど、それだと突出したピークが発生するのは防げても
> > (あの右クリ稍重のように)常にクライアント側に負荷がかかるんじゃないのか?
> なんで?

OCSP(Online Certificate Status Protocol)ってのは
証明書の有効性確認をリアルタイムで行なう仕掛けなので
確認時には必ず通信が飛ぶことになります。

CRLの場合は(更新ロジックにもよりますが)
有効なものがキャッシュされていればそれを使うので
通信が飛ぶのはキャッシュが無効になった時だけです。
だから有効期限の長いCRLの期限切れとかいった契機に
突然更新のピークが発生しちゃったりするわけです。


346 :前スレ300 ◆w795LO9.Wo :04/02/18 02:01
>>344
> 鯖側はDDoS攻撃を避けられてもクライアント側の改善は何らされる訳ではないって事でしょ。
> パケット垂れ流しするのは変わらないんだから。

>>229 にも書きましたが
シマンテックが
自分自身のプロダクトの改竄チェック程度のことに
PKIなんちう大掛かりな仕掛けを使っている
というのが今回の問題の根源だと思います。

自分の家族の本人確認にバイオメトリクス使ってるようなもんか?
ジェットヘリでタバコ買いに行ってるようなもんか?

347 :名無しさん@お腹いっぱい。:04/02/18 02:26
> OCSP(Online Certificate Status Protocol)ってのは 〜〜
クライアントからOCSPレスポンダに証明書(せいぜい2KB)を送る

> CRLの場合は(更新ロジックにもよりますが) 〜〜
クライアントはサーバからCRL(今回のは200KBくらいだっけ?)を取得する

都度2KBと、たまに200KBが集中するの、どっちがよい?

あと、有効期限の長いCRLなんて存在意義あるの?


348 :名無しさん@お腹いっぱい。:04/02/18 02:37
そいで、
> > とは言うてるけど、それだと突出したピークが発生するのは防げても
> > (あの右クリ稍重のように)常にクライアント側に負荷がかかるんじゃないのか?
突出したピークの発生(による鯖あぼん)が防げれば
(あの右クリ稍重)は発生しないんでない?

(あの右クリ稍重)は、
CRLの期限切れてんよ。取りいこー。
なんだ、鯖死んでんよ。
じゃもっかい。やっぱ死んでんよ。じゃもっかい。やっぱ死んでんよ。じゃも・・
ということだと思ってるんですけど。

349 :名無しさん@お腹いっぱい。:04/02/18 02:44
じゃなくて、
自分のPCから意図しない通信が飛ばないよう、FireWallとか入れてたので。
ということか。

350 :前スレ300 ◆w795LO9.Wo :04/02/18 13:11
>>348
ちょっとオレが勝手に使ってる用語を整理しておくわ。

・右クリ激重(げきおも)
 1/8に起きていた、右クリックするだけで分単位で応答が止まるような激しく重い状態。
 ベリサインの努力で回復。

・右クリ稍重(ややおも)
 1/8の激重回復後も、右クリック時に時々少し反応が遅くなる状態。
 本スレで発見された「最新CRLのインストール」法で回復した例多し。
 しかしそれでも回復していないという報告もある。
 回避策が見つかっているだけで、事象としては現在も継続中?


351 :名無しさん@お腹いっぱい。:04/02/18 14:13
証明書失効リストが期限切れになってアクセスに行くと、FWログに残るようにしとく
そしたらキャッシュに残ったURLを参考に取りに行って、ユーザ域でもシステム域でもいいからインスコし直す
ただそれだけ

現在のVeriSign系失効リストの期限切れ予定は
 2004年02月23日 20:00:08 Terms of use at https://www.verisign.com/rpa (c)01
 2004年02月27日 20:00:13 VeriSign International Server CA - Class 3
 2004年04月30日 07:14:14 VeriSign Commercial Software Publishers CA
 2004年05月15日 08:59:59 Class 3 Public Primary Certification Authority


352 :名無しさん@お腹いっぱい。:04/02/19 12:07
http://www.atmarkit.co.jp/fsecurity/rensai/pki05/pki01.html
証明書の有効性


353 :名無しさん@お腹いっぱい。:04/02/19 12:56
>>346
>自分の家族の本人確認にバイオメトリクス使ってるようなもんか?
使ってませんか?最低限音声ぐらいは必要でしょう。
しかし最近では音声だけの認証では破られるといったことが多発しているそうです。
顔の輪郭などとあわせて複合的に認証しなければ危険です。「おれおれ」だけじゃちょっと。

>ジェットヘリでタバコ買いに行ってるようなもんか?
船だと鮮度が落ちますので飛行機使いたいですね。さすがに自家用ジェットまではいらないと思いますが。
タバコ屋も景気悪いんでなに混ぜてるかわかったものではありません。やっぱり純なものは南米あたりがよろしい?

354 :名無しさん@お腹いっぱい。:04/02/20 11:59
あるアプリケーションAがVerisignサーバ証明書を持っているWebサーバBへアクセスします。
1. A → B : Client Hello
2. A ← B : Server Hello
3. A ← B : Server Certificate
4. A ← B : Server Hello Done
5. A → B : Client Key Exchange
6. A → B : Finished
7. A ← B : Finished
SSL通信確立までのシーケンスはこのような流れだと思うのですが、
3.のServer Certificateで
A:サーバ証明書 + 中間CA証明書 を送ってくるパターン
B:サーバ証明書 + 中間CA証明書 + ルートCA証明書 を送ってくるパターン
があるようなのだよ。

Aの例は https://www.baltimore.co.jphttps://www.ufjbank.co.jp/ib/login/index.html
Bの例は https://www.verising.co.jphttps://web.ib.mizuhobank.co.jp

一般的なSSLの通信ってAとBどっちが正しいんでしょ?
BのパターンでVerisingのルートCA証明書を送られてくるところがあるんだけど、
VerisingのルートCA証明書ってV3拡張に対応してないV1のものばっかりなんだよね。
アプリケーションは送られてきた証明書は全てV3拡張のBasicConstraintsを
チェックする仕様なので必ずエラーになります。
VerisignのルートCA証明書ってV3にならないの?


355 :名無しさん@お腹いっぱい。:04/02/20 12:51
>>354
いずれのルート証明書も
ローカルには有効期限内のものがちゃんとあるの?

356 :354:04/02/20 13:49
>>355
はい、あります。
クライアント側のアプリケーションは意図的にBasicConstraintsのチェックを
外すことができ、そうするとNGとはなりません。
なので、クライアント側のルート証明書は問題なさそうです。

>354一部Verisignのスペル間違ってた。。。


357 :前スレ300 ◆w795LO9.Wo :04/02/20 14:11
>>354
どっちが正しいか、はわからんけど
アプリが証明書がV3であることを前提としているという
その仕様自体の妥当性の問題なのか、
SSLのルート証明書がV1なベリが悪いのか、
という話になってくるのかな。

どういうアプリでどういう仕様なんかはわからんけど、

「BasicConstraintsのチェック」を指定する
=(証明書がV3であることを前提に)ルート証明書に対して厳密なチェックをする

てのが設定できるのであるとすれば、
必要に応じて外せばいい、ってことなのかな。
よくわからんけど。

なんにしても
ローカルにあるルート証明書
=すでに信頼されている
に対しても通信時毎に厳密にチェックする、てのは
過剰なようにも思うけど
そういう厳密さが要求される用途もあるんだろうね、きっと。

358 :名無しさん@お腹いっぱい。:04/02/20 23:32
>>354
ルート証明書がV1になっているのは、理由があって、
V3の拡張フィールドのせいで、ブラウザなどのクライ
アントソフトと相性が悪くなって結果動作しないことが
まま、あります。RFCではV3ならば入れなければいけない
と定められている拡張フィールドが定義されていますので、
V3の証明書を採用するならばそれらを入れないといけない
のですが、アプリケーションによってはそれらをうまく
認識しないものがあります。
V1ならば歴史があり、形式が単純であり、自由度も少ないので、
アプリケーションが誤動作する可能性がすくないのです。
ただし、複数世代の証明書が混在するような場合(リニューや
リキーした場合)、CRL配布点を指定したい場合などは、
ルート証明書以外はV3証明書でないと問題が
発生するので、ルート以外はV3が採用されます。
また、相互接続性が重要でない局面では、たとえば、日本のGPKIの
入札関連の電子署名法対応認証局などでは、使用するアプリケーションが
決まっている(ポリシーで決まっている)のでV3のルート証明書が
使われています。
(酒飲んでます。駄文失礼しました)

359 :名無しさん@お腹いっぱい。:04/02/21 09:00
過疎だけど、なにげに良スレなんだよな、ここ…

360 :名無しさん@お腹いっぱい。:04/02/21 11:06
http://www.ipa.go.jp/security/fy10/contents/over-all/02/25.html

情報処理推進機構(IPA):セキュリティセンター
 調査・研究報告書 バックナンバー
  電子商取引における電子メールに関するセキュリティ上の課題
   X.509電子証明書の互換性

361 :名無しさん@お腹いっぱい。:04/02/26 10:36
こないだ23日にVeriSign Class 3 Code Signing 2001 CA入れ直した
明日27日はVeriSign International Server CA - Class 3が切れる予定
ブラウザキャッシュが自動判定でヘッダ取りに行くからFWにログが残ってて、URLがキャッシュに残るからダウソは簡単
それにしてもサイクルが短過ぎないか?面倒でかなわん

362 :名無しさん@お腹いっぱい。:04/02/27 08:51
何気にNAVってOSが持ってないルート証明使ってるんだね。
今まで問題出なかったのが不思議だよ。

363 :Mr300% ◆w795LO9.Wo :04/02/27 18:22
>>362
> 何気にNAVってOSが持ってないルート証明使ってるんだね。
> 今まで問題出なかったのが不思議だよ。

それ詳しく教えてもらえませんか?


364 :Mr300% ◆w795LO9.Wo :04/02/27 18:24
>>361
ノートン関係のモジュールがそれらのCRLを取りに行ってるの?
サーバー系のCRLはあまり関係ないんじゃないかと思うんだけど。

365 :名無しさん@お腹いっぱい。:04/02/27 19:41
>363
NAVファイルのプロパティからデジタル署名を辿ってみてよ。
副署名の方も見ると驚愕の事実が!

上とは関係ないけど事前策で>51のリンクからcrlをDLしてインスコしたよ。

366 :名無しさん@お腹いっぱい。:04/02/27 20:56
いまローカルコンピュータに入れてる失効リスト(期限順)

2004/03/03 Microsoft Secure Server Authority(←これはしゃあないだろう
2004/03/04 VeriSign Class 3 Code Signing 2001 CA(←VeriSignはNAV2003が使ってる
2004/03/11 VeriSign International Server CA - Class 3
2004/04/15 Microsoft Internet Authority
2004/04/30 VeriSign Commercial Software Publishers CA
2004/05/15 Class 3 Public Primary Certification Authority
2004/08/14 GTE CyberTrust Root(←何が取りに行ってるんだ?


367 :前スレ300 ◆w795LO9.Wo :04/02/27 21:19
>>365
副署名はコード署名のタイムスタンプだよね?
これのルートの Thawte Timestamping CA
拇印 BE36 A456 2FB2 EE05 DBB3 D323 23AD F445 084E D656
の証明書の事?

今見ている環境にはちゃんとあるけど。
Windows98SE+NAV2003 です。


368 :前スレ300 ◆w795LO9.Wo :04/02/27 21:29
>>367
ちょっと古いタイムスタンプのファイルだと,
タイムスタンプのルート証明書が

発行元: NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.

拇印: 18F7 C1FC C309 0203 FD5B AA2F 861A 7549 76C8 DD25

ってのもあるけど、これもちゃんとシステム上にありました。
期限切れだけど。
期限切れだから消しちゃったりとかはしてない?

369 :名無しさん@お腹いっぱい。:04/02/27 21:32
ブラウザキャッシュに残るから
URL調べてフラゲか何かでダウンロードしてインスコすればよろし

370 :263:04/02/29 23:41
1/8に勤め先でトラブって以来、じっとりねったり
ウォッチさせてもらってました。といっても
やりとりされていることの中身は私にはわかりません。
惚れた手前というのもあるけど、
>>359
に同意。NAV本線で班長に「先に寝ます」と失礼した
私でありました。ごみ、重ねて失礼。ではまた。


371 :Mr300% ◆w795LO9.Wo :04/03/01 12:51
過疎スレですが、見てくれている人がいるというのは嬉しいです。

そんなにもう頻繁に書くネタもない状況だけど
せっかくのスレだし、「維持の為の維持」じゃない範囲で続けていきたいです。

ベリサインにこだわらず
PKIを核とした認証全般を学んでいきたいな、と。

もっといいスレなり板なりがあるといいんですけど
どっかにないもんですかね?

372 :名無しさん@お腹いっぱい。:04/03/03 00:45
2004年03月03日 07:07:27更新予定
Microsoft Secure Server Authority


373 :Mr300% ◆w795LO9.Wo :04/03/03 12:37
コード署名の証明書のCRLではなく、
証明書自体のインストールや
サーバー系証明書のCRLのインストールってのは
NAV/NIS環境のレスポンス等の向上に効果あるもんなんでしょうか?

正直かなり疑問なんですけど
成果が上がっているという人、いますか?



374 :名無しさん@お腹いっぱい。:04/03/03 13:01
SSL通信の認証がスムーズになったくらいかと。
NISがポート443見てるけどその点ではどうなんだろうね?

375 :名無しさん@お腹いっぱい。:04/03/04 18:57
veri発行のcrlが3つほど更新されてるね。
一番目以外は気にしなくても良いかな。
http://crl.verisign.com/Class3CodeSigning2001.crl
http://crl.verisign.com/Class3InternationalServer.crl
http://crl.verisign.com/RSASecureServer.crl

MSも1つ更新されてる。
Windowsupdateの時に拾う奴だな。
http://crl.microsoft.com/pki/mscorp/crl/msssa1.crl

376 :名無しさん@お腹いっぱい。:04/03/05 10:00
http://crl.verisign.com/

の今日今時点の一覧。

Class3CodeSigning2001.crl.20040303 03-Mar-2004 03:00 84k

「crl.20040303」ってなんやねん。
公開ミスかな?

377 :名無しさん@お腹いっぱい。:04/03/06 19:55
OS再インストしてから、やたらと証明書の期限切れダイアログがでる。
訳が分からんのでこのスレに挙がっている証明書をやたらとインスト。
それでも直らないので途方にくれていたら・・・ 
パソコンの日付設定が10年ずれていました。


378 :名無しさん@お腹いっぱい。:04/03/06 20:51
>>377

379 :名無しさん@お腹いっぱい。:04/03/07 01:12
>>377
和路太

380 :名無しさん@お腹いっぱい。:04/03/10 22:17
本日Microsoft Secure Server Authorityを入れ換え
明日はVeriSign International Server CA - Class 3更新の予定

381 :前スレ300 ◆w795LO9.Wo :04/03/19 00:26
ありゃ?
http://crl.verisign.com/Class3SoftwarePublishers.crl
18-Mar-2004 03:00 7k
って、7kしかないぞ、おいおい。

2004/01/09付けは120kくらいあったし
2004/02/01付けでも80kくらいあったのに。

有効期限切れ後、即じゃないにしても
ある程度期間が過ぎたら、CRLから削除される、
ってことなのかね?




382 :前スレ300 ◆w795LO9.Wo :04/03/19 01:04
>>381
気になって、例の不正発行証明書
https://www.verisign.co.jp/press/alert/security_alertert20010321.html
に関する情報はどうなってるか確認してみたら、
まだどっちもちゃんと残っていたよ。

1B51 90F7 3724 399C 9254 CD42 4637 996A
2001年1月30日 9:00:00
750E 40FF 97F0 47ED F556 C708 4EB1 ABFD
2001年1月31日 9:00:00

本来、2002/01/30 と 31に期限切れのものが
2001/01/30 と31 に失効しています。


383 :前スレ300 ◆w795LO9.Wo :04/03/19 01:17
>>381-382
普通、コード署名用の証明書の有効期限は1年間。
失効は有効期限内に行なわれる(はず)。

最新のCRLと1月付けのものとで
取り消しエントリの最古と最新を比べてみました。

○2004年1月9日 9:00:00付
最古
697F 7F3A 126F 49B5 073A 8F50 5EEA 0D59
2000年3月28日 9:08:49
最新
72D2 239B F233 E97C CFB6 A941 D50E 5C39
2003年4月10日 2:02:29

○2004年3月18日 20:00:32付
最古
4502 187D 399C B914 FB10 3796 F4C1 DD2F
2002年2月11日 20:11:06
最新
72D2 239B F233 E97C CFB6 A941 D50E 5C39
2003年4月10日 2:02:29

実際には3/18付けには、2001年付けのMSのものが2つあるんですが
2001年はその2つだけ。その次は2002年2月11日。

384 :前スレ300 ◆w795LO9.Wo :04/03/19 01:22
>>381-383
これらから、以下のように推測する。

コード署名の取り消し情報は、証明書の有効期限切れ以降も
最低2年間くらいはCRLに載せられている。
(ただしMSの2つは別扱い。多分ずっと載ったまま)

苦労した割には、ほとんど意味の無い情報だわ。
とほほ。

385 :名無しさん@お腹いっぱい。:04/03/19 16:33
優良スレ上げ

386 :名無しさん@お腹いっぱい。:04/03/19 22:41
Equifax Secure Certificate Authority
ってのが3/21に来ることになってるけど
そもそもこれ何だろう?

387 :名無しさん@お腹いっぱい。:04/03/21 18:01
OU = Secure Server Certification Authority

O = RSA Data Security, Inc.
キタ━━━━━━(゚∀゚)━━━━━━ !!

388 :前スレ300 ◆w795LO9.Wo :04/03/22 21:56
>>386
SSLのサーバー証明書じゃないですかね?
「来た」ってのはなんだろう。
それのCRLの更新?

389 :名無しさん@お腹いっぱい。:04/03/24 19:57
今日のWinUpdateで更新
CN = Microsoft Secure Server Authority
URL = ttp://crl.microsoft.com/pki/mscorp/crl/msssa1.crl


390 :名無しさん@お腹いっぱい。:04/03/24 20:01
こいつも来てた
OU = Equifax Secure Certificate Authority
URL = ttp://crl.geotrust.com/crls/secureca.crl

明日中にこっちも来る予定
CN = VeriSign Class 3 Code Signing 2001 CA

391 :名無しさん@お腹いっぱい。:04/03/24 20:13
今日はやたらイパーイ

CN = Microsoft Secure Server Authority
URL = http://crl.microsoft.com/pki/mscorp/crl/msssa1.crl

OU = Equifax Secure Certificate Authority
URL = http://crl.geotrust.com/crls/secureca.crl

OU = VeriSign International Server CA - Class 3
URL = http://crl.verisign.com/Class3InternationalServer.crl

OU = ValiCert Class 2 Policy Validation Authority
URL = http://certificates.starfieldtech.com/repository/root.crl

CN = Starfield Secure Certification Authority
URL = http://certificates.starfieldtech.com/repository/starfieldissuing.crl


392 :名無しさん@お腹いっぱい。:04/03/24 21:14
Verisignは中身の変更の有無は別としてもほぼ毎日更新されてるから、
一度にまとめてインスコしれば更新も同じくまとめて来るぞ。

393 :前スレ300 ◆w795LO9.Wo :04/03/29 13:00
なんか、ここの役目もすっかり終わってしまった感じですね。
だってネタないんだもん。
しょうがない。

394 :名無しさん@お腹いっぱい。:04/03/29 15:18
何かあった時また役に立つ。と言う事で保守上げ。

395 :DNS@Dyna:04/04/02 06:02
そうなんだよ。 
俺もアダルトサイト運営予定だから、ルート権限付きの専用サバ借りて、決済画面でSSL使うけど、Veriは高いし、登記簿まで
要するから、名の通った手軽なGeoTrustにしようと思ってる。

何もVeriに、こだわることもないのでは?


396 :前スレ300 ◆w795LO9.Wo :04/04/06 16:17
>>395
そりゃVeriにこだわることはないんだけど、
でもルート証明書が最初からOSにインストールしてあるとこの方が楽ちんですよね。
ユーザーにルート証明書をインストールしてね、とか言わなくて済むから。

実際、サーバー証明書だと、ベリ以外にどういう選択肢があるんだろう。

397 :前スレ300 ◆w795LO9.Wo :04/04/12 01:14
先週、公的個人認証の電子証明書取って来た。
って話は一応「証明書」つながりなんだけど
本来のスレの主旨からは遠ざかってしまっているなぁ。

いろいろ遊んでいるところですんで
そのうちまたオレのページでご報告しますわ。

http://www.memorize.ne.jp/diary/14/00211/

398 :名無しさん@お腹いっぱい。:04/04/12 01:21
結局、期限切れのclass2中間証明ってどうにもならんの?

399 :前スレ300 ◆w795LO9.Wo :04/04/12 01:24
>>398
> 結局、期限切れのclass2中間証明ってどうにもならんの?

どのclass2中間証明書の話でしょうか。
期限切れは期限切れで、
基本的にはどうしようもないと思うんですが。

400 :名無しさん@お腹いっぱい。:04/04/17 14:55
携帯でSSLを掛けたいので、3キャリアがデフォルトで対応しているのは、
ベリサインだけなんで、契約しようと思っていますが。

・グローバルサーバID
・セキュアサーバID
とどう違うんでしょうか?

http://www.verisign.co.jp/server/products/sidh_1_2_a.html
http://www.verisign.co.jp/server/products/sidh_1_2_b.html

見たところだと、40bit暗号にしか対応していないブラウザでも
128bit暗号強度にして通信すると言う理解で良いのでしょうか?

でも、これってユーザーから見た場合、このサーバが
ステップアップしてSSL通信してるとかって、わからないですよね?

401 :前スレ300 ◆w795LO9.Wo :04/04/19 12:39
>>400
http://www.verisign.co.jp/server/first/serveridguide.html
ホーム 初めてのSSLサーバ証明書 ガイド
サーバIDとは

を見ると、

世界中でベリサインだけが、対応する全てのブラウザに対して、128ビットSSL暗号化通信を可能にするグローバル・サーバIDを発行

SSLセッションで、セキュア・サーバIDや他社IDを用いた場合、ウェブサーバ/ブラウザのバージョンの組み合わせによっては通信データが40ビットの暗号化となるのに対して、
グローバル・サーバIDを用いた場合には、対応するブラウザ全ての環境で、自動的に128ビットSSL暗号化機能が有効になります。
128ビットSSLは、40ビットSSLと比較して、データの暗号化の強度が2の88乗倍(約3×1026倍)にも高まります。

とあるんで、そういう事なんじゃないですかね。

「ウェブサイト運営主体の実在性を証明」を重視するならどっちでもいい=セキュアサーバIDでよい
「暗号通信の強度を高めたい」のであればグローバルサーバIDが必要

ってことじゃないですかね。

ただ、利用者に「あんたがどうあれ128ビットSSLなんだよ」ってのは
単に通信しているだけじゃ(多分)わからんので
トップページとかで自慢げに宣伝でもしておかんと利用者にアピールできないかも。
(でも、携帯サイトでそんなん出たらウザい気も。)




402 :400:04/04/20 00:46
>>401
res thx.

http://www.verisign.co.jp/server/help/faq/110053/index.html
ここにそのものズバリがあったのですが、いまいち確信がなかったんで。

まぁ、「ベリサインしか」"グローバル"を発行してないってことは、一般的には
"セキュア"で十分ってことなんでしょうな。

ただ、うちのけちくさい会社がグローバルIDを申請してたんでちょっと気になってました。



403 :前スレ300 ◆w795LO9.Wo :04/04/20 08:49
>>402

> http://www.verisign.co.jp/server/help/faq/110053/index.html
> ここにそのものズバリがあったのですが、いまいち確信がなかったんで。

あーほんとだ。FAQはザッと眺めたつもりだったけど見落としてたな。
技術情報 Q&A - サーバIDの仕様
だったか。

これって本来は導入検討時に悩む項目だから、
もっと上のほうにあってほしいような。

ポイントはやっぱ401でも書いだけど、

「ウェブサイト運営主体の実在性を証明」のみを重視するならどっちでもいい=セキュアサーバIDでよい
常に「暗号通信の強度を高めたい」のであればグローバルサーバIDが必要

ではないかと、少なくともワタシは思います、ハイ。


404 :あげ:04/04/25 22:16
ホッシュ

405 :名無しさん@お腹いっぱい。:04/04/28 14:01
最近になってまた右クリックでexplorerがベリの旦那に接続しようとし始めた。

406 :名無しさん@お腹いっぱい。:04/04/28 14:36
Winうpだてにルート証明書の更新来た、重要じゃなく推奨の方。

>405
NAVの定義ファイル辺りの証明書をインスコしてみな

407 :名無しさん@お腹いっぱい。:04/04/30 17:50
NortonがらみのVeriSign失効リスト取りに行くと激烈に重くなる場合がある
そこで期限切れになるのを見計らってローカルに先取りで入れてしまうのがよろしかろうと
ただし日付時刻に時差があるから、タイミングに注意
1.エクスプローラでブラウザキャッシュを開いて、詳細表示でファイルの種類を降順でソートする
2.新しく取りに行った失効リストが先頭に来るので、右栗プロパティからURLをコピー
URLはあらかたこんなところだ
OU = ValiCert Class 2 Policy Validation Authority
(ttp://certificates.starfieldtech.com/repository/root.crl)
OU = VeriSign International Server CA - Class 3
(ttp://crl.verisign.com/Class3InternationalServer.crl)
CN = VeriSign Class 3 Code Signing 2001 CA
(ttp://crl.verisign.com/Class3CodeSigning2001.crl)
OU = VeriSign Commercial Software Publishers CA
(ttp://crl.verisign.com/Class3SoftwarePublishers.crl)
3.これらのURLをダウソローダに食わせてローカルデスクにダウソ、ダブル栗で新旧内容を確認
4.ローカル証明書失効リストにある古いほうの失効リストを削除
5.新しくダウソした失効リストを右栗でインスコ
6.すると現在のユーザの証明書失効リストに入ってくるからローカルコンピュータの証明書失効リストにドロップして移動しておしまい
証明書失効リストの見方は前スレ300氏が解説してくれてるのでそちらを参照してくれ
ただ、何でもかんでもローカルに置いても、Nortonみたいにご利益があるものとないものがあるようで
WinUpdateがらみのはその都度取りに行ってるから、ローカルにインスコしても無駄のようだ
CN = Microsoft Internet Authority
(ttp://crl.microsoft.com/pki/mscorp/crl/mswww1.crl)
CN = Microsoft Secure Server Authority
(ttp://crl.microsoft.com/pki/mscorp/crl/msssa1.crl)
長くなったが参考までに


408 :前スレ300 ◆w795LO9.Wo :04/04/30 23:43
>>407
まとめ乙。

409 :名無しさん@お腹いっぱい。:04/04/30 23:59
電子証明書なんてOpenSSLで簡単に発行出来るから自分の作ったついでにダダで
作って配ってやろうとしたらいらないとさ。プロバイダー経由じゃ月額200円も
払わなけりゃならないのをダダでやるっていうのに・・・。

所詮電子証明書なんてその程度のものさw

410 :名無しさん@お腹いっぱい。:04/05/01 00:09
>>409
藻前のルート証明書をインポートするより、ぬるぽウイルス踏むほうがマシ。

411 :名無しさん@お腹いっぱい。:04/05/01 04:34
>>410
ツーか俺もどこの誰かも分からん奴には発行せんよw

しかしベリサインボリ杉、メール用の証明書なんて年額200円でいいだ
ろうに・・・。

412 :前スレ300 ◆w795LO9.Wo :04/05/01 08:03
>>411
> しかしベリサインボリ杉、メール用の証明書なんて年額200円でいいだ
> ろうに・・・。

ワタシは電子メール用の証明書は
thawte の personal email certificates をずっと使ってます。

http://www.thawte.com/email/index.html

無料ですけど全部英語です。
添付ファイル付ける時とかには電子署名したりしてます。

証明書を自作したりとか、フリーの証明書とかもあるけど
相手にルート証明書を登録してもらわないといけない、
という問題があります。
thawte は確かルート証明書を標準で持ってたと思います。


413 :名無しさん@お腹いっぱい。:04/05/01 19:27
>>412

 thawte のデジタル証明書って、証明書に自分の名
前入れるまでが大変みたいですけど、入れて使って
ますか?。

 自分の場合、英語力が無い関係で、名前入れるまで
の手続きがさっぱりわからなかったので、COMODO の
を使ってます。けど本当は(名前入れられたら)tha
wte の方が信頼性高そうなので乗り換えたいんですよ
ね。

414 :名無しさん@お腹いっぱい。:04/05/01 19:28
>>412
自家製証明書でルーツ証明書をわざわざインストールする必要はないよ。
単純に明示的に署名を信頼するサイン処理して貰うだけでOK。
無料の奴は使ったこともあるが1年期限が面倒だからね、俺は期限が2038年
1月18日の自家発行して使ってるよw

415 :前スレ300 ◆w795LO9.Wo :04/05/01 21:45
>>413
名前入れずに使ってます。
「メールアドレスを認証しているだけ」ね。
無料で名前まで入れられるかよくわからないし。


416 :前スレ300 ◆w795LO9.Wo :04/05/01 21:48
>>414
> >>412
> 自家製証明書でルーツ証明書をわざわざインストールする必要はないよ。
> 単純に明示的に署名を信頼するサイン処理して貰うだけでOK。

へー。自己認証=ルート扱いだと思ってた。
自分でもちょっと試してみますわ。

417 :名無しさん@お腹いっぱい。:04/05/01 23:03
>>416
デフォルトで発行元の信頼を継承するになってるのを明示的に証明書を信頼
するに変更してやるだけでOK。この発行元の信頼の為に馬鹿高いコスト支払
わなくちゃいけないなんて馬鹿らしいと思わない?

418 :名無しさん@お腹いっぱい。:04/05/02 00:30
>>415
 うーん、やっぱりそうですか...。ちょっと残念。

>>417
 自分も最初はそう思ってたんですが、友人から総スカンくらいましたよ。
 ただ、OpenSSL は便利なので、個人的にはファイルの暗号化とかに使
ってますけどね。オンラインストレージとかに、大事なデータとか保存
する時に PGP と S/MIME で2重に暗号化したりとか。
 自宅のネット環境がトラぶった時に、あやしげなネットカフェでも
安心してダウンロード・保存できて助かります。
 もちろん、証明書の有効期限は10年w。
 


419 :名無しさん@お腹いっぱい。:04/05/02 00:33
Norton Internet Security 2004
圧縮ファイルもリアルタイムで監視可能だが、ONにすると重すぎ
スクリプト遮断機能がある
広告ブロックがアメリカ仕様で、お絵かき掲示板などの画像も消してしまう
スレに貼り付けてあるだけのウイルスコードに反応する
2chの過去ログ取得する時はFWを無効にしないといけない
Antispamが勝手にメーラーと統合する上に不安定(OEと相性が悪い?)
ポップアップ通知が鬱陶しい
LiveUpdateが遅い
webごとにスプリクト遮断やActiveX遮断やプライバシー制御の設定ができる
WEB閲覧するときHTMLファイルにスクリプトを埋め込む処理が重い
 (XPSP2ではデフォルトでポップアップ広告遮断機能があるので無駄になる)
回線速度が遅くなるという報告
ルールが適切ではないとの声もあるがPFWルールの自動作成が進んでいる
不正コピー・不正期限延長ユーザーが多い
個人情報を送ってるかについては疑惑は晴れず。
http://www.symantec.com/region/jp/products/nis/features.html
http://www.symantec.com/region/jp/products/nav/features.html

ウイルスバスター2004
圧縮ファイルもリアルタイムで監視可能だが、ONにすると重すぎ
FWレベル高にしないとアプリごとの制御ができない等、おまけ程度
スパイウェアの検出をするが削除は出来ない
迷惑メール検出の判定精度が悪い上に検出しても件名に[MEIWAKU]と付けるだけで意味がない
ユーザー登録しないとウィルス定義をUPできないので不正コピーユーザーは少ない
http://www.trendmicro.com/jp/products/desktop/vb/evaluate/features.htm

FWがしょぼい代わりに不具合が少ないバスターとFWにいろいろと機能が付いてる
代わりに不具合大盛りなNISって感じかな。
どちらもアンチウイルス機能自体には文句が出ないのは例年通り。

http://pc3.2ch.net/test/read.cgi/sec/1067918099/321

420 :名無しさん@お腹いっぱい。:04/05/02 01:10
>>418
CA.shのDAYSを↓みたく書き換えて、必要な所に$DAYS追加してやれば意識し
なくても有効期限ギリギリの証明書発行できるよ

x=`date +%s`
y=`expr 2147483648 - $x`
z=`expr $y / 86400`

DAYS="-days $z"

つーかその程度のことも嫌がる奴はセキュリティー意識が欠落してるんだよw

421 :名無しさん@お腹いっぱい。:04/05/02 01:29
 当方、下記の Windows 版の Openssl
http://www.shininglightpro.com/products/Win32OpenSSL.html
と、ActivePerl を使ってますので、CA.pl のようですね。

>つーかその程度のことも嫌がる奴はセキュリティー意識が欠落してるんだよw

 確かに。S/MIME の話をした時も「信頼できない」というより「そんな得体の
知れない、気味が悪いものは入れたくない」という意見が多かったですよw。


422 :名無しさん@お腹いっぱい。:04/05/02 01:46
うちはCygwinでインストール時にOpenSSL追加して使ってる、Win上でUNIX系
使うのに一番楽そうだから。まあマイクロソフトが謹製電子証明書を無料で
配らない限り、広まりそうにないよねw
http://matsu-www.is.titech.ac.jp/~sohda/cygwin/antenna/

423 :名無しさん@お腹いっぱい。:04/05/02 22:11
ところで気になったんだが、電子証明書で使用できる最高の暗号方式ってどう
なんだろう?AES256ビットとか使えるのかな?

424 :名無しさん@お腹いっぱい。:04/05/03 00:30
自分で調べたら今んとこDigestでsha1、4089ビットが最強みたいね。

425 :名無しさん@お腹いっぱい。:04/05/03 00:31
やば↑4096が正解

426 :名無しさん@お腹いっぱい。:04/05/03 18:56
なんか最近1029と1033と1034の3ポートで常にcrl.verisign.comにアクセスしてるみたいなんですが…
1月のノートン事件の時には証明書?を古いのを消して新しいのを入れる事で乗り切ったのですが、今回はよくわからないです。
検索してもノートン事件の事しかひっかからないし…
あんま知識ないんで自力で解決できず、インターネットへのアクセスもかなり遅くなって困っています。
どなたか解決法ご存知ではないでしょうか?

427 :名無しさん@お腹いっぱい。:04/05/03 19:26
どのプロセスが通信してるのか。

428 :名無しさん@お腹いっぱい。:04/05/03 19:46
>>426
それがわからないんです。
たぶんファイアーウォールとかいうので見れるかなとか思ってWinXPについてるやつを起動させてみようとしたのですが、なんかエラーが出て起動できませんでした。
片っ端から起動してるプログラム終了してみても通信が切れないんで、おそらくエクスプローラか、終了できないノートンの常駐監視のやつかと思うのですが。(NISは入れてません。NSWのみです。)
どのプロセスが通信してるのか知る方法を教えていただけないでしょうか?この板ではやや初心者質問スレ向きの質問ですが…

429 :名無しさん@お腹いっぱい。:04/05/03 20:04
netstat

430 :426:04/05/03 21:03
すいませんこの板見てZoneAlarm入れたらverisignへのアクセスはなくなりました。
原因は結局わかりませんでしたが、とりあえず解決したということで、お騒がせしました。m(_ _)m

431 :423:04/05/04 02:18
OpenSSL 0.9.7dによる自家製証明書についてのまとめ。

最大鍵長:4096(これを超えるとpkcs12出来ないっぽい)
暗号形式:des3(AESは証明書自体は作成できるが、Outlookは対応してないっぽい)
ハッシュ:sha1(証明書のほうはopenssl.cnfで設定できるが、CAの方は-sha1付け
        てやらないとmd5のままになるので注意)

ってところかな?誰も見てないっぽいけどw

432 :名無しさん@お腹いっぱい。:04/05/04 03:04
>>431
 見てたけど答えらんなかっただけ(^^;。
 4096 超えると pkcs12 が出来ないんですか。へぇー知らなかった。
 16384 bit とか作ってたw。2048bit位で充分らしいけど。
 2番目は高度暗号化パック以後のWinにて、トリプルDESまで対応って事ですよね。
 3番目はよく知らないけど、md5じゃ衝突の可能性があるって事かな?。

433 :423:04/05/04 04:20
> 4096 超えると pkcs12 が出来ないんですか。へぇー知らなかった。
なんかロードできませんとか言うエラーが出て作成できなかった、つーか
出来た人居たら教えてw

XPサービスパック2でAES対応みたいなのを見たけど、いつになることやら・・・。
md5はまだ破られてないけど、いろいろ脆弱性が見つかってるみたい、んで160
ビットのSHA1を使いましょうって話みたいよ。

つーかこれ以上の自己署名証明書作って使えたよって人居たら報告よろしくw

182 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)