2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 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

434 :名無しさん@お腹いっぱい。:04/05/09 10:59
テキストだけだと3DES 168ビットで暗号化されるけど、添付ファイルがあると
RC2 40ビットでしか暗号化されないんだけど・・・。これって逆じゃないの?

つか送る前に教えてくれよ・・・

435 :名無しさん@お腹いっぱい。:04/05/09 11:02
【禿藁】電車内で鼻水を垂らして寝ているOL【観覧時は飲み物に注意汁】 
http://pc4.2ch.net/trst/read.cgi/swf/1072760803/150

436 :名無しさん@お腹いっぱい。:04/05/13 15:29
NIS2003だが、またOS起動時に毎回ベリに繋がる
今度は何なんだよ_| ̄|○

437 :名無しさん@お腹いっぱい。:04/05/13 23:58
ファウアウォールでccApp(c:\program files\common files\symantec shared\ccapp.exe)の通信を許可してログを取る
ログが残ったら更新された証拠だからキャッシュを見る
あとは上のほうにあるローカルインスコの方法を参考に

438 :名無しさん@お腹いっぱい。:04/05/14 00:06
>ファウアウォール
ドイツ訛りのつもりならフォイアウォール

439 :名無しさん@お腹いっぱい。:04/05/14 09:58
すみません スレ違いかも知れませんが、質問させてください
あるサイトからhttpsで求人に応募しようとしたのですが
セキュリティ証明書が信頼する会社から発行されていません
とのメッセージがでました

発行者はKSI First Serverとなっているんですが
信頼していいものでしょうか?

よろしくお願いします。


440 :名無しさん@お腹いっぱい。:04/05/15 23:16
>>439
その場合、証明書の発行元がブラウザーに登録されていないって話で、送信内
容はちゃんと暗号化されます。そのSSLで表示されたアドレスがちゃんとその
会社のものか、そのページを右クリック、プロパティーを選択してそのアドレ
スがアドレスバーのアドレスと一致するのが確認できたら心配要りませんよ。

441 :前スレ300 ◆w795LO9.Wo :04/05/19 15:05
>>439
信頼するのが
「SSLによって、そのサイトと暗号通信がされるか」なのか、
「そのサイトの素性が確かかどうか」なのか。

前者であれば >>440 の通りだと思いますが、
後者であれば微妙なところ。

ただ、
「セキュリティ証明書が信頼する会社から発行されていません 」
というメッセージが出ること自体は、
そのサイト自身の問題ではなく、
あなたの通信環境の問題かもしれません。

ちょっと興味があるので
差支えがなければ、どこのサイトか教えてもらえませんか?

442 :名無しさん@お腹いっぱい。:04/05/19 20:10
>>440-441
ご回答ありがとうございました。
その会社のアドレスは
http://www.e-fro.co.jp/
です


443 :前スレ300 ◆w795LO9.Wo :04/05/19 22:00
>>442
早速見てきましたが、
この会社のwebページで、「https://」から始まるリンクって
どこにありますか?
ちょっと見つけられなかったんですけど。

トップページを https:// で見ようとすると
確かに「このセキュリティ証明書は、信頼する会社から発行されていません。
証明書を表示して、この証明機関を信頼するかどうか決定してください。」
というエラーになりますね。

発行元は、webホスティング会社のファーストサーバ社のようです。
http://www.fsv.jp/function/b_ssl.html

そこでホスティングしてるんでしょうね、その会社。

444 :名無しさん@お腹いっぱい。:04/05/20 00:29
ジャストシステムが証明書の商売を始める模様。
ニュースレターに載ってた。
1年2520円だそうだが。

445 :前スレ300 ◆w795LO9.Wo :04/05/20 00:33
>>443
> http://www.fsv.jp/function/b_ssl.html

気が付きましたか?このページの一番下。

「ファーストサーバは日本ベリサイン株式会社のセキュアサイトパートナーです。」

ちゃんとこのスレのテーマに帰ってきてるんですね(笑)

446 :前スレ300 ◆w795LO9.Wo :04/05/20 00:36
>>444
> ジャストシステムが証明書の商売を始める模様。

https://www.justmyshop.com/camp/verisign/?w=tpcm_verisign

インターネットを巡る情報は、すべて傍受される危険性があります。
機密扱いで管理している文書も、悪意ある「盗み見」や「改ざん」により、重大なトラブルを招きかねません。
あなたの大切な情報と信用を守るためには、電子証明書が効果的です。
「ベリサイン 個人用電子証明書ライセンスシート」(MyShop価格 2,520円[税込]送料無料)をご利用いただくと、
低コストかつ手軽に、「デジタル(電子)署名」「暗号化」といったセキュリティ機能を実現できます。

てなわけで、これもベリにつながってくるわけだ。

447 :前スレ300 ◆w795LO9.Wo :04/05/20 00:42
>>431
> OpenSSL 0.9.7dによる自家製証明書についてのまとめ。

すんません。見てますけど勉強不足でついていけてません。

ワタシの方では、純MS路線(笑)の
.NET Framework の証明書作成ツール (Makecert.exe)で
どんなことが出来るか試してみます。

448 :名無しさん@お腹いっぱい。:04/05/31 20:24
期限切れたー!むきー!!!1

449 :前スレ300 ◆w795LO9.Wo :04/06/01 10:17
Makecert.exe による自家製証明書についての途中経過。

Micorosoftのテスト用証明書作成ツール Makecert.exe というのがあります。
電子署名などのテスト用に、「しかるべき認証機関で発行された証明書」の代わりに使用できる証明書を作成する、
というのが本来の目的なので「テスト用」となっていますが、
ルート証明書として使用できる、自分自身で発行する「自己証明書」を作成できますので、
「しかるべき認証機関に認証してもらうのではなく、自分自身で認証する証明書」
として利用するのであれば、別に「テスト用」に限られるわけでもないと思います。

実際、作成された証明書自体に、明に「テスト用」とか書かれているわけではないし
ぱっと見ただけでは Makecert.exe で作られたものとはわからないのではないかと思います。

(ここらあたりは私の誤解の可能性も高いので、ご指摘よろ。)


450 :前スレ300 ◆w795LO9.Wo :04/06/01 12:30
>>449
Makecert.exe は、.NET Framework のSDKを入れれば使えるようになりますが、
これを使ってみたいだけのために、.NET Framework のSDKを入れる、というのも難儀な話です。

これは元々、Authenticodeのツールなので、以下のパッケージにも含まれています。

http://www.microsoft.com/downloads/details.aspx?FamilyID=2B742795-D0F0-4A66-B27F-22A95FCD3425
Authenticode for Internet Explorer 5.0 & Authenticode for DEC Alpha - Internet Explorer 5.0
(英語です)

また、Microsoft Download Center の platformSDK のUpdateから
.NET Framework のSDKのアップデートとして公開されている
Makecert.exe Ver5.131.3617.0 が単独でダウンロードできるようです。

http://download.microsoft.com/download/platformsdk/Update/5.131.3617.0/NT45XP/EN-US/makecert.exe

こいつは、-pe オプションをサポートしているバージョンなので
「とりあえず makecert.exe だけありゃいいや」という人にはちょうどいいかも。

ただ、大きな問題点は、 Makecert.exe については、まともなドキュメントがなかなか見つからない、ということです。

http://www.microsoft.com/japan/msdn/library/ja/cptools/html/cpgrfcertificatecreationtoolmakecertexe.asp
MSDN Japan: 証明書作成ツール (Makecert.exe)

これ見ただけで使うのは至難の技ではないでしょうか。

Makecert.exe についての、なんかいいドキュメントを知っている方、教えてください。

451 :名無しさん@お腹いっぱい。:04/06/01 22:25
http://mars.elcom.nitech.ac.jp/Research/MM/security/easycert/
とかのEasyCertでも一通り出来る!?

CACanet.orgも一時見なかったらすげぇ変わっているし。

452 :名無しさん@お腹いっぱい。:04/06/01 22:31
age

453 :前スレ300 ◆w795LO9.Wo :04/06/02 13:01
>>451
> http://mars.elcom.nitech.ac.jp/Research/MM/security/easycert/
> とかのEasyCertでも一通り出来る!?

おお、こりゃすげえ。全然知りませんでした。
「お手軽に自己証明書を発行する」という狙いなら
こっちのほうが Makexert.exe なんかより断然良さそうだわ。

早速ためしてみますね。ご紹介感謝。


454 :名無しさん@お腹いっぱい。:04/06/05 10:29
age

455 :前スレ300 ◆w795LO9.Wo :04/06/07 16:48
とりあえずEasyCertで自分で認証局立てて
自分用の証明書を作成して、
その証明書でOEから署名付きメール送ったり
暗号化メールを返してもらったり出来ることまで確認しました。

証明書の発行管理の機能がちゃんとあるので
単発のツールでしこしこ証明書作るのに比べれば雲泥の差ですし
証明書の記載内容の自由度も高いです。

ただ、証明書自体に対する知識がある程度ないと
「なにをどう指定してよいやらさっぱりわからない」
ということにはなるとおもいます。

少なくとも、第三者に対してではなく
自分自身や仲間内で電子署名によりなりすましを防いだり
暗号化によってデータを秘匿したりする、といった用途には
十分使えるんじゃないかと思います。

いやーすげえな、EasyCert。感動しました。


456 :名無しさん@お腹いっぱい。:04/06/07 22:41
>>455
でしょ!?漏れも3年前くらいに感動した(w
確かこっからのLINKでCACAnetも知ったんだったと記憶している。
(遙か昔の物語)

CACAnetも覗いてみると結構ためになるかもね。
漏れは一般MLをまた〜りROMってます。


457 :名無しさん@お腹いっぱい。:04/06/08 14:05
自己証明書+S/MIME と PGP とだと
どっちがどうなんだろう?と思ってたら
ちゃんと語られていた。

さすがは2ちゃんねるだ。

PGPってすごく良いの?2
http://pc5.2ch.net/test/read.cgi/sec/1049559446/470-483


458 :名無しさん@お腹いっぱい。:04/06/08 20:36
>>457
どっかで見たような書き込みがと思ったら...俺がいた(w


459 :名無しさん@お腹いっぱい。:04/06/10 14:51
参考
http://www.atmarkit.co.jp/fsecurity/special/04smime/smime01.html
S/MIMEでセキュアな電子メール環境をつくる!


ついでに以前紹介されてるやつ。
http://www.atmarkit.co.jp/fsecurity/special/02fivemin/fivemin00.html
5分で絶対に分かるPKI

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




460 :名無しさん@お腹いっぱい。:04/06/10 20:54
みんな、なか〜ま!

461 :名無しさん@お腹いっぱい。:04/06/16 01:35
 EasyCert 0.89b1 ← このバージョンって前から配布してましたっけ?。
 以前見た時は、7日間制限版と、輸出規制に関連したキー長512bit制限版
しか無かったような気がしたんですが。だから、使ってなかったんだけど...。
 使うなら 0.89b1 だね。(起動ウィンドウが「AiCA」だけど)

 というか、OpenSSL のフロントエンドが激しく欲しい。

 S/MIME の証明書って、証明書ファイルだけを渡すと、渡された相手が暗
号化しようとした場合、40bit とかでしか暗号化できないんですよね。
メールで送ると 192bit 3DES で暗号化してもらえるんだけど。

 メールのヘッダに、メーラーの種別とバージョンが書いてあるから、
それで、どの暗号化が使えるか判断してるって事でしょうかね。

462 :名無しさん@お腹いっぱい。:04/06/16 13:37
>>461
>  EasyCert 0.89b1 ← このバージョンって前から配布してましたっけ?。

↑ってどこにあるんですか?

http://mars.elcom.nitech.ac.jp/security/download.html

では見つからないんだけど。

463 :名無しさん@お腹いっぱい。:04/06/16 15:24
>>462

 そのページにありますけど、あれ?、EasyCert 0.89b2 って書いてあるな(^^;。
 インストールしてヘルプのバージョン情報を見ると 0.89b1 なんですが...。
 でも、どのバージョンの readmej.txt を見ても、
「このバージョンは輸出可能版であり、秘密鍵はDES 56bit、
PKCS#12 内の秘密鍵はRC2 40bitで保存されます。」
って書いてありますね orz。

>>461
>メールで送ると 192bit 3DES で暗号化してもらえるんだけど。

 訂正: 3DES 168bit の間違いでした。

464 :名無しさん@お腹いっぱい。:04/06/16 16:58
右クリック重いよ〜ヽ(`Д´)ノウワァァァン

465 :名無しさん@お腹いっぱい。:04/06/16 17:51
>>464
中指を鍛えよ!
熱湯をザブリとかけ、キリリと冷やしたタオルでばんばん叩くのじゃ

466 :名無しさん@お腹いっぱい。:04/06/18 23:25
NIS2003でOS起動時にccEvtMgr.exeが毎回ベリに
接続するんだがどうしたらいいんでしょう?
解りやすくたのんます

467 :名無しさん@お腹いっぱい。:04/06/19 02:09
Live Update

468 :名無しさん@お腹いっぱい。:04/06/19 06:03
>>466
とりあえず許可してあげてください。

469 :466:04/06/19 18:37
>>467-468
とりあえず許可してるのですが、
毎回繋がるのです。(ルーター自動接続です)
これって何か変ですかね?


470 :名無しさん@お腹いっぱい。:04/06/19 20:05
ノートン先生…なんでそんなにベリサインに繋ぐの?。・゚・(ノ∀`)・゚・。

471 :名無しさん@お腹いっぱい。:04/06/19 20:27
>>463
うちの 0.88b2 には「このバージョンは...」部分の記載が無いんですが...
0.89以降の対処なんでしょうかね?キー長は1024とか選択出来たりします。
ですが、OutlookExpressで試してみて受け付けてもらえなかったので、
結局は512にしました。

久方ぶりにキーを見てみたら、去年キーの有効期限が切れていたよ...orz

472 :名無しさん@お腹いっぱい。:04/06/19 23:02
ところでこの会社の株っめちゃ高いんだけど、
ここの社員の待遇ってもしやめちゃいいのかな??

これまでのレスを読んでると、私のイメージ的には
外資だから殺伐としてそう。。。

473 :名無しさん@お腹いっぱい。:04/06/19 23:14
>うちの 0.88b2 には「このバージョンは...」部分の記載が無
>いんですが... 0.89以降の対処なんでしょうかね?

 CertWorker の販売に合わせて差別化したのかも知れませんね。

474 :名無しさん@お腹いっぱい。:04/06/23 21:42
age

475 :前スレ300 ◆w795LO9.Wo :04/06/24 01:00
EasyCertでいろいろ遊んでいるんですが、
今日「CRLで取り消されている証明書」ってのを作りました。
ていうか、CRL配布ポイントを指定した証明書を失効させ、
CRLを発行した、と言うのが正確か。

今まで、「有効期限内だけど、CRLで無効にされている証明書」を使うとどうなるのか?
ってのを実際に試してみることが出来なかったのですが
やっとできました。

しかしアレですな。今年1/8のノートン騒動で出来たこのスレも
半年ほどで500近くまでのろのろ成長しています。
内容も、ベリの話題というより、PKI一般の話題になってきてます。
この先も細々とその路線で進んでいきたいなと思っています。

「ベリとかに頼らず自分で運用するPKI」って感じで。
とりあえずはEasyCertではじめる
署名付きメール、暗号化メールあたりからかな。


476 :名無しさん@お腹いっぱい。:04/07/01 00:28
証明書の有効期限が切れた場合、サーバーへの認証に失敗する
と思っていたんですが、いくつか検索してたあるページに、PCの
日時の設定を一時的に変更してWindowsの修正パッチをインストール
したという記事がありました。これはサーバー側の失効証明書リスト
の更新がきちんとされてないからなのでしょうか?

477 :前スレ300 ◆w795LO9.Wo :04/07/01 13:05
>>476
これはどの証明書についてのお話でしょうか?
サーバー証明書なのか、コード証明書なのか。
差し支えなければ、あるページがどこのページか教えてもらえませんか?

478 :476:04/07/02 03:14
>>477
はい。サーバ証明書のつもりで読んだんですが、コード証明書
の事だったかもしれません。そもそも良く分かってないのですが、
ブラウザにインストールされたサーバ証明書が古くなったら、その
ブラウザからそのサーバへのアクセス拒否はどのように実行され
るのでしょうか?

>あるページがどこのページか教えて
すみません。あっちこっちうろうろしてた途中で読んだ記事の
記憶なので、どこのページだったかはっきり憶えてません。

479 :476:04/07/02 03:17
>>478
すみません。サーバ証明書が古くなったら有効期限切れですね。
でもその時、ブラウザが参照する時計の時間を戻されたらどうなるんでしょう。

480 :えー:04/07/02 13:21
蒸し返すようで申し訳ないですが・・・
http://www.microsoft.com/japan/technet/security/bulletin/fq01-017.asp
によると、
--
問題は、VeriSign コード署名証明書には CDP 情報が含まれていないことにあります。
従って、VeriSign がこれら 2 通の証明書を最新の CRL に追加しても、システムが自動的に
ダウンロードし、確認することはできません。マイクロソフトのアップデートは VeriSign の欠落を補います。
--------
ということは、Verisignが誤ってMSのものとして発行した証明書↓
--
“Microsoft Corporation”. 主要認証局の 1 つである VeriSign は、2001 年 1 月に、
2 通のデジタル証明書をマイクロソフトの社員を詐称したある個人に誤って発行したと報告してきました。
これらの証明書は 「Microsoft Corporation」 の名前を使用して ActiveX コントロールや
Word マクロなどのプログラムにデジタル署名するのに使用される恐れがあります。
--------
この問題と、これを回避することが出来ないコード署名証明書のために、クライアントPCに
2通の証明書を含む CRL と、CDP 機構を使用せず、ローカル マシン上でCRLを参照する
仕組みを実装するアップデートを行ったと思われます。

本来ならば、コード署名証明書によって署名されたクライアントAPがCRL確認動作を行う
べきものが、望む動作が出来なくなったことが不具合を引き起こしていませんか?

<予想>
上記不具合と修正によって、本来は、[次回CRL更新時にCRLを確認する]と言う動作で
あるべきが、その動作をせず、ある特定の(都合の良い)時にCRLをチェックするという
動作に変わってしまったことで、2004.01.07 まではアクセスが少なくなってしまったが、
その特定の時にアクセスが集中してしまった。

<参考>
http://www.microsoft.com/japan/technet/security/bulletin/MS01-017.asp

481 :前スレ300 ◆w795LO9.Wo :04/07/02 14:29
>>480
> <予想>
> 上記不具合と修正によって、本来は、[次回CRL更新時にCRLを確認する]と言う動作で
> あるべきが、その動作をせず、ある特定の(都合の良い)時にCRLをチェックするという
> 動作に変わってしまったことで、2004.01.07 まではアクセスが少なくなってしまったが、
> その特定の時にアクセスが集中してしまった。

これは単に

「上記不具合と修正によって、
 内部的に保持するようになったCRLの有効期限が2004.01.07 までだったので、
 それまではCRLの更新に行かなかった」

っていうことなんじゃないでしょうか。

しかし、改めてよく考えてみると、
CDP情報をもっていない証明書にたいして
CRLを確認する、ってのはどういう細工をしたんでしょうね。

「CDP情報が無い場合でも、その証明書の発行者のCRLを内部的に保持している場合には
それを使って取り消し確認をする」

ってロジックを加えたのかな?

482 :えー:04/07/02 17:21
>>481
>ってロジックを加えたのかな?

それしか考えられませんよね。

となると、次回いつCRLを取得するか:も問題になるのですが、
(1)そのときのCRLのnextUpdateがどうなっていたのか、
(2)付加したロジックが自己判断により取得周期を決めたのか、
(3)CDP情報がない証明書だからCRLなんてチェックしなくてもいいだろうと
  付加ロジックが判断していたのか、
などが疑問に思えてきます。

CDP情報が入っていないコード署名証明書って、いまから探して見つかるのだろうか?

483 :前スレ300 ◆w795LO9.Wo :04/07/02 20:38
>>482
> (1)そのときのCRLのnextUpdateがどうなっていたのか、

これがまさに 2004/01/08 なわけですね。
>>111-113 >>115 >>125 あたり参照。


> (2)付加したロジックが自己判断により取得周期を決めたのか、
> (3)CDP情報がない証明書だからCRLなんてチェックしなくてもいいだろうと
>   付加ロジックが判断していたのか、

これはどちらも「ない」と思います。
「DDPが無くてもCRLをチェックする」(仮説)以外には単に
  キャッシュ上にあるか、インストールされているかのCRLが
  nextUpdate期間内なら、それを使う。
  nextUpdate期間外なら、新しいCRLが取得できるまで、
  取得しようとアホのようにリトライを続ける。
じゃないですかね。


> CDP情報が入っていないコード署名証明書って、いまから探して見つかるのだろうか?

これはワタシは見たこと無いですわ。

#久々にこの件の話の相手をしてくれる方が現れて、なんだか嬉しい(笑)

484 :えー:04/07/02 21:46
>>483
なるほど納得しました。

あるがとうございました。

485 :えー:04/07/03 00:49
またまた疑問なんですけど、
http://support.microsoft.com/default.aspx?scid=kb;ja;293811
↑のなかの、「重要:」のうち、
--
(・2)このアップデートにある CRL ではなく、VeriSign CRL のローカル コピーを手作業で
選択して使用する場合は、完全な VeriSign の CRL の有効期間は短く、1 週間毎に更新
する必要があることに注意してください。
(・3)完全な VeriSign CRL を手作業でインストールしてから、このアップデートをインストール
する場合は、その後で CRL の新しいバージョンをインストールする必要があります。
--------

これどういう意味でしょうか?

<予想>
(・2)crlupd.EXE では、verisignpub1.crl を参照する処理に修正されるが、
それを行わないで、(コード署名されたプログラムの開発者が)動作を修正する事
によって対策を行う場合、CRLの更新周期に注意すべきだ。
(# この場合、修正プログラムはもはや CDP の無い証明書は使用できなくなり、)
(# CDPを有する証明書で修正プログラムを署名しなければならないのでは?)

(・3)上記(・2)を行った後で、プログラムのエンドユーザが crlupd.EXE を行った場合、
[完全な VeriSign の CRL] が(プログラム処理によって)更新され、verisignpub1.crl よりも
優先されるような処理にすべきだ。

486 :前スレ300 ◆w795LO9.Wo :04/07/04 20:15
>>485
Microsoftは、NET環境ではないWindows上でも、
自分達を騙る証明書だけは必ず無効にする、という意図で
crlupd.EXE というアップデートを作ったのではないか?
とワタシは想像しています。

中身はたぶん、
(1)問題の証明書を無効にするため「だけ」のCRLをOS内部で保持する。
(2)CDPが記載されていない証明書に対しても、発行者のCRLを保持している場合は、取り消し確認を行なう。
というものです。

しかし、問題の証明書を無効にするため「だけ」のCRL(以下、「イカサマCRL」と呼びます)
を強制的に保持するため、副作用として、
(1)VeriSignが発行している正しいCRLをインストールしていた場合、イカサマCRLで置き換えられてしまう。
(2)イカサマCRLのnextUpdateが約3年後と長大であるため、ちゃんとCDPのある証明書に対しても、その間は正しいCRLを参照に行かない。
という事態になってしまいます。

イカサマ証明書には偽MSの取り消し用の3つのエントリしかありません。
ということは、VeriSignに取り消されている別の証明書があったとしても無効にできないわけですね。
他所の無効証明書を見逃してでも、MSを騙る証明書だけは無効にする。
そういうアップデートだったわけです。

CDPのない証明書に対してCRLのチェックをしつつ他の無効証明書も正しくチェックするには
イカサマではない正しいCRLをインストールしてやればいいのですが、
手動で登録したCRLは、自動的に最新に更新することは出来ませんから
自分でまめに更新してやらないといけない、というわけです。

だから、デフォルトはイカサマCRLで、自分とこのだけは無効にするので、他のもちゃんとチェックしたい人は、自分でこまめにCRLを更新してね。
という事を言ってるんだと思いますよ。

なんにしろ、プログラマに対する注意喚起とかではないと思います。


487 :えー:04/07/05 04:19
>>486
やはりそう解釈するのが普通でしょうね。

MS01-017 の FAQ を見てもそう解釈するのが妥当なようです。
( http://www.microsoft.com/japan/technet/security/bulletin/fq01-017.asp )
「VeriSign 社の CRL の全部分をシステムにホストしていますが、このアップデートをインストールする場合、
何か特別な操作を行う必要はありますか?」

そうだとすると、自分で CRL を更新する方法ですが、ここのスレッドの話の流れから推察すると、
%SystemRoot%\system32 にダウンロードした CRL をコピーすれば良いような気がしますが、
合ってるのかな? (IEのキャッシュフォルダにも .crl があるけど・・・)
(# CRL自体にも発行者の署名があるので、ファイルを書き換えるのは NG ですね。)

またその方法を、MS が公開していなか探してみたのですが、
( http://support.microsoft.com/default.aspx?scid=kb;ja;289749 )
  Q.: CRL は IIS コンピュータ上に保存されますか?
  A.: CRL キャッシュの格納場所については、セキュリティ上の問題があるため公開しておりません。
公開はしていないと書いてはありますが、
  Q.: CRL はどのように識別されるのですか? ファイル名ですか?
  A.: crl ファイル拡張子によって識別されます。たとえば、CRLfilename[1].crl です。
拡張子は書いてあるので CRL のキャッシュの場所がわかったのでしょうか・・・

本来は、CDP の入った証明書を使用していれば、手動で CRL を更新する必要はなかったわけで、
偽MS証明書の問題が発生する以前に、CDP なし証明書の危険を回避する手法として、
一部の関係者に[手動で CRL を更新する方法]を提供していたのだろうか?

488 :前スレ300 ◆w795LO9.Wo :04/07/05 11:54
>>487
CRLの更新方法としては、今までここに出てきたのでは
(1)mmcの証明書ツールを使う >>233-235
(2)updcrl.exeを使う >>252
ですね。


489 :名無しさん@お腹いっぱい。:04/07/06 19:45
explorer.exeがcrl.verisign.comにアクセスする件について
http://news12.2ch.net/test/read.cgi/news/1089106169/


490 :前スレ300 ◆w795LO9.Wo :04/07/06 21:40
>>489
これ、なんかもう見られないんですけど、
どんな内容だったんでしょうか?


491 :名無しさん@お腹いっぱい。:04/07/14 14:48
ホシュ

492 :名無しさん@お腹いっぱい。:04/07/16 21:55
明日の午前5時前後にThawteServerCAとThawtePremiumServerCAの証明書が切れるんだけど
ほっといていいのカナ、いいのカナ?

493 :前スレ300 ◆w795LO9.Wo :04/07/27 20:37
>>492

気になるようであれば、ルート証明書の更新をしておくと良いのでは。
Windows Update から出来たと思う。


あげとこう。

494 :名無しさん@お腹いっぱい。:04/07/28 13:37
正直全く分からん
キャッシュ消すとまた繋ぎにいくし…

495 :名無しさん@お腹いっぱい。:04/07/28 13:38
VeriSignとGeoTrustってだいぶ価格が違うようだけど、どっちがいいの?

496 :名無しさん@お腹いっぱい。:04/07/28 19:06
27日に何かの更新があったね。

497 :名無しさん@お腹いっぱい。:04/07/29 05:48
ここの証明書ってすごい安いけど、なんでだろう。。
日本語が意味不明なサイトで結構あやしいんだけど。
http://www.trustlogo.co.jp

498 :名無しさん@お腹いっぱい。:04/07/29 10:35
>497
それは補償額を見ればわかる。一番安いのはたったの$50-。
最もどういう状況で補償してくれるのか、よくわからんけど。


499 :名無しさん@お腹いっぱい。:04/08/02 02:29
最近有名になったGeoTrustはどうなんだろう。
GMOだから信頼性ないか

500 :名無しさん@お腹いっぱい。:04/08/16 14:11
またpca3.crlか…
いい加減アクセスするのはやめてくれよ、ノートン先生。

501 :名無しさん@お腹いっぱい。:04/08/31 22:07
あげとくか。

502 :名無しさん@お腹いっぱい。:04/09/04 01:25
Windows XPにSP2を適用させたら証明書を取りに行かなくなった…
?(´・ω・`)?

503 :前スレ300 ◆w795LO9.Wo :04/09/04 08:28
>>502
それは興味深い話ですね。

自分とこがXP環境じゃないので確認不能ですが
XPの側のファイヤーウォールで止められてる、
なんてオチではないですか?


504 :名無しさん@お腹いっぱい。:04/09/04 16:37
>>503
いや、XPのFWはサービスごと停止してNISのみを使ってまつ。
いったいなんなんでしょう…(´ω`)ウレシインダケドネ

505 :名無しさん@お腹いっぱい。 :04/09/13 05:05:03
前スレ300 さんの業務日誌が HTTP 500 Error になるよ

506 :前スレ300 ◆w795LO9.Wo :04/09/15 16:33:03
>>505
> 前スレ300 さんの業務日誌が HTTP 500 Error になるよ

MEMORIZEの方ですかね?
それともライブドアのblogのほうですか?

http://blog.livedoor.jp/mr300/

ああ。更新してねえや、ちっとも。
結局「我が国の電子政府の現状についての調査(笑)」しかやってませんです。
JREバージョン地獄ですよ、わが国の電子政府は(笑)


507 :名無しさん@お腹いっぱい。:04/09/15 17:18:25
話の流れを断ち切るようでスマヌ。
実は相談に乗って欲しい。

俺はしがないiDCでのSSL担当なんだが、
グローバル・サーバIDをインストールするとき、
証明書と秘密鍵の整合性が確認できず、
いつもどきどきしながらhttpd restartを叩いている。

殆どは運用で大丈夫なんだが、たまに過去の履歴が不安になるので
なんとか整合性を確認したいのだが・・・

川崎に問い合わせても、大概冷たい返事が返ってきて鬱になる。
opensslコマンドにはそのような確認を行うコマンドはなさそうだし・・

Redhat限定で良いんで、誰かそのようかコマンドか確認手順を
教えてくれ。

ちなみに、川崎と八重洲では、八重洲の部署に勤めている
女の子はかなり美人系が多いことは確かだ。間違いない。

508 :前スレ300 ◆w795LO9.Wo :04/09/15 19:45:24
>>507
SSLもRedhatもOpenSSLもあまり詳しくないんで
お役に立てないとは思うんですが、
秘密鍵と証明書をpkcs12でexportしてみれば、
整合が取れてなかったらエラーになってくれるんじゃないですか?

全くの憶測だけで言ってますんでタトしてたらごめんなさい。

509 :前スレ300 ◆w795LO9.Wo :04/09/15 19:50:02
>>508
あーなんか単にまとめるだけで整合性までは見ないような気もするなぁ。
生半可な発言はもうやめて、誰か詳しい人の光臨を待ちます。ごめんなさい。

510 :名無しさん@お腹いっぱい。:04/10/01 18:06:20
ベリサインのグローバルサーバIDと
セキュアサーバIDって何が違うの?
あのサイトの説明はいまいちよく分からん。
普通にサイトにSSL導入したい場合はセキュアサーバIDでOK?

511 :名無しさん@お腹いっぱい。:04/10/02 13:41:08
>>510
>>400-403

512 :名無しさん@お腹いっぱい。:04/10/03 01:46:51
>>510

セキュアサーバ > ブラウザの仕様を信じて暗号化。設定は不要。
             しかしブラウザによっては40bitの場合有り
グローバルサーバ > サーバorクライアントに中間CA証明書設定が必要だが、
               絶対128bit暗号化通信

apacheの場合、中間CAを盛り込まないと下手すりゃ期限切れで
警告がでるので注意されたし。
あと、補償金額にも差がある。これは余り関係ないか。

513 :名無しさん@お腹いっぱい。:04/10/04 15:45:03
で、結局は証明書は必須なの?
いらないのならベリサインへのアクセスを止めたいんだけど、
どうすればいい?

514 :名無しさん@お腹いっぱい。:04/10/04 17:34:39
>>513

http://service1.symantec.com/SUPPORT/INTER/nisjapanesekb.nsf/jp_docid/20030606122656947

515 :名無しさん@お腹いっぱい。:04/10/05 00:40:33
ちょっとお聞きしたいのですが、
以下のような現象はベリサインの影響なんですか、それともノートンですかね?

--------------
当方、XPSP2を使ってるのですが起動してログイン画面でHDDやFDDに
アクセスしてるのですが、このアクセスが終了してからログインするのと終了前に
ログインするのとではservice.exeのCPU使用率が違うのです。

アクセス終了後に入ると0%で、終了前だと5〜6%を常に使用しています。
アクセスが起きる原因は恐らくノートン(NIS2003)だと思うのですが、それが何故に
関係するのかも理解できません。

同じような現象が起きている方、又は原因がお解かりになる方の助言をお願いします。

-------------
如何でしょう?

516 :名無しさん@お腹いっぱい。:04/10/08 03:18:07
例えば商売でサーバーを立ち上げそこでコンテンツサービスするとします。
その際、ベリサインのような認証局が発行する証明書を購入して、そのサーバー
がルート証明書として使用するとします。この場合、認証局が発行する証明書
は具体的にどのような形でサーバー運用者に渡るんでしょうか?CD−Rか
何かに焼いて渡すんですか?

517 :前スレ300 ◆w795LO9.Wo :04/10/08 12:58:40
>>516

サーバIDの受信
サーバIDは「申請内容確認」のお電話から5営業日以内にE-Mailで技術管理担当者へ送信致します。

http://www.verisign.co.jp/server/idregister/flow_7.html

ところで「そのサーバーがルート証明書として使用するとします」って、ちょっと誤解がないですか?
サーバー証明書はルート証明書じゃないと思います。

p.s.おれはベリのサポートかよ(笑)。給料おくれよ>べり

518 :423:04/10/08 17:35:19
>>517
まだやってたのか、あんたも飽きないねぇ〜w

最近ISPでPOP/SMTP over SSLサービスをやってる所も出て来たんだけど、ポー
ト番号が特殊なせいでウイルスソフトのメールスキャンが利用出来なくなる場
合がある。んでオレがDelegateで中継してメールスキャンもPOP/SMTP over SSL
も利用出来るようにした設定を置いていくので突っ込んでくれ。

delegate.exe ADMIN=hoge@mail.co.jp \
DGROOT="C:/Program Files/DeleGate" \
LIBPATH="C:/Program Files/DeleGate/lib" \
FSV=sslway \
SERVER=pop://secure.mail.co.jp:995:-:{localhost:110} \
SERVER=smtp://secure.mail.co.jp:465:-:{localhost:25} \
-Plocalhost:110,localhost:25 \
-Vrfy \
-vs \
LOGFILE="" \
PROTOLOG="" \
ERRORLOG="" \
TRACELOG=""

まああと細かい所はこの辺を確認してみて。
http://irish.ubiq.reset.jp/docs/Manual.htm
http://irish.ubiq.reset.jp/docs/DeleSSL/ssl.html

519 :名無しさん@お腹いっぱい。:04/10/13 17:14:38
すみません、みなさんはVeriSingへのアクセスはそのまま許して放置してるんですか?
それとも、FWで防いだりしてるんですか?

そのまま、アクセス放置してても問題ないんでしょうか?

520 :名無しさん@お腹いっぱい。:04/10/21 00:49:26
>>519

http://service1.symantec.com/SUPPORT/INTER/nisjapanesekb.nsf/jp_docid/20030606122656947

521 :名無しさん@お腹いっぱい。:04/11/12 14:19:53
保守

522 :名無しさん@お腹いっぱい。:04/11/19 23:50:33
NIS2003だけど起動時毎回ベリに繋がる( '・ω・)
しばらく良かったんだけどな〜
皆さんどうですか?

523 :前スレ300 ◆w795LO9.Wo :04/11/20 01:09:20
「前スレ300」ことMr.300%の技術日誌
http://blog.livedoor.jp/mr300/

久々更新。べりの話題じゃないけど電子認証関係ってことで。
公的個人認証のスクープ情報の再検証編です。

毎度ながら、このあたりの話題はどの板/スレが適切なんでしょうね。

524 :名無しさん@お腹いっぱい。:04/11/20 05:59:53
>>522
新しいのを取りに逝かなくちゃ。

525 :522:04/11/20 09:42:18
>>524
どうすればいいんでしょう( '・ω・)
ベリで更新するんでつか?


526 :名無しさん@お腹いっぱい。:04/11/20 10:16:42
>>525
>252に詳しく書いてあります。
一度このスレを全部読んで見るといいですよ、俺も最初は苦労しましたけど。

527 :名無しさん@お腹いっぱい。:04/11/20 18:13:42
>>526
苦労しましたがやっと出来ました
いまいち何をおこなったのかよく理解していませんが、
起動時にverisignに繋ごうとする現象は解消しました。

NISは放っておいたらずっとこういう状態なんですかね(;・∀・)

優しいお導きありがとうございました<(_ _)>

528 :名無しさん@お腹いっぱい。:04/11/20 18:14:15
↑522です

529 :名無しさん@お腹いっぱい。:04/11/20 18:37:26
シマンテックの証明書が月曜日の9時にまた切れるね

530 :名無しさん@お腹いっぱい。:04/11/30 16:37:49
Virisignのセキュリティーシールの新しいフラッシュのやつが表示されないマシンがあるのですが、なぜでしょう?

531 :名無しさん@お腹いっぱい。:04/12/03 11:53:15
べり落ちてねーか?

532 :名無しさん@お腹いっぱい。:04/12/03 12:09:36
あ、やっぱ落ちてるよね。
うちフラッシュシール張ってんだけどページがスゲー重くなって苦情が来てる。




533 :FLP:04/12/03 12:28:43
落ちてますよね。

534 :名無しさん@お腹いっぱい。:04/12/03 12:31:44
今仕事で作ってるHPに、今日フラッシュシール貼ったのに
全然表示されないわ重くなるわで超焦った(w

公開前でよかった。

535 :名無しさん@お腹いっぱい。:04/12/03 12:41:42
フラッシュシールでるようになったよ。証明書は出ないけど。
画像シールと違ってページ自体重くなるのは困る!
ついでにサポートがメールだけってのが腹が立つ。

536 :hoge:04/12/03 14:39:53
プレスリリース キタ━━━━(゚∀゚)━━━━ッ!!
ttp://www.verisign.co.jp/press/info/announce20041203.html

537 :前スレ300 ◆w795LO9.Wo :04/12/05 12:37:03
あら、珍しくスレ伸びてると思ったら、そんな事が起きてたんですね。

落ちてた期間がそこそこあるのなら、
日割り・時間割りで料金の返還請求ってのはどうでしょう。
そういうのが出来る規約かどうかは未チェックですが。

まぁ返還請求は実際には無理っぽいとしても、
せめて仕事でHP作っている人用には
クライアント向け、またはHP利用者向けに
そのままリンク可能な謝罪ページを作って貰えるといいですよね。
プレスリリースの内容ではピンと来ないかもしれないので。
「○○の期間、HPが重かったのはベリのせいです、ごめんなさい」
みたいな、実際起きていた事との関連がわかりやすいように。

HP利用者の認識は「ベリサイン セキュアシールが表示されない」ではなく「なんかえらいHP重い」でしょうからね。


538 :名無しさん@お腹いっぱい。:04/12/06 09:54:02
リンク可能な謝罪ページや障害情報はあると便利だね。
シール貼ってまだ間もないんだけどベリが落ちるのって珍しいのかな?

539 :名無しさん@お腹いっぱい。:04/12/10 01:03:14
>>519
FWはあるみたいじゃん。セキュリティーの会社だからな。
FWなかったら寂しいべ。
だれか、べりさいんに侵入してみてくれよ。

540 :名無しさん@お腹いっぱい。:04/12/16 14:03:31
フラッシュシール張ったら、プライバシーレポートでCookieブロック済みって出ちゃうんだけど、こうゆうもんなの?
www.verisign.co.jp/ でも同じように出るし・・・

541 :名無しさん@お腹いっぱい。:04/12/16 14:43:55
サードパーティのクッキーをブロックするようにしてんじゃないの?

542 :540:04/12/16 17:21:52
確かにIE6の設定はサードパーティのクッキーをブロックする設定になっているけども、デフォルトでブロックする設定になってるから・・・。
ttp://www.atmarkit.co.jp/fwin2k/experiments/ie6privacy/ie6privacy_05.html
これ見た感じ、ベリサインがP3P準拠のプライバシ・ポリシーを提供すればいいと思うんだけど、現段階ではしてないってことだよね?
これってどこのサイトでもいっしょだよね?
っていうわけで、ベリサインが対応するまで仕方ないですってことにしちゃっていいのかな?


543 :前スレ300 ◆w795LO9.Wo :04/12/17 10:13:16
特報!シマンテックがベリ買収!!

http://www.itmedia.co.jp/enterprise/articles/0412/16/news104.html

544 :名無しさん@お腹いっぱい。:04/12/17 10:14:08
しまったー。ネタを記名で書いちまったー。トホホ。

545 :名無しさん@お腹いっぱい。:04/12/17 11:31:19
(・∀・)ニヤニヤ

546 :名無しさん@お腹いっぱい。:04/12/18 00:57:18
バーカバーカバーカ

547 :名無しさん@お腹いっぱい。:04/12/29 20:43:34
基本的な質問だけど、Verisignの署名の入ったサーバ証明書
って誰でも取れるの?
もしそうだとすると、MicrowSoftという名の会社でも取得できてしまう
ということ?


548 :蕪木ら某 ◆Googl8RmwA :04/12/30 00:34:10
>>547
ttp://www.verisign.co.jp/server/idregister/flow_1.html
> 任意団体や個人のお客様など、法人格の無いお客様の場合には、
> サーバIDを取得いただくことができません。
?????

549 :名無しさん@お腹いっぱい。:04/12/30 14:57:40
>>548
法人格があっても同一名、類似名の会社はあると思うが。

550 :名無しさん@お腹いっぱい。:04/12/30 23:09:40
>>549
その通り。
住所まで見ないとね。

551 :名無しさん@お腹いっぱい。:05/01/01 11:50:11
>>550
住所まで覚えている奴はあまりいないと思うので、
サーバ証明書ってあまり意味ないように思うのは俺だけ?

552 :名無しさん@お腹いっぱい。:05/01/02 11:22:14
そのへんはCAの信用にかかわるキモだから、
類似商号は登録拒否していると思われ。
役所じゃないから、登録する義務はないからね。


553 :名無しさん@お腹いっぱい。:05/01/05 23:25:47
>>547

法人格でも、以下の条件のどちらか満たせないと取得できない

1.登記簿謄本(現在事項証明書)が提出できる

2.帝国データバンクへの登録(商号登記・情報提出)などが行われている

ベリサインはその辺がメチャメチャ厳しい。
なのでベリサインの証明書を持っているサイトはまず大丈夫かと思われる。

事実、さる官公庁相手に証明書の更新手続きをしたら相手が逆ギレして
認証が2週間STOPして、相手と対人認証をベリサインの人間を引き連れて
期限切れ3日前にやっと到着したという目にも涙語るも涙という事があった。

登記が偽物かという話はあるだろうが、結構めんどくさい作業なので
SSLを取ってまで野郎という奴はいないだろう。

554 :名無しさん@お腹いっぱい。:05/01/06 00:15:21
>553
なんか大変だったみたいだけど、とりあえずもちつけ。
「事実、さる〜」以降を説明してくれると、大変ありがたいのだが。

555 :名無しさん@お腹いっぱい。:05/01/06 01:03:33
お役所仕事に嵌った。(10文字)

556 :553:05/01/06 22:56:23
>>554
そんではお言葉に甘えて。

一昨年の話で恐縮だが、うちの会社である官公庁のシステムに利用する
証明書を扱っており、年末に更新だったので部署経由で証明書の更新手続きを依頼した。
ところが、担当の課長相当が相当なケチものらしく、ベリサインからの電話に対して
「他部署からの話が違う」「いったいいくらで作業しているんだ」とかぬかしやがった。
当然認証作業はSTOP。それに官公庁から証明書の価格詳細を示す書類を出さないと
再認証には応じないとという要求を他部署経由で出してきたために
ベリサインの営業と相談。

そんな資料は当然出せないので、相手部署とベリサインとの折衝に苦労したよ。
結果的に、他部署の営業とベリサインの営業、認証部隊を引き連れてそのお役所に
出向いて価格の説明と認証作業を実施し、最終認証も現地で行って事なきを得た。
それが証明書期限の3日前に到着、インスト作業はヒーヒーもんだった。

今年は担当が変わったらしくたったの2日で最終認証にこぎ着けたよ。
やっぱりお役所は大変だぁ。
だから証明書担当の気構えとしては
・お客担当営業に、強く「申請責任者に定時間中に電話を必ず取って下さい!!」と念を押す
・風邪を引かない
・バックアップ担当を出来るだけ回すか、育て上げピンチの時に
 最終認証に出てもらえるようにする。
・川崎の番号はそらで覚えておく
かな。

営業経由で他の営業にきちんと説明できないとこの仕事はやっていけないよ。
証明書って保険みたいなくせに期限切れだけはめざといからなぁ。
以上。名無しに戻ります。

557 :554:05/01/07 11:20:24
>556
お疲れ様でした。認証ビジネスも決して楽ではないんだね。
おかげで大変参考になりました。

558 :名無しさん@お腹いっぱい。:05/01/07 13:48:51
>>556
官公庁が使うベリの証明書取得を仲介してて
お役所仕事に嵌った。

でよろしいかな?

559 :556:05/01/08 00:39:05
>>558

いや、「お役所のクソ役人」に嵌った。
にして下さい。
今年はごく普通の対応だったので、お役所仕事全般という
訳ではなかったので。

560 :前スレ300 ◆w795LO9.Wo :05/01/10 11:07:16
気が付けばあの日から1年が過ぎています。
皆様お元気ですか?


561 :名無しさん@お腹いっぱい。:05/01/10 11:19:54
でもverisignのCPSでは、悪意のactivex配布する会社にもコード署名可能な
証明書を平気で発行できるんだよね。ようするに、糞。

562 :前スレ300 ◆w795LO9.Wo :05/01/10 14:16:10
>>561
「どこの誰が、いつ作ったコンポーネントなのか」
をとりあえず特定できるだけでも
「どこの誰が、いつ作ったコンポーネントなのかすらわからない」
よりはマシなんじゃないでしょうか。

ベリの仕事は、どこの誰かを証明するまでで
そいつが善人か悪人かってのはまた別問題だと思う。

「ようするに、糞」ってのはどうかと。
activexは糞かもしれませんが(笑)

563 :名無しさん@お腹いっぱい。:05/01/13 12:44:04
http://takagi-hiromitsu.jp/diary/20050111.html#p01
だめだこりゃ・・・

564 :名無しさん@お腹いっぱい。:05/01/13 23:05:18
>>594
ダメってその日記の主がイタイってことでOK?

565 :名無しさん@お腹いっぱい。:05/01/14 14:12:17
>>564
おまいにはこのスレは高度すぎて無理だろう。

しかし高木さんもよくこれだけ頑張れるものだ... 漏れだったら
ここまで粘れないよ...

566 :名無しさん@お腹いっぱい。:05/01/14 18:20:21
しかしベリは高すぎるよ。寡占の弊害だよね。
このスレも寡占を加速するようなスレタイなのがまずい。
スレタイ変えれ

567 :名無しさん@お腹いっぱい。:05/01/14 18:58:06
>>565
図星突かれて中傷ですか

568 :名無しさん@お腹いっぱい。:05/01/14 19:21:40
>>563
読んでたらむかついてきたっ
>>566
電子証明書(デジタルID)一般の話題を表すスレタイにされたい

569 :名無しさん@お腹いっぱい。:05/01/14 19:33:08
>>567
高木さんがこんな場末に来るわけないだろ。
日本でセキュリティ関係の仕事している香具師なら、誰でも
知ってる人だよ。漏れは場末のネットワーク屋さ。

>>568
漏れも役所の馬鹿担当者の無責任さに猛烈に腹が立った。漏れでは
あんな冷静な対応できないよ。

>>566
禿同。

570 :名無しさん@お腹いっぱい。:05/01/14 19:39:47
( ´,_ゝ`)プッ

571 :名無しさん@お腹いっぱい。:05/01/14 22:09:12
>>565
役所の立場というものを考えると、高知県の言い分で一部だけ納得できるところがある。
その部分に対して高木氏は話の核心に触れずに流してしまった。
やっぱり、政治的な部分がわからない香具師はイタイよ。
俺から見れば馬鹿丸出し。「ちゃんと新聞嫁!」と、言いたい。
ここでタジタジしている役所の担当者もどうかとは思うが。

ところで、藻前は俺が一部納得したのは、どこを指しているかわかるか?
昼間から2ちゃんねるに書き込んでいるような香具師にはわからんだろうな。

572 :名無しさん@お腹いっぱい。:05/01/14 22:20:28
--------------------------------------------
ここまで、俺の自作自演


573 :名無しさん@お腹いっぱい。:05/01/14 22:25:27
> このサイトのセキュリティ証明書の取り消し情報は、使用できません
このような警告がブラウザで表示されることがあるのですが、
問題がサーバ側にあるのか、クライアント側にあるのかすら自分には分かりません。
セキュリティ証明書+取り消し情報 で検索してここにたどり着きました。
どうしたらよいのでしょうか?

574 :名無しさん@お腹いっぱい。:05/01/14 22:58:17
>>571
LGPKI のことか?
高知県は LGPKI も使ってないわけだが?

575 :名無しさん@お腹いっぱい。:05/01/15 01:30:48
>>571
県: ネットスケープは今回対応していない……

↑ここだろ?お前が納得したのは。


576 :名無しさん@お腹いっぱい。:05/01/15 01:54:31
ワラタ >>575

577 :名無しさん@お腹いっぱい。:05/01/15 11:06:19
クソ知ったかの無駄な抵抗だな

578 :名無しさん@お腹いっぱい。:05/01/15 11:06:27
東京電子自治体共同運営サービスも大変だよ〜。

都と都内市町村関連の入札が電子化されるってことで
入札に参加したい人は、まずは資格審査ってのを受けないといけないんだけど
それに所定の電子証明書が必要。
でもって、これの登録ってのが、初めての人には結構ハードルが高い。
おまけにコールセンターへの接続ハードルも高く、問題解決ハードル通過力は極めて低い。

だから、ちゃんと登録できない人続出。
てなわけで、受付の締め切りが12/10→12/28と延長されたけど、
やっぱりだめみたいで、1/21までに再延長されてる。
一応「資格審査申請 入力登録センター」てのは作るみたいだけど。

国のやることもアレだけど
地方自治体のやることはもっとアレだと思う。

579 :名無しさん@お腹いっぱい。:05/01/15 11:44:49
>>578
東京電子自治体共同運営電子調達サービスの指定認証局

「KeySignサービス」
  日本電子認証株式会社
  有効期間1年: 9,450円
  有効期間2年:16,800円
  有効期間3年:22,050円

「TDB電子認証サービスSG」
  株式会社帝国データバンク
  有効期間2年1ヶ月16,800円

「商業登記に基づく電子認証制度(商業登記認証局)」
  法務省
  有効期間3ヶ月〜27ヶ月
  (3ヶ月2,500円、以降1月あたり1,800円。最長3+24=27ヶ月)
  有効期間1年: 7,900円
  有効期間2年:15,100円

我らがベリは、特定認証局じゃないです。
でも、帝国の後ろにはベリが居るようです。
あとTOiNX、よんでんも。

http://www.gpki.go.jp/cas/ee.html
http://www.verisign.co.jp/egov/index.html


580 :名無しさん@お腹いっぱい。:05/01/15 11:47:17
>>579
一見、天下の法務省が一番割安だが、
電子証明書の申請と取得に有料の専用ソフトを購入しないといけない。
その初期費用が発生するので注意が必要。
(ソフト自体は最初に1回買えばよい)


581 :名無しさん@お腹いっぱい。:05/01/18 14:46:48
初めて証明書更新しようと準備してるのですが、手続きに少し不満を感じました。

延長という形式がなくて更新しかないってのは技術的に納得いくのですが、
前と後の証明書の期間が重なる部分を2重に料金取られるのは避けようがないのでしょうか?

サーバの更新運用考えると1〜2日は重ねたいとは思いますが、
早めに手続きしたら2週間ぐらい重なって、
その余計な期間分の料金がだぶるのは、避けれるものなら避けたいですよね。

でも期限ぎりぎりは怖いし・・・みんな我慢してるのかな〜

582 :名無しさん@お腹いっぱい。:05/01/18 18:27:00
なんか勘違いしてたかもorz  ハズイ

更新したら、
開始日:ベリサインの手続きした日
終了日:前の証明書の終了日の1年後
になるってのが普通の解釈ですよね。

これであってますか?

583 :名無しさん@お腹いっぱい。:05/01/18 19:49:47
>>582
うちもそろそろ更新なんだが、581の考えであってると思う。
開始日:ベリサインが発行した日
終了日:ベリサインが発行した1年後
証明書の有効期限に1年プラス数日という考え方がないですから、
単純に発行手続き(更新手続きも同様)から1年のはず。

セコムから買えば、更新の場合は価格が安くなるから
ちょっとだけ納得できる。

584 :名無しさん@お腹いっぱい。:05/01/26 00:30:45
この中に証明書申請担当香具師はいねぇか?

今日久しぶりに証明書更新申請しようとしたら
いつの間にやらポータルサイト制に
変貌してたんだよ!!

申請ドメインの履歴から管理できるのは良いが、
俺が2ヶ月かけて作った手順書が・・・ OTL

くそー、こうなったら日○○に電話してやるー。

一度行ってみそ。個人申請用証明書ももらえっから。
あるとログインがかなり便利。

585 :名無しさん@お腹いっぱい。:05/01/26 10:08:19
日能研?

586 :前スレ300 ◆w795LO9.Wo :05/01/26 18:11:56
>>584
すんません、これってどこの話ですか?ベリ?

> 一度行ってみそ。個人申請用証明書ももらえっから。
> あるとログインがかなり便利。

ってのに激しく興味があるんですが。


587 :蕪木ら某 ◆Googl8RmwA :05/01/27 00:01:59
>>586
-> ttp://www.verisign.co.jp/user/index.html
  ttp://www.verisign.co.jp/server/help/faq/190039/index.html
  ???

588 :名無しさん@お腹いっぱい。:05/01/27 10:58:13
981 :仕様書無しさん :05/01/26 16:15:44
http://freebbs.around.ne.jp/article/u/ungrpso/38/tbjykb/orvdlz.html#orvdlz
Mine <eeuonjcxqg> 2005/01/23 13:24:39**
そもそも当該の警告は

マイクロソフトが勝手に警告を出しているだけで、その証明書が
有効であるか否かにはまったく関係がありません。
ちゃんとした証明書を発行しても、それをマイクロソフト社に対
して申請しないと警告を出すという、横柄なことをIEがやってい
るわけでして。
べりサインやらセコムやらの証明書なら信頼するが、広島市が独自に
発行した証明書は信頼できないってのは変な話。

一般論としては、ただの一企業が承認しようがどうだろうが、
信頼性にはまったく影響しない。この警告はまったく意味がなく
単なるマイクロソフト社のユーザーに対する脅しでしかないわけ
ですよ。仮にマイクロソフト社が承認した証明書で、何かしらの
不利益を被っても、マイクロソフト社が責任をとってくれるわけでなし。

マイクロソフト社は、広島市を正規の団体として認めていないと
いうだけの話で、広島市自体は、マイクロソフト社に認められよ
うと認められまいと、そんなこたぁ関係ないし、マイクロソフト
社が「広島市を正規の団体として認めない」と言うのなら、ただ
の馬鹿企業。広島市の証明書に対して、不要な警告を出さないよ
うに努力するべきは、日本国の正規の自治体である広島市ではな
く、マイクロソフト社であるべきなんですよね。

589 :名無しさん@お腹いっぱい。:05/01/27 12:11:20
>588
それは現実を見ていない理想論。
現状利用者を保護するためには、それなりのルート証明書に辿り着く
証明書でしか保護できない。

590 :前スレ300 ◆w795LO9.Wo :05/01/27 14:30:06
>>589
「それなりのルート証明書」というのが
「デフォルトでWindowsが持ってるルート証明書」だけなのか
それプラス「利用者自分が信頼するに足ると判断した証明書」なのか、って事でしょう。

「デフォルトでWindowsが持ってるルート証明書」以外のルート証明書は
利用者が真偽を確認するための方法を提供した上で
利用者が「信頼されたルート証明書」としてWindowsに登録する。

適切な情報開示と自己責任による信頼っつー事ですね。

マイクロソフトが信頼していないルート証明書は
自分自身が信頼するに足るか否かを確認して判断しろ、ってゆーことで。

電子政府関連の各省庁の証明書なんて
「デフォルトでWindowsが持ってるルート証明書」になんか全然つながってませんぜ。

法務省の例
http://shinsei.moj.go.jp/certification/certificate.html

591 :前スレ300 ◆w795LO9.Wo :05/01/27 14:40:03
>>563
ちなみに、「広島県・市町村電子申請システム」のサイトは、さすがにちゃんとした証明書使ってますね。

https://www.shinsei-hiroshima.jp/

ベリの証明書だし(笑)

まーなんにしろ、公共の期間がSSL対応のサイト構えるなら、
ちゃんとした証明書使わにゃいけませんよね。
たとえ自己証明書でも有効期限とかサイト名とかぐらいはきちんとしないと。

592 :前スレ300 ◆w795LO9.Wo :05/01/27 14:52:47
ううう。誤字だらけだわ、上げてるわ…。

どうも>>543以来不調ですわ。

593 :名無しさん@お腹いっぱい。:05/01/27 22:39:00
>>590
ようやくまともな香具師が出てきた。待ってたぞ。

>>589
バーカ。チンカス溜まってそうな奴の書き込みだな。
それなりの証明書って何だよ?
お役所はシェアだけじゃ一企業を認めるわけにはいかねぇんだよ。

594 :名無しさん@お腹いっぱい。:05/01/27 22:51:25
で w795LO9.Wo はどうやって法務省の証明書を入手するんだ?

595 :前スレ300 ◆w795LO9.Wo :05/01/28 00:35:29
>>594
そこなんだよね。さっきの

http://shinsei.moj.go.jp/certification/certificate.html

からダウンロードするんだけど
このサイト自体はhttpsでアクセスできないので
サイトの素性を確かめることが出来ない。
おまけにフィンガープリントも同じサイトに書かれてる。まぁ

http://www.moj.go.jp/KANBOU/shinsei.html
http://www.e-gov.go.jp/fingerprint/moj.html

にもあるにはあるんだけどね。


596 :前スレ300 ◆w795LO9.Wo :05/01/28 00:41:29
マイクロソフトを信頼しない人は
マイクロソフトが信頼するルート証明書も信頼できないでしょうから
証明書ストアにデフォルトで登録されている
「マイクロソフトが信頼するルート証明書」も一回全部削除して
ひとつひとつ自分で信頼するに足るか否かを検証すべきでしょう。

なんてね。

597 :名無しさん@お腹いっぱい。:05/01/28 19:29:31
596>「マイクロソフトが信頼するルート証明書」も一回全部削除して
ひとつひとつ自分で信頼するに足るか否かを検証すべきでしょう。

そんなことするとWindowsUPDATEが出来なくなったりいろいろあるからやめれ。(本当)
どうしてなのか因果関係は知らないが。
それに、マジ復旧は不可能に近いぞ。遊びでやるのもやめれ。

596>なんてね。

イタズラも大概にしておけ。



598 :名無しさん@お腹いっぱい。:05/01/29 00:01:01
まだいたのか罵倒空振り知ったか野郎は

599 :584:05/01/29 01:26:15
マイクロソフトのルート証明書よりも
クーポン券が川崎にFAXしなくて良いとはどういう事だ。
発行ステータスがどういう状態か確認できるとはどういう事だ。
お客さんのメールアドレスが必須と言うことはどういうことだ。
グローバルサーバIDの注文履歴しか出てこないとはどういう事だ。OTL

とりあえず大田区界隈に出没するのはやめておこう。
○東○方面に出没。ちなみに美人の宝庫。

600 :前スレ300 ◆w795LO9.Wo :05/01/29 02:19:24
>>597
> イタズラも大概にしておけ。

そうですね。ちょっと冗談が過ぎました。
>>596を訂正します。

マイクロソフトを信頼しない人は
マイクロソフトが信頼するルート証明書も信頼できないでしょうから
証明書ストアにデフォルトで登録されている
「マイクロソフトが信頼するルート証明書」も
ひとつひとつ自分で信頼するに足るか否かを検証すべきでしょう。
もしも信頼できない証明書があったら、
エクスポートしておいてから削除するのもいいかもしれません。

なんてね。


601 :名無しさん@お腹いっぱい。:05/01/29 03:37:50
バカ池沼に構うなよ

602 :名無しさん@お腹いっぱい。:05/01/29 12:28:02
くそー、申請がうまくいかねーぞ。
正しいCSR入れてるつもりだが、Organizational Unit(部門名)が違うとはじかれるし、
何回かやってるうちに(同じCSR入れたはずなのに)突然うまくいった、
しかしその後、帝国データバンクで検索できーねーとかいうが、
帝国データバンクのHPから今検索できてるし、
んでもう一回やり直したら、またOrganizational Unit(部門名)が違うとはじかれる。

もう嫌!

603 :602:05/01/29 13:05:11
はっはっは、勘違いで八つ当たりしてた模様、ごめんよベリサイン
その後うまくいったが、何で違うCSRで先の画面に進めたのかなぞだな

604 :名無しさん@お腹いっぱい。:05/02/06 05:22:00
「livedoor SSL」6万3000円/年だそうだが、どうよ?
http://japan.cnet.com/news/sec/story/0,2000050480,20080453,00.htm

605 :名無しさん@お腹いっぱい。:05/02/06 15:01:09
そこが出すとデジタルでは保護されててもアナログじゃ筒抜けっぽいな

606 :名無しさん@お腹いっぱい。:05/02/07 14:37:08
ライブドアホのセキュアシールは、ダサイ

607 :名無しさん@お腹いっぱい。:05/02/09 15:11:30
ベリサインの新シール、flashバージョンをデフォで使わせようとしてるけど、
Flashが入ってないPCに考慮してgifにしようかと思った。
そんなケースはレアだとは思うけど、flashにするメリットもあまりないし。

みんなどうしてる?

608 :名無しさん@お腹いっぱい。:05/02/09 20:33:19
シールなんて無しが基本。

609 :名無しさん@お腹いっぱい。:05/02/10 10:59:48
flashの方も簡単にコピーできるんですね。


610 :名無しさん@お腹いっぱい。:05/02/11 18:44:48
シールなんですけど、以前は透明化だったものが透明化じゃなくなってます。
どういうこと?


611 :名無しさん@お腹いっぱい。:05/02/23 11:17:37
質問です。verisignで発行される証明書とapacheなどで生成する証明書
は何が違うか分かりません。verisignはブランドで金とってるんですか?


612 :前スレ300 ◆w795LO9.Wo :05/02/23 12:34:44
>>611
ベリサインでは世界で最も実績のある第3者認証機関として、サーバIDの申込みをされたウェブサイトの運営主体が実在するものであるか、非常に厳格な認証局運用規定に則り、実際にその運営主体への確認を行った上でサーバIDを発行しています。

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

613 :名無しさん@お腹いっぱい。:05/02/23 14:29:52
>611
・verisignが発行する証明書は、verisignが認証した証明書。
 よってverisignを信用できるなら、その証明書も信用できる。
・自己署名は、自分で自分を認証している。よって誰も証明
 してくれない。
・世の中のほとんど全てのweb browserは、verisignのルート証明書
 を持っている。よって、verisignが発行した証明書が正しいかどう
 か自動的に判断できる。これに対し、自己署名はユーザが`自己の
 責任において信用するものであるので、多くのブラウザは「確認
 できない」とワーニングを出す。
 なおAUの携帯ブラウザは、自己署名のページに接続できない仕様に
 なっている。

> verisignはブランドで金とってるんですか?

ある意味そうとも言える。一番最初に証明書ビジネス始めた会社だからね。
別にverisign以外の会社でも対象によっては何も問題ないのだけど、verisign
ならまず間違いなく使えるので。

614 :名無しさん@お腹いっぱい。:05/02/23 14:35:39
verisignうぜー。以前ここでドメインとったけど、飽きたから
更新しないようにしたら、自宅に十通くらい
封筒で更新しろしろ迫って来てすんげーしつこかった。
しかも、更新起源切れても二、三回追加で来たし。
更新しないとちゃんと伝えておいたのに。
むかついたんでクレーム入れてやったが。
もう、ここからドメインは取りません。


615 :611:05/02/23 15:49:56
>612
>613
verisign証明書と自己署名の証明書は基本的には
違わないんですね。
お二方ともご回答ありがとうございます。

616 :名無しさん@お腹いっぱい。:05/02/23 16:08:23
>>615
証明書自体のデータ構造としては「基本的に違わない」と言ってもいいかもしれないけど
第三者からの実在性についての確認があるかないかでは
認証という意味ではまったく違うものだと思います。

617 :名無しさん@お腹いっぱい。:05/03/03 19:12:46
真の情報化社会を迎えるには
政府レベルで一人にひとつ生涯固定の証明を発行するしかないね

免許や年金・社会保険番号、ソーシャルセキュリティー、電子マネーと共通で


618 :名無しさん@お腹いっぱい。:05/03/03 21:11:32
【情報セキュリティ基礎】
617の提案は情報化社会を崩壊させかねない危険な提案である。
その理由に付いて論じなさい。
少なくとも数学的な論点と、社会的な論点について述べる事。


619 :名無しさん@お腹いっぱい。:05/03/03 23:14:26
重機ねっと

620 :名無しさん@お腹いっぱい。:05/03/05 18:06:23
暗号は解かれるものである
人は騙せるものである

621 :名無しさん@お腹いっぱい。:05/03/07 12:04:48
>620
(100点満点で)5点

622 :620:05/03/10 11:15:40
よっしゃ試験勉強ナシで零点回避w

んでそろそろ模範解答を…

623 :名無しさん@お腹いっぱい。:05/03/10 11:39:24
>622
そんな不真面目な態度で解説してもらえると思っているのか?
大体0点回避って何の意味があるわけ?普通大学じゃ60点未満で
単位取得できないだろ?

...そうかリアル厨房・工房か... 大学ではそれじゃぁ通用しな
いから、頑張ってね。

624 :620:05/03/11 16:38:36
煽りはいいから答えうp

625 :620:05/03/11 16:40:38
age は余計だったこれはスマソ

626 :名無しさん@お腹いっぱい。:05/03/11 21:31:52
↓これに気づいてるヤシは少ないと思われ。
http://www.verisign.co.jp/corporate/releases/20050311b.pdf

627 :sage:05/03/11 21:40:42
624

628 :sage:05/03/11 21:41:21
ex

629 :名無しさん@お腹いっぱい。:05/03/11 21:55:57
天下のverisign でもこんなことがあるのか…
手持ちのお客様データ真剣に考えようorz 趣旨スレ違いスマソ

鍵が漏れればもっとエキサイティングだったけどね

626氏 指摘乙

630 :名無しさん@お腹いっぱい。:05/03/11 22:00:24
>>626
http://www.verisign.co.jp/corporate/investor/shareholder/index.html

2/1付けと併せて読むと趣き深い。

631 :名無しさん@お腹いっぱい。:05/03/11 22:01:24
>626
もっと詳しい情報ないの?

632 :名無しさん@お腹いっぱい。:05/03/11 22:02:07
>626
もっと詳しい情報キボンヌ

633 :名無しさん@お腹いっぱい。:05/03/11 22:02:31
>626
詳しい情報キボンヌ

634 :名無しさん@お腹いっぱい。:05/03/11 22:05:44
626のネタ、もっと詳しい情報があったら教えれ。

635 :名無しさん@お腹いっぱい。:05/03/11 22:11:43
>>626
「電車内で盗難」?
これは盗難よりも
パソコンくんが網棚旅行とかに出かけた疑いのほうが強くないか?

車上狙いならまだわかる。
でも電車だし。
スラれたのならまだわかる。
でもパソコンだし。

盗難ねぇ。うーん。

636 :名無しさん@お腹いっぱい。:05/03/12 13:39:01
>>635
泥酔して超無防備状態というのもあるかもしれん。

これからは仕事帰りに酒も飲めなくなるのか... orz

637 :名無しさん@お腹いっぱい。:05/03/12 13:57:54
>636
仕事帰りに泥酔したければ、危ないものは持ち歩くな(藁
泥酔して財布の中身全部なくすなんて話、良く聞くよ。

638 :名無しさん@お腹いっぱい。:05/03/12 20:22:16
某元国会議員のことかー!

639 :名無しさん@お腹いっぱい。:05/03/13 16:37:38
CNET、スラッシュドットで取り上げられたな。

640 :名無しさん@お腹いっぱい。:05/03/15 10:33:26
最近のベリって、いっぱい人辞めてるらしいぜ。
パソコンどころか社員も管理できてるのか怪しいよな。

641 :名無しさん@お腹いっぱい。:05/03/15 16:24:14
私怨逆恨み面白いね(p

642 :名無しさん@お腹いっぱい。:05/03/15 18:20:12
s/mimeの証明書を取るにはどこがよい?
ISP・ジャストシステムと無関係だと、日立情報システムかUS VeriSignしかない?
情報が少なくて、よく分からん。

643 :名無しさん@お腹いっぱい。:05/03/15 23:16:06
>>642

 プロバイダと関係が無い証明書の場合は、日立情報の
 証明書をお勧めします。

 年額3150円(税込み)
 但し郵便振替が必要になりますのでご承知おき下さい。
 お申し込みは以下のリンクからどぞー。

 http://digitalid.shield.ne.jp/verisign/index.html

644 :名無しさん@お腹いっぱい。:05/03/18 00:52:58
>>640

つーか、そういうことより、情報セキュリティコンサルティングなんて
売れる立場か?って感じだな・・・。

645 :名無しさん@お腹いっぱい。:05/03/18 15:55:06
>>640
和塩を調べてみた
http://www.geotrust.co.jp/ssl_help/scls3-1.html
>Q メール暗号化をしたいのですが、どの商品を選べはいいのでしょうか? 
>A 通信経路のメールデータを暗号化する場合は、メールサーバにクイックSSLプレミアムを
>インストールしていただくことで対応できます。 メールの文面を暗号化する場合は、
>メーラーのS/MIME機能を使うために (クライアント証明書)を送信者・受信者の環境に
>インストールすることで対応できます。

うーん、そんなんで大丈夫なんか?

646 :名無しさん@お腹いっぱい。:2005/03/22(火) 18:01:03
>>644

株価は反応してるみたいだが。

647 :名無しさん@お腹いっぱい。:2005/03/23(水) 00:37:20
>644

その割には騒ぎがおおきくならないな。
○○○とかがやらかしたら祭りになると思うが...

だいたいこんなタイムリーな時期に新聞屋が反応しないのが気になる。
工作したんだろうけど。
Webメディアで反応していないのはImpressとどこ?



648 :名無しさん@お腹いっぱい。:2005/03/23(水) 15:28:47
>>645
> うーん、そんなんで大丈夫なんか?

「そんなんで」ってのはどのあたりのことだろう?

649 :名無しさん@お腹いっぱい。:2005/03/26(土) 21:59:05
>>648
クライアント証明書をS/MIME に使う?

650 :名無しさん@お腹いっぱい。:2005/03/27(日) 12:13:44
無料の証明書って全滅したの?

651 :名無しさん@お腹いっぱい。:2005/03/28(月) 14:56:03
>>642
s/mimeの証明書って、メールの暗号化に使うってことかな。
具体的にどういう使い方を考えてるのかがわからないんだけど
仲間内で使うだけなら自作でもええんじゃない?


652 :名無しさん@お腹いっぱい。:2005/03/29(火) 01:48:05
>>651
仲間内で使うなら PGP でよい。
S/MIME はそういうものじゃない。自作すんな。

653 :前スレ300 ◆w795LO9.Wo :2005/03/29(火) 09:22:58
>>652
そういうものじゃないってことはどんなものなんですか?
PKIを利用した電子メールの署名/暗号化と理解してたんですけど。

654 :名無しさん@お腹いっぱい。:2005/03/29(火) 12:52:16
>>652
S/MIMEは自作して仲間内で使っています。

というのも、PGP/GPG対応メーラは最近多少増えてはいるけど、
素人にOEとかでS/MIME使わせる方が楽なんで、
結局、自作S/MIMEで利用しています。

本来の使い方ではないのでしょうが、簡単に近辺の人に
使ってもらうのには重宝するですよ。

655 :前スレ300 ◆w795LO9.Wo :2005/03/29(火) 13:13:49
>>654
PKIの効果として乱暴に言えば
(1) 電子署名による送り手の同一性の保障
(2) .暗号化による通信データの秘匿
(3) 電子認証による書き手の素性の保障
の3つが考えられると思うけど、

内輪だけでの運用であれば、
内輪であることと(1)とで(3)はある程度無視することも可能だろうから
自作の証明書を使う、てのもアリだと思います。
自作の証明書でも(1)と(2)は実現できますから。
簡単に近辺の人々と電子署名や暗号化が運用できているのであれば
十分に「本来の使い方」じゃないかと思います。

ただ、不特定多数との運用であれば
「信頼のおける第三者による素性の保障」
すなわち(3)が必要になってくると思いますから
自作ではなくそれなりの認証機関の電子認証サービスを利用すべきでしょう。
当然、費用はかかりますが。

656 :名無しさん@お腹いっぱい。:2005/03/29(火) 15:57:06
>>652
メールはPGPが常識

657 :前スレ300 ◆w795LO9.Wo :2005/03/30(水) 11:05:24
>>650
> 無料の証明書って全滅したの?

thawte はまだやってるみたいですよ。全部英語だけど。

http://www.thawte.com/email/index.html

658 :名無しさん@お腹いっぱい。:皇紀2665/04/01(金) 12:21:08
 S/MIMEメールで相手の電子証明書が失効しているのか?を即座に
検証する機能がついているメールソフトってEutlook Expressくらい
なんでしょうか?
 さっきS/MIMEメールを受信しました。相手の証明書はベリサイン発行のものです。
 電子証明書の有効性をオンラインで確認すると表題のように
「デジタル ID が失効されていないか、この証明書の失効情報を判別できませんでした。」
 こう表示されますが、要するにベリサインの失効情報(CRLというのかな?)に記載されていない。
 
 "有効な証明書"ということなんでしょうか?

 一瞬「失効してるID?」と理解してしまったもので

659 :名無しさん@お腹いっぱい。:皇紀2665/04/01(金) 18:04:21
>>658
> Eutlook Expressくらいなんでしょうか?
ボタンを押せば失効確認をしてくれるMUAもけっこうあるね。

> "有効な証明書"ということなんでしょうか?
CRLにアクセスできなかったときとかにもそのメッセージが出るんだろうね。
「有効です」とは言っちゃいけないわけで。
なんか翻訳がタコっぽいんだけど、英語版だとどうなんだろ。

660 :名無しさん@お腹いっぱい。:皇紀2665/04/01(金) 23:45:21
>>659
>ボタンを押せば失効確認をしてくれるMUAもけっこうあるね
 すいません、たとえばどんな?OutlookExpressはOKでしたがOUTLOOK2003
鶴亀メールはできないです、ベッキーも駄目みたいな話だったんで。
 Thunderbirdあたりはできるんかな?
>「有効です」とは言っちゃいけないわけで。
 これもよく考えてみればそうですね。でももう少し日本語をなんとかならなかったかなー・・。

661 :名無しさん@お腹いっぱい。:皇紀2665/04/02(土) 00:52:41
まあ、失効確認なんてしなくてええんでね?

662 :名無しさん@お腹いっぱい。:2005/04/02(土) 12:32:30
>まあ、失効確認なんてしなくてええんでね?

 署名で改竄無が確認できても、「ある資格保持者にしか証明書を
発行しないことで間接的に証明書の持ち主が資格者だと証明する認証局」
ってありますね。
#ただこういう証明書がS/MIMEに使えてるかは?なんですが。
 ともあれその場合、電子証明書の失効確認には意味が無いこともナイト
思いますけど。

663 :名無しさん@お腹いっぱい。:2005/04/02(土) 17:01:58
何でもかんでもPKIでやろうとするのが間違い。
文書の署名者が現在も当該資格を有しているかの確認は、別の方法で確認したっていい。
失効は鍵が危殆化したり、発行ミスがあったときだけでいいんでね?

664 :名無しさん@お腹いっぱい。:2005/04/02(土) 17:12:31
>>663
 なんでもかんでもPKIでやろうというのではなくいですよ。
>文書の署名者が現在も当該資格を有しているかの確認は、別の方法で確認したっていい。
 例が適切でなかったですね。
>失効は鍵が危殆化したり
 それを確認したいってことですが。
  


665 :名無しさん@お腹いっぱい。:2005/04/02(土) 19:37:41
まあ、危殆化なんて滅多にねーんでね?

毎回失効確認が必要でホントにするってのなら、証明書検証なんて不要になっちゃう罠。

666 :423:2005/04/06(水) 21:59:04
このスレも息が長いねぇ〜。Windows上でCygwinのOpenSSLで電子証明書発行
の解説、サイトに載せたんだ興味ある人は見てねぇ〜。
http://tokyoxjp.hp.infoseek.co.jp/

667 :前スレ300 ◆w795LO9.Wo :2005/04/07(木) 00:04:54
>>666
お久しぶりです&gj!
勉強させていただきます。

668 :名無しさん@お腹いっぱい。:2005/04/07(木) 19:41:01
>>666
敢えて言おう!!                      乙!

669 :名無しさん@お腹いっぱい。:2005/04/17(日) 08:06:54
保守

670 :名無しさん@お腹いっぱい。:2005/04/19(火) 13:30:47
Apache環境で使ってるサーバID+キーペアファイルを
IIS環境へ移行することは可能なのでしょうか?
VeriSignのFAQにある「互換性」という言葉にひっかかる気がするのですが、
なんとか出来ないものかと。。。
助けてくださいっ!

671 :蕪木ら某 ◆Googl8RmwA :2005/04/19(火) 14:19:13
>>670 324069 ?????

672 :名無しさん@お腹いっぱい。:2005/04/20(水) 22:00:21
お詳しい方いらっしゃいましたらSSLクライアント認証について教えて下さい。
新規セッション開始時には、サーバ及びクライアント共に証明書を交換し
その有効性を確認後、共通鍵作成->暗号化通信開始という流れになりますが、
既存セッション再開時は、セッションIDを元にサクっと暗号化通信に入って
るような記事を見かけました。
元ネタこれです。 ttp://www.keyman.or.jp/search/30000073_1.html
実際、既存セッション再開時のハンドシェイク過程で証明書の有効性は
確認していないのでしょうか?
クライアント側証明書がスマートカードやUSBメモリなんかに入ってる
ケースでは抜いたら通信が出来なくなったりするんですがこの現象
の説明がつかなくて困っております。
どなたかご教授お願いしますm(__)m

673 :名無しさん@お腹いっぱい。:2005/04/22(金) 12:44:28
>>672
「既存セッション再開時のハンドシェイク過程ので証明書の有効性の確認の有無」と
「クライアント側証明書がスマートカードやUSBメモリなんかに入ってるケースでは抜いたら通信が出来なくなったりする」
とは問題が別のように思うのですが。

仮に有効性の確認があったとしても
クライアント側が有効性を確認するのは通信相手であるサーバー側の証明書ですよね。
サーバー側はクライアント側の証明書の有効性を確認するでしょうけど
それとクライアント上でクライアント証明書がアクティブか否かは関係ありませんよね。

それよりも有効性の確認以前に
クライアント証明書がアクティブでなければ
暗号電文の復号ができないんじゃないかと思うんですが。

674 :名無しさん@お腹いっぱい。:2005/04/22(金) 14:10:31
すいません。
SSLというのは鍵があれば解読できると書いてありましたが
たとえば誰かにPCの中を見られたらどこかに鍵があって
それでYahoo!のメールのパスワードとかを解読されることが
あるのでしょうか?
あとPCを見られなくてもパケット受信でいろいろ情報が
出てきたのですが絶対安全なものなのでしょうか?

675 :名無しさん@お腹いっぱい。:2005/04/22(金) 14:45:40
>>666
広告うぜーよ
消しちまってくれ

676 :前スレ300 ◆w795LO9.Wo :2005/04/22(金) 15:19:59
>>674
えっと、なんていうかうまく説明できないけど
あなたの疑問の大半は多分SSLとは何の関係もないと思います。

677 :前スレ300 ◆w795LO9.Wo :2005/04/23(土) 14:30:26
バスターがアップデート・バグで祭り状態。
私がこのスレに常駐するきっかけになった2004/1/8ノートン祭りを思い出します。
あの時は「これって社会問題になるんちゃうかな?」と思いましたが
新聞沙汰にすらなりませんでした。

でも今回の件はちょっと騒ぎになってます。

だけど今回の件はベリとは関係なさそうです。

678 :名無しさん@お腹いっぱい。:2005/04/23(土) 19:11:16
yahooのトップに、「JRや新聞各社のLANでトラブル」、
って表示されたから、最初はテロか?サイバー攻撃か?とも思ったが、
やっぱりって感じ。

実名挙げられた企業は迷惑こうむっただろうね〜

679 :名無しさん@お腹いっぱい。:2005/05/09(月) 01:18:24
ちょっと寂しいので気持ち上げとこう。

680 :名無しさん@お腹いっぱい。:2005/05/10(火) 18:39:25
>672

Windowsの場合、OSによる。
98系はセッションIDの再利用(リユース)をサポートしていないので
定期的に(5分?)クライアント証明書の再提出が裏で行われている。

2000系はセッションIDの再利用(リユース)をサポートしているので
サーバのセッション保持期間内(だいたいデフォルト24時間)の間は
クライアント証明の再提出は不要。

もともとIEなんかは再提出時はユーザーが知らない間に
裏で証明書提出を行うが、
外部トークンの場合は鍵が無いのでそうなる。

たぶん。。。

681 :名無しさん@お腹いっぱい。:2005/05/10(火) 18:41:22
http://dhcp255-146.tamatele.ne.jp/

wwwwwwwwwwwwうぇwwwおkwww
wwwwwwwwwwww
wwwっうぇっうぇっwwwwwww
wwwwwwwwwwwwwwwwwwwww

682 :名無しさん@お腹いっぱい。:2005/05/10(火) 18:47:37
>670

Opensslを使って一度p12形式にする。
それをIEへ入れる。
そしたらIISで使用可能になる。

たぶん。。。

683 :名無しさん@お腹いっぱい。:2005/05/24(火) 02:32:06
ほっしゅ

684 :名無しさん@お腹いっぱい。:2005/06/17(金) 09:48:30
ノートン・スレのテンプレに追加されたかね。

12 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2005/06/09(木) 23:35:37
脳豚うpロダはVeriSignの証明書失効リストは下記のどれか、または複数を読んでいる。

VeriSign Class 3 Code Signing 2001 CA (http://crl.verisign.com/Class3CodeSigning2001.crl
VeriSign International Server CA - Class 3 (http://crl.verisign.com/Class3InternationalServer.crl
VeriSign Commercial Software Publishers CA (http://crl.verisign.com/Class3SoftwarePublishers.crl
VeriSign Class 3 Public Primary Certification Authority - G2 (http://crl.verisign.com/pca3.crl
VeriSign Class 3 Public Primary Certification Authority - G2 (http://crl.verisign.com/pca3-g2.crl
VeriSign Time Stamping Services CA (http://crl.verisign.com/tss-ca.crl
VeriSign Class 3 Code Signing 2004 CA (http://CSC3-2004-crl.verisign.com/CSC3-2004.crl

これらはブラウザキャッシュに溜まるので、プロパティから失効リストのURLと有効期限を調べる。
URLをダウソするか、URLリストを作ってフラゲ等で一括ダウソしてから、右クリでインスコする。
verisign.comを遮断しなくても最低これだけやっとけば、勝手に通信に行って遅くなることもない。

もう少し上を行きたいなら、mmc.exeでローカルコンピュータとカレントユーザの証明書管理のスナップインを作成(スナップインの作り方はttp://www.atmarkit.co.jp/fwin2k/operation/mmccons/mmccons_01.htmlなどを見て調べれ)。
カレントユーザ証明書失効リストの中身を、ローカルコンピュータ証明書失効リストの場所にドラッグ&ドロップすれば、全ユーザで有効になる。
詳細表示にしておけば期限もわかるが、短いものだとだいたい一週間単位で更新が入るので、そのときまたダウソしてインスコ。
個別ダウソが面倒ならURLリストで全部ダウソして入れ換えれば済む。

685 :名無しさん@お腹いっぱい。:2005/07/10(日) 08:24:49
保守

686 :名無しさん@お腹いっぱい。:2005/07/10(日) 09:02:01
>>573
最近、アンカー先と同様の状況になることが良くあるんですけど、ページを正常に開く対処方法はYESを押すしかないのでしょうか?
特に、プロバイダのページや、銀行、ショッピングサイトでなります。
OS:XPSP2

687 :名無しさん@お腹いっぱい。:2005/07/11(月) 04:51:33
ほしゅ

688 :名無しさん@お腹いっぱい。:2005/07/11(月) 04:51:53
保守

689 :名無しさん@お腹いっぱい。:2005/07/11(月) 10:42:17
>>686
もう少し詳しいことがわからないとにんともかんとも。
具体的にはどこのサイトですか?
再現テストしてみたいんですけど。

690 :名無しさん@お腹いっぱい。:2005/07/11(月) 11:23:34
>>689
ご指摘ありがとうです。

その後、

インターネット一時ファイルを削除し、
インターネットオプション-詳細設定の「発行元証明書の取り消しを確認する」を一度オフにして
各ページを閲覧後、「発行元証明書の取り消しを確認する」をオンに戻してみたら、今のところ

出なくなりました。(再起動はまだなのでこれから確認します)
もうしばらく様子見て書き込みます。

ブラウザはSleipnirで、セキュリティにはOutpostPRO(2.7)、NOD32(2.50.25),
PeerGuardian2,Microsoft AntiSpyware(Beta1)、Spyblaster、Spybotなど。

該当アドレスは、以下のページなどです。
ttp://enter.nifty.com
ttp://www.rakuten.co.jp
ttp://direct.smbc.co.jp/aib/

691 :名無しさん@お腹いっぱい。:2005/07/21(木) 10:41:14
>>690
その後再現はしてますか?

そもそも挙げられてるアドレスが全部https:じゃなくてhttp:なのが
とても気になってるんですが。

692 :名無しさん@お腹いっぱい。:2005/07/29(金) 20:14:40
>>691
急な引越しで回線接続待ちだったので今まで回答できませんでした。見てますか?

で、接続再開して1時間アプリのVerUpとかであっちこっち飛んできましたが、以前の問題は発生してませんね。
それとhttps:じゃなくてhttp:なのは、https:のページにログインボタンなどで飛ぶ仕掛けのhttp:なページでも発生していたからです。

693 :名無しさん@お腹いっぱい。:2005/07/30(土) 08:56:20
はいはい見てますよ。

元々、ちょっと解せない事象なので
再現してないなら、それはそれでいいんじゃないですか?

なにせ再現しないことには確認のしようはないし。

694 :名無しさん@お腹いっぱい。:2005/08/01(月) 01:34:32
●..●...●●...●●●●...●●.....●.●●.●..●.●●●....●●●...●.●.●●

ウイルス対策ソフトの検出力結果
http://www.geocities.co.jp/SiliconValley-Cupertino/2010/security.html

●●..●..●●.●●....●.●●.●.●●●●●..●.●●●...●..●●.●....●●

695 :名無しさん@お腹いっぱい。:2005/08/01(月) 09:44:30
>>694
このスレ的には
これのどこを読めばいいんでしょうか?

696 :名無しさん@お腹いっぱい。:2005/08/01(月) 10:05:50
>>695
コピペなので無視

697 :名無しさん@お腹いっぱい。:2005/08/10(水) 20:21:23
こう淋しいと、思わずコピペにでもレスしたくなるよなw

698 :名無しさん@お腹いっぱい。:2005/08/24(水) 09:02:41
みんな。公的個人認証は取ってるかい?

699 :名無しさん@お腹いっぱい。:2005/08/24(水) 20:42:45
>>698
ただ?

700 :名無しさん@お腹いっぱい。:2005/08/25(木) 09:42:54
>>699
住基ネットカード持っていれば500円。

東京都の例
http://www.soumu.metro.tokyo.jp/05gyousei/ninshou/ninshou-top.htm

701 :名無しさん@お腹いっぱい。:2005/08/25(木) 12:08:17
それあると何ができるの?
S/MIMEとかに使える?

702 :名無しさん@お腹いっぱい。:2005/08/25(木) 15:26:58
>>701
> S/MIMEとかに使える?

使えません。
詳しくはこちらを。
http://www.jpki.go.jp/services/index.html


703 :名無しさん@お腹いっぱい。:2005/09/01(木) 17:43:29
そうだよなー。
やっぱ使い道ないもんなぁ。

e-Taxに使えますよっ!

704 :名無しさん@お腹いっぱい。:2005/09/06(火) 15:15:33
windowsでapacheを使ってSSLを導入。
ベリサインからcsrを取得し下記のHP
https://www.verisign.co.jp/server/help/install/iapache_renew.html

にしたがって導入をおこないapacheを立ち上げると、
SSLPassPhraseDialog builtin is not supported on Win32 (key file C:/Program Files/Apache Group/Apache2/private/key.pem)
というエラーがでて起動できません。
ファイルの置き場所がちゃんと参照されてないわけでもないし・・・。う〜む;
どなたか このミジンコの私にご教授ください

705 :名無しさん@お腹いっぱい。:2005/09/09(金) 10:42:18
>>704
https://www.verisign.co.jp/server/help/contact/apache.html

706 :名無しさん@お腹いっぱい。:2005/09/20(火) 23:26:52
保守

707 :名無しさん@お腹いっぱい。:2005/09/26(月) 12:36:27
>>703
> そうだよなー。
> やっぱ使い道ないもんなぁ。
> e-Taxに使えますよっ!

e-Tax使う場合だと
公的個人認証が一番安くあがるんじゃないかな。
カードリーダーライターの費用入れても。

企業の場合でも、代取の個人認証でいけるし。

708 :名無しさん@お腹いっぱい。:2005/09/28(水) 14:11:16
自動車の運転免許証を身分証明に使う場合
項目に「氏名の読み」と「性別」がないんだよね。

ということは、男女どっちでも読めそうな字面の人が
免許更新時に仮装すれば、性別詐称が出来ちゃうかもよ。

709 :名無しさん@お腹いっぱい。:2005/09/29(木) 19:18:33
数字にその辺の隠し情報は載ってる

710 :名無しさん@お腹いっぱい。:2005/10/07(金) 16:57:39
セキュリティの警告「セキュリティ証明書は有効期限が切れたか、まだ有効になっていません」 
というのが表示されたんだけど、これほっといたらまずいのかな?


711 :名無しさん@お腹いっぱい。:2005/10/07(金) 17:52:37
>>710
何をやったときに出ましたか?

多分、セキュリティ証明書の有効期限が切れたか、まだ有効にないかのどちらかなんでしょうけど。

712 :名無しさん@お腹いっぱい。:2005/10/07(金) 18:03:02
>>711
有難うございます。amazonマーッケトプレイスで本とか売ってできたお金を銀行に振り込ませる作業を行うときにでました。
>>710のメッセージの上に「このサイトと取り交わす情報は他の人から読み取られたり変更されたりすることはありません。
しかしこのサイトのセキュリティ証明書に問題があります」
と表示されるので、ほうっておいてもいいのかと思ったのですが、有効でない証明書うんぬんが気になります。

713 :名無しさん@お腹いっぱい。:2005/10/07(金) 21:46:47
>>712
そのサイトの証明書に問題があるんでしょうね。

問題なければアドレスを教えてください。

714 :名無しさん@お腹いっぱい。:2005/10/07(金) 22:00:52
>>713
ttp://www.amazon.co.jp/exec/obidos/account-access-login/ref=cs_top_ya_1_1/249-3364888-6737938

↑このページの右上の出品用アカウントというところからログイン(メルアドとパスワードが必要)して
入金(Amazonペイメント)をクリックして出てくる3つの項目のいずれかをクリックすると>>710のメッセージが出てきました。


715 :前スレ300 ◆w795LO9.Wo :2005/10/08(土) 00:12:33
>>714
やってみたけど再現しません。

そのページ(https://ですよね?)が表示されている状態で
ブラウザ右下の鍵のアイコンをダブルクリックして
表示される証明書の「詳細」タブの
「シリアル番号」と
「発行者」の「OU=」の値を教えてもらえますか?

あとできればその時のアドレスも。


716 :名無しさん@お腹いっぱい。:2005/10/08(土) 18:56:55
>>715
すいません。今確認したら直ってました。サイト側が正常にしてくれたようです。
ありがとうございました。

717 :名無しさん@お腹いっぱい。:2005/10/08(土) 20:13:25
>>716
よかったですね。
はぁ…。

718 :名無しさん@お腹いっぱい。:2005/10/18(火) 15:49:42
NECについてるXPなんですがリカバリした直後、
ゾーンアラームがWindowsExplorerのcrl.verisign.comへの接続を求めていました。
怪しかったので拒否してしまったのですが、verisignのHPを調べてみたら
なんかセキュリティの関係みたいなんです。
一度拒否した後接続を求められないので、再接続することができなくてとても心配です。
セキュリティの何かの更新をWindowsExplorerはverisignに求めていたのでしょうか?
このまま放置しても大丈夫ですか?

719 :名無しさん@お腹いっぱい。:2005/10/19(水) 17:54:11
>>718
何かの証明書の取り消し確認に行ってたんだと思います。
ゾーンアラームのcrl.verisign.comの設定を解除してはいかがですか?
ゾーンアラームの詳しい使い方は私にはわかりませんがスレがあるようです。

ZoneAlarm Part30
http://pc8.2ch.net/test/read.cgi/sec/1128154132/

720 :718:2005/10/19(水) 18:16:28
>>719
ありがとうございます。

>何かの証明書の取り消し確認に行ってたんだと思います。
接続を拒否してしまったので行けなかったはずです。
それなのにその後、再接続が求められません。
このまま放置しておいても大丈夫なのでしょうか?

>ゾーンアラームのcrl.verisign.comの設定を解除してはいかがですか?
一度接続を求められたとき、拒否はしたものの、拒否設定にはしていないので
その後WindowsExplorerが接続をすればまた接続を求めるメッセージが出るんです。
しかしそれが出ないということは、接続を求めていないということです。

721 :名無しさん@お腹いっぱい。:2005/10/20(木) 09:11:26
>>720
わかんない。
でも、証明書の取り消し確認に引っかかって
無効証明書だからどーたらこーたら…
などという事態には、一度もなったことは無いな。
少なくとも私は。

722 :名無しさん@お腹いっぱい。:2005/10/21(金) 20:45:31
IEの信頼済みゾーンに*.0.0.0.0を誤って記入してしまったが、削除しようとしても削除できない。
レジストリで一括削除とかでもいいので何らかの削除方法ないですか?

723 :718:2005/10/23(日) 17:33:20
>>721
そうですか。しばらく様子みてみます。
ありがとうございました。

724 :名無しさん@お腹いっぱい。:2005/10/27(木) 08:54:06
すげーな外務省の電子入札・開札システム。
MSVMベースだもんだから、自前でMSVM再配布してるよ。

http://www.e-procurement.mofa.go.jp/introduction/msvm_download1.html

ちなみに普通の電子申請の方はSUN Java指定。
でも指定バージョンはJRE1.3.1_10。
とほほ。

725 :名無しさん@お腹いっぱい。:2005/10/27(木) 15:22:30
前者の方が100倍ましかと
今ではJRE1.3なんてまともに配布してないし、
入れたら即トラブルだ。

726 :名無しさん@お腹いっぱい。:2005/10/27(木) 20:43:46
これがね。省庁毎に要求してくるJREのバージョンが見事にばらばら。
特定環境に依存せんようにjavaなんかと思えば
windowsオンリーばっか。

全くなにやってんだか。電子政府って。

727 :名無しさん@お腹いっぱい。:2005/10/28(金) 02:44:09
>>724
2007年までに改修できるのか?

728 :名無しさん@お腹いっぱい。:2005/10/28(金) 15:46:18
>>727
2007年って何があるの?

729 :名無しさん@お腹いっぱい。:2005/10/28(金) 20:59:01
団塊の世代で一番数が多いのが、戦後間近の昭和22年(1947年)生まれですので、その方々が60歳で定年を迎えた場合には、2007年となるためです。

730 :名無しさん@お腹いっぱい。:2005/10/30(日) 20:51:25
  ∧_∧
 ( ´∀`)  / ̄ ̄ ̄ ̄ ̄
 (    ) < ねェねェ、VeriSignって偉いの?
 | | |  \_____
 (__)___)


731 :名無しさん@お腹いっぱい。:2005/10/30(日) 20:57:30
偉そう

732 :名無しさん@お腹いっぱい。:2005/10/31(月) 03:34:48
>>726
そうそう。
担当者に直接言ったことあるが…
「そうですねぇ。」
だってさ。
彼らも上から言われてノルマこなしてるだけだから、どーしよーもねーな。

733 :名無しさん@お腹いっぱい。:2005/10/31(月) 03:36:32
各省庁、自治体間で統一するよう意見書出したいが、
パブリックコメント募集しないかな。

734 :名無しさん@お腹いっぱい。:2005/10/31(月) 03:48:10
強力な独裁者でも出ない限り無理
ある意味それが健全な社会の証なのかもw

735 :前スレ300 ◆w795LO9.Wo :2005/10/31(月) 06:06:55
とりあえず小泉くんにメールしてみてはどうだろう。

736 :名無しさん@お腹いっぱい。:2005/10/31(月) 06:15:51
S-JISテキストとCSVだけで沢山だ!

737 :名無しさん@お腹いっぱい。:2005/10/31(月) 08:52:04
おお。いいねぇテキストデータ主義。
基本的には賛成だけどXMLも便利よん。

738 :名無しさん@お腹いっぱい。:2005/10/31(月) 15:38:18
>>735
とりあえず「首相官邸」で意見を提出しておいた。

これでもしなんか動きがあったりしたらビックリしちゃうよな。

739 :名無しさん@お腹いっぱい。:2005/10/31(月) 15:45:57
どっかの軍事大国にでも占領してもらおう
改革がサクサク進むぞ

740 :名無しさん@お腹いっぱい。:2005/10/31(月) 16:05:25
>>739
日本語廃止になったら、日本語処理いらないから文字コードに悩まなくていいしね。

741 :名無しさん@お腹いっぱい。:2005/10/31(月) 18:30:12
そのかわり脳内変換処理に時間がかかるように・・・

742 :名無しさん@お腹いっぱい。:2005/10/31(月) 18:38:26
英語が国語になったら1科目減る?

743 :名無しさん@お腹いっぱい。:2005/10/31(月) 19:54:25
卑賤領民の運命なんて占領国次第ですよ。

744 :名無しさん@お腹いっぱい。:2005/11/01(火) 04:05:33
>>728
Microsoft VMのサポート終了

745 :名無しさん@お腹いっぱい。:2005/11/02(水) 09:29:54
>>738
>とりあえず「首相官邸」で意見を提出しておいた。

おおお。返事来たよ!


----- Original Message -----
From: "首相官邸HP発信専用" <hentou@kantei.go.jp>
To: <***@********>
Sent: Wednesday, November 02, 2005 9:06 AM
Subject: [首相官邸より]

>  ご意見等をお送りいただきましてありがとうございました。
>  いただきました国政へのご意見・ご要望は、今後の政策立案や執務上の参考とさせていただくとともに、内閣官房、内閣府、総務省、経済産業省へも送付させていただきます。
>
>   首相官邸ホームページ「ご意見募集」コーナー担当


テンプレだ_| ̄|○

746 :名無しさん@お腹いっぱい。:2005/11/02(水) 16:57:52
  ∧_∧
 ( ´∀`)  / ̄ ̄ ̄ ̄ ̄
 (    ) < >>745 だね。
 | | |  \_____
 (__)___)

747 :名無しさん@お腹いっぱい。:2005/11/24(木) 09:05:33
捕手

城島

748 :名無しさん@お腹いっぱい。:2005/11/28(月) 18:49:33
http://www.cyberpolice.go.jp/column/explanation13.html

@police−セキュリティ解説 - 電子署名

難しいw

749 :名無しさん@お腹いっぱい。:2005/12/07(水) 10:55:41
ネタないなぁ。

750 :名無しさん@お腹いっぱい。:2005/12/09(金) 20:07:03
一ヶ月お試し証明書ってまだやってるの?


751 :名無しさん@お腹いっぱい。:2005/12/09(金) 20:19:32
>>750
http://www.verisign.co.jp/welcome/try_verisign.html

60日みたいね。



752 :名無しさん@お腹いっぱい。:2005/12/09(金) 20:45:08
やっぱ、取るとかっこいい代物かなぁ? 証明書って。

753 :名無しさん@お腹いっぱい。:2005/12/10(土) 11:22:14
>>752
そういうもんじゃないと思う。

754 :名無しさん@お腹いっぱい。:2005/12/11(日) 10:10:51
>>753

かっこよくなかったら、個人じゃ誰も使わんよ。個人に使ってほしくねーのかね。


755 :名無しさん@お腹いっぱい。:2005/12/11(日) 11:57:10
今のところ個人はそんなに眼中にないんじゃないかな。
やっぱ企業だよ企業。

756 :名無しさん@お腹いっぱい。:2005/12/11(日) 21:40:40
そっか、個人は関係ないのね。
しかし、企業だとPKIとかやろうとしたら、マジ大変だと思うんだが。

757 :名無しさん@お腹いっぱい。:2005/12/11(日) 22:12:18
>>756
自前でCAやると大変だからこそ、ベリサインとかの出番なんだが

758 :名無しさん@お腹いっぱい。:2005/12/12(月) 00:20:33
>>757

客からCA作れと言われてる私は死んだも同然です。

759 :名無しさん@お腹いっぱい。:2005/12/13(火) 10:51:55
>>758
CertWorker買っておしまい、っつーわけにはいかんの?
立ち上げや運営まで期待されてんの?
それなら難儀な話しだが。


760 :名無しさん@お腹いっぱい。:2005/12/13(火) 12:42:23
3日くらいでSSLの概要を理解できない客みると、大卒資格剥奪した方がいいと思ってしまう。


761 :名無しさん@お腹いっぱい。:2005/12/13(火) 20:46:40
確かに機関車は難しいよ。

762 :名無しさん@お腹いっぱい。:2005/12/13(火) 22:10:57
>>759

すべて、作るんだと。これからどれだけRFCを読まねばならないか…。
しかし、客は春には試験運用だと、君一人でやるんだと、本気です。
X.509証明書はキッチリ公的なヤツから持ってこいなどと、まるで遠くで聞こえる春雷のようです。

大企業は、創造性が無いくせに、多くの規格に簡単に対応できれば技術力があると。
そのぐらいうちの会社じゃ当たり前だよーん、ていうのが凄いと、勘違いしとるのです。


763 :名無しさん@お腹いっぱい。:2005/12/14(水) 12:20:44
>762
とりあえず、上司に保険の話してみれば?
会社の法務部に蹴飛ばされるか、提携しようとした保険会社に
ふっかけられて、現実を知るだろう。

764 :名無しさん@お腹いっぱい。:2005/12/14(水) 22:00:31
暗号の専門家を沢山抱えている某電話会社ですら、未だに
ルートCAやらない理由はリスクをきちんと把握できないから。
リスクを把握できないと保険料率も決まらんからね。

社内システム向けに独自CAを使っている会社はいくらでも
あるけどな。


765 :名無しさん@お腹いっぱい。:2005/12/14(水) 23:51:52
みなさん、ありがとう、ありがとう、ありがとう。

私はこっちのスレに移動します。
http://pc8.2ch.net/test/read.cgi/prog/1112823999/

さようなら。

766 :名無しさん@お腹いっぱい。:2005/12/15(木) 00:02:04
↓これのメールソフトとして Outlook 2003 がないのはなぜだろう。
ttp://www.nifty.com/mail/digi-id/index.htm

767 :名無しさん@お腹いっぱい。:2005/12/15(木) 00:07:32
>765
イ`。馬鹿上司のために吊るなんて馬鹿馬鹿しいぞ。
漏れも馬鹿上司のせいでメンヘラになってしまったが、なんとか
生きている。


768 :名無しさん@お腹いっぱい。:2005/12/15(木) 04:12:15
>>766
新しいソフトに軒並み対応してない 確認できない
ニフティー自体が開発してないのでどうしようもない

769 :蕪木ら某 ◆Googl8RmwA :2005/12/15(木) 05:49:46
>>758-765>>767
+ http://takagi-hiromitsu.jp/diary/20050205.html#p01
 ......

770 :名無しさん@お腹いっぱい。:2005/12/26(月) 20:29:41
保守。

e−tax使うなら、台鳥の個人の認証使うほうが安上がりだよ。
カードリーダーライターは要るけど。

771 :名無しさん@お腹いっぱい。:2006/01/02(月) 11:31:14
おめあげ。

ベリサイン自体のネタは最近あんまりないね〜。
電子認証全般のネタやってる板やスレはどっかあるのかしらん。

ことしもよろしく。

772 :名無しさん@お腹いっぱい。:2006/01/20(金) 10:31:18
なんて寂しいんだ。
自動車登録のワンストップサービスも始まっているというのに。
ベリには関係ないけどね。

773 :名無しさん@お腹いっぱい。:2006/01/22(日) 13:35:22
一般顧客向けのメールに証明書つけようと思うんだけど、BtoCでそんなことやってるの聞いたことないので
ちょっち二の足踏んでる。
どうかな?


774 :名無しさん@お腹いっぱい。:2006/01/22(日) 15:14:33
>>773
決して悪いことだとは思いませんが
変なメールが着た、と不安になる人も居るかもしれません。

大事な書類はPDFにして電子署名入れとくといいかも。
でもちゃんと電子署名入ったPDFってのもなかなか見かけないんだよなぁ。

官報ぐらいか。

775 :蕪木ら某 ◆Googl8RmwA :2006/01/23(月) 01:56:04
>>773-774
http://www.atmarkit.co.jp/fsecurity/rensai/trend03/trend03.html
etc.

776 :名無しさん@お腹いっぱい。:2006/01/23(月) 08:55:22
>>775
そうなんだよね。
「勲章マーク付いてたら署名つきメールなので安心ですよ」なんつーといて
ご丁寧に偽の電子証明書まで作って署名された日にゃ
電子認証のことをちゃんとわかってないとコロっとだまされちゃう危険性が。

OEの電子署名機能って、あまりに知られなさすぎだからねぇ。

777 :773:2006/01/23(月) 12:55:54
まあ、周知はしっかりやるつもりではいるんだが、
偽署名か。うーむ。

778 :名無しさん@お腹いっぱい。:2006/01/23(月) 13:16:27
>>777
お客さん側にちゃんとした知識があって正しい運用が出来ないと
「赤い勲章マークの電子メールは署名入りで安心です」とか程度だと
むしろわざわざ騙されやすくしてしまうんじゃないか、っつーことね。

電子証明書の確認までやってもルート証明書から偽造されたら。
ルート証明書のフィンガープリントとかをちゃんと確認までしないと。

その証明書情報までフィッシングされてたら?

気にしていたらキリがないが、利用者側の知識があやふやだと
せっかくのセキュリティもなんら機能しませんからね。

779 :773:2006/01/24(火) 19:04:48
つうことは、なんでもかんでも署名つけるのはNGだな。
署名つけたほうがいい場面を想定したほうがいいな。

780 :名無しさん@お腹いっぱい。:2006/01/24(火) 19:33:32
企業のPDF版プレスリリースやお知らせ、お詫びの類も電子署名入ってるもんなんか、ほとんと見たこと無い。
それに手を入れて改変して、ご丁寧に偽証明書で電子署名なんか付けちゃえば
いかにももっともらしい怪文書、一丁あがり!だね。


781 :773:2006/01/24(火) 19:39:22
なんだよw 意味ねえのかなあ。ベリサインの啓蒙活動とかねえのかな。

782 :名無しさん@お腹いっぱい。:2006/01/24(火) 19:54:37
>781
特定の相手に渡す文書なら、pdfの署名も意味があるだろう。
#糞高い紺猿レポートとかね。

啓蒙活動は難しい。そもそも一般人がVerisignの名前を知る
はずもない訳で、そんな知らない会社が保証すると言われて
も、なんのこっちゃ?だろ。

それにルート証明書の信用度を測る方法なんてあるのか?
結局会社の知名度や対応ブラウザ数ぐらいでしか測れないだろ。


783 :名無しさん@お腹いっぱい。:2006/01/24(火) 20:11:10
>>778
> 電子証明書の確認までやってもルート証明書から偽造されたら。
> ルート証明書のフィンガープリントとかをちゃんと確認までしないと。
>
> その証明書情報までフィッシングされてたら?

利用者がそういうこと気にしなくていいのがPKIでは?。。。

ウェブブラウザでのhttpsの使い方に関しては、利用者に
セキュリティの知識は無くても、
・鍵マークがついていること
・ウェブブラウザの表示しているURLが正しいこと
・証明書に関して警告が表示されていないこと
を確認すればOKという教え方が出来るよね。

同様にメールでも
・(勲章などの)マークがついていること
・送信元メールアドレスが正しいこと
・証明書に関して警告が表示されていないこと
を確認すればいい、というのが原則じゃないかな。

この場合問題点は
・メーラによってマークが違う
・署名に対応していないメーラだと怪しげな添付ファイルがついてしまう
・実装も運用も枯れてないので最新のセキュリティ動向に注意が必要かも
この3点だと思う。
冒頭で引用したような懸念はhttpsで気にしないのと同様に
気にしないでいい。

784 :773:2006/01/24(火) 20:31:34
>>783
なんだか前向きな意見があってうれしいですな。

>httpsで気にしないのと同様に気にしないでいい。

周知はしっかりやった上で、それくらいの感じ(https)で始めてみるかな。




785 :名無しさん@お腹いっぱい。:2006/01/24(火) 22:12:32
>>783
Windowsにデフォルトで入っているルート証明書にぶら下がる証明書しか使わないのならそれでいいかもしれない。
それ以外の証明書だとルート証明書に対する警告は避けられないでしょ?

だからまあ黙ってベリとかの証明書使えよ。企業なら高くても。ってことかね。

やっとスレの趣旨に沿った話にw


786 :名無しさん@お腹いっぱい。:2006/01/24(火) 22:32:23
cacert.orgあたりがIEにデフォルトで入らんもんかね

787 :名無しさん@お腹いっぱい。:2006/01/24(火) 22:41:08
その前に、LGPKIとかGPKIってどういう扱いなんだっけ?>ルート証明書

788 :名無しさん@お腹いっぱい。:2006/01/25(水) 00:14:59
送信元メールアドレスが正しいことww

789 :名無しさん@お腹いっぱい。:2006/01/25(水) 00:33:54
kwsk

790 :名無しさん@お腹いっぱい。:2006/01/25(水) 00:59:06
ところで「ハードディスクからサルベージした削除済メール」に証拠能力あるんかね。
送信元メールアドレスなんかはどうとでもなるしさ。

791 :名無しさん@お腹いっぱい。:2006/01/25(水) 01:01:27
>>787
少なくともWindowsは標準では持っていない。
きみんとこは入ってる?

例:総務省の場合
http://www.soumu.go.jp/menu_06/shinsei/ninshoukyoku_detail.html

792 :名無しさん@お腹いっぱい。:2006/01/25(水) 01:28:58
>>791
無い、と思う。(Mac OS X 10.3)
いくらがんばってGPKIやLGPKIっつってもWindowsに
デフォルトで入ってないんじゃなあ、と思うべ?
役所でCD-ROM配るような特殊な運用でなければ
一般ユーザー向けには今後もベリでも使っとけってこと
なのかなと思う。
フィンガープリントを確認とか、普通やらせたくないよなあ。

793 :名無しさん@お腹いっぱい。:2006/01/25(水) 01:39:04
>>792
ふつー入ってないとおもう。
フィンガープリントを確認とか、確かに面倒なんだけど、
GPKIとか公的なもんではあたりまえ。
JPKIなんか都道府県ごとにルート証明書違うしさ。
おまけに一般人は他人の証明書の有効性確認が出来ない。
参考:
http://www.jpki.go.jp/preflink/index.html
http://www.soumu.metro.tokyo.jp/05gyousei/ninshou/finger.htm

じゃあWindowsとかに標準で入れてあるルート証明書は無条件に信用しちゃっていいのか?と。
PKI利用するからには、証明書ツリーの素性は自分でちゃんと確認せんとしょうがない。

でもルート証明書の情報がhttpsじゃないところはざらなんだよな。
本当に悪意をもってフィッシングされたらかえってコロっと騙されちゃうんじゃないかな。
「鍵マーク付いてる」とか「赤い勲章付いてる」とか。

794 :773:2006/01/25(水) 14:31:38
「鍵マーク付いてたのにフィッシングサイトだった」って感じか。。

795 :790-792:2006/01/25(水) 14:38:28
773さんの相方をつとめさせていただいておりますのは
わたくし790-792でございます。

796 :名無しさん@お腹いっぱい。:2006/01/26(木) 02:35:46
サーバ証明書の検証について教えてください。

アクセス先の証明書の認証では、ルートが信頼できていれば問題無いと
認識しています。
中間証明書は、アクセス元のPCに未インストールだったとしても問題ない
はずです。アクセス元にインストールされてるのが有効期限切れだったと
しても、アクセス先に有効な証明書がインストールされていれば証明書
チェーンは確立するはずです。

ところが、なぜかアクセス元にインストールされている有効期間切れの
中間証明書が認識されてしまい、証明書チェーンが確立しません。

アクセス元はwindowsなのですが、この現象はOSの設定によるのでしょうか?

797 :名無しさん@お腹いっぱい。:2006/01/26(木) 09:18:01
>>796
ローカルのルート証明書が期限切れのとき、わざわざ自動的に探しに行ってくれたりしないですよね。
中間証明書も同じで、ローカルに持っているものが期限切れだと、その時点でエラーということでは?

専門業者のサーバー証明書をお使いなら、そちらのサポートに問い合わせてみてはいかがでしょうか。

http://www.verisign.co.jp/server/help/faq/110089/index.html
↑ちなみに、これの手順の中では、ローカルの中間証明書をバックアップ後削除させているが
終了後に復元しておく旨の指示が特に無い。



798 :名無しさん@お腹いっぱい。:2006/01/26(木) 10:39:18
>>797
※SSL/TLSと仮定して。

http://www.ipa.go.jp/security/rfc/RFC2246-AFJA.html#f11
> もしサーバーが認証されるときは、その証明書メッセージは、
> 信用のおける認証局へ通じる、有効な認証局チェーンを提供して
> いなければならない。

間違ってたらごめんだけど、サーバから送ってくれると思うよ。
>>796の原因とかはわからない。。

799 :名無しさん@お腹いっぱい。:2006/01/26(木) 15:13:42
>>798
提供されてるけど、Windowsが取りに行かない、っつーことなんじゃない?

800 :名無しさん@お腹いっぱい。:2006/01/26(木) 21:02:25
800

801 :名無しさん@お腹いっぱい。:2006/01/27(金) 22:29:57
>>796 は再現条件晒さないと何も出てこなそうだよ。
質問としては抽象的だから一般論しか返ってこない。
晒しても回答は無しの可能性は高いけど。

802 :名無しさん@お腹いっぱい。:2006/01/28(土) 13:07:21
>>796
http://www.verisign.co.jp/server/cus/rootcert/2028pca3.html

↑はそのものズバリの情報ではないけれど、これをよく読むと
「ローカルに保持している中間証明書が期限切れになっても
Windows/IEは自分で新しい証明書を探しには行かない」と読めると思うんだが。

中間証明書をローカルにキャッシュしている場合は
期限切れの際には自分で更新しろ、っつーことじゃないかな。

まーMSが勝手にキャッシュしてくれてるわけで
自分でそういう運用をしてるわけではないとは思うんだが。

ローカルの中間証明書を削除しておけば万事うまくいくんじゃないかな。

803 :名無しさん@お腹いっぱい。:2006/01/29(日) 06:11:37
>>796ではないけれど。
>>802
うーん。
サーバが提示した証明書チェーンを無視?
> 中間証明書をローカルにキャッシュしている場合は
> 期限切れの際には自分で更新しろ
少なくともデフォルト設定ではそんな糞実装ありえへんと
思うんだけど。

> Windows/IEは自分で新しい証明書を探しには行かない
余談ですが、こんな感じらしいです。
http://support.microsoft.com/default.aspx?scid=kb;ja;834438#XSLTH3148121120120121120120
> Microsoft Windows XP および Microsoft Windows Server 2003
> のユーザーの場合、この更新は、チェーン検査エンジンに対して、
> 自身が信頼していない証明書が提示されたときに行われます。この
> 更新が行われると、証明書がルート証明書プログラムに追加されているか
> どうかを確認するために、Windows Update への問い合わせが行われます。

804 :803:2006/01/29(日) 06:15:04
>>803
補足。
後半はルート証明書の更新の話。中間証明書じゃない。

805 :802:2006/01/29(日) 09:13:39
>>803
> >>796ではないけれど。
> >>802
> うーん。
> サーバが提示した証明書チェーンを無視?
> > 中間証明書をローカルにキャッシュしている場合は
> > 期限切れの際には自分で更新しろ
> 少なくともデフォルト設定ではそんな糞実装ありえへんと
> 思うんだけど。

「キャッシュ」という書き方は適切じゃなかったです。
問題の証明書がインストールされていない場合に
Windows/IEが内部的にキャッシュするものについては、きちんと更新されると思います。
インストール=証明書ストア上に置く、です。


中間証明書をローカルにインストールしている場合は
期限切れの際には自分で更新しろ

まーMSが勝手にインストールしてくれてるわけで
自分でそういう運用をしてるわけではないとは思うんだが。


806 :名無しさん@お腹いっぱい。:2006/01/29(日) 10:10:54
少なくともルート証明書に直接ぶら下がってる鯖証明書に関しては見に行かない
確認できないって言われる

807 :802:2006/01/29(日) 10:55:23
http://www.microsoft.com/technet/security/topics/cryptographyetc/tshtcrl.mspx
Troubleshooting Certificate Status and Revocation

↑これをちゃんと読めばいいんだろうけど、英語なのでちょっと尻込み中。
↓とりあえずこれを読んで見ているところ。

http://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx
Windows Server 2003 を使用した相互証明および限定従属の計画と実装

808 :802:2006/01/30(月) 18:19:26
すんません。激しく思い違いをしていたようです。

http://www.microsoft.com/technet/prodtechnol/exchange/JA/guides/E2k3MsgSecGuide/6b38974a-fe02-413b-a9d1-9c71cccdd297.mspx
送信者の中間 CA のデジタル証明書が機関情報アクセスを提供せず、受信者の Exchange サーバーの [ローカル コンピュータ] 証明書ストアに存在しない場合、送信者のデジタル署名を確認できない

すなわち、証明書に機関情報アクセス(AIA)が適切に設定されていない場合は
証明書ストアに必要な証明書を置いておかないと、証明書チェーンが確立できない

という話のようです。


809 :796:2006/02/01(水) 23:32:08
796です。
 質問が曖昧ですみませんでした。
 具体的には以下のケースです。
 
■アクセス先が以下のようなツリー構造になっている。
 ・A(ルート)>B(中間)>C(サーバ証明書)
■アクセス元は上記AのみPCにインストールされている。

このケースでは正常にアクセスできるはずです。
https://www.verisign.co.jp/」が同じ形式ですが、中間証明書が有効期間切れでもアクセス可能です。
(初期状態のXPでは同証明書の有効期限の古い版しかインストールされてません。)
また、アクセス元よりすべての中間証明書を削除しても、アクセス可能です。

問題なのが、なぜかアクセスできないPCがあるのです。みんなはアクセスできるのにその人のPCからだけは
なぜか証明書の検証で有効期限切れでひっかかるのです。

たぶんXPの設定かなにかだとはおもうのですが、原因不明で困ってます。




810 :名無しさん@お腹いっぱい。:2006/02/02(木) 00:25:27
>>809
さっぱりわからん。
同じマシンの別のアカウントでも起きるの?

811 :名無しさん@お腹いっぱい。:2006/02/02(木) 00:27:08
>>809
中間証明書を削除するとうまくいくけど
インストールしたままだとダメってことなの?

812 :名無しさん@お腹いっぱい。:2006/02/07(火) 15:16:33
今日「Dear CitiBank Client,」から始まる英文のメールが来た。
セキュリティ強化のため、以下のリンクからアカウント情報を更新せよ、とか言ってる。

https://citibusinessonline.da-us.citibank.com/cbusol/signon.do

そーっとリンクにマウスカーソルを乗せてみる。
ステータスバーに表示される実際のリンク先は…

http://citibusinessonline.da-us.citibonka.com/cbusol/signon.do

シティボンカだよシティボンカ(げらげら
httpsじゃないしさ。
でも試しにhttpsにしてみたら、おお。ちゃんとインチキ証明書でSSLでつながるよ。
でもセキュリティの警告が出るから、きっと一生懸命ニセ証明書まで準備したけど「こりゃダメだ!」っつーことでリンクに使うのやめたんだろうね。

http://www.citibonka.com

を直叩きすると、ちゃんと本家にジャンプするし。
これはフィッシングの知識とかないお年寄りなんかは騙されちゃうかもね。

あーしかしこれだけ絵に描いたようなフィッシングメールは初めて貰ったよ。なんか感激だ。


ちなみに偽サイトにはごていねいに「VeriSign Scured」のロゴが付いてました。


813 :名無しさん@お腹いっぱい。:2006/02/09(木) 22:15:26
ttp://www.verificationengine.jp/
逆にぁゃιぃ、つーかあんた自身SSL通信要求しれと思った

814 :名無しさん@お腹いっぱい。:2006/02/09(木) 23:34:51
>>813
ぎゃははは。httpsで繋いだら警告出てやんの。
どーこの証明書使ってるんだよw

815 :名無しさん@お腹いっぱい。:2006/02/11(土) 02:11:09
くれくれ君で大変申し訳ないのですが、EasyCertの旧バージョンをお持ちの方いましたら
メールで送ってはいただけないでしょうか。

最新版の091b2や090b01、089b2までは見つかるのですがそれ以前のものが見つかりません。

WaybackMachineもとことん当たりましたがダメでした。

816 :名無しさん@お腹いっぱい。:2006/02/11(土) 02:27:13
オレもほしひw

817 :815:2006/02/11(土) 02:50:55
とあるスレで、セキュリティ関係のHPを作ってて、2chCAとまでは行かないけど、
希望者に証明書を発行出来るようにできればいいなと。

OpenSSLも使えるのだけど、管理が大変で。。。。。。。

818 :前スレ300 ◆w795LO9.Wo :2006/02/11(土) 08:28:09
>>817
なんか面白そうなので、よかったらもう少し詳しく教えていただけませんか?

819 :47 ◆wI09.nTZZ. :2006/02/11(土) 09:45:07
>>818
単純な自己署名の証明書を配布するだけですよ。
ルート証明書は当然オレオレ状態ですが、自分のドメインは持っているので、
そこを配布点にして、希望者に発行しようかと(無料)
ルート証明書をRSA2048bitで作ったので、古くないと使えないw
Webフォームに入力してもらう形をとれば、比較的簡単に大量発行も可能
ですし。(Webプログラミングの能力はないです)

まぁそんなことをぼんやりと考えてたわけです。
証明書の発行は、生々しいプロバイダーのメールに限定しますが。

まだ妄想状態ですので。。。。。。。w

820 :前スレ300 ◆w795LO9.Wo :2006/02/11(土) 11:36:23
>>819
なるほど。メールとか用の証明書ですか?
AiCAじゃダメ?

821 :44 ◆wI09.nTZZ. :2006/02/11(土) 12:03:04
AiCAでも良いんですけどね。

出来るだけ楽をしたいと横着しただけで。
見つからなければ、そのままOpenSSL使います。大量発行用のスクリプト書けば済む話でしょうし。

証明書は汎用かな。BasicConstraints=CA:FALSE にはするけど、後のポリシーはどうしましょう。

と考えはあるけど、まだ妄想段階を出てませんので。。。。。。

822 :前スレ300 ◆w795LO9.Wo :2006/02/11(土) 12:57:40
>>821
出来るだけ楽をしたいなら、GUIよりむしろCUIでは?

823 :44 ◆wI09.nTZZ. :2006/02/11(土) 23:35:53
自動処理の仕組みを作れば、CUIだろうがGUIだろうが一緒。

そこまでの道程がGUI>CUIな感じなだけで。
すっかりGUIに慣れちゃったからなー。

824 :前スレ300 ◆w795LO9.Wo :2006/02/11(土) 23:41:24
>>823
そうですか。
旧バージョン、見つかるといいですね。
ごめんなさい。ワタシは持ってません。

825 :名無しさん@お腹いっぱい。:2006/02/12(日) 16:58:57
comodo や thawte のメール用の無料証明書って、
一年後に revoke して同じメールアドレスで再取得できるの?
誰か知ってる人、教えてください。


826 :前スレ300 ◆w795LO9.Wo :2006/02/12(日) 18:04:19
>>825
thawte は取れますよ。
もう5年くらい使ってます。


827 :名無しさん@お腹いっぱい。:2006/02/12(日) 18:49:03
ありがとうございます。
取得の簡単な comodo はどうかな?

828 :前スレ300 ◆w795LO9.Wo :2006/02/12(日) 19:34:16
>>827
thawteも全部英語ですが、慣れれば簡単ですよ。

829 :44 ◆wI09.nTZZ. :2006/02/13(月) 01:56:46
無料証明機関というのはまんどいな。
金の臭いはするんだけど。。。。。。w

それよか、こんな感じのソリューションを普及させた方が金になるな。
http://www.softether.com/jp/vpn/manual/web/4-6.aspx#

アイディアはあるが、売り込み先も金にする方法もわかんね。しかもスキルはもっとたらん!w

830 :名無しさん@お腹いっぱい。:2006/02/13(月) 12:48:18
公的個人認証が使えるっつーのは面白いな。

831 :44 ◆wI09.nTZZ. :2006/02/13(月) 22:19:22
ですね〜

個人ベースの信用機関はなんとかなりそうになってきたけど、もうすこしがんがらないと。
完全無料のサービスってのは、完全に趣味だから、KIAIがないとつらいですな。

832 :前スレ300 ◆w795LO9.Wo :2006/02/13(月) 22:46:34
>>831
個人ベースの信用機関ってのがよくわからんのですが。
自己証明書を作ってあげるサービスってことですか?


833 :44 ◆wI09.nTZZ. :2006/02/13(月) 23:40:43
>>832
S/MIMEとSSL証明書だね。こっちが発行機関の証明書だからオレオレでなくてオレ(個人)が署名。
CAには出来ない様にするけど、暗号化とそのメールアドレスが存在するかしないかの証明くらいにしかならん。
発行が手間&お手軽にS/MIME使いたい人向けかも。

2ch証明機関と同じでない? 信頼性はフィンガープリント見ろと。

あと、出来ればsage


834 :前スレ300 ◆w795LO9.Wo :2006/02/14(火) 00:06:54
>>833
それなら別にthawteでいいような気がするけど。
英語は面倒だけどルート証明書が信頼されてるし。

2ch証明機関てのは初耳なんですけど、どこ見たらわかりますか?

sageは失礼。チェック外れてた。

835 :44 ◆wI09.nTZZ. :2006/02/14(火) 00:07:50
>>834
昔作らない?って話が何度も出てるよ。
それと、簡単でないと普及しないからねー。その辺も問題だわ。

836 :名無しさん@お腹いっぱい。:2006/02/14(火) 01:37:25
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060210/229014/
タイムリーな話題ということで

837 : :2006/02/14(火) 07:56:35
ワラタ もともと信用してないけどなw

838 :名無しさん@お腹いっぱい。:2006/02/14(火) 15:20:39
詐欺師の身元を保証するって事は、CA が詐欺に加担していると言えるな。
いや、詐欺師からカネもらってるから、CA も詐欺師そのものだな。
こういうのは証明パスをどっかに晒して欲しいよ。まじで。

839 :名無しさん@お腹いっぱい。:2006/02/14(火) 16:33:56
>>838
ベリの場合だと、法人に対する証明書については、
申請者が法人かどうかを確認するだけで
その法人が詐欺だろうが泥棒だろうが関知はしない。

詐欺師や泥棒でも運転免許が取れるのと同じ。

840 :名無しさん@お腹いっぱい。:2006/02/14(火) 16:55:33
一般人はそうは思わんだろうな。
そこが問題。

841 :名無しさん@お腹いっぱい。:2006/02/14(火) 20:40:59
>>836
うっかり写真のとこクリックして星澤が画面一杯に表示されて
キモイよー・゚・(つД`)・゚・

>>839
法人登記を確認するというのは、メールだけで取れるのに
くらべれば結構なハードルだと思うよ。
少なくとも使い捨てはできないんでフィッシングサイト
立ち上げるのには使いづらい。

このレベル以上の社会的信用を求めるとすると、それは
CAの仕事か?という問題が。もちろんそういうのが
あってもいいけど。論点ずれとる。

842 :名無しさん@お腹いっぱい。:2006/02/14(火) 20:56:02
>>839
詐欺師か泥棒かは関係ない。そんなの確認できない。
ある程度の身元の確認ができれば、犯罪者のリスクは高くなる。
身元を明かさずにメールだけで処理できるのは手抜き過ぎ。
CAはカネを出してくれるほうの味方。
だまされた間抜けな一般人に対しては、賠償責任無いしね。

843 :名無しさん@お腹いっぱい。:2006/02/15(水) 19:33:24
>>834
Thawte解説発見。

http://www.atmarkit.co.jp/fwin2k/win2ktips/647freeca/freeca01.html

844 :名無しさん@お腹いっぱい。:2006/02/15(水) 20:03:41
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060214/229197/
とうとうキタ━━━━(゚∀゚)━━━━!!

845 :名無しさん@お腹いっぱい。:2006/02/15(水) 20:29:29
>>844
来ましたねー。

だから鍵が出てるだけではダメなんだってば。

846 :名無しさん@お腹いっぱい。:2006/02/15(水) 23:20:48
さあ、CRLの力の見せ所だぞ!
ちゃんと実装してるのかなあ?
…実際どうなんでしょうか?

847 :名無しさん@お腹いっぱい。:2006/02/15(水) 23:55:43
>>846
「失効」なんつーのは見たことないもんなぁ。
ふつーわ。

848 :名無しさん@お腹いっぱい。:2006/02/16(木) 00:44:13
ちょっと教えてくれ。
thawte から無料でもらった鍵で暗号化したメールは、
その気になれば thawte が復号化できるってことか?
秘密鍵のコピーを保存してるかも知れないぞ。

849 :名無しさん@お腹いっぱい。:2006/02/16(木) 01:22:20
>>848
秘密鍵は渡していないと思うが。

850 :名無しさん@お腹いっぱい。:2006/02/16(木) 04:48:38
渡していないという証拠は無いだろ

851 :名無しさん@お腹いっぱい。:2006/02/16(木) 08:58:14
>>850
確かに自分で検証したわけではないからその通りだ。
まーThawteが信用出来ないなら使わなければいいだけだし。

第三者からの信用を犠牲にして自己証明書を使うか
お金払ってベリや国内のCA(JCSIとか)から証明書取るか、ですな。

852 :名無しさん@お腹いっぱい。:2006/02/16(木) 09:03:29
>>848
> thawte から無料でもらった鍵で暗号化したメールは、

ていうか、そもそも秘密鍵はThawteからもらうんじゃないし。
CryptAPIで申請人自身が自分が作って、PKCS#10で証明書要求を出しているのだと思われ。

キーペアは自分で作って、公開鍵をThawteに渡して証明書を発行してもらう。
秘密鍵は自分のマシンから出て行かないし、出て行ってはいけない。

Thawteは「申請人は、申請されたメアドでメールが受信できること」=メアドの実在性を確認・証明してくれるだけ。
メアドの実在証明だけで、他の一切は証明してくれない。だからタダ。
名前とか住所とか勤務先とかまで証明して欲しかったら有料になる。


853 :名無しさん@お腹いっぱい。:2006/02/16(木) 16:58:13
>>852
まあ、理屈では、あんたの言うとおりなんだろうけどね。
おいらは comodo で取得したが、ウェブでメアドと名前を入力したら、
メールが送られてきて、そのメールの文中のボタンをクリックしたら、
それだけで証明書や鍵がインストールされてしまったぞ。
どのマシンで何が処理されたかなんて、ユーザには判らんぞ。実際。

鍵屋で鍵を買うようなもので、疑い出したらキリが無いがな。
すくなくとも可能性としては認識すべきだな。
おいらは PGP を使ってるから心配ないがね。

854 :名無しさん@お腹いっぱい。:2006/02/16(木) 17:39:41
>>853
安易に根拠もなく信頼するよりはちゃんと疑ったほうがいい、とはワタシも思います。
でもまあやみくもに疑ってもキリはないし。

だけど「タダのものを過信するな」ってのは大事でしょうね。
セキュリティもんを本気で使うんなら
ちゃんとお金を払うか、完全に自己責任でやるか
どっちかでしょうね。金を使うか頭を使うか。

PGPはワタシは詳しく知らないんだけど
本人性の担保というか、第三者への認証は可能なのか?
てのはとても興味があるので調べてみたいと思います。

855 :名無しさん@お腹いっぱい。:2006/02/16(木) 17:40:20
>>853
ひやー、comodoスゲエ。
一回試してみるか。どんなもんか。

856 :前スレ300 ◆w795LO9.Wo :2006/02/17(金) 13:21:25
>>853
> おいらは comodo で取得したが、ウェブでメアドと名前を入力したら、
> メールが送られてきて、そのメールの文中のボタンをクリックしたら、
> それだけで証明書や鍵がインストールされてしまったぞ。

comodoってジャパンではなく本国の方ですよね?試してみました。
証明書発行の仕組み自体はThawteと同じでMSCAPIを使っているようです。

Thawteは他に免許書番号みたいな個人で一意の情報を自己申告させますが、
comodoは確認内容が「指定のメールアドレスでメールを受信できること」だけですね。
こっちの方が簡単でいいですね。メールアドレスの実在証明だけなら。


> どのマシンで何が処理されたかなんて、ユーザには判らんぞ。実際。

たしかにそうですね。
この流れだとキーペアは自動的に自分で作ってるけど、ユーザーには判らんっぽい。

857 :名無しさん@お腹いっぱい。:2006/02/17(金) 14:49:03
>>854
PGP では PGP Global Directory という無料キーサーバがあります。
https://keyserver.pgp.com/vkd/GetWelcomeScreen.event
公開鍵をアップロードすると、鍵内部のメールアドレスあてに返信されてきます。
返信されたメールの文中のリンクにアクセスすれば公開鍵が登録されます。
鍵に署名はしてもらえませんが、ここのサーバから落とした公開鍵を使用すれば、
メールアドレスの実在証明にはなると思われます。

858 :854:2006/02/17(金) 15:48:19
>>857
なるほどねー。うまい仕掛けですね。
勉強になりました。ありがとうございます。

859 :854:2006/02/17(金) 19:16:07
>>856
秘密鍵は申請したマシン上にしかないはずだから
申請したのと別のマシンで証明書を取得すると失敗するはず。


860 :名無しさん@お腹いっぱい。:2006/02/17(金) 20:17:01
>>859
要するに自分のマシンか接続先かということ。

> 秘密鍵は申請したマシン上にしかないはずだから

comodoの場合は全自動で処理されるから、
接続先にコピーされても判らんっぽい。

861 :名無しさん@お腹いっぱい。:2006/02/17(金) 22:14:07
>>860
CAPIを使っているみたいだから無理だと思う。


862 :名無しさん@お腹いっぱい。:2006/02/18(土) 01:02:01
話がずれてる。CAPIとか関係ない。
接続先とはcomodoのこと。

863 :名無しさん@お腹いっぱい。:2006/02/18(土) 02:40:27
>>862
キーペアは自動的に自分で作っている。
秘密鍵は、仕組み的には外に出ようがない。
comodoからダウンロードしたプログラムがローカルで動くとかじゃない限り。

864 :名無しさん@お腹いっぱい。:2006/02/18(土) 03:22:40
それをあんたが実際に確認したなら別にそれでいいんじゃない?
さげ。

865 :名無しさん@お腹いっぱい。:2006/02/18(土) 05:01:50
COMODOが鍵作ってルート証明書といっしょに突っ込まれても
見分けがつかないと思うが

866 :名無しさん@お腹いっぱい。:2006/02/18(土) 07:39:37
んだ、んだ

867 :名無しさん@お腹いっぱい。:2006/02/18(土) 07:39:49
だから無理だっつってんのに。
そんなにcomodoが信用できないなら使わなきゃいいだけでしょ。

868 :名無しさん@お腹いっぱい。:2006/02/18(土) 09:35:42
COMODOはどうでもいいけど
863はなぜ自分で作っているとわかるんだ?

869 :名無しさん@お腹いっぱい。:2006/02/18(土) 10:42:32
>>868
↓こういう画面が出るだろ?COMODOでも。

http://www.verisign.co.jp/codesign/help/faq/210028/index.html

870 :名無しさん@お腹いっぱい。:2006/02/18(土) 11:08:32
なるほど
2つめのも表示されたんか

871 : :2006/02/18(土) 11:13:36
ローカルにファイルを保存する警告だよ、2番目は。
証明書ストアに保存する場合は出ない。(自宅のWin2003CAにて確認済み)

872 :44 ◆wI09.nTZZ. :2006/02/18(土) 11:47:57
立ててみますた。

【メール】S/MIME友の会【署名・暗号化】
http://pc8.2ch.net/test/read.cgi/sec/1140230616/

873 :名無しさん@お腹いっぱい。:2006/02/18(土) 12:45:25
>>871
出ないなら、わからないじゃん

874 :名無しさん@お腹いっぱい。:2006/02/18(土) 12:45:40
CryptAPI のちょうどいい解説が見つからないわ。

まー脆弱性ありまくりのMSの機能だって信用できんと言われればそれまでだが。


875 :名無しさん@お腹いっぱい。:2006/02/18(土) 12:50:11
>>873
いやいや1つ目は出るだろ?

2番目のは秘密キーを単独でファイルに保存する場合
(Authenticodeの署名用の証明書の取得の場合など)
に出るメッセージだから、comodoのメール用証明書の取得の流れでは出ない。

>>869
はCryptAPIがWEBページからの依頼でローカルに秘密鍵を作る際に出される
セキュリティ確認メッセージの例で、comodoで両方出るわけではない。

876 :名無しさん@お腹いっぱい。:2006/02/18(土) 13:03:51
なるほど
1つ目が出れば自前の秘密鍵だとわかるんか?
でも、これってルート証明書入れるときも出るんちゃうか?

877 :名無しさん@お腹いっぱい。:2006/02/18(土) 13:48:51
>>876
ルート証明書入れるときのはメッセージが違うと思う。
↓の14みたいなやつだろ?それは。

https://www.mof.go.jp/bid/ie/inst_ie.html

878 :名無しさん@お腹いっぱい。:2006/02/18(土) 13:55:44
なんにしろ、Thawteもcomodoも、一応はちゃんとした認証サービス会社。
(=Windowsがデフォルトでルート証明書を保持している)
無料サービスはあくまで有料サービスのお試し用というのが狙いだと思う。

だから、証明書の発行の仕組みとかをわざわざ変えて
タダの利用者にはインチキくさいことをする、なんてことはちょっと考えにくい。
企業として、わざわざ手間かけてそんなことするメリットがないのでは?
認証サービス会社の場合、信用を損なうというデメリットは致命的だから。

素性もよくわからないところならともかく。


879 :名無しさん@お腹いっぱい。:2006/02/18(土) 13:58:14
>>878
とはいえ、Windowsで証明書に関するセキュリティがどのように守られているのか、
まさしくいまここでああだこうだ言っている話が
利用者にとってわかりにくいというか、ちっともわからないというのも事実。

今回あらためてよくわかった。

結局はMicrosoftと自分が利用する認証機関とを信用することが前提
ということになってしまう。

安全な電子社会への道は遠いね。

880 :名無しさん@お腹いっぱい。:2006/02/18(土) 14:22:42
869は鍵を作ってるスクリプトが証明書を要求してるよという警告ですか
それ以外にはこのダイアログは出ないと
だから自前だよと

しかし、それは一般ユーザには、わからないね
ダイアログの表示にも書いてないし

COMODOのルートは数年前と変わったし、昔のOSには入ってないよ

881 :名無しさん@お腹いっぱい。:2006/02/18(土) 14:54:29
>>880

>しかし、それは一般ユーザには、わからないね
>ダイアログの表示にも書いてないし

確かに。
おまけにダイアログの日本語訳があまりにひどすぎる。
これに限らず、だけどね。日本語になってないものも多いし。

ルート証明書は古いOSには最初から入ってなくても
windows updateから提供されるはず。

http://www.atmarkit.co.jp/fsecurity/rensai/re_pki03/re_pki01.html

古いといっても限度はあるけどね。

882 :名無しさん@お腹いっぱい。:2006/02/18(土) 15:03:23
只のサービスはルートばら撒きが目的かも

883 :名無しさん@お腹いっぱい。:2006/02/18(土) 17:33:25
まぁ、WINDOWSを信用しないかぎりはどうにもならん。前提条件だし。
ゲイツOSが信用出来ないのは同意だがな。

Windows XP Professional と Windows Server 2003 の PKI 拡張機能
http://www.microsoft.com/japan/technet/prodtechnol/winxppro/plan/pkienh.mspx

証明書サービスを使用してワイヤレス LAN のセキュリティを保護する
http://www.microsoft.com/japan/technet/security/prodtech/windowsserver2003/pkiwire/swlan.mspx




884 :名無しさん@お腹いっぱい。:2006/02/19(日) 10:01:26
やってることとしては↓かな。

http://uone.hp.infoseek.co.jp/brouser_cert.html

885 :名無しさん@お腹いっぱい。:2006/02/19(日) 16:18:01
>>880
アホか
ダイアログなんていくらでも偽表示できるだろ
鍵を仕込むのは無理だろうが

886 :名無しさん@お腹いっぱい。:2006/02/19(日) 18:16:23
>>885
鍵を仕込むのは無理ってのはどういう意味?

887 :880:2006/02/19(日) 18:44:49
>>885
そうかい。でも、もうどうでもいいよ。
すまんな。

888 :前スレ300 ◆w795LO9.Wo :2006/02/20(月) 18:31:14
興味があったので、comodo の無料証明書取得の仕組みを調べてみた。

大筋の流れとしては、

ローカル:キーペアの作成
ローカル:CSR(証明書要求)の生成&送信
  認証局側:申請内容の確認
  認証局側:証明書発行
ローカル:証明書受け取り
ローカル:証明書とキーペアを証明書ストアに登録

となる。

ここで利用されている Windows の Microsoft Enrollment Control の仕様を信用するならば
証明書受領前にキーペアの秘密鍵を取り出すことは、利用者本人ですら出来ない。
受領した証明書はWindows証明書ストアに登録される。
ここから秘密鍵を取り出すのは、ローカルの操作でしか出来ない。
(外からそんな事が出来ては大変だ。)


889 :前スレ300 ◆w795LO9.Wo :2006/02/20(月) 18:33:16
comodo の無料証明書取得(1):証明書要求(PKCS#10)

まずは申請ページのフォームに、証明書を申請したいメールアドレスなどの情報を入力する。
[Agree & Continue]ボタンを押すと、入力したデータに基づき、PKCS#10形式のCSRを生成する。
(CSR=Certificate Signing Request:証明書要求)
具体的には Microsoft Enrollment Control(xenroll.dll) のCreatePKCS10というメソッドを使っている。
xenroll.dll はActiveXコンポーネントなので、このフォームはIEからしか実行できないわけだ。

-------------------------------
<object classid="clsid:127698e4-e730-4e5c-a2b1-21490a70c8a1" codebase=/cab/xenroll.cab id=XEnroll></object>

(中略)

  function makePKCS10(dn, keyUsage)
   On Error Resume Next
   makePKCS10 = XEnroll.CreatePKCS10(dn, keyUsage)
   if (Err.Number <> 0) then
    Err.Clear
    makePKCS10 = false
    XEnroll.Reset()
   end if
  end function
-------------------------------

これで生成したCSRを内部的にフォーム要素に貼り付けて comodo にフォーム送信している。
CSR生成時にローカルで自動生成された秘密鍵は、Windowsシステム内のどこかにこっそりしまわれており、
証明書を受領するまでは直接触ることはできない仕様になっているらしい。

890 :前スレ300 ◆w795LO9.Wo :2006/02/20(月) 18:34:21
comodo の無料証明書取得(2):証明書要求(PKCS#7)

証明書が無事発行されたら、Certificate Customer Services から Your certificate is ready for collection! というメールが来る。
このメールが受信できる=申請したメールアドレスが実在する、ということになる。
本当は、証明内容の確認→証明書の発行、というプロセスになるべきだが、両方をまとめて一気にやっちゃってるわけだ。

このメールで指定されたURLを開くと、Secure Email Certificates という証明書受け取りページが開く。
ここで申請メールアドレスと指定されたパスワードを入力すると、PKCS#7形式で証明書を受け取るページへ進む。

-------------------------------
<object classid="clsid:127698e4-e730-4e5c-a2b1-21490a70c8a1" codebase=/cab/xenroll.cab id=XEnroll></object>

(中略)

  sub loadPage
   On Error Resume Next
   XEnroll.Reset()
   XEnroll.AcceptPKCS7("---省略---")
   setCertStatus(Err.Number)
   Err.Clear
   XEnroll.Reset()
  end sub
-------------------------------

Microsoft Enrollment Control(xenroll.dll)は、AcceptPKCS7 というメソッドで
受け取った証明書と、どっかにしまってあった秘密鍵とをセットにして、証明書ストアに格納する。


891 :前スレ300 ◆w795LO9.Wo :2006/02/20(月) 18:37:51
>>888-890
というわけで、comodo の無料メール証明書取得の際の秘密鍵は
comodo が作るのではなくローカルで生成されており、
comodo に送信もされていないはずである。

PKIの仕様とMSの実装を信用する、という前提ではね。

892 :前スレ300 ◆w795LO9.Wo :2006/02/20(月) 18:48:54
ちなみに、ベリの60日間お試し証明書も同じような感じですね。

https://digitalid.verisign.co.jp/browser/client/shutoku.html

893 :名無しさん@お腹いっぱい。:2006/03/01(水) 16:44:41
あっはっはっは。もう三月ですよ。春間近ですよ。出来てねーですよ。
わっはっはっは。


894 :名無しさん@お腹いっぱい。:2006/03/01(水) 18:25:49
>>758 やっぱりか

895 :名無しさん@お腹いっぱい。:2006/03/04(土) 18:28:12
ttp://triaez.kaisei.org/~kaoru/ssl/cell.html
AUのサポートも大変だな

896 :名無しさん@お腹いっぱい。:2006/03/05(日) 01:48:03
>895
ここを見ると最近の機種はすべてwep2.0なので、end-to-end(普通のSSL)
を使うことが判る。
http://www.au.kddi.com/ezfactory/tec/spec/new_win/ezkishu.html

しかしリンク先のToriton,Inc って安いね。auでつかえるかどうかを
Freeの証明書で確かめてみる価値はありそうだ。

897 :896:2006/03/05(日) 11:14:50
http://www.trustlogo.co.jp/handy_phone.htm
にお試しページがあった。
AU W32Hで大丈夫だったよ。

...もう少し早く気付いていれば...orz


898 :名無しさん@お腹いっぱい。:2006/03/08(水) 02:56:15
存在証明してこの値段って Toriton, Inc はちゃんと利益でてんのかね


899 :名無しさん@お腹いっぱい。:2006/03/08(水) 04:09:36
>>883
まさにオレオレOSですよ。

900 :896:2006/03/08(水) 21:13:15
>898
存在証明といっても、ユーザに各種書類を提出させて、転送不要指定の
配達記録郵便送って、返事が帰ってきたら情報に矛盾が無いことを確認
するぐらいじゃあるまいか。

証券会社に口座を作ったときもそれぐらいだったし、他のCAなんか個人
契約なら免許証のコピーしか要求されなかったよ。

901 :名無しさん@お腹いっぱい。:2006/03/20(月) 00:07:07
保守しとこう。

902 :前スレ300 ◆w795LO9.Wo :2006/03/22(水) 11:07:30
このスレはワタシが立てたんじゃないんだけど、ほぼレギュラーメンバー状態。
今の状態だと次スレって別に要らないようにも思う。

でもベリに限らず、電子認証とか電子証明書とか一般の話題にふさわしい場所が他にないのなら
そういうスレはあっていいように思う。

今まで何回か聞いてみたけど、ほかに適切な板やスレがある、という話を聞いたことが無い。
もし無いなら PKI 全般の話題のスレとして次スレを立ててもいいように思うけど
ここがふさわしいのかどうなのか、ちょっと自信が無い。

それ以前にスレ立てしたことがないので、作法とかがわからない。
情けない。


903 :名無しさん@お腹いっぱい。:2006/03/22(水) 12:31:57
980まで行ったら次スレ行こうよ

904 :前スレ300 ◆w795LO9.Wo :2006/03/22(水) 16:33:00
☆★初めての投資信託 5★☆
http://live19.2ch.net/test/read.cgi/market/1141476047/
で少しだけ話題になった

http://www.dt-union.com/sp619.html
国際個人投資家連盟 - 225パーソナル・ヘッジファンド Delta One

いかにも胡散臭いサイトです。
下部の申し込みページへのリンクにご丁寧に
「128Bit SSL セキュリティ」と書かれていますが
リンク先は http:// です。

詐欺サイトじゃないなら嘘はいけませんよね。
詐欺サイトならもっと真剣に作って欲しいものです。

905 :名無しさん@お腹いっぱい。:2006/03/28(火) 20:53:29
PGPとかS/MIME専門スレならあるんだがな。
PKI総合スレでいいんじゃない?
テンプレは次スレでまたーり作ろうじゃないか。スレタイだけは考えないとね。
↓改良キボン
【PKI-SSL-CA】公開鍵認証基盤【電子証明書】

906 :名無しさん@お腹いっぱい。:2006/03/28(火) 20:54:28
>>904
投資ファンドって時点で怪しいもんですから

907 :前スレ300 ◆w795LO9.Wo :2006/03/28(火) 21:19:18
>>906
怪しいからいろいろ触ってたらますます怪しかったのよ。

908 :名無しさん@お腹いっぱい。:2006/04/06(木) 08:41:06
保守しとくかね。

909 :前スレ300 ◆w795LO9.Wo :2006/04/21(金) 13:04:48
CRL配布のプロトコルにLDAPを使っている電子証明書が、ICカードもんを中心に割とあるようです。

企業内LANとかでLDAPが外に出られないので使えない、という話を時々聞きますが
さらに「LDAPを通さないプロバイダ」もある、という噂も聞きました。

そんなプロバイダがあるんでしょうか?
ご存知の方、居ませんか?

910 :名無しさん@お腹いっぱい。:2006/04/26(水) 12:27:36
COMODO の奴を申請かけたら
AddTrust External CA Root が証明書を作ろうとした。
こんな CA からの証明書は要らないのだが
http://secure.comodo.net/ubiquity/SSLServerCertificates.html

Country を Japan にしたから、こんな CA の証明書が出来たんだろうかw

911 :名無しさん@お腹いっぱい。:2006/04/30(日) 23:13:48
テッド 早く株価あげてくれ。 

912 :名無しさん@お腹いっぱい。:2006/05/11(木) 12:27:31
ほす

913 :名無しさん@お腹いっぱい。:2006/05/17(水) 09:53:10
ホゥ!ティービー
http://www.moj.go.jp/ONLINE/CERTIFICATION/

ほう。

914 :名無しさん@お腹いっぱい。:2006/05/26(金) 08:52:15
>>913
こんなの誰が見るんだよって笑ってたら
なんか法務省民事局の「商業登記に基づく電子認証制度について」のリンク先が
いきなりホゥ!ティービーになってるし。

なかなか思い切ったことするな、法務省。

915 :名無しさん@お腹いっぱい。:2006/06/02(金) 22:12:59
法務省

916 :名無しさん@お腹いっぱい。:2006/06/13(火) 10:10:09
↓こういうことを質問された方がいらっしゃいます。
http://www.sangiin.go.jp/japanese/joho1/syuisyo/162/syuh/s162009.htm
質問主意書 質問第九号 印紙税に関する質問主意書
櫻  井   充
【参考】http://www.dr-sakurai.jp/

↓でもって純ちゃんはこう答えています。
http://www.sangiin.go.jp/japanese/joho1/syuisyo/162/touh/t162009.htm
答弁書 答弁書第九号 内閣参質一六二第九号 平成十七年三月十五日
内閣総理大臣 小 泉 純 一 郎

超訳するならこんな感じですかね。

Q>電子文書には印紙税かけんでもかまんの?

A>まだほとんど利用されてないから、放っといていいじゃん。


917 :名無しさん@お腹いっぱい。:2006/06/13(火) 14:54:36
ってことはそのうち掛けるのか
結構高いのもあるな

918 :名無しさん@お腹いっぱい。:2006/06/21(水) 07:14:32
ほし

919 :名無しさん@お腹いっぱい。:2006/07/07(金) 18:43:26
http://www.mof.go.jp/jouhou/syukei/sy180704/1807a.htm
◆予算執行調査(平成18年7月)
予算執行調査結果について(参考例)より

【事業名】
旅券発給関連経費(電子申請システム運営経費) 【外務省】[862百万円]

【問題点】
 電子申請による発給件数が極めて低調(累計133件)。
他方、運営経費は年間平均約8億円。1件当たりのコストは約1,600万円で、通常発給(約3〜4千円)と比べ5,000倍以上。

【要因】
 利用が低調な理由として、申請に住基カードの取得が必須であるが、その取得者数が未だに僅少(人口比0.54%)なことや、
セットアップコストが高い等の一般的要因に加え、申請者にとって10年(5年)に1回しか利用機会がなくメリットが実感しにくいなど、旅券申請の場合の固有要因も存在。

【改善点・検討の方向性】
 政府は一般行政サービスの電子申請システム化を推進しているが、旅券発給に関する状況等を勘案した場合、厳しい財政事情から見て、その継続は合理性を有するとは言い難い状況。
本システムの廃止を含めた見直しを早急に検討すべき。


920 :名無しさん@お腹いっぱい。:2006/07/14(金) 09:15:55
>>919

>外務省は10日、自宅のパソコンからインターネットを通じてパスポートの発給申請ができる「旅券電子申請システム」を来年度から凍結することを決めた。来年3月末をめどに申請の受け付けを中止する。

あひゃひゃひゃ。

921 :名無しさん@お腹いっぱい。:2006/07/28(金) 10:09:59
http://headlines.yahoo.co.jp/hl?a=20060727-00000117-yom-soci
16歳少女が他人の保険証悪用、住基カードを偽造

 福岡県内の無職少女(16)が、拾った他人の保険証を悪用し、住民基本台帳カードを偽造していたことが県警の調べでわかった。


16歳の少女はなぜ住基カードが必要だったのか?

(1) 登記オンライン申請
(2) e−Tax
(3) 厚生労働省オンライン申請
(4) 特許オンライン申請
(5) その他


http://www.sanspo.com/shakai/top/sha200607/sha2006072809.html
15歳少女出演させAV4本を制作、芸能プロ社長ら2人を逮捕

福岡県警は27日、労働者派遣法違反容疑で東京都渋谷区代々木、芸能プロ社長、佐藤健士容疑者(36)ら2人を逮捕。
調べでは昨年12月、当時15歳の県内の少女を都内のAV会社に派遣、AVに出演させた疑い。同社は少女出演のAVを4本作った。
少女は出演後、2人から「AV女優として働いていくには年齢証明が必要」と言われ、福岡市内で拾った20歳女性の保険証で住民基本台帳カードを取得。
県警は少女を遺失物横領容疑などで逮捕、送検した


はい。正解は「(5) その他」の「AVに出演するため」でした。


922 :名無しさん@お腹いっぱい。:2006/07/28(金) 11:45:21
ほんとに「拾った」のか?
年齢証明が必要になったとき都合よく保険証落ちてたりする?
しねーよ。

923 :名無しさん@お腹いっぱい。:2006/08/05(土) 08:30:09
保守。
公的個人認証のカードリーダーは役場でも一緒に売ればいいのに。

924 :名無しさん@お腹いっぱい。:2006/08/25(金) 12:15:50
崖っぷち!電子政府〜迷走する4500億円プロジェクトの行方・第4回:
インサイダー覆面座談会「電子政府“無責任”の連鎖を断て!」―前編
http://www.itmedia.co.jp/enterprise/articles/0608/18/news002.html

崖っぷち!電子政府〜迷走する4500億円プロジェクトの行方・第5回:
インサイダー覆面座談会「電子政府“無責任”の連鎖を断て!」―後編
http://www.itmedia.co.jp/enterprise/articles/0608/22/news001.html

925 :名無しさん@お腹いっぱい。:2006/09/12(火) 00:54:48
あげ

926 :名無しさん@お腹いっぱい。:2006/10/07(土) 08:39:37
電子文書には印紙が貼れない。だから印紙税がかけれない。

さあ、どうしよう。
そこで電子印紙か?
それとも国営有料のタイムスタンプサービスか?

927 :すずき@通りすがり:2006/10/21(土) 11:04:34
> 910

いるかいらないかは個人の判断に任せるとして、
AddTrust External CA Root の、 SHA1 拇印 が
02 fa f3 e2 91 43 54 68 60 78 57 69 4d f5 e4 5b 68 85 18 68
のやつなら、 Firefox 1.5.0.7 の証明書ストアにも認証局証明書として
はじめから入ってます。

http://secure.comodo.net/ubiquity/SSLServerCertificates.html

Firefox の証明書ストアは M$ の証明書ストアとは違うところにあります。
ということで Japan 云々は関係ないのでは?

928 :名無しさん@お腹いっぱい。:2006/11/01(水) 03:36:50
証明書切れても運用してる企業のWEB受注システムって
かなりヤバイですか?


929 :名無しさん@お腹いっぱい。:2006/11/01(水) 07:39:05
>>928
受注システムがというより企業自体がヤバイのではないかと。
ちなみににどこの会社ですか?ヒントだけでも。

930 :名無しさん@お腹いっぱい。:2006/11/15(水) 10:03:12
まったくここは時の停まった部屋だな。

931 :名無しさん@お腹いっぱい。:2006/11/16(木) 18:50:02
正式/日本語版が出たので、
Windows PowerShell を入れて遊んでるんだが
スクリプトも署名入りじゃないと動かないセキュリティ・ポリシーがデフォルトになってる。

開発者・技術者もPKI避けては通れない時代になってきましたな。

932 :名無しさん@お腹いっぱい。:2006/11/17(金) 00:19:27
WSHがノートン先生のせいでほとんど使い物にならなくなったのが
トラウマになってるんだろうな

933 :名無しさん@お腹いっぱい。:2006/11/17(金) 00:25:47
>>932
なんで自分で書いたスクリプトを悪質呼ばわりされるのか、と
悲しい気持ちになりましたよ、ええ。

934 :名無しさん@お腹いっぱい。:2006/11/17(金) 02:08:22
>>933
ナカーマ

935 :名無しさん@お腹いっぱい。:2006/11/17(金) 09:37:07
漏れは証明書サーバー立ててるから署名し放題だぜ

936 :名無しさん@お腹いっぱい。:2006/11/17(金) 10:09:18
オレオレ証明書?

937 :名無しさん@お腹いっぱい。:2006/11/17(金) 10:15:29
コード署名とかで
自分だけで使う分には
べつに自己証明書でもいいとは思うけど。

938 :名無しさん@お腹いっぱい。:2006/11/17(金) 11:05:45
三菱東京UFJのオンラインバンクがノートンにばしばし検疫されまくって
いるんだが・・・

939 :名無しさん@お腹いっぱい。:2006/11/26(日) 20:14:49
サポートの女性の高圧的な態度はどうにかならないのかねぇ・・・


940 :名無しさん@お腹いっぱい。:2006/11/27(月) 18:30:56 ?2BP(0)
age

941 :名無しさん@お腹いっぱい。:2006/11/27(月) 20:07:04
>>939
そういうのは、「電話の担当を変えてくれ」と、ごり押しすればOK。
で、変わったら、「ヒドい人だったと」とでも言ってスッキリしとけ。


942 :名無しさん@お腹いっぱい。:2006/11/29(水) 19:32:05
これじゃあもう次スレは要らないなあ。
PKI汎用で立てようかとも思ってたけど。

943 :名無しさん@お腹いっぱい。:2006/12/01(金) 20:26:47
関連wiki
http://wiki.ninki.org/wiki.cgi?p=%a1%da%a5%d9%a5%ea%a5%b5%a5%a4%a5%f3%a1%dbVeriSign+%a1%da%be%da%cc%c0%bd%f1%a1%db


944 :名無しさん@お腹いっぱい。:2006/12/21(木) 12:35:03
ITmedia News:FeliCaの暗号が破られた?――ソニーは完全否定
http://www.itmedia.co.jp/news/articles/0612/20/news103.html

これ大変じゃないか?

945 :名無しさん@お腹いっぱい。:2006/12/21(木) 18:05:36
>>944
雑誌を売りたいが為の記事って感じだね・・・

946 :名無しさん@お腹いっぱい。:2006/12/21(木) 18:27:56
実際、記事中ではどの暗号の鍵が破られ、それが何ビットだったのかなど、
具体的な内容は語られていない。
また暗号が解かれたのはEdyのように書かれているが、それも明らかにはしておらず、
客観的に見て、説得力に欠ける内容になっていることは否めない。




この時点で胡散臭すぎだろw

947 :名無しさん@お腹いっぱい。:2006/12/21(木) 22:05:44
ttp://internet.watch.impress.co.jp/static/yajiuma/index.htm
「にゅーあきばどっとこむ」によると、このFeliCa関連の開発資料が、
Winnyのネットワーク上に流出しているという。
どうやら、「キンタマウイルス」に感染したことが原因らしい。
筆者は問題のファイルを入手していないが、元ネタの2ちゃんねるの投稿を読むと、
暗号化に使われる秘密鍵のリストも流出資料に含まれているようだ。




あながちネタじゃなかったりw

948 :名無しさん@お腹いっぱい。:2006/12/21(木) 22:26:00
もうウソがバレまくってるけどね
アホ信者必死だなと
せめて板で暴れて汚し回るなクズと言いたい。

949 :名無しさん@お腹いっぱい。:2006/12/21(木) 23:01:05
このスレに何の関係があるんだ?

950 :名無しさん@お腹いっぱい。:2006/12/21(木) 23:04:55
まぁ来週のIPAの発表待ちだな。

万一本当に破れるとなったら、Sony社の存続すら怪しくなってくるが。
デマだったら風説の流布でタイーホの予感。

951 :名無しさん@お腹いっぱい。:2006/12/21(木) 23:45:09
何度目の嘘つきなんだかこいつは

952 :名無しさん@お腹いっぱい。:2006/12/22(金) 01:26:08
>>950
IPAは「ハードのことはうちは専門外」とか言って逃げたよ。
で、話されていることの半分は本当で、半分は嘘なんだとさ。

たぶん、Sonyの方が嘘だろ。
IPAに持ち込まれたネタが嘘なら、IPA自身が否定すればいいし、半分も糞もない。

たぶん、SONYはもう終わり。


953 :名無しさん@お腹いっぱい。:2006/12/23(土) 11:47:01
>>952
IPA自身は検証してないってだけの話だろ。

954 :名無しさん@お腹いっぱい。:2006/12/23(土) 13:19:48
>>953
もし、そうだったら、半分が嘘とか言う必要もない。

955 :名無しさん@お腹いっぱい。:2006/12/23(土) 14:16:17
>>954
熱くなってるところ悪いがスレ違いだから帰れボケ

956 :名無しさん@お腹いっぱい。:2007/01/02(火) 14:27:10
ハードの話をIPAに持ち込んだ馬鹿がいるという
単なる事実が「半分」なんだから当たり前だろ。
VeriSignとぜんぜん関係ない話をスレに持ち込む馬鹿がいるみたいに

957 :名無しさん@お腹いっぱい。:2007/01/03(水) 09:35:06
何言ってるんだ。
中身が剥き出しになった時点で、もうアウト決定なんですけど。



958 :名無しさん@お腹いっぱい。:2007/01/03(水) 09:47:33
>>957
いいから帰れよ

959 :名無しさん@お腹いっぱい。:2007/01/05(金) 17:24:14
>>956
まあ、ベリの話しだけではもう全然ネタがない。
ベリにはサーバー管理者やプログラム開発業者はともかく
一般人が利用できるような商品サービスはほとんどないしね。
そういう意味ではベリスレはもう役目を終えたんだろうね。

でもPKIとかのセキュリティ技術一般のネタを扱うスレもオレは知らないので、ネタとして持って来ました。
まあ確かに普通にスレチではあるけどね。

どっかそういうスレがあったら教えてください。
ないなら、ここがdat落ちしたら次スレはベリスレでなくPKIスレか認証技術一般かなんかで立てようかとも思ってます。

Felicaは高速処理のため、PKI使ってないんだよね。
だから場合によっては破られる余地もあるのかもしれないと思った。

まーなんにしろスレチだね。ははは。

960 :名無しさん@お腹いっぱい。:2007/01/06(土) 19:16:03
じゃあ次スレはPKI総合にするか

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)