1 :
名無しさん@お腹いっぱい。 :
04/01/09 17:04
2 :
名無しさん@お腹いっぱい。 :04/01/09 17:06
バージン
3 :
名無しさん@お腹いっぱい。 :04/01/09 17:07
4 :
名無しさん@お腹いっぱい。 :04/01/09 17:07
2
いやー今回の件で勉強になったよ
6 :
名無しさん@お腹いっぱい。 :04/01/09 17:08
本家は自演で荒らされてる 以後300はこちらで自演してくださいW*88
7 :
名無しさん@お腹いっぱい。 :04/01/09 17:11
未だによく分からん
で、結局エンドユーザはどうすりゃいいの? 待ってりゃなおるの?
9 :
名無しさん@お腹いっぱい。 :04/01/09 17:15
正直全く分からん
10 :
名無しさん@お腹いっぱい。 :04/01/09 17:17
ベリサインは塞ぐ必要ないって事でok?
ノートンに関しては、電子署名の期限切れた時の処理が DoSまがいの阿呆仕様だったのが原因でほぼFAかと。 証明書関係のファイル取りに行って応答待ちになるから それを最初から遮断するって意味では塞ぐのは正解。 但し証明書関係の処理が怪しくなるから セキュリティ的には不正解。
12 :
名無しさん@お腹いっぱい。 :04/01/09 17:31
>>10 ふさいじまったら永久に治らん
もう更新できるので最初の1回繋ぎに行けば治る
ジエーン!と参上しますた。 オレ自身、電子認証とかは勉強始めたばっかでまだにんともかんとも。 ただ、有効性確認のやり方がまずいと なんかの契機にトラフィック増大というか爆発というか 今回のようなことが起きるんではないか? みたいな懸念はなんとなくあった。 これから公的個人認証とか始まったら、どうなるんだろう。 このあたりのテーマ、もっと適切なスレや板、 ご存知の方居たら教えてっちょ。
14 :
名無しさん@お腹いっぱい。 :04/01/09 17:52
http://www.ipa.go.jp/security/pki/index.html PKI 関連技術解説
PKI は、Public Key Infrastructure の略であり、公開鍵基盤と訳されます。これは、「公開鍵(暗号技術)」による「基盤(インフラ)」を表しています。この技術を用いることで、暗号化、デジタル署名、認証といった様々な 情報セキュリティ対策を実現できます。
これ、オレが今まで見た中で、日本語でタダで読めるものの中では一番いいんだけど
あまりに敷居が高くてまだまたげない。
改めて取り組んでみるか。
18 :
名無しさん@お腹いっぱい。 :04/01/09 23:32
19 :
前スレ300 ◆w795LO9.Wo :04/01/10 02:26
NIS2003スレと敢えてマルチ。 あっちはトップリ付け忘れてたよ。 以下はあくまでオレの拙い理解&推測なので誤解なきよう。 間違えている可能性は大いにあります。 くわしいひと、間違いがあったら指摘してっちょ。 ○そうではないかと思われること ・証明書が期限切れで無効=そのファイルが無効、というわけではない。 (証明書の確認が出来ないだけ。改竄は確認できる。) ・証明書失効リスト(CRL)は、常に定期的に取得するもので、個々の証明書の期限切れとは直接は関係ない。 →「ある証明書の期限が切れた」から慌てて取りに行くものではない。 ・証明書が無効になる条件は、 (1) 有効期限切れ(証明書内に明記されている) (2) 失効(失効リストに載っている) ・有効期限内の証明書は、失効していないか確認する必要がある。 →失効リストに載ってないか調べる。 ・有効期限切れのものは、その時点で無効である。 →失効リストを調べるまでもない。 ・有効期限外の証明書に関する失効リストは、そのうち発行されなくなるかもしれない。 ○オレとしての原因邪推・多分最終版 ・有効期限切れの証明書の、期限切れの失効リストをわざわざ更新しようとして、取りに行こうとしている大バカモノがいるのではないだろうか? ・それがもう発行されていなくて、まさかそうだと思わずにタイムアウトするまで一所懸命リトライしている大バカモノがいるのではないだろうか? ○おまけ:調べてわかったこと ・NAVは、改竄された電子署名済ファイルがあっても別に何もしてくれない。 (これはちょっとビックリ!)
20 :
前スレ300 ◆w795LO9.Wo :04/01/10 02:30
21 :
前スレ300 ◆w795LO9.Wo :04/01/10 02:40
ある環境で [発行元証明書の取り消しを確認する] のチェックをはずす =取り消しリストの取得をやめる で軽くなるんだったら、 まさしくその環境が「異常な数の「証明書失効リスト」のダウンロードを要求」していたんだと思うが。
さすがにもう祭りも終わりかぁ。
>>6 さんの許可が出ているので
ここで一人でジエーンすっか。
オレの推理がもし正しいのなら ・証明書ストア内のローカルの証明書とかは一切関係ない。 ・もし問題の失効リストが発行再開されれば直ってしまう。 てことなんだがな。
>証明書ストア内のローカルの証明書とかは一切関係ない。 やっぱ、これは断言しない方がいいかもな。 ちょっと自信が揺らいできた。 でも、ルート証明書更新しても直らなかったと思うんだがなぁ。 それに、古い署名のルートはもちろん古いルート証明書のはずだし。
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の根認証機関の最新バージョンを得ます。 .
>指示の十分なセットは、設置によってあなたを歩かせるこのページで利用可能です。
って断言してるなぁ。
明日にはこれが日本語訳されるんかな。
でもほんとか?これ。
ベリサインの協力で「勝手に直った」ちゃうんか??
我ながら見事な一人芝居だ。 虚しくなってきた。 もう寝よう。 明日起きたら、 なんだかすっかり直ってて きっと何も無かったことになってるんだろうな。 まあいいや。 あの祭りの楽しい日々は忘れないよ。 おやすみなさい。さようなら。
27 :
名無しさん@お腹いっぱい。 :04/01/10 04:38
>>26 君にとってはこの問題発見の瞬間が人生のピークだったってことか・・・
残りにつまらない人生を生きろw
28 :
名無しさん@お腹いっぱい。 :04/01/10 13:40
まとめていただいたけど、 ノートン激重の直接の原因は 「グローバル・サーバIDの中間CA局証明書」の期限切れ じゃないと思う。 だから対策も 中間CA証明書の取り直し ではないと思うんだ。
30 :
名無しさん@お腹いっぱい。 :04/01/10 23:50
>>25 >この問題を解決するために、あなた、ねばならない Verisignの根認証機関の最新バージョンを得ます。 .
>指示の十分なセットは、設置によってあなたを歩かせるこのページで利用可能です。
これはショッピングサイトなんかのサーバー認証の場合の
説明だと思う。この場合サーバーに認証鍵置くからね。
パソコンにインストールされているソフトの認証の場合は、その
ソフトの署名をやり直さない限り直らないと思うのだが・・・
いま復旧したように見えるのは、ベリサインのサーバー側で
何らかの対処(一時的にダミーの応答させるとか)してるん
じゃないかと推測してる。
現にIEのキャッシュ削除したら、またベリサインへ繋ぎに
いこうとするみたいだしね。
>>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エンタープライズ)
>>27 ほんとだねー。
オレもそう思うよw
名無しに戻っておとなしくするか。
35 :
名無しさん@お腹いっぱい。 :04/01/11 02:55
>>34 Windows XPおよびそれ以前のオペレーティングシステムにおいて、MS CAPIベースで動作するサードパーティ製品のセキュリティパッチの一部には、
2004年1月7日で有効期限が切れる特定のCRL(Class3SoftwarePublishers.crl)が含まれており、crl.verisign.comからその更新版を取得しようとした結果、急激なダウンロード要求の増加につながったものと思われます。
↓
ある製品のセキュリティパッチに、期限切れのCRLが含まれており…
↓
誰だ(笑)?
VeriSignのニュースリリースを読んだ… 暗に批判してるなぁ脳dを…
39 :
名無しさん@お腹いっぱい。 :04/01/11 03:18
明にベリサインになすくりつけるシマンテック 暗にシマンテックを批判するベリサイン 興味深い構図です。
金払ってるのがノートンで 貰ってるのがベリサインだからな 悪いのはベリだろ
>>40 でも
金払ってるんのがユーザーで
貰ってるのがシマンテックだから
シマンテックも悪いんじゃないか?w
>>34 CRLをダウンロードできなかった場合、CRLを失効情報として取り扱う多くのアプリケーションにおいて以下の2つのうちどちらかの方法がとられることが一般的です。
(1) よい子
いくつかのアプリケーションは動作しつづけ、以前にダウンロードされ、かつ有効なCRLを参照します。このようなアプリケーションでは今回影響はありません。
(2) あほな子
ローカルにキャッシュされたCRLを利用しないその他のアプリケーションでは、crl.verisign.comにアクセスを要求します。
今回、アクセスが集中し、CRLをダウンロードしにくくなった原因として、後者のアプリケーション動作によるものと考えられます。
あほな子は誰だ?
ベリはなんで1/7だけ多くなった? 脳dもベリだけのせいにはできんでしょ WやEが立ち上がらなくなる必要はない つくりがワルイ 警告出せばいいじゃんか
46 :
名無しさん@お腹いっぱい。 :04/01/11 03:49
>>43 期限切れCRL入りパッチを撒いた奴がいるからだ、と
ベリは暗に言っていますよ。
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
窓の杜の方、いきなり古い証明書を削除しろって書いてあるけど バックアップくらいさせれよ
結局こういうことだよね 脳豚が期限切れのCRLをアップデートしないまま配布 その結果1/7以降CLRダウンロード要求が大量発生 ベリのサーバーがあぼーん ここで警告なり出して古いCLRで動作すればいいものを、いつまでも ダウンロード要求 やっぱり脳豚が一番悪いような・・・
http://www.verisign.co.jp/ 重要なお知らせ
ベリサイン CRL配布サイトのレスポンス遅延について
しっかしまあちっちゃく書いてるなあ。
普通なかなか気が付かないぞ。
一応「重要」とは書いてあるけど。
シマンテックの方はトップページに書いてないし。
1、プログラムの電子署名って何なの?
ソフトウェア開発者が、自分とこの作ったプログラムとかが、確かに自分らが作ったものであること、自分らがリリースしてから後、改竄がされてないことを、利用者が確認できるための仕組みだ。
これは開発者側が気が向けばお金を払ってやる仕組みで、絶対にやらないといけないとかいうわけじゃない。
このプログラムの電子署名サービスとして代表的なのに、ベリサインの「コードサイニング証明書」(Code Signing)てのがある。(っていうか他はちょっと聞いたことない)
http://www.verisign.co.jp/codesign/index.html
>>56 2、プログラムの電子署名ってどんなもん?見えるの?
例えば、ノートンのアレ、CCAPP.EXE を見てみよう。
C:\Program Files\Common Files\Symantec Shared\CCAPP.EXE
これを右クリして(もう右クリ、大丈夫だよね:-)、プロパティを出そう。「デジタル署名」というタブがあるファイルは、電子署名がされてるんだ。出てこないものはされてない。
「デジタル署名」をクリックすると、このファイルにある署名の一覧が出る。たいてい一個しかないので、それを選んで「詳細」を押す。
すると、デジタル署名の詳細が表示される。
署名者の情報
名前 Symantec Corporation
電子メール 利用不可 (署名の情報としては公開してないだけ)
署名時刻 2003年12月2日 16:38:47
(これは見るファイルによって違うはずだけど、ファイルの更新日時とわずかな誤差のはず)
これでとりあえず、このファイルがシマンテックによって作られたもの、ということが確認できるわけだ。
>>56 >>57 3、ちょっと待て。だれがそれを保証してくれるんだ?
それはベリサインです。(ベリサインのサービスを使ってる場合)
確かに署名にはシマンテックの名前があるが、それは誰が証明してくれるのか?
普通のはんこの場合だと、みとめ印じゃなくて実印の場合は、押捺した書類と一緒に「印鑑証明書」を付ける。
これには、印影と登録者の情報が載ってて、押された印影と、証明書の印影を比べて同じなら、「登録者が押したもの」と推定できる、という仕組みね。車買ったことのある人とかだと、慌てて印鑑登録はしたことあるはず。
電子署名も似たような仕組みになってて、一緒に電子署名の証明書ってのが付いてきてるんだな。
>>56-59 5、おいおいオレのって期限切れだよ。もう使えないのか?
この電子署名による証明は、あくまで証明書にかかれているとおり、
・ソフトウェアがソフトウェア発行者の送信であるか確認する
・公開後のソフトウェアを変更から保護する
という2点だけ。「これは○○が作りました」「パッチとかクラックとかされてません」ってことね。
それをベリサインが証明してくれる期間がその「有効期間」ってことで、それが切れたからといってそのファイルやプログラムそのものの有効期限が切れたり、使えなくなったりするわけじゃない。
そもそも電子署名のされてないプログラムは結構あるし、昔はそんなものなかたし。
利用期間を設定や制限しているアプリが時々あるけど(笑)、これもプログラム署名によって制御しているわけじゃない。署名の有効期限と、プログラムやファイルの有効期限は別物です。
それに証明の期間は切れてても、少なくとも署名の妥当性=改竄とかされてないか?てのは確認できるんだ。
確認できないのは「ソフトウェアがソフトウェア発行者の送信であるか確認」なんだけど、そもそも一度は正しく署名されているものについて、これが変わるのは
「これは誰かがうちをかたってリリースしたもんだ。うちのじゃないぞコラ!」って場合か、
今は社名が変わっちゃったりしてる場合くらいか。
>>56-60 6、カイネズミされてないってなんでわかるんだよ?
とりあえずカイネズミじゃなくてカイザンです。
デジタル署名の詳細に「このデジタル署名は問題ありません。」と表示されていれば、改竄がない、ってことです。
ちなみに、ファイルを改竄してからデジタル署名の詳細を確認すると、「このデジタル署名は有効ではありません。」っていわれて、OSによっては赤シイタケ付き書類のアイコンが表示されます。
実験方法を書くとナニなので、言われなくてもやり方がわかる人は試してみてください。やる人は必ず、コピーしたファイルでやってね。オリジナルをカイネズミせぬよう。
>>56-61 7、おいおい期限切れなのに無問題かよ!?
証明書の期限が切れているデジタル署名の詳細を表示しても、「このデジタル署名は問題ありません。」と表示されてしまいます。
これは厳密には「このデジタル署名自体に問題はありませんが、証明書の期限が切れています。」くらいのはずです。
でも、うっかりここに「問題ない」以外を出したり、黄色ビックリなんかを出したりすると、「おいおいオレのヤベエよ」とか慌てる人が出てくるので、わざとそうしている、とここはゲスカンしておきます。っていうか何も考えてないのかもしれなない。
「署名自体の有効性」ってのと「署名の証明の有効性」ってのは別物で、前者が改竄がないことの確認、後者が身元の確認って感じではないかと。
いくら証明書が有効でも、署名自体が無効=改竄されていればそいつはアウト。
署名自体が有効であれば、少なくとも改竄はされていない、ってことね。
どっちにしてもユーザーはシマンテックに金払ってるんだから ノートンでの不具合はシマンテックが詫びるべき、と考える。
65 :
名無しさん@お腹いっぱい。 :04/01/11 14:13
良スレ!
署名鍵が盗まれた場合、文書を改ざんした後に再署名されると 改ざんを検出することは不可能となります。(電子公証とか使えばよいが今は普及していない) 証明書には有効期間がありますので、盗難にあった署名鍵が悪用される 期間は証明書有効期間に限定させることができるといえます。 (そのためには、検証アプリケーションが正しい動作をしなければいけませんが) 鍵の正当な所有者は、署名鍵が悪用されていると感じたら、証明書を 失効させることができます。 しかし、今日、一般的に使用されている失効手段であるCRLの場合は、 利用者証明書の有効期間が切れると、その証明書の失効情報 はCRLから削除されます。(これはX.509やRFCで規定された仕様です) つまり、利用者が認証局に失効を申請して、失効情報がCRLにのったとしても、 その利用者証明書の有効期間がすぎると、自動的にCRLからエントリが削除されます。 これは、CRLのサイズを増大させないための処置です。 また、有効期間をすぎた証明書は一律に無効とすることで対処可能である という考え方があるからです。 したがって、有効期間がすぎた証明書は、失効されていたかどうかは、 過去のCRLを参照しないと判断できなくなります。。 CRLで失効を運用している場合は、そのことに注意する必要があります。
>>67 >しかし、今日、一般的に使用されている失効手段であるCRLの場合は、
>利用者証明書の有効期間が切れると、その証明書の失効情報
>はCRLから削除されます。(これはX.509やRFCで規定された仕様です)
おお、どなたか存じませぬがありがとうございます。
偉そうに書いてますけど
オレもいろいろわからないところばっかなんですよ。
怪しいところ、間違ってるところありましたら
ツッコミおねがいします。
>>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 に公開した。
(それまで更新がなかったかどうかは定かでない)
>>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 に公開した。
(それまで公開/更新がなかったかどうかは定かでない)
>>67 さん
X.509のそのへんの仕様って
どれのどのへんみたらわかりますか?
教えてくんですんません。
>>67-71 あー、激しく誤読してた。
>利用者証明書の有効期間が切れると、その証明書の失効情報
>はCRLから削除されます。(これはX.509やRFCで規定された仕様です)
CRLの発行をやめる、とは書いてませんよね。
失効情報が削除される、と。
(2) 推測
だから、Verisignは、そいつ絡みの失効リスト、
Class3SoftwarePublishers.crl
を失効後対応の、失効リストが空のものに更新した。
てことかな。
失効後に参照されるべき次バージョンの証明書の名前を変えた上に 配布鯖まで変えてしまったから、参照元が混乱したってのもあるのでは?
鈴木さんに連絡取りたいのに結婚して佐藤さんになって引っ越してしまってて手がかりなしたって事だよ。
>>74 そんな事実はないと思うんだが。
具体的に説明して欲しい。
>>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)を所定の場所に公開する。
実際には、所定の場所は証明書自身に書かれているので、利用者がそこから取ってくる、というわけだ。
>>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 に有効期限が切れたという(笑)
注:上記の内容は、お使いの環境によって異なる可能性があります。
*:.。..。.:*・゚(n‘∀‘)η゚・*:.。..。.:*!!!☆ 生暖かく見守ってまつ。VeriSignガンバレ〜!
>>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 に切れてるんだけどね(笑)。
有効期限切れの証明書は、そもそもCRL引くまでもなく期限切れで無効。 なのにCRLわざわざ引く、ってのは無駄なだけじゃないのかな。 CAはこの先、期限切れの証明書のCRLを永遠に提供しつづけなければいけないのかな。 CRL 配布ポイントが指定されているからっといって、必ず即座にそこからCRLが取れる、とは限らない。 最新のCRLが取れなかった場合の大域的な処理を考えんといかんのだろうね。 ところで期限切れ証明書のCRLを取りに行こうとしているのは ノートンなんだか。MS-CAPIなんだか。 どっちなんでしょうね。
84 :
名無しさん@お腹いっぱい。 :04/01/12 00:08
NAV2002/NIS2002はどの証明書で署名されてるんだろ? 恐れ入りますが、誰か調べてみてくんない?
>>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
>>85 あがとりい。
ついでに有効期限と「シリアル番号」ってのも教えてくんない?
いや
電子証明書のね。
でも見に行ってるCRLは2003と同じっぽいな。
2002で起動遅いって人は、
ieの「発行元証明書」のとこはどうしてるんだろう。
>>85 あと、
ノートン関連でタイムスタンプが2001年のEXEかDLLがあれば
それの証明書も確認していただければ。
>>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
>>88 本当にありがとう。
2002年の署名の方は2003と同じ証明書ですね。
ということは、署名されたプログラムが出てくる局面によっては
2003と同じ問題が起きていた可能性はあります。
でも、今はその証明書のCRLもスムーズに取れるみたいだから
NIS2002が今なお起動が重い、という問題とは関係なさそうです。
2001年の署名の証明書はCRL配布ポイントなしですか。
じゃあ関係なさそうだ。
これが(多分)最後のお願いです。
その署名のルート証明書のシリアル教えてもらえませんか?
すんまそん。
>>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
>>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
であると。
ご協力に感謝します。
でも、両方とももう切れてるんだよね。
すがる思いでここに辿り着きますた_| ̄|○
http://www.verisign.co.jp/server/help/faq/110089/index.html ここを見ながら証明書の更新とやらをしようと思ったんですけど
[Step 2:グローバル・サーバID導入サイトへの接続確認]のBの通りに
[証明書]ボタンをクリックしても、警告音?とともに
【この種類のドキュメントには、セキュリティ証明書がありません】という
メッセが出るだけで、Cに進めません…なぜなんでしょう?
因みに、1/7までの証明書のバックアップを取らずに削除してしまったので
現在、証明書が入ってない状態です。
このスレは全部読みましたが私には全くチンプンカンプンです。
お手数ですが、どなたか対処法か、または解決法が分かる場所への誘導
おながいします。
>>93 そうでした(>▽<)ゞ テヘ!
私の不注意でお手数おかけしてすいません、ホントすいません、生まれて
すいません_| ̄|○
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 これなんかが多分そうなんじゃないかな。
だから、
本 来 は ユ ー ザ ー は 何 も し な く て も い い 。
>>96 「グローバル・サーバID用の中間CA局証明書」ていうのは
Windowsマシンの場合、ローカルに持っていたりもする。
そこにマシン上に有効なグローバル・サーバID用の中間CA局証明書があれば
たとえサーバー側がちゃんと更新してなくても自己解決で問題回避できる。
逆に、マシン上のグローバル・サーバID用の中間CA局証明書が古いままでも
ちゃんと更新しているサーバーには、なんの問題もなくアクセクできる。
(これは実際に確認してみた。)
ユ ー ザ ー 側 で の 更 新 は あ く ま で 保 険 的 な 自 己 防 衛 。
98 :
前スレ300 ◆w795LO9.Wo :04/01/12 12:31
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通信時の問題であって、今回のノートン激重とは直接関係ない。
だから、ノートンのユーザーがあわててこれに対処する必要はない。
逆に、慌てていろいろルート証明書を削除したりとかは
絶対にしてはいけない。
期 限 切 れ の 証 明 書 は 削 除 す る 必 要 は な い 。
逆 に 、 絶 対 に 削 除 し て は い け な い。
ご清聴ありがとうございました。ジエン終了(笑)
もう消したよ
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ファイルが出てこない。 これって結局、きっかけはシマンテックとベリサインだけど 本 当 に 悪 い の は マ イ ク ロ ソ フ ト じ ゃ な い か ! ?
>103 そりゃ、あんた、証明書のキーがレジストリの何処にあるか見りゃ一目瞭然でしょ。 Microsoftの下にあるのよ、Verisignの下じゃなくってさ。 おまけにルート証明、中間証明はそれぞれ個別のファイルじゃなく、 OS(IEかも)の1ファイルとして一纏めになってるんだから。 #このファイルをregsvr32で登録すると削除した期限切れ証明書も復活します。
>>104 オレが言いたいのは
「ルート証明書の期限切れになって初めてCRL取得に行く」
って動作が明らかにおかしいんじゃないか?
ってことなんだけど。
>105 期限切れにならなきゃCRLに載らない訳だから、 その動作は正しいんじゃないの? 切れる前に更新版が確実に出てるはずなんだから、 それを前もって取り込んでおけば、ある程度は回避出来たはず。
>>106 期限切れはCRL見るまでもなく無効。
だからCRLには載せる必要ない。
CRLは「期限内だけど失効させたい証明書」のブラックリスト。
本来は有効期限内に見ないといけないもの。
難しいお話中すいません92です。
>>100 :前スレ300さんの予想通り、窓の杜の記事↓を見て今回のことを
http://www.forest.impress.co.jp/article/2004/01/09/verisign.html 知りました。で、お陰で新証明書も取得できたんですが、その後もここを
ROMってたら…
>!注意!本来ユーザーは何もしなくて良い_| ̄|○
>!重要!古い証明書は絶対に削除してはいけない_| ̄|○
>#このファイルをregsvr32で登録すると削除した期限切れ証明書も復活
>します
相変わらずチンプンカンプン…ララァ、私を導いてくれ_| ̄|○
結局、サーバー管理者ではなく・ユーザー側で・古い証明書を削除済みで・PC
の知識も無い私は今後どうすれば、、、。
スマンテック社員が責任転嫁に必死なスレはここですね。
別に削除する前に証明書をバックアップしてるなら、いつでも戻せるだろ。
111 :
名無しさん@お腹いっぱい。 :04/01/12 21:04
>105 > 「ルート証明書の期限切れになって初めてCRL取得に行く」 > って動作が明らかにおかしいんじゃないか? NAVの件で言えば、 「持ってたCRLの有効期限が切れたので新しいCRLを取得に行った」です。
112 :
名無しさん@お腹いっぱい。 :04/01/12 21:12
113 :
名無しさん@お腹いっぱい。 :04/01/12 21:15
あと、更新した中間CA証明書についてですが、 公開鍵とサブジェクトが同じだからクライアント側の動作には 特に問題ないのかなぁとも思ったりする。 そして、証明書を更新するのに鍵ペアは更新しないっていう VeriSignはどうかと思う。 中間CAに限らず、ルートCA証明書の更新についても同じ扱いだね。ベリ。
(゚д゚)エー!? 期限切れ証明書、削除しちゃいけなかったの!?
>>111-113 なるほどー。
例の「発行ミス証明書」対応かなんかで
最低限それに関わるCRLだけデフォルトで持たせてる
ってことかな?
しかしそれだと2001/03/24〜2004/01/08の間に失効したかもしれない
他の証明書は一切チェックできないわけだよね。
でも、勉強になりました。ありがとうございました。
116 :
名無しさん@お腹いっぱい。 :04/01/12 22:18
つまりユーザー側はwindowsUpdateでルート証明書の更新をしさえすればいいというわけですか? つーことわアンインストールしてweb見れる隙に更新し、それから再インストールでもいいわけですか? つーか俺、httpsのところしか見れなかったんだけど、そういうのもあり?
∩_ ∩ ( ・ ω ・ )
∩ ∩ ( ・ ω ・ )
∩_ ∩ ( ・ ω ・ ) し つ | |
∩_ ∩ ( ・ ω ・ ) と つ | |
∩_ ∩ ( ・ ω ・ ) 。 と つ目゚ | |
∩_ ∩ ( ・ ω ・ ) 。 と つ目゚ | |
∩_ ∩ ( ・ ω ・ ) 。 と つ目゚ | |
∩_ ∩ ( ・ ω ・ ) 。 と つ目゚ | |
125 :
前スレ300 ◆w795LO9.Wo :04/01/12 23:58
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取得のアクセスがあり、あぼーんしてしまうのだろうか。
>>127 ということは、やはり本件はSymantec側のテスト不足 or 仕様が糞のどちらかでFAでしょうか
129 :
名無しさん@お腹いっぱい。 :04/01/13 03:58
ごめん。 よく考えてみると、どこぞのあほうに騙されて証明書を発行したベリが一番悪い。 それが本件の根本的な原因。 対応し切れなかったNAVも悪いが、まぁ被害者と言えなくもないと思う。
130 :
名無しさん@お腹いっぱい。 :04/01/13 04:00
>>126 見てます。スルーされても仕方ないようなところ、ワザワザありがdございますた
>>127 >>103 に書いたけど、オレ、ノートンない環境で
コード署名の確認だけでCRL取得に行くの確認したつもりなんだ。
ノートン自身も独自でCRL取得してるのかもしれないけど
少なくとも、右クリックの遅延は
右クリックされた時点で、Windowsがノートンの対応モジュール
NAVSHEXT.DLL のコード署名を確認しようとしてCRL取得が発生
と分析しました。
NAVSHEXT.DLL は 2002 では署名なし、2004では別のCRL配布ポイントなのと
絶対数が2003より少ないので、
被害が2003に集中したのでは?と。
まだ疑念だらけの推理ですけどね。
ご意見など頂ければ幸いです。
オレは、誰が悪いのか、ってのより
新の原因は何なのか?の方に興味があって粘着してます。
>>132 アホや。
「真の原因」やね。
まあ、
>>129 名前:名無しさん@お腹いっぱい。[] 投稿日:04/01/13 03:58
>ごめん。
>よく考えてみると、どこぞのあほうに騙されて証明書を発行したベリが一番悪い。
>それが本件の根本的な原因。
>対応し切れなかったNAVも悪いが、まぁ被害者と言えなくもないと思う。
これには全面的に同感です。
1/8事件では結局その日のうちに対応してしまったんだが いまだに調査中で根本対応ができてないのがMSとSymantecなのはどうかと 祭りが面白くて当日は明け方まで貼りついていた自分って
135 :
名無しさん@お腹いっぱい。 :04/01/13 17:42
タスクトレイのノートンとスタート右クリのエクスプローラで アウポがどうするか聞いてくるんだがどうすりゃイイ?
好きにすれ
>>134 祭りが終わった今でも、オレ的にはいろいろ新発見が続いてるんだけど
もう祭りは終わってるから…。
でも、この5日ほどで過去一年分以上勉強した気がするよ。
*アクセス制限中に他所の板に書いた内容をここにもコピペしとこうかね
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ならあまり気にすることはない
----- こんなもんでしょうか -----
>>137 ・問題の Class3SoftwarePublishers.crl に対応するCRLを、Windowsがこっそり内蔵していた。
・おまけに↑の有効期限は2001/03/24〜2004/01/08 8:59:59(JST)という長大なもの。
・右クリだけでCRL取りに行くには2003のみ。2002と2004では起きない。
・そもそも2002の構成ファイルの多くは電子署名されていない。
・どうもWindowsのコード署名の確認では、証明書の有効期限が切れていてもCRLを取りに行く事があるようだ。
てあたりが祭り以降にわかったこと。
2002でも署名確認するモジュールをLiveUpdateで仕込まれてるらしい
>>140 >2002でも署名確認するモジュールをLiveUpdateで仕込まれてるらしい
ていうことですよね。
であれば、今まだ続いているらしい
NIS2002の起動/終了時にCRL取得が飛ぶ、
って問題も説明がつく。
ただわからんのがなんで毎回見に行くのか、ということ。
通信を許可してやれば、ちゃんとCRL取得して
有効なものがキャッシュに残ってたら見に行かないはずなのに。
キャッシュ強制的に消したりしてるのかな?
NAV2003でつが、一応KPFでVeriSign許可してログ取ってまつ ログ見てみると、1日1回程度の頻度でNMAIN.EXEがアクセス 20分置きぐらいの間隔でEXPLORER.EXEがアクセス(右クリの頻度とは関係なさそう VeriSign遮断して取消チェック外しても実際何の支障もないので、いずれ遮断することになるでしょう
>>142 さん
なんてファイル持ってきてるかまでわかります?
例の Class3SoftwarePublishers.crl ですか?
>>144 上のは始めてみる名前だけど、700Kもあるで。おいおい。
下のはやっぱ例の奴ですな。
でも、どっちも現状有効期限内なのに
実際取り直しているのなら、ちょっとアホっぽい。
ピーガー・モデムやPHSカードで通信している人には辛いっぽい。
あるときNAV2003がLiveUpdateで仕込まれてから、勝手にVeriSignに接続しるようになったわけで CDから再インスコし直しても、レジスト時に現行モジュールに書き換えられるようでつ NISスレで見た限りでは、2002もごく最近同じものを仕込まれたそうで
普通はHTTP Headメソッド辺りで属性見るところを HTTP Getで内容全部取ってるのではなかろうかと
>>146 「あるとき」ってのは2004/01/08 9:00よりも前のあるときですか?
>>148 原本のCD-ROMの最終タイムスタンプは2002/12/10かそこら(発売日よりは前のはず
\Program Files\Common Files\Symantec Sharedにある、現在のcc*.exeの最終タイムスタンプが2003/05/23
つまり2003/05/23以後に仕込まれたということですな
151 :
名無しさん@お腹いっぱい。 :04/01/14 01:19
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を取りに行くことになる。
ほんまに大丈夫なんかいな?
>>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
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にしてくれ。 と開き直られるかもしれんヨカン。
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
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日なんですが。
>>169 98SEマシンのIEのバージョンはいくつくらいですか?
171 :
名無しさん@お腹いっぱい。 :04/01/14 17:33
173 :
名無しさん@お腹いっぱい。 :04/01/14 19:32
>>169-171 うーん。会社のほうは会社が crl.verisign.com をブロックしているのかも。
ご自宅のほうの「ここに書かれている状況」ってのは
具体的にはどうですか?右クリ重とか?
基本的には激重は解消していて、
時々右クリがやや重いことあり、てな感じだと思うけど。今は。
174 :
前スレ300 ◆w795LO9.Wo :04/01/14 20:00
175 :
前スレ300 ◆w795LO9.Wo :04/01/15 02:02
ついでにもうひとつ
>>103 のオレの間違いについて。
>おまけに、ここからが大事。
>「ルートの証明書の期限が切れてからでないとCRLを取りに行かない」
>それも後者の手順で表示させた時にしかキャッシュにCRLが出てこないんだ。
>これは明らかにおかしい。
これは、ルートの証明書の期限とは関係なく
>>125 あたりの事情で「内蔵されていたCRLが切れたので、新しいCRLを取りに行った」ということ。たまたまルート証明書の期限切れと、内蔵されていたCRLの次回更新予定日とが一致していただけ、ということのようだ。
(でも、これはきっと「たまたま」ではないだろう)
今日わかったことのまとめ。 ・コード署名は、タイムスタンプがあれば証明書の有効期限切れ後でも有効という仕様。 ・だから、証明書の期限切れ後にCRLを参照するのも仕様通りの動作。 ・ベリサインは、証明書の有効期間内はCRLを毎日更新する。 ・CRLでは「有効期間の終了日」ではなく「次の更新予定日」。 (一度失効したものが復活することはない。次の更新予定日を過ぎれば「新しいCRLがあること」が期待できるということで、内容自体が無効になるわけではない。) ・だ か ら 「CRLが失効」 す る わ け で は な い。 ・X.509の仕様では、CRLは次の更新予定日までにちゃんと出さないといけないことになっている。
相変わらずオレのジサクジエンというか一人相撲というかジイコウイ爆発!だけど 一応スレタイ通りの内容になってはきているような。
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確認自体を止めるか、でしょうね。
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ならあまり気にすることはない
----- こんなもんでしょうか -----
ちなみにMTT-ME BA6000、Kerio PFW 2.1.5、NAV2003の条件下の話でつ
しかしアンチウィルスのモジュールが書き変えられる条件って割れ以外に考えられないが 本当に外部から改竄されるようじゃ、セキュリティ以前の問題じゃなかろうか あ!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
186 :
前スレ300 ◆w795LO9.Wo :04/01/15 22:34
協力したいが、目ぼしい所でIntelやApple、 はたまたVeriSignの物まで署名付きの物は見つからない。
あ、この調査の狙いは
「コード署名なんて実際にはノートン以外にはめったにないのではないか?」
という仮説立証のための情報収集です。
だって、コード署名って証明書一つに付き年間9万円かかるんだよ。年間。
おまけにベリは
http://www.verisign.co.jp/codesign/help/faq/200019/index.html Q>コードサニング証明書はどのような単位で取得する必要がありますか。
A>部門(Division)および製品などの単位で取得してください。
コードサイニング証明書を申請する際には、証明書の情報として 組織名(Organizational)及び 部門(Division)を指定します。
部門・部署単位等、証明書の管理責任を負える単位で取得してください。
などと仰っているし。
特定アプリについての「なかった報告」も募集。 メーカー/ソフト名/バージョン/グレード等 なかった。 てな感じ。
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万くらいかかるでしょ。年間。
NAV2002ですが、以下の手順で crl.verisign.com へのアクセスを行うことを確認できます。 (1) NIS2002などで、crl.verisign.com へのアクセスを監視するように設定 (2) IE でインターネット一時ファイルを削除 (3) NAV2002 のタスクトレイアイコンをダブルクリック これで crl.verisign.com へアクセスします。 一度アクセスすれば、再度、タスクトレイアイコンをダブルクリックしても インターネット一時ファイルにキャッシュされているCRLを使用しますので、 アクセスには行きません。 インターネット一時ファイルを削除した後、(3) をすれば、また、アクセスにいきます。
>>196 この件で、たとえば、4月10日までにベリサインがCRLを更新しなかった場合
どうなるかというと、
(1) 4月11日に NAV2002のタスクトレイアイコンをダブルクリック
↓
(2) Windows はキャッシュのCRLが、次回更新日時を過ぎていることを
確認すると、そのCRLは使用せず、新しいCRLを取得しようとします。
Windowsは、ベリサインのサイトからCRLを取得してキャッシュに入れます。
しかし、次回更新日時を過ぎたままです。
↓
(3) 再度、タスクトレイアイコンをダブルクリック。
↓
(4) (2) の動作が再び実行。
という感じになります。
NAV2003の場合は、ダブルクリックが右クリックになるわけですね。
今日思ったこと。
・Windows自体は、コード署名の確認は、WEBから持ってきた実行可能ファイルを実行したり、直接インストールしようとした時にくらいしかチェックしていないっぽい。
・だってFW入れてる人。ノートンの特定のファイルからしかcrl呼び出し無いんでしょ?
・だから、システム内での通常の動作でコード署名が確認されているのなら、それはOSじゃなくアプリ自身がやっている可能性が高いんじゃないか?
・例えば、自分とこのモジュールだけど、別実行ファイルや別DLLになっているものを呼ぶときに、時々自分でチェックしている、とか。
・例えば、システムの起動時とか、終了時とか。なぜか右クリックの時とか(笑)。
・でもって、改竄とかされてると
>>194 で紹介されているようなメッセージが出たりとかするのでは?
・(モジュール改竄テストはやってみたんだけど、うまくエラーが起こせなかった。)
・これがいわゆる
『プログラムのセキュリティ維持のため、シマンテック製品は定期的にシステムコンポーネントの整合性を確認する作業を行っていますが』
ってやつなのかな?と。
・コード署名のCRLなんか無視してもよさそうだけど、サーバー証明書は話が別!
・ならいっそ、CRLテストは有効にして、コード署名のルート証明書消しちゃうか(暴論)?
>>197 コンピューターの時計を4月10日以降に進めると、遅延発生が実験できますよ。
オレやってみたけど。
NAV2003だと、なつかしの右クリ重が。
あの日ほどの激重ではないけど
クリるたび反応が重い。
2ちゃんねるを見ているよい子は絶対に真似しちゃだめだよ。
Don't try this at home.
>>195 少なくとも2003は、今日のLiveUpdateでccと名の付くモジュールの署名は別のものになったので
そいつは、現在も毎日更新されているCRLを見に行きます。
ベリがパワーを10倍に増やした、というのを信じれば(笑)
1/8ほどひどいことにはならないかもしれません。
あと、4/10は土曜日なので
閉まっているオフィスも多いかも。
今、自動的に指定フォルダ以下から、署名のあるファイルを見つけてくるスクリプトを構想中。 本当は署名の内容まで確認できればいいんだけど。 どっとねっとだとできるんかな?
>>190 java関連の署名は、MS仕様のコード署名とは別の、
ベリサインが言うところの「オブジェクト署名」ってのを使うようです。
これにはタイムスタンプ機能が無いため、
オブジェクトの署名の有効期限=証明書の有効期限
ってことになっちゃうみたいですね。
電子政府関係も、いまのところ各省庁の足並みがバラバラで
java使うところも、省ごとで指定のJREのバージョンが違ってたり平気でします。
おまけに、法務省の登記情報閲覧サービスなんか
なんと今やレア・アイテム化したMSVM限定です。
なんとさらにSUNのVMには未対応です(笑)
MS仕様のコード署名について タイムスタンプをサポートしているのはベリサインだけ と豪語してますから、MSのコード署名を使うなら、ふつーベリサイン ってことにしかならないかも。 だって署名の有効期限を気にしなくていいわけだから。 でも、WEBから直、実行ファイルを撒くという 本来コード署名が想定している使い方以外で わざわざ金払ってコード署名使おう、なんて奇特な人も少ないかも。 シマンテックぐらいか(笑) でもさらに。.net framework では、システムにインストールするモジュールには すべて署名が入ってないといかんそうです。 そりゃ大変だ。もういっつも証明書の有効性確認しまくりかも。 (ここいらは事実誤認の危険性あり。)
204 :
名無しさん@お腹いっぱい。 :04/01/16 03:18
> おまけに、法務省の登記情報閲覧サービスなんか > なんと今やレア・アイテム化したMSVM限定です。 > なんとさらにSUNのVMには未対応です(笑) クライアント端末には極力なにもインストールさせたくないという 要件があるんでしょう。
206 :
名無しさん@お腹いっぱい。 :04/01/16 03:38
すねてないでMSVM続投してくださいよ>MS
サポート終了が延期されてほっとした人たち多数だと思います。
あと、
>>190 を見るとどうもSunJVMはCAPI未対応らしい。
なので、1月8日問題は起こらなかったが
>>190 みたいな事が起こると。
どっちもどっちだと思いたいよ私は。
あ、もしかしてMSVM継続配給のために Windows98/Meのサポート延長したのか(笑)? (んなわけはない。) まあ裁判からみだから仕方あんめえなぁ>MSVM終了
208 :
名無しさん@お腹いっぱい。 :04/01/16 03:43
209 :
名無しさん@お腹いっぱい。 :04/01/16 03:46
MS:みんながぶーぶー言うならMSVMなんてもうやめてやらぁあほー みんな:急にやめられたら対応しきれねぇだろー。(違う意味でぶーぶー) MS:(それみたことか)じゃサポートだけはちょっと伸ばしてやるぞよぞよ。 みんな:ちょっと安心 MS:でも再配布なんてしてやらんもんねー。 みんな:(やれやれ)
>>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 おお、いろいろと情報が。
一番最初の、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日問題での対処法で「確認を取り消す」にしたまま ネットで買い物しても平気なんでしょうか?
試しにCRLの日付をパッチしてみた。 Wクリで表示できたので「やった!」と思って 組み込んで確認してみたら…だめだった。 そりゃ署名入ってたら改竄できんわなぁ、普通…。
>>218 とにかく慎重にいくのであれば
重くても我慢して「確認する」で使うか。
https:// のサイトで買い物する前後で手動でON/OFFするか、
でしょうな。
セキュリティに関しては「大丈夫」とか「危険はほとんどない」とか
他人には、さしたる根拠も無しには言えないからなあ。
あくまで自分の判断で
わかんなければ安全な方に振るしかない。
とりあえず一番安全なのは、重くても我慢して「確認する」で使う
もしくはパソコンの電源を入れない。
買い物専用のユーザアカウント立てるよろし セキュ最優先で、余計な権限は与えない
223 :
名無しさん@お腹いっぱい。 :04/01/17 21:37
人間の証明
>>222 >買い物専用のユーザアカウント立てるよろし
>セキュ最優先で、余計な権限は与えない
あ、それいいアイディアですね。
お気に入りも買い物系はそっちだけに登録して。
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
228 :
前スレ300 ◆w795LO9.Wo :04/01/18 11:55
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の偽造にもチャレンジしてみたけど、さすがに駄目だったし。 なんとかしてくれないかなぁ……。
NIS2002起動遅延の改善テスト 準備編(1)〜「証明書」ツールの起動アイコン作成 (1) [ファイル名を指定して実行]で mmc と入力して起動。 (2) [コンソール]→[スナップインの追加と削除]を選択する。 (3) [追加]から、一番下あたりにある「証明書」を選択する。 (4) デフォルトの[ユーザーアカウント]のままで[完了]を選択する。 (5) [OK]でスナップインの追加と削除を終了する。 (6) コンソールルート配下に「証明書」が追加されていることを確認する。 (7) [コンソール]→[名前を付けて保存]で、デスクトップに「証明書.msc」を選択する。 (8) デスクトップに「証明書.msc」という金鎚アイコンが出来ていれば準備完了。 #WinXPで実行する際、(2)と(7)の [コンソール] は [ファイル] に読み替えです。
準備編(2)〜インストール済CRLのバックアップ&削除 (1) 「証明書.msc」を実行して証明書ツールを起動する。 (2) [中間証明機関]の[証明書失効リスト]を開く。 (3) 「VeriSign Commercial Software Publishers CA」というのが1つだけあるはずなのを確認する。 (4) それを右クリックして[すべてのタスク]→[エクスポート]を選択し、適当な名前でエクスポートする。(例えば verims040107.crl とか。) (5) きちんとエクスポートできているのを確認したら、証明書ツール上のさっきのCRLを右クリックメニューから削除する。
入替え編〜新しいCRLを取得&インストール
(1)
http://crl.verisign.com/Class3SoftwarePublishers.crl にアクセスして、名前を付けて保存する。
(2) 保存した Class3SoftwarePublishers.crl をダブルクリックで開いて「次の更新予定」が2004/04くらいなのを確認して[OK]で閉じる。
(3) 保存した Class3SoftwarePublishers.crl を右クリック→[インストール]で、言われるがままにデフォルトでインストールする。
(4) 証明書ツールで、新しい有効期限のCRLが登録されていることを確認する。
(5) システムを再起動して、起動時間が改善したかどうか確認する。
233-235をやってみた所元に戻ったようだ。 DLしたClass3SoftwarePublishers.crlは 各ユーザごとにインストールする必要があるかも?
237 :
前スレ300 ◆w795LO9.Wo :04/01/24 12:53
>>236 ご指摘のとおりです。
今のやり方だとアカウント固有になっちゃいます。
各ユーザーごとにイントールする必要があります。
少しやり方を考えてみます。
あと、ずっと直るわけではなく、
インストールしたCRLの次回更新日までの命なので、ご注意を。
>>232 >とりあえず、MSが仕込んでるCRL自体と同じ内容で、
>期限をさらに3年間くらい延長したものを出してはもらえないか、
>ダメモトでベリサインのサポートにメールしてみるよ。
というわけで、本当にメールしました。
どうなるかな。
239 :
名無しさん@お腹いっぱい。 :04/01/24 13:33
98SE、NAV2003だとどうするか、だれか知りませんか〜
241 :
前スレ300 ◆w795LO9.Wo :04/01/24 19:18
誰か自己解凍&実行CABファイルから中身を取り出す なるべく簡単な方法知りませんか?
実行形式はWinRARで展開できることがあるけど シェアで試用期間あったかどうだか
>>234 の
>(2) [中間証明機関]の[証明書失効リスト]を開く。
個人だの中間証明機関とかあるとこの一番下の方が
文字化けして読めないのは自分だけですかね
なんか気になるのでだれか教えてください。
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
>>240 > 98SE、NAV2003だとどうするか、だれか知りませんか〜
>>245-246 を試してみて、結果を教えていただけませんか?
遅レスすみません。 前スレ300 ◆w795LO9.Woさん、いろいろありがとうございます。 ご指示のとおりやってみましたが、残念ながら、コマンドエラーとなります。 crlupd.exeをダウンロード・実行しても同じでした_| ̄|○ 今日のところは、もう寝ます。 明日また試してみます。うまくいったら、また報告しますので。
>>249 本当だ。化けてますね。
証明書ストアが壊れてるんだろうか。
IEの修復セットアップとかしたら直るのかなぁ。
ちょっと見当がつかないや、ごめんなさい。
>>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 をダウンロード&実施。
>>250 > ご指示のとおりやってみましたが、残念ながら、コマンドエラーとなります。
> crlupd.exeをダウンロード・実行しても同じでした_| ̄|○
すんません。Windows98はデフォルトでは Windows\System にはパス通ってませんでした。
だからフルパスでコマンド叩く必要があります。
>>252 が改訂版ですんで、また試してみてください。
>>254 さん
起きていてよかった。ありがとうございます。<(_ _)>
どうやらうまくいきました。
ついでに貴サイトにもうかがいました。
なんつうか…巨大ベンダー三竦みって感じですかね…( ;^^)へ..
どれが蛇かな…
ついでに254、255もコピペして保存させていただきました。
無期限CRL、スパッとだして欲しいもんすね…
とにかくありがとうございました。
>>256 >>240 さん。うまくいきましたか。よかったよかった。
「充分に長い期限のCRL」(例えば2049年12月31日まで)とかがもし出れば
これはもう事実上無期限と言ってかまわんだろう、ということで
勝手に「無期限CRL」と呼んでいます。
ノートン自身やWindowsの寿命のことを考えると、
実際にはあと3年位でも大丈夫かな?と思います。
>>254-255 は、まだ単なる自分自身への覚え書きです。
「(3) もう一度 crlupd.exe を作り直す。 」と簡単に書いてますが
具体的な手順はワタシ自身まだちゃんと見えてません。
普通に使う分には、わざわざパッチを作らなくても
例のCRLインストールの手順で、無期限CRLをインストールすれば
それでOKになります。
無期限CRLの偽造にもチャレンジしてみましたが、やはり無理でした。
そんなことが出来るようでは、セキュリティじゃないですからね。
>無期限CRLの偽造 ……あはは……
(1) 最も望ましいのは原因側による正しい対応。 (プログラムのアップデート等) (2) 次に望ましいのは原因側による有効な対応。 (動作に関連する環境の変更等) (3) どちらもダメなら自己解決。 というわけで、 (1) シマンテックが問題個所を直す (2) ベリサインまたはMSが内蔵CRLの期限を延長する (3) うまくいく設定や手順を探す の(3)の一環です>偽造にチャレンジ でも、あくまでこれは緊急避難です。 (1)か(2)が実施されれば必要ないわけですから。 すみません。わたくし嘘を申しておりました。 面白そうだからやってみました。
wwww
NAS以外の製品に乗り換えるのが一番だろう。
(4)パッチ当て という奥の手も…
263 :
名無しさん@お腹いっぱい。 :04/01/26 01:46
いや久々にhacking魂を見せてもらった気がする。 乗りかかった船なもんでしょうがねえってんで 挙句「面白そうだからやってみました」。 惚れるねえ。
いやいや、「しょうがえ」ってな義務感だけでは出来ないですよ。 「面白い」という気持ちがないと続かない。 実際、面白かったですから(笑) だから、自分としてはもう困っていないので 飽きたらやめちゃうかもしれない。 少なくとも、ベリからなんらかの返事貰うまではやめませんけど。 でも本当に勉強になりましたよ。 ベリのCPSは読むわ X.509の仕様は読むわ いくつか頑張って英文ドキュメント読むわ 仕事もこれくらい真面目にすれば……ねぇ(苦笑)
>仕事もこれくらい真面目にすれば……ねぇ(苦笑) まったくですねwww なぜこういうことには、スイッチが入るのか? ついでにこれも究明してほすいwww
268 :
前スレ300 ◆w795LO9.Wo :04/01/26 18:16
>>238 >
>>232 > というわけで、本当にメールしました。
> どうなるかな。
さっき見たら、ベリサインからメールが来てました!
件名:【日本ベリサイン】『実践ハッキングおよび防衛術習得トレーニング』のお知らせ
【注】本メールは、ベリサインからの情報配信を希望されたお客様にのみお送りしています。
ああああ。そういやだいぶ前に希望してた事あったような気がする。
とはいえ、すげえタイミングで来たもんだな(笑)。
CRLをハックしようとしてたのがバレたか!?
>268 ( ・∀)人(∀・ )通報しますた!
>>268 いえいえ。実はそのメールの前に、ちゃんと一次回答が来てました。
カスタマーサービスの方からで、簡単にまとめれば
・担当者が詳細の確認をする。
・担当から返信がある。
・時間はかかる。
というような内容でした。
問い合わせ番号も付いてました。
とりあえずは、見てはもらった、と言うことですね。
これからどうなるのかが楽しみです。
272 :
前スレ300 ◆w795LO9.Wo :04/01/29 02:23
Class3SoftwarePublishers.crl 27-Jan-2004 17:43 119k 27日に更新あり。 もしや?と思いダウンロードして開いてみるが 次回更新日が5月1日になってるだけ。 なーんだ。
しかし Class3SoftwarePublishers.crl は なんでいつも半端な時間に更新してるんだろう。 他が午前3時でほぼ揃っているだけに、なんか気になる。
>273 無効になったり期限が切れたりする証明書が出たときに、 その都度出してるんじゃないの? てか、Liveうpだてみたいに自動でcrlうpだてしてくれるスクリプトでも作った方がいくない?
>>274 > >273
> 無効になったり期限が切れたりする証明書が出たときに、
> その都度出してるんじゃないの?
現在、当方の調査によると、
http://crl.verisign.com/Class3SoftwarePublishers.crl は、
次回更新日まで約3ヶ月後のものが、ほぼ1週間ごとに更新されていたようです。
ですけど今回は、24日→27日と、それより短い間隔で出ました。
> てか、Liveうpだてみたいに自動でcrlうpだてしてくれるスクリプトでも作った方がいくない?
それは考えてはいます。
今後ベリサインがなんも対応しなかったら
真剣に作ろうと思ってます、はい。
>275 >次回更新日まで約3ヶ月後のものが、ほぼ1週間ごとに更新されていたようです。 >ですけど今回は、24日→27日と、それより短い間隔で出ました。 この3日間で緊急を要する失効があったとか。 >今後ベリサインがなんも対応しなかったら >真剣に作ろうと思ってます、はい。 作りがアレでDoSツールになってしまうワナw
窓の杜を見て、あっさりバックアップも取らずに証明書を削除して入れ直したのですが、 「www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign」と、その一つ上のClass 2〜と言うのも一緒に削除してしまいました。 前者は日本ベリサインから入れ直す事ができましたが、後者は名前もはっきりせず、 どれを入れ直せばいいのやらわかりません。 どなたか教えてください・・。orz
>>276 > この3日間で緊急を要する失効があったとか。
サイズが同じで変わってません。
コンペアもかけてみましたが
どうやら同じ内容と思われます。
> 作りがアレでDoSツールになってしまうワナw
わはは。それはあるかもw
>>277 ルート証明書じゃなくて中間証明機関なら
無くても特に致命的ではないかも。
ルート証明書なら、「ルート証明書の更新」で
古いものも元に戻ったと思う。
別のマシンがあるなら、
そいつから無さげなやつをエクスポートしてきて
インポートするといいです。
コピー&ペーストが「コピペ」なら
エクスポート&インポートは「Xインポ」?
>>279 > ルート証明書なら、「ルート証明書の更新」で
正確にはWindiws Update の
「ルート証明書のアップデート」ね。
>>279-280 レスありがとうございます。
別のマシンも持ってない為、ベリサインからそれらしい物をDLしてインポートしてみたり、
IEの再インストールもやってみましたが復活しません・・・。
色々検索してみた結果、ルート証明書ではなく、
中間証明書の「VeriSign Class 2 CA Individual Subscriber-Persona Not Validated」っぽい気がします。
期限が件の中間証明書と近い2004/01/07あたりだったのを理由に削除したのですが、
もう必要ない物だったんでしょうか?
>>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.〜は元々期限切れで必要無いかと。 またアメリカとカナダの住民しかインストールできないとか。
3か月分の奴しか出してくれないのかよ。 ケチだなぁ、ベリ公。
今日、接続時に↓こんなの拾いますた。 RSASecureServer.crl
オトモダチの薬剤師のお姉さまが、向精神薬とか処方する度に同じようなこと言われるそうだ
漏れの知ってるおばちゃん(!)の薬局には かなりキてるそうなあんちゃんが「ブロン」箱買いに来るらしい
>>282 あー、やっぱりそんな感じの名前の奴ですよね。
>>283 では、特に気にしなくていいのかな・・・。
普段あんまりいじらない所なのでさっぱりで。
お二人ともレスありがとん。
上の方で期限が切れた物も必要とかなんとかってレスがあったので少し気になってましたが、
そんなに気にしなくていいのかな。
>>286 これ2028/08/02まで、一気に期限が延びたね。
293 :
名無しさん@お腹いっぱい。 :04/01/30 19:50
NIS2002ユーザーですが、有効な証明書をインストール出来ず困って います。 日本べリサイン(tps://)から証明書をインストールしたら「中間証明機関」 ではなく、「ほかの人」にインストールされてしまいます。 又、その証明書の詳細を確認すると「内容不明でエラー」となっていました。 NIS2002で有効な証明書のインストールに成功された方、手順を教えて 頂けないでしょうか。 お願いします。
294 :
名無しさん@お腹いっぱい。 :04/01/31 06:30
このスレいつまで続くの?
NAVのウイルス定義に含まれるDLLから証明書をインポートしてもいいかも。 もちろん最新版(現在インテリの1/30付けが最新)からね。
>>293 今回インストールされた証明書は
中間証明機関でも、失効でもなくて
信頼された証明書としてインストールされてるよ。
Liveupdateや、シマンテックの説明通りにインストールしたなら大丈夫だろ。
未だに何の問題も解決出来ていないのは漏れだけなのでしょうか…
>>286 のURLの通りに証明書をインポートしたもののまったく何の変化もなし。
相変わらずWordはファイル開こうとすると落ちるし、
Norton AntiVirus 2003の定義ファイルもエラーのまま…などなど。
本当にNortonが原因かも怪しく思えてきた。ワケワカンネーヨ。・゜・(/Д`)・゜・。
>286の方法、acceptをクリックした後ダウンロードできませんと言われてしまう... IE使用、FW停止、IEセキュリティ設定甘めでもだめぽ。
300 :
名無しさん@お腹いっぱい。 :04/02/01 14:31
>299の方 おかげで中間証明機関にインストール出来ました。 大変有用な情報提供、有難う御座いました。 ただし、NIS2002で「起動激重」「通知領域からアイコン消滅」等の 現象は改善されませんでした。 NIS2002で改善に成功された方、手順を教えて頂けませんでしょうか。
>>299 の方法も試してみたが変化なしだった。
ちゃんとインストールできていないんだろうか。
何が悪いんだろう…ついにエクスプローラーもうまく動かなくなってきたよ。
もうダメぽ・゜・(/Д`)・゜・
304 :
名無しさん@お腹いっぱい。 :04/02/02 12:00
>>300 NIS2003ですが、私も同じ状態です。
「起動激重」
「タスクトレイに、スタートアップ登録のアイコンが表示されず」
OSはXPです。
おひさし。
激重なみなさん。まず、
IEの詳細設定で「発行証明書の取り消しを確認する」のチェックを外してもダメ?
これやっても激重だとすれば、他に原因があるかも。
それで直るならCRL関連が原因だから
>>233-236 か
>>252 をお試しあれ。
>>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への対応はどうなんだ?と。
まぁ、日本法人に言ってもしゃあないよね。
回答してきたのはマーケティング部の課長だし。
頑張って英訳して、米ベリサインに直接突撃するしかないか。
まんどくさい。
>>305 「発行証明書の取り消しを確認する」のチェックを外しても激重です。
マウ筋なぞは、アイコンが表示されていないのに正常に動作したり、
スタートアップ関連に問題がありそうです。
Atokパレットが表示されないのが痛かったが、
ジャストシステムのサイトで解決できた。
とりあえず、プログラム→スタートアップ登録はランチャのみでしのぎます。
309 :
前スレ300 ◆w795LO9.Wo :04/02/02 15:06
>>309 ありがとうございます。
酔眼では厳しそうなので、明日にでも試してみます。
311 :
名無しさん@お腹いっぱい。 :04/02/03 09:00
NT系OSの場合、中間証明書は、ユーザー毎のストアにいれずに、 ローカルコンピュータのストアに入れて、ユーザーごとのストアは削除しましょうね
> ローカルコンピュータのストアに入れて、ユーザーごとのストアは削除しましょうね 詳しく
>312 ここの過去レスを参考にしてMMCの証明書ツールを開いている状態から 追加で対象がローカルコンピュータの証明書ツールを作る。 そうすると両者がツリー状に表示されるから ユーザー側の証明書をD&DでローカルPC側にコピる。 削除するか?って聞かれたらNOにしておいた方がいいと思う。
>>309 改善しました。
OS再インスコも思慮していただけに、感謝。
>>314 >
>>309 > 改善しました。
結局どっちが効いたの?
組み込みタイミングの調整の方かな?
>>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
319 :
前スレ300 ◆w795LO9.Wo :04/02/04 00:59
>>318 それでもいいし
男らしくいきなり「開く」から「証明書のインストール」してもかまわない(笑)。
何度も書くが、シマンテックはそんなこと書いているけど
ベリサインのルート証明書の失効は
今回の件とは全く関係ないと思うよ。
まぁ更新自体はやっておいたほうがいいと思うけど。
>>315 スタートアップ、タスクトレイ表示の不安定に関しては、
「組み込みタイミングの調整」が有効でした。
NIS2003の起動が遅くなった件は、改善していません。
当該PCは、EPSON製Me→XPにUPしたもの。
ただし、少なくとも1月某日以前は不具合なし。
似たような使い方をしている、XPノートPCは、
某日以後、同様に不調となったものの、
このスレの情報等により、
NIS2003の起動を含め、漸次復調。
>>320 304さん。
気が向いたら、以下確認してみてくんない?
1、時計戻したら直りますか?
→直るようなら、やはり証明書かCRLの期限切れが原因。
2、crl.verisign.com への通信を止めていませんか?
3、ノートン関連のコンポーネントからの通信を遮断していませんか?
4、ノートン関連のコンポーネントが、どっかと通信しているようですか?
→と聞くのは簡単だが、どうやって調べよう?
5、「発行元証明書の…」はAdministratorでも確実にオフになってますか?
→XPのばやい、Administrator でログインするのは少々テク要。
特にHomeEdition では。
>>321 >1、時計戻したら直りますか?
すっきり治りました、が、現在に戻すとまたNISの起動が遅くなります。
因みに、
現在このコンピュータにインストールしてあるシマンテック製品とコンポーネントのすべては最新版です。
とのこと。
>2,3.4
詳しいことはわかりませんが、FWにあやしぃ設定はしてないはず。
妙な通信の兆候はなし。
>5
「発行元証明書の…」は、1とのandとorを試したが、関係なし。
Xp-Homeですが、アマガエルは私のみ。
訂正 orは間違い。
>>322 > >1、時計戻したら直りますか?
> すっきり治りました、が、現在に戻すとまたNISの起動が遅くなります。
ということはやはりシステム遅延の原因は内蔵CRLの失効だな、多分。
でも「発行元証明書の…」をオフにしても効果なし、ということは
やはりその設定をしている箇所が適切でない、と見るべきか。
じゃあ、以下のを試してみてもらえますか?
1、セーフモードで起動する。
http://support.microsoft.com/default.aspx?scid=kb;ja;315222 2、アカウント「Administrator」でログオンする。
3、IEのオプション「詳細設定 - セキュリティ」の「発行元証明書の取り消しを確認する」をオフにする。
その手順で、 「発行元証明書の取り消しを確認する」をオフにしても、 NISの起動は遅いです。 システムの復元を試したところ、 「復元ポイントの選択」で、 <をクリックしても前月(1月)にならない。 いよいよダメかな?
博多っ子は ばりサイン じゃけのう
327 :
名無しさん@お腹いっぱい。 :04/02/05 23:35
>>301 の方
ずいぶん遅くなって申し訳ありません。OSはXPです
ディスククリーンアップの中の[WebClient/Publisherの一時ファイル]が一連
の不具合以前は32KBだったのですが、現在は152KBになっています。
何か関係があるのでしょうか?
ファイル内容が解れば良いのですが、MSのサポート技術情報418438に
よると製品の問題で「表示ダイアログ」が表示されないとの事です。
WebClient/Publisherの一時ファイルは、たんなるキャッシュなので さほど問題じゃないかも。 消せなくなる問題は、確かにあるみたいですけどね。 "前スレ300 ◆w795LO9.Wo" さんが、いろいろ有益な情報をカキコしてらっしゃるので、 そのあたりをお試しアレ。
>>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 に変わっている。
単に署名だけではなく、
プログラム自体の署名チェックの契機自体にも手が入ったのなら
もしかして右クリ問題の根本解決の可能性も期待できるかも。
今は忙しいからすぐには試せないけど
後で試してみよう。
あんまし期待せんほうがええかなぁ…。
>>330 中間証明書の失効リスト
VeriSign Commercial Software Publishers CA
2004/04/28迄、ってのがもう一回インストールされてて
前にインストールしてた人は2つになってると思う。
1つは消してもいいのかな?
ローカルコンピュータの方にもインストールしてたんだけど
こっちは要らなかったのかな?
>332 ローカルPCにも入れると2つに見えるから、消すならユーザー側を消しなされ。
>>333 どうもです。
ユーザー側に2つ、ローカルに1つの状態だったんで
ユーザー側を1つ削除して、両方とも1つづつにしました。
NISって何もしなくてもcrl.microsoft.comとcrl.verisign.comのパケット通すようになってるんだね。 レジストリ見て分かったよ。
そろそろライブアップデートでNAVをアップデートしても大丈夫なんかな(w
>>335 プログラム制御の
Symantec Norton Personal Firewall Security Statistics
を見てみれ。
338 :
名無しさん@お腹いっぱい。 :04/02/08 20:05
ウッキキー!お猿さんだよ〜
340 :
前スレ300 ◆w795LO9.Wo :04/02/14 13:15
ここんとこ特にというか全然動きはない。 皆さんのところの右クリは正常化してますか?
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
> とは言うてるけど、それだと突出したピークが発生するのは防げても > (あの右クリ稍重のように)常にクライアント側に負荷がかかるんじゃないのか? なんで?
鯖側はDDoS攻撃を避けられてもクライアント側の改善は何らされる訳ではないって事でしょ。 パケット垂れ流しするのは変わらないんだから。
345 :
前スレ300 ◆w795LO9.Wo :04/02/18 01:56
>>343 > > とは言うてるけど、それだと突出したピークが発生するのは防げても
> > (あの右クリ稍重のように)常にクライアント側に負荷がかかるんじゃないのか?
> なんで?
OCSP(Online Certificate Status Protocol)ってのは
証明書の有効性確認をリアルタイムで行なう仕掛けなので
確認時には必ず通信が飛ぶことになります。
CRLの場合は(更新ロジックにもよりますが)
有効なものがキャッシュされていればそれを使うので
通信が飛ぶのはキャッシュが無効になった時だけです。
だから有効期限の長いCRLの期限切れとかいった契機に
突然更新のピークが発生しちゃったりするわけです。
>>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のインストール」法で回復した例多し。
しかしそれでも回復していないという報告もある。
回避策が見つかっているだけで、事象としては現在も継続中?
証明書失効リストが期限切れになってアクセスに行くと、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
>>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.jp や
https://www.ufjbank.co.jp/ib/login/index.html Bの例は
https://www.verising.co.jp や
https://web.ib.mizuhobank.co.jp 一般的なSSLの通信ってAとBどっちが正しいんでしょ?
BのパターンでVerisingのルートCA証明書を送られてくるところがあるんだけど、
VerisingのルートCA証明書ってV3拡張に対応してないV1のものばっかりなんだよね。
アプリケーションは送られてきた証明書は全てV3拡張のBasicConstraintsを
チェックする仕様なので必ずエラーになります。
VerisignのルートCA証明書ってV3にならないの?
>>354 いずれのルート証明書も
ローカルには有効期限内のものがちゃんとあるの?
>>355 はい、あります。
クライアント側のアプリケーションは意図的にBasicConstraintsのチェックを
外すことができ、そうするとNGとはなりません。
なので、クライアント側のルート証明書は問題なさそうです。
>354一部Verisignのスペル間違ってた。。。
357 :
前スレ300 ◆w795LO9.Wo :04/02/20 14:11
>>354 どっちが正しいか、はわからんけど
アプリが証明書がV3であることを前提としているという
その仕様自体の妥当性の問題なのか、
SSLのルート証明書がV1なベリが悪いのか、
という話になってくるのかな。
どういうアプリでどういう仕様なんかはわからんけど、
「BasicConstraintsのチェック」を指定する
=(証明書がV3であることを前提に)ルート証明書に対して厳密なチェックをする
てのが設定できるのであるとすれば、
必要に応じて外せばいい、ってことなのかな。
よくわからんけど。
なんにしても
ローカルにあるルート証明書
=すでに信頼されている
に対しても通信時毎に厳密にチェックする、てのは
過剰なようにも思うけど
そういう厳密さが要求される用途もあるんだろうね、きっと。
>>354 ルート証明書がV1になっているのは、理由があって、
V3の拡張フィールドのせいで、ブラウザなどのクライ
アントソフトと相性が悪くなって結果動作しないことが
まま、あります。RFCではV3ならば入れなければいけない
と定められている拡張フィールドが定義されていますので、
V3の証明書を採用するならばそれらを入れないといけない
のですが、アプリケーションによってはそれらをうまく
認識しないものがあります。
V1ならば歴史があり、形式が単純であり、自由度も少ないので、
アプリケーションが誤動作する可能性がすくないのです。
ただし、複数世代の証明書が混在するような場合(リニューや
リキーした場合)、CRL配布点を指定したい場合などは、
ルート証明書以外はV3証明書でないと問題が
発生するので、ルート以外はV3が採用されます。
また、相互接続性が重要でない局面では、たとえば、日本のGPKIの
入札関連の電子署名法対応認証局などでは、使用するアプリケーションが
決まっている(ポリシーで決まっている)のでV3のルート証明書が
使われています。
(酒飲んでます。駄文失礼しました)
過疎だけど、なにげに良スレなんだよな、ここ…
こないだ23日にVeriSign Class 3 Code Signing 2001 CA入れ直した 明日27日はVeriSign International Server CA - Class 3が切れる予定 ブラウザキャッシュが自動判定でヘッダ取りに行くからFWにログが残ってて、URLがキャッシュに残るからダウソは簡単 それにしてもサイクルが短過ぎないか?面倒でかなわん
何気に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はあまり関係ないんじゃないかと思うんだけど。
>363 NAVファイルのプロパティからデジタル署名を辿ってみてよ。 副署名の方も見ると驚愕の事実が! 上とは関係ないけど事前策で>51のリンクからcrlをDLしてインスコしたよ。
いまローカルコンピュータに入れてる失効リスト(期限順) 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
ってのもあるけど、これもちゃんとシステム上にありました。
期限切れだけど。
期限切れだから消しちゃったりとかはしてない?
ブラウザキャッシュに残るから URL調べてフラゲか何かでダウンロードしてインスコすればよろし
1/8に勤め先でトラブって以来、じっとりねったり
ウォッチさせてもらってました。といっても
やりとりされていることの中身は私にはわかりません。
惚れた手前というのもあるけど、
>>359 に同意。NAV本線で班長に「先に寝ます」と失礼した
私でありました。ごみ、重ねて失礼。ではまた。
過疎スレですが、見てくれている人がいるというのは嬉しいです。 そんなにもう頻繁に書くネタもない状況だけど せっかくのスレだし、「維持の為の維持」じゃない範囲で続けていきたいです。 ベリサインにこだわらず PKIを核とした認証全般を学んでいきたいな、と。 もっといいスレなり板なりがあるといいんですけど どっかにないもんですかね?
2004年03月03日 07:07:27更新予定 Microsoft Secure Server Authority
373 :
Mr300% ◆w795LO9.Wo :04/03/03 12:37
コード署名の証明書のCRLではなく、 証明書自体のインストールや サーバー系証明書のCRLのインストールってのは NAV/NIS環境のレスポンス等の向上に効果あるもんなんでしょうか? 正直かなり疑問なんですけど 成果が上がっているという人、いますか?
SSL通信の認証がスムーズになったくらいかと。 NISがポート443見てるけどその点ではどうなんだろうね?
376 :
名無しさん@お腹いっぱい。 :04/03/05 10:00
http://crl.verisign.com/ の今日今時点の一覧。
Class3CodeSigning2001.crl.20040303 03-Mar-2004 03:00 84k
「crl.20040303」ってなんやねん。
公開ミスかな?
OS再インストしてから、やたらと証明書の期限切れダイアログがでる。 訳が分からんのでこのスレに挙がっている証明書をやたらとインスト。 それでも直らないので途方にくれていたら・・・ パソコンの日付設定が10年ずれていました。
378 :
名無しさん@お腹いっぱい。 :04/03/06 20:51
本日Microsoft Secure Server Authorityを入れ換え 明日はVeriSign International Server CA - Class 3更新の予定
381 :
前スレ300 ◆w795LO9.Wo :04/03/19 00:26
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日。
>>381-383 これらから、以下のように推測する。
コード署名の取り消し情報は、証明書の有効期限切れ以降も
最低2年間くらいはCRLに載せられている。
(ただしMSの2つは別扱い。多分ずっと載ったまま)
苦労した割には、ほとんど意味の無い情報だわ。
とほほ。
385 :
名無しさん@お腹いっぱい。 :04/03/19 16:33
優良スレ上げ
Equifax Secure Certificate Authority ってのが3/21に来ることになってるけど そもそもこれ何だろう?
OU = Secure Server Certification Authority O = RSA Data Security, Inc. キタ━━━━━━(゚∀゚)━━━━━━ !!
>>386 SSLのサーバー証明書じゃないですかね?
「来た」ってのはなんだろう。
それのCRLの更新?
Verisignは中身の変更の有無は別としてもほぼ毎日更新されてるから、 一度にまとめてインスコしれば更新も同じくまとめて来るぞ。
なんか、ここの役目もすっかり終わってしまった感じですね。 だってネタないんだもん。 しょうがない。
394 :
名無しさん@お腹いっぱい。 :04/03/29 15:18
何かあった時また役に立つ。と言う事で保守上げ。
そうなんだよ。 俺もアダルトサイト運営予定だから、ルート権限付きの専用サバ借りて、決済画面でSSL使うけど、Veriは高いし、登記簿まで 要するから、名の通った手軽なGeoTrustにしようと思ってる。 何もVeriに、こだわることもないのでは?
>>395 そりゃVeriにこだわることはないんだけど、
でもルート証明書が最初からOSにインストールしてあるとこの方が楽ちんですよね。
ユーザーにルート証明書をインストールしてね、とか言わなくて済むから。
実際、サーバー証明書だと、ベリ以外にどういう選択肢があるんだろう。
結局、期限切れのclass2中間証明ってどうにもならんの?
>>398 > 結局、期限切れのclass2中間証明ってどうにもならんの?
どのclass2中間証明書の話でしょうか。
期限切れは期限切れで、
基本的にはどうしようもないと思うんですが。
400 :
名無しさん@お腹いっぱい。 :04/04/17 14:55
>>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 >
http://www.verisign.co.jp/server/help/faq/110053/index.html > ここにそのものズバリがあったのですが、いまいち確信がなかったんで。
あーほんとだ。FAQはザッと眺めたつもりだったけど見落としてたな。
技術情報 Q&A - サーバIDの仕様
だったか。
これって本来は導入検討時に悩む項目だから、
もっと上のほうにあってほしいような。
ポイントはやっぱ401でも書いだけど、
「ウェブサイト運営主体の実在性を証明」のみを重視するならどっちでもいい=セキュアサーバIDでよい
常に「暗号通信の強度を高めたい」のであればグローバルサーバIDが必要
ではないかと、少なくともワタシは思います、ハイ。
ホッシュ
405 :
名無しさん@お腹いっぱい。 :04/04/28 14:01
最近になってまた右クリックでexplorerがベリの旦那に接続しようとし始めた。
Winうpだてにルート証明書の更新来た、重要じゃなく推奨の方。 >405 NAVの定義ファイル辺りの証明書をインスコしてみな
409 :
名無しさん@お腹いっぱい。 :04/04/30 23:59
電子証明書なんてOpenSSLで簡単に発行出来るから自分の作ったついでにダダで 作って配ってやろうとしたらいらないとさ。プロバイダー経由じゃ月額200円も 払わなけりゃならないのをダダでやるっていうのに・・・。 所詮電子証明書なんてその程度のものさw
>>409 藻前のルート証明書をインポートするより、ぬるぽウイルス踏むほうがマシ。
411 :
名無しさん@お腹いっぱい。 :04/05/01 04:34
>>410 ツーか俺もどこの誰かも分からん奴には発行せんよw
しかしベリサインボリ杉、メール用の証明書なんて年額200円でいいだ
ろうに・・・。
>>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
>>413 名前入れずに使ってます。
「メールアドレスを認証しているだけ」ね。
無料で名前まで入れられるかよくわからないし。
>>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。
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
422 :
名無しさん@お腹いっぱい。 :04/05/02 01:46
423 :
名無しさん@お腹いっぱい。 :04/05/02 22:11
ところで気になったんだが、電子証明書で使用できる最高の暗号方式ってどう なんだろう?AES256ビットとか使えるのかな?
424 :
名無しさん@お腹いっぱい。 :04/05/03 00:30
自分で調べたら今んとこDigestでsha1、4089ビットが最強みたいね。
425 :
名無しさん@お腹いっぱい。 :04/05/03 00:31
やば↑4096が正解
なんか最近1029と1033と1034の3ポートで常にcrl.verisign.comにアクセスしてるみたいなんですが… 1月のノートン事件の時には証明書?を古いのを消して新しいのを入れる事で乗り切ったのですが、今回はよくわからないです。 検索してもノートン事件の事しかひっかからないし… あんま知識ないんで自力で解決できず、インターネットへのアクセスもかなり遅くなって困っています。 どなたか解決法ご存知ではないでしょうか?
どのプロセスが通信してるのか。
>>426 それがわからないんです。
たぶんファイアーウォールとかいうので見れるかなとか思ってWinXPについてるやつを起動させてみようとしたのですが、なんかエラーが出て起動できませんでした。
片っ端から起動してるプログラム終了してみても通信が切れないんで、おそらくエクスプローラか、終了できないノートンの常駐監視のやつかと思うのですが。(NISは入れてません。NSWのみです。)
どのプロセスが通信してるのか知る方法を教えていただけないでしょうか?この板ではやや初心者質問スレ向きの質問ですが…
netstat
すいませんこの板見てZoneAlarm入れたらverisignへのアクセスはなくなりました。 原因は結局わかりませんでしたが、とりあえず解決したということで、お騒がせしました。m(_ _)m
OpenSSL 0.9.7dによる自家製証明書についてのまとめ。 最大鍵長:4096(これを超えるとpkcs12出来ないっぽい) 暗号形式:des3(AESは証明書自体は作成できるが、Outlookは対応してないっぽい) ハッシュ:sha1(証明書のほうはopenssl.cnfで設定できるが、CAの方は-sha1付け てやらないとmd5のままになるので注意) ってところかな?誰も見てないっぽいけどw
>>431 見てたけど答えらんなかっただけ(^^;。
4096 超えると pkcs12 が出来ないんですか。へぇー知らなかった。
16384 bit とか作ってたw。2048bit位で充分らしいけど。
2番目は高度暗号化パック以後のWinにて、トリプルDESまで対応って事ですよね。
3番目はよく知らないけど、md5じゃ衝突の可能性があるって事かな?。
> 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
NIS2003だが、またOS起動時に毎回ベリに繋がる 今度は何なんだよ_| ̄|○
ファウアウォールでccApp(c:\program files\common files\symantec shared\ccapp.exe)の通信を許可してログを取る ログが残ったら更新された証拠だからキャッシュを見る あとは上のほうにあるローカルインスコの方法を参考に
>ファウアウォール ドイツ訛りのつもりならフォイアウォール
すみません スレ違いかも知れませんが、質問させてください あるサイトからhttpsで求人に応募しようとしたのですが セキュリティ証明書が信頼する会社から発行されていません とのメッセージがでました 発行者はKSI First Serverとなっているんですが 信頼していいものでしょうか? よろしくお願いします。
440 :
名無しさん@お腹いっぱい。 :04/05/15 23:16
>>439 その場合、証明書の発行元がブラウザーに登録されていないって話で、送信内
容はちゃんと暗号化されます。そのSSLで表示されたアドレスがちゃんとその
会社のものか、そのページを右クリック、プロパティーを選択してそのアドレ
スがアドレスバーのアドレスと一致するのが確認できたら心配要りませんよ。
>>439 信頼するのが
「SSLによって、そのサイトと暗号通信がされるか」なのか、
「そのサイトの素性が確かかどうか」なのか。
前者であれば
>>440 の通りだと思いますが、
後者であれば微妙なところ。
ただ、
「セキュリティ証明書が信頼する会社から発行されていません 」
というメッセージが出ること自体は、
そのサイト自身の問題ではなく、
あなたの通信環境の問題かもしれません。
ちょっと興味があるので
差支えがなければ、どこのサイトか教えてもらえませんか?
442 :
名無しさん@お腹いっぱい。 :04/05/19 20:10
443 :
前スレ300 ◆w795LO9.Wo :04/05/19 22:00
444 :
名無しさん@お腹いっぱい。 :04/05/20 00:29
ジャストシステムが証明書の商売を始める模様。 ニュースレターに載ってた。 1年2520円だそうだが。
>>444 > ジャストシステムが証明書の商売を始める模様。
https://www.justmyshop.com/camp/verisign/?w=tpcm_verisign インターネットを巡る情報は、すべて傍受される危険性があります。
機密扱いで管理している文書も、悪意ある「盗み見」や「改ざん」により、重大なトラブルを招きかねません。
あなたの大切な情報と信用を守るためには、電子証明書が効果的です。
「ベリサイン 個人用電子証明書ライセンスシート」(MyShop価格 2,520円[税込]送料無料)をご利用いただくと、
低コストかつ手軽に、「デジタル(電子)署名」「暗号化」といったセキュリティ機能を実現できます。
てなわけで、これもベリにつながってくるわけだ。
>>431 > OpenSSL 0.9.7dによる自家製証明書についてのまとめ。
すんません。見てますけど勉強不足でついていけてません。
ワタシの方では、純MS路線(笑)の
.NET Framework の証明書作成ツール (Makecert.exe)で
どんなことが出来るか試してみます。
期限切れたー!むきー!!!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
452 :
名無しさん@お腹いっぱい。 :04/06/01 22:31
age
453 :
前スレ300 ◆w795LO9.Wo :04/06/02 13:01
454 :
名無しさん@お腹いっぱい。 :04/06/05 10:29
age
とりあえずEasyCertで自分で認証局立てて 自分用の証明書を作成して、 その証明書でOEから署名付きメール送ったり 暗号化メールを返してもらったり出来ることまで確認しました。 証明書の発行管理の機能がちゃんとあるので 単発のツールでしこしこ証明書作るのに比べれば雲泥の差ですし 証明書の記載内容の自由度も高いです。 ただ、証明書自体に対する知識がある程度ないと 「なにをどう指定してよいやらさっぱりわからない」 ということにはなるとおもいます。 少なくとも、第三者に対してではなく 自分自身や仲間内で電子署名によりなりすましを防いだり 暗号化によってデータを秘匿したりする、といった用途には 十分使えるんじゃないかと思います。 いやーすげえな、EasyCert。感動しました。
>>455 でしょ!?漏れも3年前くらいに感動した(w
確かこっからのLINKでCACAnetも知ったんだったと記憶している。
(遙か昔の物語)
CACAnetも覗いてみると結構ためになるかもね。
漏れは一般MLをまた〜りROMってます。
457 :
名無しさん@お腹いっぱい。 :04/06/08 14:05
>>457 どっかで見たような書き込みがと思ったら...俺がいた(w
459 :
名無しさん@お腹いっぱい。 :04/06/10 14:51
みんな、なか〜ま!
461 :
名無しさん@お腹いっぱい。 :04/06/16 01:35
EasyCert 0.89b1 ← このバージョンって前から配布してましたっけ?。 以前見た時は、7日間制限版と、輸出規制に関連したキー長512bit制限版 しか無かったような気がしたんですが。だから、使ってなかったんだけど...。 使うなら 0.89b1 だね。(起動ウィンドウが「AiCA」だけど) というか、OpenSSL のフロントエンドが激しく欲しい。 S/MIME の証明書って、証明書ファイルだけを渡すと、渡された相手が暗 号化しようとした場合、40bit とかでしか暗号化できないんですよね。 メールで送ると 192bit 3DES で暗号化してもらえるんだけど。 メールのヘッダに、メーラーの種別とバージョンが書いてあるから、 それで、どの暗号化が使えるか判断してるって事でしょうかね。
>>462 そのページにありますけど、あれ?、EasyCert 0.89b2 って書いてあるな(^^;。
インストールしてヘルプのバージョン情報を見ると 0.89b1 なんですが...。
でも、どのバージョンの readmej.txt を見ても、
「このバージョンは輸出可能版であり、秘密鍵はDES 56bit、
PKCS#12 内の秘密鍵はRC2 40bitで保存されます。」
って書いてありますね orz。
>>461 >メールで送ると 192bit 3DES で暗号化してもらえるんだけど。
訂正: 3DES 168bit の間違いでした。
右クリック重いよ〜ヽ(`Д´)ノウワァァァン
>>464 中指を鍛えよ!
熱湯をザブリとかけ、キリリと冷やしたタオルでばんばん叩くのじゃ
466 :
名無しさん@お腹いっぱい。 :04/06/18 23:25
NIS2003でOS起動時にccEvtMgr.exeが毎回ベリに 接続するんだがどうしたらいいんでしょう? 解りやすくたのんます
Live Update
468 :
名無しさん@お腹いっぱい。 :04/06/19 06:03
>>467-468 とりあえず許可してるのですが、
毎回繋がるのです。(ルーター自動接続です)
これって何か変ですかね?
ノートン先生…なんでそんなにベリサインに繋ぐの?。・゚・(ノ∀`)・゚・。
471 :
名無しさん@お腹いっぱい。 :04/06/19 20:27
>>463 うちの 0.88b2 には「このバージョンは...」部分の記載が無いんですが...
0.89以降の対処なんでしょうかね?キー長は1024とか選択出来たりします。
ですが、OutlookExpressで試してみて受け付けてもらえなかったので、
結局は512にしました。
久方ぶりにキーを見てみたら、去年キーの有効期限が切れていたよ...orz
ところでこの会社の株っめちゃ高いんだけど、 ここの社員の待遇ってもしやめちゃいいのかな?? これまでのレスを読んでると、私のイメージ的には 外資だから殺伐としてそう。。。
>うちの 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 これはどの証明書についてのお話でしょうか?
サーバー証明書なのか、コード証明書なのか。
差し支えなければ、あるページがどこのページか教えてもらえませんか?
>>477 はい。サーバ証明書のつもりで読んだんですが、コード証明書
の事だったかもしれません。そもそも良く分かってないのですが、
ブラウザにインストールされたサーバ証明書が古くなったら、その
ブラウザからそのサーバへのアクセス拒否はどのように実行され
るのでしょうか?
>あるページがどこのページか教えて
すみません。あっちこっちうろうろしてた途中で読んだ記事の
記憶なので、どこのページだったかはっきり憶えてません。
>>478 すみません。サーバ証明書が古くなったら有効期限切れですね。
でもその時、ブラウザが参照する時計の時間を戻されたらどうなるんでしょう。
蒸し返すようで申し訳ないですが・・・
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を内部的に保持している場合には
それを使って取り消し確認をする」
ってロジックを加えたのかな?
>>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情報が入っていないコード署名証明書って、いまから探して見つかるのだろうか?
これはワタシは見たこと無いですわ。
#久々にこの件の話の相手をしてくれる方が現れて、なんだか嬉しい(笑)
>>483 なるほど納得しました。
あるがとうございました。
またまた疑問なんですけど、
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を更新してね。
という事を言ってるんだと思いますよ。
なんにしろ、プログラマに対する注意喚起とかではないと思います。
>>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
489 :
名無しさん@お腹いっぱい。 :04/07/06 19:45
490 :
前スレ300 ◆w795LO9.Wo :04/07/06 21:40
>>489 これ、なんかもう見られないんですけど、
どんな内容だったんでしょうか?
491 :
名無しさん@お腹いっぱい。 :04/07/14 14:48
ホシュ
明日の午前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ってだいぶ価格が違うようだけど、どっちがいいの?
27日に何かの更新があったね。
497 :
名無しさん@お腹いっぱい。 :04/07/29 05:48
>497 それは補償額を見ればわかる。一番安いのはたったの$50-。 最もどういう状況で補償してくれるのか、よくわからんけど。
499 :
名無しさん@お腹いっぱい。 :04/08/02 02:29
最近有名になったGeoTrustはどうなんだろう。 GMOだから信頼性ないか
またpca3.crlか… いい加減アクセスするのはやめてくれよ、ノートン先生。
501 :
名無しさん@お腹いっぱい。 :04/08/31 22:07
あげとくか。
Windows XPにSP2を適用させたら証明書を取りに行かなくなった… ?(´・ω・`)?
503 :
前スレ300 ◆w795LO9.Wo :04/09/04 08:28
>>502 それは興味深い話ですね。
自分とこがXP環境じゃないので確認不能ですが
XPの側のファイヤーウォールで止められてる、
なんてオチではないですか?
>>503 いや、XPのFWはサービスごと停止してNISのみを使ってまつ。
いったいなんなんでしょう…(´ω`)ウレシインダケドネ
前スレ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バージョン地獄ですよ、わが国の電子政府は(笑)
話の流れを断ち切るようでスマヌ。 実は相談に乗って欲しい。 俺はしがない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 セキュアサーバ > ブラウザの仕様を信じて暗号化。設定は不要。
しかしブラウザによっては40bitの場合有り
グローバルサーバ > サーバorクライアントに中間CA証明書設定が必要だが、
絶対128bit暗号化通信
apacheの場合、中間CAを盛り込まないと下手すりゃ期限切れで
警告がでるので注意されたし。
あと、補償金額にも差がある。これは余り関係ないか。
513 :
名無しさん@お腹いっぱい。 :04/10/04 15:45:03
で、結局は証明書は必須なの? いらないのならベリサインへのアクセスを止めたいんだけど、 どうすればいい?
514 :
名無しさん@お腹いっぱい。 :04/10/04 17:34:39
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
518 :
423 :04/10/08 17:35:19
>>517 まだやってたのか、あんたも飽きないねぇ〜w
最近ISPでPOP/SMTP over SSLサービスをやってる所も出て来たんだけど、ポー
ト番号が特殊なせいでウイルスソフトのメールスキャンが利用出来なくなる場
合がある。んでオレがDelegateで中継してメールスキャンもPOP/SMTP over SSL
も利用出来るようにした設定を置いていくので突っ込んでくれ。
delegate.exe
[email protected] \
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
521 :
名無しさん@お腹いっぱい。 :04/11/12 14:19:53
保守
NIS2003だけど起動時毎回ベリに繋がる( '・ω・) しばらく良かったんだけどな〜 皆さんどうですか?
523 :
前スレ300 ◆w795LO9.Wo :04/11/20 01:09:20
>>524 どうすればいいんでしょう( '・ω・)
ベリで更新するんでつか?
>>525 >252に詳しく書いてあります。
一度このスレを全部読んで見るといいですよ、俺も最初は苦労しましたけど。
>>526 苦労しましたがやっと出来ました
いまいち何をおこなったのかよく理解していませんが、
起動時にverisignに繋ごうとする現象は解消しました。
NISは放っておいたらずっとこういう状態なんですかね(;・∀・)
優しいお導きありがとうございました<(_ _)>
↑522です
シマンテックの証明書が月曜日の9時にまた切れるね
Virisignのセキュリティーシールの新しいフラッシュのやつが表示されないマシンがあるのですが、なぜでしょう?
531 :
名無しさん@お腹いっぱい。 :04/12/03 11:53:15
べり落ちてねーか?
532 :
名無しさん@お腹いっぱい。 :04/12/03 12:09:36
あ、やっぱ落ちてるよね。 うちフラッシュシール張ってんだけどページがスゲー重くなって苦情が来てる。
533 :
FLP :04/12/03 12:28:43
落ちてますよね。
今仕事で作ってるHPに、今日フラッシュシール貼ったのに 全然表示されないわ重くなるわで超焦った(w 公開前でよかった。
535 :
名無しさん@お腹いっぱい。 :04/12/03 12:41:42
フラッシュシールでるようになったよ。証明書は出ないけど。 画像シールと違ってページ自体重くなるのは困る! ついでにサポートがメールだけってのが腹が立つ。
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なかったら寂しいべ。
だれか、べりさいんに侵入してみてくれよ。
フラッシュシール張ったら、プライバシーレポートでCookieブロック済みって出ちゃうんだけど、こうゆうもんなの? www.verisign.co.jp/ でも同じように出るし・・・
サードパーティのクッキーをブロックするようにしてんじゃないの?
543 :
前スレ300 ◆w795LO9.Wo :04/12/17 10:13:16
しまったー。ネタを記名で書いちまったー。トホホ。
(・∀・)ニヤニヤ
バーカバーカバーカ
547 :
名無しさん@お腹いっぱい。 :04/12/29 20:43:34
基本的な質問だけど、Verisignの署名の入ったサーバ証明書 って誰でも取れるの? もしそうだとすると、MicrowSoftという名の会社でも取得できてしまう ということ?
549 :
名無しさん@お腹いっぱい。 :04/12/30 14:57:40
>>548 法人格があっても同一名、類似名の会社はあると思うが。
551 :
名無しさん@お腹いっぱい。 :05/01/01 11:50:11
>>550 住所まで覚えている奴はあまりいないと思うので、
サーバ証明書ってあまり意味ないように思うのは俺だけ?
そのへんはCAの信用にかかわるキモだから、 類似商号は登録拒否していると思われ。 役所じゃないから、登録する義務はないからね。
>>547 法人格でも、以下の条件のどちらか満たせないと取得できない
1.登記簿謄本(現在事項証明書)が提出できる
2.帝国データバンクへの登録(商号登記・情報提出)などが行われている
ベリサインはその辺がメチャメチャ厳しい。
なのでベリサインの証明書を持っているサイトはまず大丈夫かと思われる。
事実、さる官公庁相手に証明書の更新手続きをしたら相手が逆ギレして
認証が2週間STOPして、相手と対人認証をベリサインの人間を引き連れて
期限切れ3日前にやっと到着したという目にも涙語るも涙という事があった。
登記が偽物かという話はあるだろうが、結構めんどくさい作業なので
SSLを取ってまで野郎という奴はいないだろう。
>553 なんか大変だったみたいだけど、とりあえずもちつけ。 「事実、さる〜」以降を説明してくれると、大変ありがたいのだが。
お役所仕事に嵌った。(10文字)
>>554 そんではお言葉に甘えて。
一昨年の話で恐縮だが、うちの会社である官公庁のシステムに利用する
証明書を扱っており、年末に更新だったので部署経由で証明書の更新手続きを依頼した。
ところが、担当の課長相当が相当なケチものらしく、ベリサインからの電話に対して
「他部署からの話が違う」「いったいいくらで作業しているんだ」とかぬかしやがった。
当然認証作業はSTOP。それに官公庁から証明書の価格詳細を示す書類を出さないと
再認証には応じないとという要求を他部署経由で出してきたために
ベリサインの営業と相談。
そんな資料は当然出せないので、相手部署とベリサインとの折衝に苦労したよ。
結果的に、他部署の営業とベリサインの営業、認証部隊を引き連れてそのお役所に
出向いて価格の説明と認証作業を実施し、最終認証も現地で行って事なきを得た。
それが証明書期限の3日前に到着、インスト作業はヒーヒーもんだった。
今年は担当が変わったらしくたったの2日で最終認証にこぎ着けたよ。
やっぱりお役所は大変だぁ。
だから証明書担当の気構えとしては
・お客担当営業に、強く「申請責任者に定時間中に電話を必ず取って下さい!!」と念を押す
・風邪を引かない
・バックアップ担当を出来るだけ回すか、育て上げピンチの時に
最終認証に出てもらえるようにする。
・川崎の番号はそらで覚えておく
かな。
営業経由で他の営業にきちんと説明できないとこの仕事はやっていけないよ。
証明書って保険みたいなくせに期限切れだけはめざといからなぁ。
以上。名無しに戻ります。
>556 お疲れ様でした。認証ビジネスも決して楽ではないんだね。 おかげで大変参考になりました。
>>556 官公庁が使うベリの証明書取得を仲介してて
お役所仕事に嵌った。
でよろしいかな?
>>558 いや、「お役所のクソ役人」に嵌った。
にして下さい。
今年はごく普通の対応だったので、お役所仕事全般という
訳ではなかったので。
560 :
前スレ300 ◆w795LO9.Wo :05/01/10 11:07:16
気が付けばあの日から1年が過ぎています。 皆様お元気ですか?
でもverisignのCPSでは、悪意のactivex配布する会社にもコード署名可能な 証明書を平気で発行できるんだよね。ようするに、糞。
562 :
前スレ300 ◆w795LO9.Wo :05/01/10 14:16:10
>>561 「どこの誰が、いつ作ったコンポーネントなのか」
をとりあえず特定できるだけでも
「どこの誰が、いつ作ったコンポーネントなのかすらわからない」
よりはマシなんじゃないでしょうか。
ベリの仕事は、どこの誰かを証明するまでで
そいつが善人か悪人かってのはまた別問題だと思う。
「ようするに、糞」ってのはどうかと。
activexは糞かもしれませんが(笑)
563 :
名無しさん@お腹いっぱい。 :05/01/13 12:44:04
>>594 ダメってその日記の主がイタイってことでOK?
>>564 おまいにはこのスレは高度すぎて無理だろう。
しかし高木さんもよくこれだけ頑張れるものだ... 漏れだったら
ここまで粘れないよ...
566 :
名無しさん@お腹いっぱい。 :05/01/14 18:20:21
しかしベリは高すぎるよ。寡占の弊害だよね。 このスレも寡占を加速するようなスレタイなのがまずい。 スレタイ変えれ
>>563 読んでたらむかついてきたっ
>>566 電子証明書(デジタルID)一般の話題を表すスレタイにされたい
>>567 高木さんがこんな場末に来るわけないだろ。
日本でセキュリティ関係の仕事している香具師なら、誰でも
知ってる人だよ。漏れは場末のネットワーク屋さ。
>>568 漏れも役所の馬鹿担当者の無責任さに猛烈に腹が立った。漏れでは
あんな冷静な対応できないよ。
>>566 禿同。
( ´,_ゝ`)プッ
>>565 役所の立場というものを考えると、高知県の言い分で一部だけ納得できるところがある。
その部分に対して高木氏は話の核心に触れずに流してしまった。
やっぱり、政治的な部分がわからない香具師はイタイよ。
俺から見れば馬鹿丸出し。「ちゃんと新聞嫁!」と、言いたい。
ここでタジタジしている役所の担当者もどうかとは思うが。
ところで、藻前は俺が一部納得したのは、どこを指しているかわかるか?
昼間から2ちゃんねるに書き込んでいるような香具師にはわからんだろうな。
-------------------------------------------- ここまで、俺の自作自演
573 :
名無しさん@お腹いっぱい。 :05/01/14 22:25:27
> このサイトのセキュリティ証明書の取り消し情報は、使用できません このような警告がブラウザで表示されることがあるのですが、 問題がサーバ側にあるのか、クライアント側にあるのかすら自分には分かりません。 セキュリティ証明書+取り消し情報 で検索してここにたどり着きました。 どうしたらよいのでしょうか?
>>571 LGPKI のことか?
高知県は LGPKI も使ってないわけだが?
575 :
名無しさん@お腹いっぱい。 :05/01/15 01:30:48
>>571 県: ネットスケープは今回対応していない……
↑ここだろ?お前が納得したのは。
クソ知ったかの無駄な抵抗だな
東京電子自治体共同運営サービスも大変だよ〜。 都と都内市町村関連の入札が電子化されるってことで 入札に参加したい人は、まずは資格審査ってのを受けないといけないんだけど それに所定の電子証明書が必要。 でもって、これの登録ってのが、初めての人には結構ハードルが高い。 おまけにコールセンターへの接続ハードルも高く、問題解決ハードル通過力は極めて低い。 だから、ちゃんと登録できない人続出。 てなわけで、受付の締め切りが12/10→12/28と延長されたけど、 やっぱりだめみたいで、1/21までに再延長されてる。 一応「資格審査申請 入力登録センター」てのは作るみたいだけど。 国のやることもアレだけど 地方自治体のやることはもっとアレだと思う。
>>579 一見、天下の法務省が一番割安だが、
電子証明書の申請と取得に有料の専用ソフトを購入しないといけない。
その初期費用が発生するので注意が必要。
(ソフト自体は最初に1回買えばよい)
581 :
名無しさん@お腹いっぱい。 :05/01/18 14:46:48
初めて証明書更新しようと準備してるのですが、手続きに少し不満を感じました。 延長という形式がなくて更新しかないってのは技術的に納得いくのですが、 前と後の証明書の期間が重なる部分を2重に料金取られるのは避けようがないのでしょうか? サーバの更新運用考えると1〜2日は重ねたいとは思いますが、 早めに手続きしたら2週間ぐらい重なって、 その余計な期間分の料金がだぶるのは、避けれるものなら避けたいですよね。 でも期限ぎりぎりは怖いし・・・みんな我慢してるのかな〜
582 :
名無しさん@お腹いっぱい。 :05/01/18 18:27:00
なんか勘違いしてたかもorz ハズイ 更新したら、 開始日:ベリサインの手続きした日 終了日:前の証明書の終了日の1年後 になるってのが普通の解釈ですよね。 これであってますか?
>>582 うちもそろそろ更新なんだが、581の考えであってると思う。
開始日:ベリサインが発行した日
終了日:ベリサインが発行した1年後
証明書の有効期限に1年プラス数日という考え方がないですから、
単純に発行手続き(更新手続きも同様)から1年のはず。
セコムから買えば、更新の場合は価格が安くなるから
ちょっとだけ納得できる。
この中に証明書申請担当香具師はいねぇか? 今日久しぶりに証明書更新申請しようとしたら いつの間にやらポータルサイト制に 変貌してたんだよ!! 申請ドメインの履歴から管理できるのは良いが、 俺が2ヶ月かけて作った手順書が・・・ OTL くそー、こうなったら日○○に電話してやるー。 一度行ってみそ。個人申請用証明書ももらえっから。 あるとログインがかなり便利。
日能研?
586 :
前スレ300 ◆w795LO9.Wo :05/01/26 18:11:56
>>584 すんません、これってどこの話ですか?ベリ?
> 一度行ってみそ。個人申請用証明書ももらえっから。
> あるとログインがかなり便利。
ってのに激しく興味があるんですが。
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がやってい
るわけでして。
べりサインやらセコムやらの証明書なら信頼するが、広島市が独自に
発行した証明書は信頼できないってのは変な話。
一般論としては、ただの一企業が承認しようがどうだろうが、
信頼性にはまったく影響しない。この警告はまったく意味がなく
単なるマイクロソフト社のユーザーに対する脅しでしかないわけ
ですよ。仮にマイクロソフト社が承認した証明書で、何かしらの
不利益を被っても、マイクロソフト社が責任をとってくれるわけでなし。
マイクロソフト社は、広島市を正規の団体として認めていないと
いうだけの話で、広島市自体は、マイクロソフト社に認められよ
うと認められまいと、そんなこたぁ関係ないし、マイクロソフト
社が「広島市を正規の団体として認めない」と言うのなら、ただ
の馬鹿企業。広島市の証明書に対して、不要な警告を出さないよ
うに努力するべきは、日本国の正規の自治体である広島市ではな
く、マイクロソフト社であるべきなんですよね。
>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
ううう。誤字だらけだわ、上げてるわ…。
どうも
>>543 以来不調ですわ。
>>590 ようやくまともな香具師が出てきた。待ってたぞ。
>>589 バーカ。チンカス溜まってそうな奴の書き込みだな。
それなりの証明書って何だよ?
お役所はシェアだけじゃ一企業を認めるわけにはいかねぇんだよ。
594 :
名無しさん@お腹いっぱい。 :05/01/27 22:51:25
で w795LO9.Wo はどうやって法務省の証明書を入手するんだ?
596 :
前スレ300 ◆w795LO9.Wo :05/01/28 00:41:29
マイクロソフトを信頼しない人は マイクロソフトが信頼するルート証明書も信頼できないでしょうから 証明書ストアにデフォルトで登録されている 「マイクロソフトが信頼するルート証明書」も一回全部削除して ひとつひとつ自分で信頼するに足るか否かを検証すべきでしょう。 なんてね。
597 :
名無しさん@お腹いっぱい。 :05/01/28 19:29:31
596>「マイクロソフトが信頼するルート証明書」も一回全部削除して ひとつひとつ自分で信頼するに足るか否かを検証すべきでしょう。 そんなことするとWindowsUPDATEが出来なくなったりいろいろあるからやめれ。(本当) どうしてなのか因果関係は知らないが。 それに、マジ復旧は不可能に近いぞ。遊びでやるのもやめれ。 596>なんてね。 イタズラも大概にしておけ。
まだいたのか罵倒空振り知ったか野郎は
マイクロソフトのルート証明書よりも クーポン券が川崎にFAXしなくて良いとはどういう事だ。 発行ステータスがどういう状態か確認できるとはどういう事だ。 お客さんのメールアドレスが必須と言うことはどういうことだ。 グローバルサーバIDの注文履歴しか出てこないとはどういう事だ。OTL とりあえず大田区界隈に出没するのはやめておこう。 ○東○方面に出没。ちなみに美人の宝庫。
>>597 > イタズラも大概にしておけ。
そうですね。ちょっと冗談が過ぎました。
>>596 を訂正します。
マイクロソフトを信頼しない人は
マイクロソフトが信頼するルート証明書も信頼できないでしょうから
証明書ストアにデフォルトで登録されている
「マイクロソフトが信頼するルート証明書」も
ひとつひとつ自分で信頼するに足るか否かを検証すべきでしょう。
もしも信頼できない証明書があったら、
エクスポートしておいてから削除するのもいいかもしれません。
なんてね。
バカ池沼に構うなよ
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
そこが出すとデジタルでは保護されててもアナログじゃ筒抜けっぽいな
606 :
名無しさん@お腹いっぱい。 :05/02/07 14:37:08
ライブドアホのセキュアシールは、ダサイ
607 :
名無しさん@お腹いっぱい。 :05/02/09 15:11:30
ベリサインの新シール、flashバージョンをデフォで使わせようとしてるけど、 Flashが入ってないPCに考慮してgifにしようかと思った。 そんなケースはレアだとは思うけど、flashにするメリットもあまりないし。 みんなどうしてる?
シールなんて無しが基本。
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 ・verisignが発行する証明書は、verisignが認証した証明書。 よってverisignを信用できるなら、その証明書も信用できる。 ・自己署名は、自分で自分を認証している。よって誰も証明 してくれない。 ・世の中のほとんど全てのweb browserは、verisignのルート証明書 を持っている。よって、verisignが発行した証明書が正しいかどう か自動的に判断できる。これに対し、自己署名はユーザが`自己の 責任において信用するものであるので、多くのブラウザは「確認 できない」とワーニングを出す。 なおAUの携帯ブラウザは、自己署名のページに接続できない仕様に なっている。 > verisignはブランドで金とってるんですか? ある意味そうとも言える。一番最初に証明書ビジネス始めた会社だからね。 別にverisign以外の会社でも対象によっては何も問題ないのだけど、verisign ならまず間違いなく使えるので。
614 :
名無しさん@お腹いっぱい。 :05/02/23 14:35:39
verisignうぜー。以前ここでドメインとったけど、飽きたから 更新しないようにしたら、自宅に十通くらい 封筒で更新しろしろ迫って来てすんげーしつこかった。 しかも、更新起源切れても二、三回追加で来たし。 更新しないとちゃんと伝えておいたのに。 むかついたんでクレーム入れてやったが。 もう、ここからドメインは取りません。
>612 >613 verisign証明書と自己署名の証明書は基本的には 違わないんですね。 お二方ともご回答ありがとうございます。
616 :
名無しさん@お腹いっぱい。 :05/02/23 16:08:23
>>615 証明書自体のデータ構造としては「基本的に違わない」と言ってもいいかもしれないけど
第三者からの実在性についての確認があるかないかでは
認証という意味ではまったく違うものだと思います。
真の情報化社会を迎えるには 政府レベルで一人にひとつ生涯固定の証明を発行するしかないね 免許や年金・社会保険番号、ソーシャルセキュリティー、電子マネーと共通で
【情報セキュリティ基礎】 617の提案は情報化社会を崩壊させかねない危険な提案である。 その理由に付いて論じなさい。 少なくとも数学的な論点と、社会的な論点について述べる事。
重機ねっと
暗号は解かれるものである 人は騙せるものである
>620 (100点満点で)5点
よっしゃ試験勉強ナシで零点回避w んでそろそろ模範解答を…
>622 そんな不真面目な態度で解説してもらえると思っているのか? 大体0点回避って何の意味があるわけ?普通大学じゃ60点未満で 単位取得できないだろ? ...そうかリアル厨房・工房か... 大学ではそれじゃぁ通用しな いから、頑張ってね。
煽りはいいから答えうp
age は余計だったこれはスマソ
626 :
名無しさん@お腹いっぱい。 :05/03/11 21:31:52
627 :
sage :05/03/11 21:40:42
624
ex
天下のverisign でもこんなことがあるのか… 手持ちのお客様データ真剣に考えようorz 趣旨スレ違いスマソ 鍵が漏れればもっとエキサイティングだったけどね 626氏 指摘乙
630 :
名無しさん@お腹いっぱい。 :05/03/11 22:00:24
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のネタ、もっと詳しい情報があったら教えれ。
>>626 「電車内で盗難」?
これは盗難よりも
パソコンくんが網棚旅行とかに出かけた疑いのほうが強くないか?
車上狙いならまだわかる。
でも電車だし。
スラれたのならまだわかる。
でもパソコンだし。
盗難ねぇ。うーん。
636 :
名無しさん@お腹いっぱい。 :05/03/12 13:39:01
>>635 泥酔して超無防備状態というのもあるかもしれん。
これからは仕事帰りに酒も飲めなくなるのか... orz
>636 仕事帰りに泥酔したければ、危ないものは持ち歩くな(藁 泥酔して財布の中身全部なくすなんて話、良く聞くよ。
某元国会議員のことかー!
CNET、スラッシュドットで取り上げられたな。
640 :
名無しさん@お腹いっぱい。 :05/03/15 10:33:26
最近のベリって、いっぱい人辞めてるらしいぜ。 パソコンどころか社員も管理できてるのか怪しいよな。
私怨逆恨み面白いね(p
642 :
名無しさん@お腹いっぱい。 :05/03/15 18:20:12
s/mimeの証明書を取るにはどこがよい? ISP・ジャストシステムと無関係だと、日立情報システムかUS VeriSignしかない? 情報が少なくて、よく分からん。
644 :
名無しさん@お腹いっぱい。 :05/03/18 00:52:58
>>640 つーか、そういうことより、情報セキュリティコンサルティングなんて
売れる立場か?って感じだな・・・。
>>640 和塩を調べてみた
http://www.geotrust.co.jp/ssl_help/scls3-1.html >Q メール暗号化をしたいのですが、どの商品を選べはいいのでしょうか?
>A 通信経路のメールデータを暗号化する場合は、メールサーバにクイックSSLプレミアムを
>インストールしていただくことで対応できます。 メールの文面を暗号化する場合は、
>メーラーのS/MIME機能を使うために (クライアント証明書)を送信者・受信者の環境に
>インストールすることで対応できます。
うーん、そんなんで大丈夫なんか?
646 :
名無しさん@お腹いっぱい。 :2005/03/22(火) 18:01:03
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 に使う?
無料の証明書って全滅したの?
651 :
名無しさん@お腹いっぱい。 :2005/03/28(月) 14:56:03
>>642 s/mimeの証明書って、メールの暗号化に使うってことかな。
具体的にどういう使い方を考えてるのかがわからないんだけど
仲間内で使うだけなら自作でもええんじゃない?
>>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
658 :
名無しさん@お腹いっぱい。 :皇紀2665/04/01(金) 12:21:08
S/MIMEメールで相手の電子証明書が失効しているのか?を即座に 検証する機能がついているメールソフトってEutlook Expressくらい なんでしょうか? さっきS/MIMEメールを受信しました。相手の証明書はベリサイン発行のものです。 電子証明書の有効性をオンラインで確認すると表題のように 「デジタル ID が失効されていないか、この証明書の失効情報を判別できませんでした。」 こう表示されますが、要するにベリサインの失効情報(CRLというのかな?)に記載されていない。 "有効な証明書"ということなんでしょうか? 一瞬「失効してるID?」と理解してしまったもので
>>658 > Eutlook Expressくらいなんでしょうか?
ボタンを押せば失効確認をしてくれるMUAもけっこうあるね。
> "有効な証明書"ということなんでしょうか?
CRLにアクセスできなかったときとかにもそのメッセージが出るんだろうね。
「有効です」とは言っちゃいけないわけで。
なんか翻訳がタコっぽいんだけど、英語版だとどうなんだろ。
660 :
名無しさん@お腹いっぱい。 :皇紀2665/04/01(金) 23:45:21
>>659 >ボタンを押せば失効確認をしてくれるMUAもけっこうあるね
すいません、たとえばどんな?OutlookExpressはOKでしたがOUTLOOK2003
鶴亀メールはできないです、ベッキーも駄目みたいな話だったんで。
Thunderbirdあたりはできるんかな?
>「有効です」とは言っちゃいけないわけで。
これもよく考えてみればそうですね。でももう少し日本語をなんとかならなかったかなー・・。
まあ、失効確認なんてしなくてええんでね?
662 :
名無しさん@お腹いっぱい。 :2005/04/02(土) 12:32:30
>まあ、失効確認なんてしなくてええんでね? 署名で改竄無が確認できても、「ある資格保持者にしか証明書を 発行しないことで間接的に証明書の持ち主が資格者だと証明する認証局」 ってありますね。 #ただこういう証明書がS/MIMEに使えてるかは?なんですが。 ともあれその場合、電子証明書の失効確認には意味が無いこともナイト 思いますけど。
何でもかんでもPKIでやろうとするのが間違い。 文書の署名者が現在も当該資格を有しているかの確認は、別の方法で確認したっていい。 失効は鍵が危殆化したり、発行ミスがあったときだけでいいんでね?
664 :
名無しさん@お腹いっぱい。 :2005/04/02(土) 17:12:31
>>663 なんでもかんでもPKIでやろうというのではなくいですよ。
>文書の署名者が現在も当該資格を有しているかの確認は、別の方法で確認したっていい。
例が適切でなかったですね。
>失効は鍵が危殆化したり
それを確認したいってことですが。
まあ、危殆化なんて滅多にねーんでね? 毎回失効確認が必要でホントにするってのなら、証明書検証なんて不要になっちゃう罠。
666 :
423 :2005/04/06(水) 21:59:04
667 :
前スレ300 ◆w795LO9.Wo :2005/04/07(木) 00:04:54
>>666 お久しぶりです&gj!
勉強させていただきます。
669 :
名無しさん@お腹いっぱい。 :2005/04/17(日) 08:06:54
保守
670 :
名無しさん@お腹いっぱい。 :2005/04/19(火) 13:30:47
Apache環境で使ってるサーバID+キーペアファイルを IIS環境へ移行することは可能なのでしょうか? VeriSignのFAQにある「互換性」という言葉にひっかかる気がするのですが、 なんとか出来ないものかと。。。 助けてくださいっ!
お詳しい方いらっしゃいましたら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を見られなくてもパケット受信でいろいろ情報が 出てきたのですが絶対安全なものなのでしょうか?
676 :
前スレ300 ◆w795LO9.Wo :2005/04/22(金) 15:19:59
>>674 えっと、なんていうかうまく説明できないけど
あなたの疑問の大半は多分SSLとは何の関係もないと思います。
バスターがアップデート・バグで祭り状態。 私がこのスレに常駐するきっかけになった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
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
保守
>>573 最近、アンカー先と同様の状況になることが良くあるんですけど、ページを正常に開く対処方法はYESを押すしかないのでしょうか?
特に、プロバイダのページや、銀行、ショッピングサイトでなります。
OS:XPSP2
ほしゅ
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
693 :
名無しさん@お腹いっぱい。 :2005/07/30(土) 08:56:20
はいはい見てますよ。 元々、ちょっと解せない事象なので 再現してないなら、それはそれでいいんじゃないですか? なにせ再現しないことには確認のしようはないし。
695 :
名無しさん@お腹いっぱい。 :2005/08/01(月) 09:44:30
>>694 このスレ的には
これのどこを読めばいいんでしょうか?
697 :
名無しさん@お腹いっぱい。 :2005/08/10(水) 20:21:23
こう淋しいと、思わずコピペにでもレスしたくなるよなw
698 :
名無しさん@お腹いっぱい。 :2005/08/24(水) 09:02:41
みんな。公的個人認証は取ってるかい?
700 :
名無しさん@お腹いっぱい。 :2005/08/25(木) 09:42:54
それあると何ができるの? S/MIMEとかに使える?
702 :
名無しさん@お腹いっぱい。 :2005/08/25(木) 15:26:58
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
706 :
名無しさん@お腹いっぱい。 :2005/09/20(火) 23:26:52
保守
707 :
名無しさん@お腹いっぱい。 :2005/09/26(月) 12:36:27
>>703 > そうだよなー。
> やっぱ使い道ないもんなぁ。
> e-Taxに使えますよっ!
e-Tax使う場合だと
公的個人認証が一番安くあがるんじゃないかな。
カードリーダーライターの費用入れても。
企業の場合でも、代取の個人認証でいけるし。
自動車の運転免許証を身分証明に使う場合 項目に「氏名の読み」と「性別」がないんだよね。 ということは、男女どっちでも読めそうな字面の人が 免許更新時に仮装すれば、性別詐称が出来ちゃうかもよ。
709 :
名無しさん@お腹いっぱい。 :2005/09/29(木) 19:18:33
数字にその辺の隠し情報は載ってる
セキュリティの警告「セキュリティ証明書は有効期限が切れたか、まだ有効になっていません」 というのが表示されたんだけど、これほっといたらまずいのかな?
>>710 何をやったときに出ましたか?
多分、セキュリティ証明書の有効期限が切れたか、まだ有効にないかのどちらかなんでしょうけど。
>>711 有難うございます。amazonマーッケトプレイスで本とか売ってできたお金を銀行に振り込ませる作業を行うときにでました。
>>710 のメッセージの上に「このサイトと取り交わす情報は他の人から読み取られたり変更されたりすることはありません。
しかしこのサイトのセキュリティ証明書に問題があります」
と表示されるので、ほうっておいてもいいのかと思ったのですが、有効でない証明書うんぬんが気になります。
713 :
名無しさん@お腹いっぱい。 :2005/10/07(金) 21:46:47
>>712 そのサイトの証明書に問題があるんでしょうね。
問題なければアドレスを教えてください。
715 :
前スレ300 ◆w795LO9.Wo :2005/10/08(土) 00:12:33
>>714 やってみたけど再現しません。
そのページ(
https://ですよね ?)が表示されている状態で
ブラウザ右下の鍵のアイコンをダブルクリックして
表示される証明書の「詳細」タブの
「シリアル番号」と
「発行者」の「OU=」の値を教えてもらえますか?
あとできればその時のアドレスも。
>>715 すいません。今確認したら直ってました。サイト側が正常にしてくれたようです。
ありがとうございました。
718 :
名無しさん@お腹いっぱい。 :2005/10/18(火) 15:49:42
NECについてるXPなんですがリカバリした直後、 ゾーンアラームがWindowsExplorerのcrl.verisign.comへの接続を求めていました。 怪しかったので拒否してしまったのですが、verisignのHPを調べてみたら なんかセキュリティの関係みたいなんです。 一度拒否した後接続を求められないので、再接続することができなくてとても心配です。 セキュリティの何かの更新をWindowsExplorerはverisignに求めていたのでしょうか? このまま放置しても大丈夫ですか?
720 :
718 :2005/10/19(水) 18:16:28
>>719 ありがとうございます。
>何かの証明書の取り消し確認に行ってたんだと思います。
接続を拒否してしまったので行けなかったはずです。
それなのにその後、再接続が求められません。
このまま放置しておいても大丈夫なのでしょうか?
>ゾーンアラームのcrl.verisign.comの設定を解除してはいかがですか?
一度接続を求められたとき、拒否はしたものの、拒否設定にはしていないので
その後WindowsExplorerが接続をすればまた接続を求めるメッセージが出るんです。
しかしそれが出ないということは、接続を求めていないということです。
>>720 わかんない。
でも、証明書の取り消し確認に引っかかって
無効証明書だからどーたらこーたら…
などという事態には、一度もなったことは無いな。
少なくとも私は。
IEの信頼済みゾーンに*.0.0.0.0を誤って記入してしまったが、削除しようとしても削除できない。 レジストリで一括削除とかでもいいので何らかの削除方法ないですか?
723 :
718 :2005/10/23(日) 17:33:20
>>721 そうですか。しばらく様子みてみます。
ありがとうございました。
前者の方が100倍ましかと 今ではJRE1.3なんてまともに配布してないし、 入れたら即トラブルだ。
これがね。省庁毎に要求してくるJREのバージョンが見事にばらばら。 特定環境に依存せんようにjavaなんかと思えば windowsオンリーばっか。 全くなにやってんだか。電子政府って。
団塊の世代で一番数が多いのが、戦後間近の昭和22年(1947年)生まれですので、その方々が60歳で定年を迎えた場合には、2007年となるためです。
∧_∧ ( ´∀`) / ̄ ̄ ̄ ̄ ̄ ( ) < ねェねェ、VeriSignって偉いの? | | | \_____ (__)___)
731 :
名無しさん@お腹いっぱい。 :2005/10/30(日) 20:57:30
偉そう
>>726 そうそう。
担当者に直接言ったことあるが…
「そうですねぇ。」
だってさ。
彼らも上から言われてノルマこなしてるだけだから、どーしよーもねーな。
各省庁、自治体間で統一するよう意見書出したいが、 パブリックコメント募集しないかな。
強力な独裁者でも出ない限り無理 ある意味それが健全な社会の証なのかもw
735 :
前スレ300 ◆w795LO9.Wo :2005/10/31(月) 06:06:55
とりあえず小泉くんにメールしてみてはどうだろう。
S-JISテキストとCSVだけで沢山だ!
おお。いいねぇテキストデータ主義。 基本的には賛成だけどXMLも便利よん。
>>735 とりあえず「首相官邸」で意見を提出しておいた。
これでもしなんか動きがあったりしたらビックリしちゃうよな。
どっかの軍事大国にでも占領してもらおう 改革がサクサク進むぞ
>>739 日本語廃止になったら、日本語処理いらないから文字コードに悩まなくていいしね。
そのかわり脳内変換処理に時間がかかるように・・・
英語が国語になったら1科目減る?
卑賤領民の運命なんて占領国次第ですよ。
>>728 Microsoft VMのサポート終了
>>738 >とりあえず「首相官邸」で意見を提出しておいた。
おおお。返事来たよ!
----- Original Message -----
From: "首相官邸HP発信専用" <
[email protected] >
To: <***@********>
Sent: Wednesday, November 02, 2005 9:06 AM
Subject: [首相官邸より]
> ご意見等をお送りいただきましてありがとうございました。
> いただきました国政へのご意見・ご要望は、今後の政策立案や執務上の参考とさせていただくとともに、内閣官房、内閣府、総務省、経済産業省へも送付させていただきます。
>
> 首相官邸ホームページ「ご意見募集」コーナー担当
テンプレだ_| ̄|○
∧_∧
( ´∀`) / ̄ ̄ ̄ ̄ ̄
( ) <
>>745 だね。
| | | \_____
(__)___)
捕手 城島
ネタないなぁ。
一ヶ月お試し証明書ってまだやってるの?
やっぱ、取るとかっこいい代物かなぁ? 証明書って。
753 :
名無しさん@お腹いっぱい。 :2005/12/10(土) 11:22:14
>>753 かっこよくなかったら、個人じゃ誰も使わんよ。個人に使ってほしくねーのかね。
755 :
名無しさん@お腹いっぱい。 :2005/12/11(日) 11:57:10
今のところ個人はそんなに眼中にないんじゃないかな。 やっぱ企業だよ企業。
そっか、個人は関係ないのね。 しかし、企業だとPKIとかやろうとしたら、マジ大変だと思うんだが。
>>756 自前でCAやると大変だからこそ、ベリサインとかの出番なんだが
>>757 客からCA作れと言われてる私は死んだも同然です。
>>758 CertWorker買っておしまい、っつーわけにはいかんの?
立ち上げや運営まで期待されてんの?
それなら難儀な話しだが。
3日くらいでSSLの概要を理解できない客みると、大卒資格剥奪した方がいいと思ってしまう。
確かに機関車は難しいよ。
>>759 すべて、作るんだと。これからどれだけRFCを読まねばならないか…。
しかし、客は春には試験運用だと、君一人でやるんだと、本気です。
X.509証明書はキッチリ公的なヤツから持ってこいなどと、まるで遠くで聞こえる春雷のようです。
大企業は、創造性が無いくせに、多くの規格に簡単に対応できれば技術力があると。
そのぐらいうちの会社じゃ当たり前だよーん、ていうのが凄いと、勘違いしとるのです。
>762 とりあえず、上司に保険の話してみれば? 会社の法務部に蹴飛ばされるか、提携しようとした保険会社に ふっかけられて、現実を知るだろう。
暗号の専門家を沢山抱えている某電話会社ですら、未だに ルートCAやらない理由はリスクをきちんと把握できないから。 リスクを把握できないと保険料率も決まらんからね。 社内システム向けに独自CAを使っている会社はいくらでも あるけどな。
>765 イ`。馬鹿上司のために吊るなんて馬鹿馬鹿しいぞ。 漏れも馬鹿上司のせいでメンヘラになってしまったが、なんとか 生きている。
>>766 新しいソフトに軒並み対応してない 確認できない
ニフティー自体が開発してないのでどうしようもない
保守。 e−tax使うなら、台鳥の個人の認証使うほうが安上がりだよ。 カードリーダーライターは要るけど。
771 :
名無しさん@お腹いっぱい。 :2006/01/02(月) 11:31:14
おめあげ。 ベリサイン自体のネタは最近あんまりないね〜。 電子認証全般のネタやってる板やスレはどっかあるのかしらん。 ことしもよろしく。
なんて寂しいんだ。 自動車登録のワンストップサービスも始まっているというのに。 ベリには関係ないけどね。
773 :
名無しさん@お腹いっぱい。 :2006/01/22(日) 13:35:22
一般顧客向けのメールに証明書つけようと思うんだけど、BtoCでそんなことやってるの聞いたことないので ちょっち二の足踏んでる。 どうかな?
774 :
名無しさん@お腹いっぱい。 :2006/01/22(日) 15:14:33
>>773 決して悪いことだとは思いませんが
変なメールが着た、と不安になる人も居るかもしれません。
大事な書類はPDFにして電子署名入れとくといいかも。
でもちゃんと電子署名入ったPDFってのもなかなか見かけないんだよなぁ。
官報ぐらいか。
>>775 そうなんだよね。
「勲章マーク付いてたら署名つきメールなので安心ですよ」なんつーといて
ご丁寧に偽の電子証明書まで作って署名された日にゃ
電子認証のことをちゃんとわかってないとコロっとだまされちゃう危険性が。
OEの電子署名機能って、あまりに知られなさすぎだからねぇ。
777 :
773 :2006/01/23(月) 12:55:54
まあ、周知はしっかりやるつもりではいるんだが、 偽署名か。うーむ。
>>777 お客さん側にちゃんとした知識があって正しい運用が出来ないと
「赤い勲章マークの電子メールは署名入りで安心です」とか程度だと
むしろわざわざ騙されやすくしてしまうんじゃないか、っつーことね。
電子証明書の確認までやってもルート証明書から偽造されたら。
ルート証明書のフィンガープリントとかをちゃんと確認までしないと。
その証明書情報までフィッシングされてたら?
気にしていたらキリがないが、利用者側の知識があやふやだと
せっかくのセキュリティもなんら機能しませんからね。
779 :
773 :2006/01/24(火) 19:04:48
つうことは、なんでもかんでも署名つけるのはNGだな。 署名つけたほうがいい場面を想定したほうがいいな。
企業のPDF版プレスリリースやお知らせ、お詫びの類も電子署名入ってるもんなんか、ほとんと見たこと無い。 それに手を入れて改変して、ご丁寧に偽証明書で電子署名なんか付けちゃえば いかにももっともらしい怪文書、一丁あがり!だね。
781 :
773 :2006/01/24(火) 19:39:22
なんだよw 意味ねえのかなあ。ベリサインの啓蒙活動とかねえのかな。
>781 特定の相手に渡す文書なら、pdfの署名も意味があるだろう。 #糞高い紺猿レポートとかね。 啓蒙活動は難しい。そもそも一般人がVerisignの名前を知る はずもない訳で、そんな知らない会社が保証すると言われて も、なんのこっちゃ?だろ。 それにルート証明書の信用度を測る方法なんてあるのか? 結局会社の知名度や対応ブラウザ数ぐらいでしか測れないだろ。
>>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
cacert.orgあたりがIEにデフォルトで入らんもんかね
その前に、LGPKIとかGPKIってどういう扱いなんだっけ?>ルート証明書
送信元メールアドレスが正しいことww
kwsk
790 :
名無しさん@お腹いっぱい。 :2006/01/25(水) 00:59:06
ところで「ハードディスクからサルベージした削除済メール」に証拠能力あるんかね。 送信元メールアドレスなんかはどうとでもなるしさ。
791 :
名無しさん@お腹いっぱい。 :2006/01/25(水) 01:01:27
>>791 無い、と思う。(Mac OS X 10.3)
いくらがんばってGPKIやLGPKIっつってもWindowsに
デフォルトで入ってないんじゃなあ、と思うべ?
役所でCD-ROM配るような特殊な運用でなければ
一般ユーザー向けには今後もベリでも使っとけってこと
なのかなと思う。
フィンガープリントを確認とか、普通やらせたくないよなあ。
793 :
名無しさん@お腹いっぱい。 :2006/01/25(水) 01:39:04
794 :
773 :2006/01/25(水) 14:31:38
「鍵マーク付いてたのにフィッシングサイトだった」って感じか。。
773さんの相方をつとめさせていただいておりますのは わたくし790-792でございます。
796 :
名無しさん@お腹いっぱい。 :2006/01/26(木) 02:35:46
サーバ証明書の検証について教えてください。 アクセス先の証明書の認証では、ルートが信頼できていれば問題無いと 認識しています。 中間証明書は、アクセス元のPCに未インストールだったとしても問題ない はずです。アクセス元にインストールされてるのが有効期限切れだったと しても、アクセス先に有効な証明書がインストールされていれば証明書 チェーンは確立するはずです。 ところが、なぜかアクセス元にインストールされている有効期間切れの 中間証明書が認識されてしまい、証明書チェーンが確立しません。 アクセス元はwindowsなのですが、この現象はOSの設定によるのでしょうか?
>>798 提供されてるけど、Windowsが取りに行かない、っつーことなんじゃない?
800 :
名無しさん@お腹いっぱい。 :2006/01/26(木) 21:02:25
800
>>796 は再現条件晒さないと何も出てこなそうだよ。
質問としては抽象的だから一般論しか返ってこない。
晒しても回答は無しの可能性は高いけど。
804 :
803 :2006/01/29(日) 06:15:04
>>803 補足。
後半はルート証明書の更新の話。中間証明書じゃない。
805 :
802 :2006/01/29(日) 09:13:39
>>803 >
>>796 ではないけれど。
>
>>802 > うーん。
> サーバが提示した証明書チェーンを無視?
> > 中間証明書をローカルにキャッシュしている場合は
> > 期限切れの際には自分で更新しろ
> 少なくともデフォルト設定ではそんな糞実装ありえへんと
> 思うんだけど。
「キャッシュ」という書き方は適切じゃなかったです。
問題の証明書がインストールされていない場合に
Windows/IEが内部的にキャッシュするものについては、きちんと更新されると思います。
インストール=証明書ストア上に置く、です。
中間証明書をローカルにインストールしている場合は
期限切れの際には自分で更新しろ
まーMSが勝手にインストールしてくれてるわけで
自分でそういう運用をしてるわけではないとは思うんだが。
少なくともルート証明書に直接ぶら下がってる鯖証明書に関しては見に行かない 確認できないって言われる
807 :
802 :2006/01/29(日) 10:55:23
808 :
802 :2006/01/30(月) 18:19:26
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 中間証明書を削除するとうまくいくけど
インストールしたままだとダメってことなの?
今日「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」のロゴが付いてました。
814 :
名無しさん@お腹いっぱい。 :2006/02/09(木) 23:34:51
>>813 ぎゃははは。httpsで繋いだら警告出てやんの。
どーこの証明書使ってるんだよw
くれくれ君で大変申し訳ないのですが、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 なんか面白そうなので、よかったらもう少し詳しく教えていただけませんか?
>>818 単純な自己署名の証明書を配布するだけですよ。
ルート証明書は当然オレオレ状態ですが、自分のドメインは持っているので、
そこを配布点にして、希望者に発行しようかと(無料)
ルート証明書をRSA2048bitで作ったので、古くないと使えないw
Webフォームに入力してもらう形をとれば、比較的簡単に大量発行も可能
ですし。(Webプログラミングの能力はないです)
まぁそんなことをぼんやりと考えてたわけです。
証明書の発行は、生々しいプロバイダーのメールに限定しますが。
まだ妄想状態ですので。。。。。。。w
820 :
前スレ300 ◆w795LO9.Wo :2006/02/11(土) 11:36:23
>>819 なるほど。メールとか用の証明書ですか?
AiCAじゃダメ?
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 そうですか。
旧バージョン、見つかるといいですね。
ごめんなさい。ワタシは持ってません。
comodo や thawte のメール用の無料証明書って、 一年後に revoke して同じメールアドレスで再取得できるの? 誰か知ってる人、教えてください。
826 :
前スレ300 ◆w795LO9.Wo :2006/02/12(日) 18:04:19
>>825 thawte は取れますよ。
もう5年くらい使ってます。
ありがとうございます。 取得の簡単な comodo はどうかな?
828 :
前スレ300 ◆w795LO9.Wo :2006/02/12(日) 19:34:16
>>827 thawteも全部英語ですが、慣れれば簡単ですよ。
公的個人認証が使えるっつーのは面白いな。
ですね〜 個人ベースの信用機関はなんとかなりそうになってきたけど、もうすこしがんがらないと。 完全無料のサービスってのは、完全に趣味だから、KIAIがないとつらいですな。
832 :
前スレ300 ◆w795LO9.Wo :2006/02/13(月) 22:46:34
>>831 個人ベースの信用機関ってのがよくわからんのですが。
自己証明書を作ってあげるサービスってことですか?
>>832 S/MIMEとSSL証明書だね。こっちが発行機関の証明書だからオレオレでなくてオレ(個人)が署名。
CAには出来ない様にするけど、暗号化とそのメールアドレスが存在するかしないかの証明くらいにしかならん。
発行が手間&お手軽にS/MIME使いたい人向けかも。
2ch証明機関と同じでない? 信頼性はフィンガープリント見ろと。
あと、出来ればsage
>>833 それなら別にthawteでいいような気がするけど。
英語は面倒だけどルート証明書が信頼されてるし。
2ch証明機関てのは初耳なんですけど、どこ見たらわかりますか?
sageは失礼。チェック外れてた。
>>834 昔作らない?って話が何度も出てるよ。
それと、簡単でないと普及しないからねー。その辺も問題だわ。
837 :
:2006/02/14(火) 07:56:35
ワラタ もともと信用してないけどなw
詐欺師の身元を保証するって事は、CA が詐欺に加担していると言えるな。 いや、詐欺師からカネもらってるから、CA も詐欺師そのものだな。 こういうのは証明パスをどっかに晒して欲しいよ。まじで。
>>838 ベリの場合だと、法人に対する証明書については、
申請者が法人かどうかを確認するだけで
その法人が詐欺だろうが泥棒だろうが関知はしない。
詐欺師や泥棒でも運転免許が取れるのと同じ。
一般人はそうは思わんだろうな。 そこが問題。
>>836 うっかり写真のとこクリックして星澤が画面一杯に表示されて
キモイよー・゚・(つД`)・゚・
>>839 法人登記を確認するというのは、メールだけで取れるのに
くらべれば結構なハードルだと思うよ。
少なくとも使い捨てはできないんでフィッシングサイト
立ち上げるのには使いづらい。
このレベル以上の社会的信用を求めるとすると、それは
CAの仕事か?という問題が。もちろんそういうのが
あってもいいけど。論点ずれとる。
>>839 詐欺師か泥棒かは関係ない。そんなの確認できない。
ある程度の身元の確認ができれば、犯罪者のリスクは高くなる。
身元を明かさずにメールだけで処理できるのは手抜き過ぎ。
CAはカネを出してくれるほうの味方。
だまされた間抜けな一般人に対しては、賠償責任無いしね。
>>844 来ましたねー。
だから鍵が出てるだけではダメなんだってば。
さあ、CRLの力の見せ所だぞ! ちゃんと実装してるのかなあ? …実際どうなんでしょうか?
847 :
名無しさん@お腹いっぱい。 :2006/02/15(水) 23:55:43
>>846 「失効」なんつーのは見たことないもんなぁ。
ふつーわ。
ちょっと教えてくれ。 thawte から無料でもらった鍵で暗号化したメールは、 その気になれば thawte が復号化できるってことか? 秘密鍵のコピーを保存してるかも知れないぞ。
849 :
名無しさん@お腹いっぱい。 :2006/02/16(木) 01:22:20
渡していないという証拠は無いだろ
>>850 確かに自分で検証したわけではないからその通りだ。
まーThawteが信用出来ないなら使わなければいいだけだし。
第三者からの信用を犠牲にして自己証明書を使うか
お金払ってベリや国内のCA(JCSIとか)から証明書取るか、ですな。
>>848 > thawte から無料でもらった鍵で暗号化したメールは、
ていうか、そもそも秘密鍵はThawteからもらうんじゃないし。
CryptAPIで申請人自身が自分が作って、PKCS#10で証明書要求を出しているのだと思われ。
キーペアは自分で作って、公開鍵をThawteに渡して証明書を発行してもらう。
秘密鍵は自分のマシンから出て行かないし、出て行ってはいけない。
Thawteは「申請人は、申請されたメアドでメールが受信できること」=メアドの実在性を確認・証明してくれるだけ。
メアドの実在証明だけで、他の一切は証明してくれない。だからタダ。
名前とか住所とか勤務先とかまで証明して欲しかったら有料になる。
>>852 まあ、理屈では、あんたの言うとおりなんだろうけどね。
おいらは comodo で取得したが、ウェブでメアドと名前を入力したら、
メールが送られてきて、そのメールの文中のボタンをクリックしたら、
それだけで証明書や鍵がインストールされてしまったぞ。
どのマシンで何が処理されたかなんて、ユーザには判らんぞ。実際。
鍵屋で鍵を買うようなもので、疑い出したらキリが無いがな。
すくなくとも可能性としては認識すべきだな。
おいらは PGP を使ってるから心配ないがね。
>>853 安易に根拠もなく信頼するよりはちゃんと疑ったほうがいい、とはワタシも思います。
でもまあやみくもに疑ってもキリはないし。
だけど「タダのものを過信するな」ってのは大事でしょうね。
セキュリティもんを本気で使うんなら
ちゃんとお金を払うか、完全に自己責任でやるか
どっちかでしょうね。金を使うか頭を使うか。
PGPはワタシは詳しく知らないんだけど
本人性の担保というか、第三者への認証は可能なのか?
てのはとても興味があるので調べてみたいと思います。
>>853 ひやー、comodoスゲエ。
一回試してみるか。どんなもんか。
>>853 > おいらは comodo で取得したが、ウェブでメアドと名前を入力したら、
> メールが送られてきて、そのメールの文中のボタンをクリックしたら、
> それだけで証明書や鍵がインストールされてしまったぞ。
comodoってジャパンではなく本国の方ですよね?試してみました。
証明書発行の仕組み自体はThawteと同じでMSCAPIを使っているようです。
Thawteは他に免許書番号みたいな個人で一意の情報を自己申告させますが、
comodoは確認内容が「指定のメールアドレスでメールを受信できること」だけですね。
こっちの方が簡単でいいですね。メールアドレスの実在証明だけなら。
> どのマシンで何が処理されたかなんて、ユーザには判らんぞ。実際。
たしかにそうですね。
この流れだとキーペアは自動的に自分で作ってるけど、ユーザーには判らんっぽい。
858 :
854 :2006/02/17(金) 15:48:19
>>857 なるほどねー。うまい仕掛けですね。
勉強になりました。ありがとうございます。
859 :
854 :2006/02/17(金) 19:16:07
>>856 秘密鍵は申請したマシン上にしかないはずだから
申請したのと別のマシンで証明書を取得すると失敗するはず。
>>859 要するに自分のマシンか接続先かということ。
> 秘密鍵は申請したマシン上にしかないはずだから
comodoの場合は全自動で処理されるから、
接続先にコピーされても判らんっぽい。
861 :
名無しさん@お腹いっぱい。 :2006/02/17(金) 22:14:07
>>860 CAPIを使っているみたいだから無理だと思う。
話がずれてる。CAPIとか関係ない。 接続先とはcomodoのこと。
863 :
名無しさん@お腹いっぱい。 :2006/02/18(土) 02:40:27
>>862 キーペアは自動的に自分で作っている。
秘密鍵は、仕組み的には外に出ようがない。
comodoからダウンロードしたプログラムがローカルで動くとかじゃない限り。
それをあんたが実際に確認したなら別にそれでいいんじゃない? さげ。
COMODOが鍵作ってルート証明書といっしょに突っ込まれても 見分けがつかないと思うが
んだ、んだ
だから無理だっつってんのに。 そんなにcomodoが信用できないなら使わなきゃいいだけでしょ。
COMODOはどうでもいいけど 863はなぜ自分で作っているとわかるんだ?
なるほど 2つめのも表示されたんか
871 :
:2006/02/18(土) 11:13:36
ローカルにファイルを保存する警告だよ、2番目は。 証明書ストアに保存する場合は出ない。(自宅のWin2003CAにて確認済み)
874 :
名無しさん@お腹いっぱい。 :2006/02/18(土) 12:45:40
CryptAPI のちょうどいい解説が見つからないわ。 まー脆弱性ありまくりのMSの機能だって信用できんと言われればそれまでだが。
>>873 いやいや1つ目は出るだろ?
2番目のは秘密キーを単独でファイルに保存する場合
(Authenticodeの署名用の証明書の取得の場合など)
に出るメッセージだから、comodoのメール用証明書の取得の流れでは出ない。
>>869 はCryptAPIがWEBページからの依頼でローカルに秘密鍵を作る際に出される
セキュリティ確認メッセージの例で、comodoで両方出るわけではない。
なるほど 1つ目が出れば自前の秘密鍵だとわかるんか? でも、これってルート証明書入れるときも出るんちゃうか?
878 :
名無しさん@お腹いっぱい。 :2006/02/18(土) 13:55:44
なんにしろ、Thawteもcomodoも、一応はちゃんとした認証サービス会社。 (=Windowsがデフォルトでルート証明書を保持している) 無料サービスはあくまで有料サービスのお試し用というのが狙いだと思う。 だから、証明書の発行の仕組みとかをわざわざ変えて タダの利用者にはインチキくさいことをする、なんてことはちょっと考えにくい。 企業として、わざわざ手間かけてそんなことするメリットがないのでは? 認証サービス会社の場合、信用を損なうというデメリットは致命的だから。 素性もよくわからないところならともかく。
>>878 とはいえ、Windowsで証明書に関するセキュリティがどのように守られているのか、
まさしくいまここでああだこうだ言っている話が
利用者にとってわかりにくいというか、ちっともわからないというのも事実。
今回あらためてよくわかった。
結局はMicrosoftと自分が利用する認証機関とを信用することが前提
ということになってしまう。
安全な電子社会への道は遠いね。
869は鍵を作ってるスクリプトが証明書を要求してるよという警告ですか それ以外にはこのダイアログは出ないと だから自前だよと しかし、それは一般ユーザには、わからないね ダイアログの表示にも書いてないし COMODOのルートは数年前と変わったし、昔のOSには入ってないよ
只のサービスはルートばら撒きが目的かも
>>880 アホか
ダイアログなんていくらでも偽表示できるだろ
鍵を仕込むのは無理だろうが
>>885 鍵を仕込むのは無理ってのはどういう意味?
887 :
880 :2006/02/19(日) 18:44:49
>>885 そうかい。でも、もうどうでもいいよ。
すまんな。
興味があったので、comodo の無料証明書取得の仕組みを調べてみた。 大筋の流れとしては、 ローカル:キーペアの作成 ローカル:CSR(証明書要求)の生成&送信 認証局側:申請内容の確認 認証局側:証明書発行 ローカル:証明書受け取り ローカル:証明書とキーペアを証明書ストアに登録 となる。 ここで利用されている Windows の Microsoft Enrollment Control の仕様を信用するならば 証明書受領前にキーペアの秘密鍵を取り出すことは、利用者本人ですら出来ない。 受領した証明書はWindows証明書ストアに登録される。 ここから秘密鍵を取り出すのは、ローカルの操作でしか出来ない。 (外からそんな事が出来ては大変だ。)
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システム内のどこかにこっそりしまわれており、 証明書を受領するまでは直接触ることはできない仕様になっているらしい。
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 というメソッドで 受け取った証明書と、どっかにしまってあった秘密鍵とをセットにして、証明書ストアに格納する。
>>888-890 というわけで、comodo の無料メール証明書取得の際の秘密鍵は
comodo が作るのではなくローカルで生成されており、
comodo に送信もされていないはずである。
PKIの仕様とMSの実装を信用する、という前提ではね。
あっはっはっは。もう三月ですよ。春間近ですよ。出来てねーですよ。 わっはっはっは。
895 :
名無しさん@お腹いっぱい。 :2006/03/04(土) 18:28:12
897 :
896 :2006/03/05(日) 11:14:50
898 :
名無しさん@お腹いっぱい。 :2006/03/08(水) 02:56:15
存在証明してこの値段って Toriton, Inc はちゃんと利益でてんのかね
899 :
名無しさん@お腹いっぱい。 :2006/03/08(水) 04:09:36
900 :
896 :2006/03/08(水) 21:13:15
>898 存在証明といっても、ユーザに各種書類を提出させて、転送不要指定の 配達記録郵便送って、返事が帰ってきたら情報に矛盾が無いことを確認 するぐらいじゃあるまいか。 証券会社に口座を作ったときもそれぐらいだったし、他のCAなんか個人 契約なら免許証のコピーしか要求されなかったよ。
保守しとこう。
このスレはワタシが立てたんじゃないんだけど、ほぼレギュラーメンバー状態。 今の状態だと次スレって別に要らないようにも思う。 でもベリに限らず、電子認証とか電子証明書とか一般の話題にふさわしい場所が他にないのなら そういうスレはあっていいように思う。 今まで何回か聞いてみたけど、ほかに適切な板やスレがある、という話を聞いたことが無い。 もし無いなら PKI 全般の話題のスレとして次スレを立ててもいいように思うけど ここがふさわしいのかどうなのか、ちょっと自信が無い。 それ以前にスレ立てしたことがないので、作法とかがわからない。 情けない。
980まで行ったら次スレ行こうよ
PGPとかS/MIME専門スレならあるんだがな。 PKI総合スレでいいんじゃない? テンプレは次スレでまたーり作ろうじゃないか。スレタイだけは考えないとね。 ↓改良キボン 【PKI-SSL-CA】公開鍵認証基盤【電子証明書】
>>904 投資ファンドって時点で怪しいもんですから
>>906 怪しいからいろいろ触ってたらますます怪しかったのよ。
保守しとくかね。
909 :
前スレ300 ◆w795LO9.Wo :2006/04/21(金) 13:04:48
CRL配布のプロトコルにLDAPを使っている電子証明書が、ICカードもんを中心に割とあるようです。 企業内LANとかでLDAPが外に出られないので使えない、という話を時々聞きますが さらに「LDAPを通さないプロバイダ」もある、という噂も聞きました。 そんなプロバイダがあるんでしょうか? ご存知の方、居ませんか?
911 :
名無しさん@お腹いっぱい。 :2006/04/30(日) 23:13:48
テッド 早く株価あげてくれ。
912 :
名無しさん@お腹いっぱい。 :2006/05/11(木) 12:27:31
ほす
913 :
名無しさん@お腹いっぱい。 :2006/05/17(水) 09:53:10
914 :
名無しさん@お腹いっぱい。 :2006/05/26(金) 08:52:15
>>913 こんなの誰が見るんだよって笑ってたら
なんか法務省民事局の「商業登記に基づく電子認証制度について」のリンク先が
いきなりホゥ!ティービーになってるし。
なかなか思い切ったことするな、法務省。
915 :
名無しさん@お腹いっぱい。 :2006/06/02(金) 22:12:59
法務省
916 :
名無しさん@お腹いっぱい。 :2006/06/13(火) 10:10:09
ってことはそのうち掛けるのか 結構高いのもあるな
ほし
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
ほんとに「拾った」のか? 年齢証明が必要になったとき都合よく保険証落ちてたりする? しねーよ。
保守。 公的個人認証のカードリーダーは役場でも一緒に売ればいいのに。
924 :
名無しさん@お腹いっぱい。 :2006/08/25(金) 12:15:50
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
まったくここは時の停まった部屋だな。
正式/日本語版が出たので、 Windows PowerShell を入れて遊んでるんだが スクリプトも署名入りじゃないと動かないセキュリティ・ポリシーがデフォルトになってる。 開発者・技術者もPKI避けては通れない時代になってきましたな。
WSHがノートン先生のせいでほとんど使い物にならなくなったのが トラウマになってるんだろうな
>>932 なんで自分で書いたスクリプトを悪質呼ばわりされるのか、と
悲しい気持ちになりましたよ、ええ。
漏れは証明書サーバー立ててるから署名し放題だぜ
オレオレ証明書?
937 :
名無しさん@お腹いっぱい。 :2006/11/17(金) 10:15:29
コード署名とかで 自分だけで使う分には べつに自己証明書でもいいとは思うけど。
938 :
名無しさん@お腹いっぱい。 :2006/11/17(金) 11:05:45
三菱東京UFJのオンラインバンクがノートンにばしばし検疫されまくって いるんだが・・・
939 :
名無しさん@お腹いっぱい。 :2006/11/26(日) 20:14:49
サポートの女性の高圧的な態度はどうにかならないのかねぇ・・・
age
>>939 そういうのは、「電話の担当を変えてくれ」と、ごり押しすればOK。
で、変わったら、「ヒドい人だったと」とでも言ってスッキリしとけ。
942 :
名無しさん@お腹いっぱい。 :2006/11/29(水) 19:32:05
これじゃあもう次スレは要らないなあ。 PKI汎用で立てようかとも思ってたけど。
943 :
名無しさん@お腹いっぱい。 :2006/12/01(金) 20:26:47
944 :
名無しさん@お腹いっぱい。 :2006/12/21(木) 12:35:03
>>944 雑誌を売りたいが為の記事って感じだね・・・
実際、記事中ではどの暗号の鍵が破られ、それが何ビットだったのかなど、 具体的な内容は語られていない。 また暗号が解かれたのはEdyのように書かれているが、それも明らかにはしておらず、 客観的に見て、説得力に欠ける内容になっていることは否めない。 この時点で胡散臭すぎだろw
948 :
名無しさん@お腹いっぱい。 :2006/12/21(木) 22:26:00
もうウソがバレまくってるけどね アホ信者必死だなと せめて板で暴れて汚し回るなクズと言いたい。
このスレに何の関係があるんだ?
まぁ来週のIPAの発表待ちだな。 万一本当に破れるとなったら、Sony社の存続すら怪しくなってくるが。 デマだったら風説の流布でタイーホの予感。
951 :
名無しさん@お腹いっぱい。 :2006/12/21(木) 23:45:09
何度目の嘘つきなんだかこいつは
>>950 IPAは「ハードのことはうちは専門外」とか言って逃げたよ。
で、話されていることの半分は本当で、半分は嘘なんだとさ。
たぶん、Sonyの方が嘘だろ。
IPAに持ち込まれたネタが嘘なら、IPA自身が否定すればいいし、半分も糞もない。
たぶん、SONYはもう終わり。
>>952 IPA自身は検証してないってだけの話だろ。
>>953 もし、そうだったら、半分が嘘とか言う必要もない。
>>954 熱くなってるところ悪いがスレ違いだから帰れボケ
ハードの話をIPAに持ち込んだ馬鹿がいるという 単なる事実が「半分」なんだから当たり前だろ。 VeriSignとぜんぜん関係ない話をスレに持ち込む馬鹿がいるみたいに
何言ってるんだ。 中身が剥き出しになった時点で、もうアウト決定なんですけど。
959 :
名無しさん@お腹いっぱい。 :2007/01/05(金) 17:24:14
>>956 まあ、ベリの話しだけではもう全然ネタがない。
ベリにはサーバー管理者やプログラム開発業者はともかく
一般人が利用できるような商品サービスはほとんどないしね。
そういう意味ではベリスレはもう役目を終えたんだろうね。
でもPKIとかのセキュリティ技術一般のネタを扱うスレもオレは知らないので、ネタとして持って来ました。
まあ確かに普通にスレチではあるけどね。
どっかそういうスレがあったら教えてください。
ないなら、ここがdat落ちしたら次スレはベリスレでなくPKIスレか認証技術一般かなんかで立てようかとも思ってます。
Felicaは高速処理のため、PKI使ってないんだよね。
だから場合によっては破られる余地もあるのかもしれないと思った。
まーなんにしろスレチだね。ははは。
じゃあ次スレはPKI総合にするか
>>935 事故署名とかわらねーじゃん、馬鹿?www
変わらないというか自己署名だ
まぁルートCAは皆自己署名だが。 その運用者を信頼するか否かだけだよ。
964 :
名無しさん@お腹いっぱい。 :2007/03/12(月) 09:29:59
紙幣なんて紙じゃん?
紙幣は、汚損・破棄しても罪に問われない。 ゆえに銀行強盗対策で、盗もうとされたとき、インクで汚すのは 法に触れない。
967 :
9 :2007/03/13(火) 23:21:16
おまいらテクセ受けるん(´・ω・)?
OCSP調子悪いので、しょっちゅうエラー出るんですが仕様ですか?
969 :
名無しさん@お腹いっぱい。 :2007/03/15(木) 11:55:54
970 :
名無しさん@お腹いっぱい。 :2007/03/27(火) 01:26:42
ベリサインのSSLマーク出してるショッピングサイトで買い物して、 メールフォームからオーダーしたんだが、全然反応ない。 よく調べると、リンクも何も無い偽マークだった…。orz てか、メールフォームも後で気付いたけど、 SSLのページじゃないし、POST先も無料メールフォームサイトのCGIになってた…。orz これってどこかに通報した方がいい?
972 :
名無しさん@お腹いっぱい。 :2007/03/27(火) 15:40:07
>>970 オレもオレも教えて。それって完全に詐欺じゃん。
ていうか、ちゃんと鍵マーククリックして証明書まで確認しないとSSLの意味ないよ。
ていうかそもそもSSLでもなかったって時点で…。
>>970 肝心のURLを書けよボケが
ひろみちゅ先生に報告したい
いやさ、晒したいのはやまやまなんだが、エロイページなもんで…。orz 俺の個人情報が…。
975 :
名無しさん@お腹いっぱい。 :2007/03/27(火) 18:28:39
>>974 晒すだけで個人情報漏れちゃうようなエロページなの?
別にあんたがどんなエロページ見てようがオレには一向に関係ないから。
ただ明らかな詐欺のサイトは糾弾すべきじゃないかい?
直アドになにか問題あるなら、ヒント希望。
もしくはあれだろ?困ってるのはあんたじゃなくあんたの友達なんだろ?多分。
そろそろ次スレの季節かな。 PKI総合って需要あるんかね?
じゃあこのスレは一代限りで終わりかな。 本当にいろいろ勉強になりました。 またどこかでお目にかかりましょう。
【トラックバック来たよ】 (ver. 0.11)
[タイトル] 【日本ベリサイン】MicrosoftR Windows VistaTM の対応予定時期の変更とお詫び [03/12]
[発ブログ] お詫び+(仮)@2ch掲示板
http://news22.2ch.net/test/read.cgi/owabiplus/1175303245/l50 [=要約=]
MicrosoftR Windows VistaTM の対応予定時期の変更とお詫び
お客様各位
本年1月26日にマイクロソフト社の新OS、Windows VistaTMへの弊社製品の対応予定について、当初その対応予定時期を3月初旬とご案内していましたが、5月下旬と変更させていただくことになりました。引き続きご迷惑をお掛けすることをお詫び申し上げます。
* 2007年3月12日時点での状況のご報告
製品出荷版(RTM版)にて、マネージドPKIの動作検証を実施しておりますが、Windows VistaTMの仕様変更に伴う修正に時間が掛かっております。
引き続きマイクロソフト社および米国ベリサインと協力し、早急に対応すべく鋭意作業中でございます。ご不便をお掛けいたしますが、よろしくお願い申し上げます。
* 対象サービス
o ベリサイン マネージドPKI 6.0
o OnSite 4.6.1
* 対応スケジュール
5月下旬の対応を目指し鋭意作業中でございます。具体的な対応予定日が決まり次第ご連絡をさせていただきます
* Windows VistaTMについて
MicrosoftR Windows VistaTMの詳細につきましては、マイクロソフト社の Webサイトをご確認ください。
http://www.microsoft.com/japan/windowsvista/default.aspx
980 :
名無しさん@お腹いっぱい。 :2007/05/09(水) 22:32:39
981 :
名無しさん@お腹いっぱい。 :
2007/05/10(木) 08:44:07 >>980 ははは。
こんなのが980番でとどめ刺しちゃったか。