Takayuki Nakamura's blog: 名前ベースのVirtualHostでそれぞれのSSLサーバ証明書を使う2007年7月4日 名前ベースのVirtualHostでそれぞれのSSLサーバ証明書を使う ＃なんだかんだしてたら、半月経ってしまった ＃来週になったら、ちゃんと再開 『Name-based SSL virtual hosts』 より 名前ベースのVirtualHostでSSLを使う場合、以下の方法をとれば、それぞれのVirtualHostごとの証明書を使うことができます。 ワイルドカード証明書を使うCN=*.example.com という設定の証明書を使えば、www1.example.com と www2.example.com で共通のサーバ証明書を使うことができます。 subjectAltNameを使う 証明書の subjectAltName に別名としてVirtualHostのDNS名を書いておきます。サーバにセットする証明書は１つですが、証明書内の別名をチェックすることで、「証明
証明書に関するshin-uemonのブックマーク (11)
-
shin-uemon 2007/07/04
-
-
LDAP によるデジタル証明書の発行
9. LDAP によるデジタル証明書の発行この章の焦点は、デジタル証明書を LDAP サーバ内に発行する方法にあります。 Certification Authority (認証局) を運営するならデジタル証明書を発行する必要が あります。LDAP への発行は、この情報をネットワーク内で利用できるようにする シンプルな方法のひとつです。また、証明書対応ソフトウェアの多くも、 望ましいレポジトリとして、ユーザ証明書に LDAP を用いています。この方法ではユーザ証明書を他のユーザ情報と一緒にしておけるので、 データの無駄な複製が必要なくなります。証明書を取り扱うには暗号ツールキットが必要です。 ここで使用するのは OpenSSL です。 9.1. LDAP サーバの設定ここで使用する LDAP サーバは OpenLDAP 2.0.x です。LDAP サーバは、証明書を記録するための属性を持てる
-
-
証明書の失効とCRLの発行
証明書の失効とCRLの発行 2003/6/14作成 2004/9/19更新 主にクライアント証明書の場合ですが、発行したあとに秘密鍵が盗まれたり、紛失することがあります。 具体的には、pkcs12のファイルを勝手にコピーされたり、秘密鍵がビルのOSと一緒に心中してしまうこともあります。 また、発行した人が意図的に誰かに秘密鍵を配布したり、譲渡する可能性もあります。 そういった証明書をいつまでも信用するわけにはいかないので無効となった証明書のリストをCAから発行してクライアント証明書の検証をするWebサーバに配布します。 １．証明書の失効 さっそく、証明書を失効します。 CAで発行した証明書を使ってCAで失効手続きをすることになります。 -revokeオプションのあとに、CAが発行した証明書を指定します。
-
SSL用証明書の作成(Windows編)
Windows環境でopensslによる各種の鍵や証明書の発行について整理しました。 Linux系は結構いろいろなサイトで紹介されていますが、Windowsについては環境が異なることからなかなかそのままではうまくいきません。おやじも何度かトライしては失敗してきたので、ここで整理しておくことにしました。今回は、たまたまBBSでクライアント証明書に関する話題もあがっていたので、それについても整理しました。 その後、初めに整理した方法ではクライアントがInternetExploreでは問題ないが、Netscape ではうまくインストールできないことが判明しました。また、万が一の場合の証明書の失効処理も配布されているopensslのバイナリにバグがあり、index.txtが壊れるという問題がありうまくできないことが判明しました。いろいろ探し回ったのですが、最新のバイナリがどうしても見つからなかった
-
クライアント証明書の発行
クライアント証明書の発行 2003/6/11作成 2004/9/19更新 続いてクライアント証明書を発行しましょう。 クライアント証明書とは、個人や機器を特定する証明書のことです。 verisignとかでは個人証明書などと呼ばれています。 途中まではサーバ証明書の発行と変わりません。 余談ですが、「クライアント証明書」でgoogleすると、多くの有名サイトを押しのけてこのページが一番に表示されてしまいました。 複雑です。 １．クライアント証明書発行の流れ クライアント証明書を発行するまでの流れは簡単にこんな感じです。 クライアント秘密鍵を作成 秘密鍵からCSRを生成 CAの秘密鍵でCSRに署名して証明書を作成 最終的にクライアントにはクライアント秘密鍵とクライアント証明書のペアと、CAの証明書があればいいのですが、クライアントがWindowsの場合、秘密鍵とCSRを作成するのは
-
XKMSシステムの開発
XKMS XKMS XKMS Java&.NET 2002 6 10 XML Consortium WG © XML Consortium. 2002/6/10 XKMS 1 z – – – – z XKMS z Java XKMS z .NET XKMS z © XML Consortium. 2002/6/10 XKMS 2 z z z © XML Consortium. 2002/6/10 XKMS 3 z – Java Consortium XML API • • – / / – ( ) XKMS – XKMS Client SDK z – XKMS Java .NET XKMS © XML Consortium. 2002/6/10 XKMS 4 XKMS … ? Before XKMS PKI Provider After XKMS ASN.1 ASN.1 X.509 PKCS
-
政府認証基盤（GPKI）のホームページ
当ホームページは、リンク・フリーです。 なお、リンクを設定される際は、「政府認証基盤（GPKI）」のホームページへのリンクである旨明示をお願いいたします。 また、当ページの利用規約はこちらです。
-
公開鍵管理プロトコル: Internet X.509 Public Key Infrastructure Certificate Management Protocols
C. Adams Entrust Technologies S. Farrell SSE 1999年 3月 English インターネット X.509 インフラストラクチャ証明書管理プロトコル ( Internet X.509 Public Key Infrastructure Certificate Management Protocols ) このメモの位置づけ 本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものです。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照してください。このメモの配布に制限はありません。 著作権表記 Copyright (C) The Internet
-
X.509 の解説
インターネットの普及に伴い公開鍵暗号方式は必須の技術となってきた。公開鍵暗号方式を利用する際には、暗号化・署名の検証などを行うために事前に正しい公開鍵が配布されていることが前提となる。 少数の限られた範囲内での利用であれば、直接対面などの手段により安全に公開鍵を流布することが可能であるが、インターネットのような多数で広範囲に渡る通信においては不可能である。 そこで個人、 組織、 サーバに対する公開鍵の正当性を保証する信用のおける第3者機関 (trusted third party) である認証局 (Certificate Authority) という概念が生まれた。 認証局では利用者と公開鍵の対を認証局（の秘密鍵）によるデジタル署名した「公開鍵証明書」を発行する。公開鍵証明書を検証する側では公開鍵証明書の（認証局による）署名を検証して、公開鍵が正当なものであるかどうか確認するこ
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました