- 締切済み
SSLの公開鍵をCAから取得できる?
SSLの通信を確認しているのですが、 クライアントPCとサーバがSSLで通信する場合、公開鍵をサーバから クライアントPCは取得しているようですが、CAからは取得できないのでしょうか? ブラウザにルート証明書がインストールされていないCAなら、 公開鍵をCAに要求し取得するものだと思っていましたが、 そうではないのでしょうか?ググっても明確な情報がでてきませんでした。ぜひご教示宜しくお願い致します。
- fabu
- お礼率69% (384/554)
- その他(インターネット接続・通信)
- 回答数1
- ありがとう数1
- みんなの回答 (1)
- 専門家の回答
みんなの回答
- 兼元 謙任(@kanekaneto)
- ベストアンサー率90% (1366/1517)
専門家ではありません。 ↓こちら参考になりますでしょうか? “ ルート証明書は、実際のファイルがPCに保存されているということで信頼の起点となり、これをトラストアンカーと呼びます。アンカーとは、船を固定する「碇(いかり)」や「信頼のよりどころ」という意味です。 ルート証明書が保管される場所は、証明書ストア、ルートストア、ルートトラストストアなどと呼ばれており、多くの場合はWindowsやMac OSなどのOS単位で存在し、ブラウザはOSにインストールされたルート証明書を利用します。ただし、ブラウザの中でもMozilla Firefoxは独自の証明書ストアを持っているため、OSにインストールされた証明書を利用しません。そのため、「Chromeでは閲覧できるのにFirefoxではSSLのエラーが表示されて閲覧できない!」といったサイトが稀に存在することがあります。“ https://ssl.sakura.ad.jp/column/difference-in-ssl/ “ SSL Installation Checker“ https://www.geocerts.com/ssl-checker “ サーバ証明書・SSL/TLS通信/実際に認証局に申請してみた【高校情報1・情報処理技術者】OpenSSLでCSRを生成“ https://youtu.be/Ob5hvd8iAbU こちらも参考に! “ SSL通信の仕組みと流れ 1. SSLサーバー証明書と公開鍵を送る 2. SSLサーバー証明書の有効性確認と共通鍵の生成 3. 共通鍵を公開鍵で暗号化して送る 4. SSL通信を開始“ https://junzou-marketing.com/works-of-ssl “CAとは「Certification Authority」の略で、認証局を意味します。電子証明書はインターネット上で本人証明を行うために使用されており、この証明書を発行する「信頼できる第三者」のことを認証局と言います。“ https://www.f5.com/ja_jp/services/resources/glossary/intermediate-certificate 「SSL」「TLS」「公開鍵」に関する質問と回答 https://okwave.jp/search?word=SSL%20TLS%20%E5%85%AC%E9%96%8B%E9%8D%B5 良い方向に進みますように! 参考になれば幸いです。
関連するQ&A
- HTTPS(SSL)の仕組みとセキュリティについて
SSLの仕組みと,そのセキュリティについての質問です. 現在,HTTPSで利用するSSLの仕組みについて勉強をしています. しかしながら, 自身がSSLの仕組みについて正しく理解できているか分かりません. また,どうしても理解ができない点が何個かあり,質問させて頂く次第になりました. (様々な書籍やwebを拝見したのですが,いづれも腑に落ちませんでした...) そのため,まず大まかに私が理解しているHTTP上のSSLの仕組みを書き,最後に質問を書かせて頂こうかと思います. 長くなりますが宜しくお願い致します. ■主な登場人物 ・認証局 CA秘密鍵 CA証明書(公開鍵?) CA証明書発行要求 ・証明書 KEYファイル(秘密鍵/公開鍵) CSRファイル/申請書(issuer側の情報/公開鍵) CRTファイル/サーバー証明書(CSRを認証局の秘密鍵で捻ったモノ) ■証明書の発行 1-1.証明書を発行したい者がCSRファイルという申請書を作成し,認証局に送ります. →CSRには登録情報(issuer)やサーバー(証明書を発行したい者)の公開鍵などが含まれます. 1-2.認証局はCSRファイルが適切であれば,署名(subject)し,認証局の秘密鍵でCSRの中の公開鍵のみを暗号化します. 1-3.これがCRTファイルになり,証明書を発行したい者に送り返されます. この時,サーバー(証明書を発行した者)は認証局によって署名されたCRTファイルを持っています. 次にこれを利用したHTTPS通信について書きます. ■HTTPS通信 2-1.クライアントがサーバーに通信要請をします. 2-2.サーバーは証明書(CRT)をクライアントに送ります. 2-3.クライアントは送られてきたCRTが信頼できるか認証局の証明書(公開鍵)を使って検証します. →CRTに埋め込まれているサーバーの公開鍵は認証局の秘密鍵によって暗号化されているので,これを認証局の公開鍵で複合化します. →認証局の公開鍵はルート証明書といい,事前にブラウザに組み込まれているものとします. 2-4.クライアントは共通鍵を発行します. 2-5.クライアントはCSRから複合化したサーバーの公開鍵を用い,自身で発行した共通鍵を暗号化してサーバーに送ります 2-6.サーバーは受け取った暗号データを自身の持つ秘密鍵で複合化し,共通鍵を取得します. 2-7.後はこの共通鍵でデータを暗号化し通信します, ■質問 1.オレオレ証明書+認証局の場合でも正常に通信ができるのはなぜか 私の理解だと2-3で,クライアントが認証局の公開鍵を用い,サーバーの証明書からサーバーの公開鍵を複合化し,それを元に共通鍵を暗号化しています. これはクライアントが認証局のルート証明書(公開鍵)を保有しているから複合化できるはずです. オレオレ証明書の場合は,認証局の公開鍵がクライアントにインストールされていません. そのため,サーバーの公開鍵を複合化できず,共通鍵の生成に失敗し,通信できなくなると思います. しかしながら,ブラウザは「署名が不明な接続先です」とのエラーを出すだけで,通信(接続)ができてしまいます. なぜでしょうか. 2.IssuerとSubjectは暗号化されていないのか 私の理解だと1-2の認証局では,サーバーの公開鍵しか暗号化されていません. ということはIssuerとSubjectは暗号化されていないということでしょうか. また,それはなぜでしょうか. 3.IssuerとSubjectは偽装できるか opensshを用いることで認証局を構築することができます. この時に,Subjectの設定をベリサインの認証局と全く同じようにし, 証明書も,ベリサインの認証局を使っているサイトのIssuerと全く同じようにした場合, SubjectとIssuerが全く同じ証明書ができると思います. この場合は,本物の証明書と同様の証明書を複製できてしまうのでしょうか. できないとは思いますが,それはなぜでしょうか. 4.証明書の偽装は可能か ブラウザから証明書の情報を見ることができます.もちろんbyteデータのraw certificateも見ることができます. この情報を丸々コピーし,全く異なるサーバーに証明書として読みこませて通信した場合は, 署名されてしまうのでしょうか. されないとは思いますが,それはなぜでしょうか. (例えば,URL=CN情報が異なっているから確認できるとか..?それならCN情報だけ書き換えてしまえばいい?) 5.証明書の検証をするにはどうしたらよいか 証明書を検証をするには,その証明書を発行した認証局の公開鍵を利用するしかないのでしょうか. 例えば,サーバー証明書(CRT)のフィンガープリントsha1データを事前に保持さえしていれば, サーバーに証明書を示された際にCRTのフィンガープリントを比較すれば,特定のサーバーかどうか検証できるか・・? 6.MITMについて MITM攻撃により,証明書が途中で書きかわることが考えられます. この場合は,書き換わった証明書をどのように特定すればいいのでしょうか. 例えば,認証局のルート証明書がないなどが考えられますが, 仮に,Rapid SSLなどで署名されている証明書でMITM攻撃がされた場合どうなるでしょうか? この場合は,Issuerなどを比較するしかないように考えられます. しかし,Issuerはcsr申請の際にうまいこと,書き換えることができてしまいます. そう考えると,どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか, フィンガープリントは偽装することができないのでしょうか. 以上となります. 様々な質問を書いてしまい,申し訳ありません 説明不足で乱文だとは思いますが, 分かる範囲でお答え頂けませんでしょうか. 宜しくお願い致します.
- ベストアンサー
- ネットワーク
- SSLによる電子証明書交換のセキュリティについて
SSLを勉強しております。 私の今の解釈ではSSLによる電子証明書の交換手順は 以下のようなイメージです。 (1)[データの方向:クライアント → サーバー] <ClientHello> マスターキーのための乱数 今からの暗号通信に用いる暗号方式のリスト などをサーバーに送信。 (2)[データの方向:サーバー → クライアント] <ServerHello> 選んだ暗号方式 マスターキーのための乱数 <ServerCertificate> サーバーが保持するサーバー証明書 サーバーが保持するルートCA証明書 <CertificateRequest> <ServerHelloDone> ・ ・ ・ 次にClientCertificateが送られてきて・・という感じですが、ここまででわからない点があります。 以下に質問を挙げます。 [質問] 手順(2)においてサーバーは電子証明書をクライアントに送るわけですが、参考書を読んでいる限りでは証明書データは暗号化せずにそのまま生データを送るような説明でした。 もしそうだとすればパケットキャプチャさえすれば証明書をそっくりそのまま盗まれることになりますので考えにくいのですがどうなのでしょうか? 暗号化されているなら「何の鍵」で暗号化されているのでしょうか? クライアントの公開鍵は(2)のタイミングではまだ知らないのでクライアントの公開鍵ではないと思いますが。 長くなってすいません。 わかりにくければ補足します。 よろしくお願いします。
- ベストアンサー
- ネットワーク
- httpとhttpsとSSLの違い
http は通信内容が平文でネットワークを流れる。 https は通信内容がWEBサーバとPCのブラウザ間で暗号化される。ブラウザのキャッシュが効かない。 SSL は通信内容がWEBサーバとPCのブラウザ間でSSL証明書をもって暗号化できる。httpsに追加して使える(2重に暗号化?)。httpには使えない。通信を要求するサーバが信頼できることを証明する。 と理解していますが、たぶんどれか間違っていると思います。 上記3個の違いを簡潔に教えてください。 よろしくお願いします。
- ベストアンサー
- ネットワーク
- SSL証明書インストールの必要性
職場のクライアントパソコンのブラウザにSSL通信用のSSL証明書を各サイトごとにインストールする作業をしております。 ふと思ったのですが、ブラウザの画面下にある鍵のマークをクリックして、インストールの作業をしておりますが、ただ通信するだけだったら何もしなくても使えると思います。わざわざサイトごとに配布している証明書をブラウザにインストールする必要性があるとしたら、どのようなことがありますでしょうか。それともこの作業はあまり意味のないことなのでしょうか。 変な質問で申し訳ありませんが、よろしくお願いします。
- ベストアンサー
- ネットワーク
- 双方向SSL時にクライアント証明書が表示されない
現在、顧客DMZ内にあるサーバに対し、インターネット上の 特定のクライアント様からサービスを利用できるように、 双方向SSLの環境を構築しておりますが、困った事があります。 詳細は次のようになります。長文となっておりますが、何卒ご教授 よろしくお願いいたします。 【1.現象】 ブラウザからSSLを行うサーバにアクセスすると、ポップアップボックスが表示され、 クライアントのブラウザの証明書ストアにあるクライアント証明書のうちどれを 使用するかが尋ねられますが、ボックスに何も表示されません。 【2.システム構成】 (1)アプリケーションサーバ OS:Windows 2003 Server WWWサーバ:IIS 6.0 サーバ証明書:セキュア・サーバID(ベリサイン社) IIS設定: ・サーバ証明書インストール ・「セキュリティで保護されたチャネル (SSL) を要求する」にチェック ・「クライアント証明書を要求する」を選択 ブラウザ:IE 6.0 (2)CA機関(個人持ち) Win2003の証明書サービスを使用し、クライアント証明書を発行します。 ここで発行した証明書を(3)のクライアントに配布します。 (3)クライアント OS:Windows XP SP2 ブラウザ:IE 6.0 (2)において、証明書サービスから発行したクライアント証明書を クライアント機にコピーし、ダブルクリックし証明書をインストールしました。 ◆補足 ・上記(1)、(3)間でSSL通信を行います。 ・上記(1)、(2)、(3)は各々別マシンです。 ・上記(1)は社内ネットワーク上にあり、(3)はインターネット上から(1)にアクセスします。 (2)はネットワークに繋がっておらず独立しています。 ・上記(3)から(2)のアクセスにおいてクライアント証明書が表示されません。 また、試しに(1)において、(3)と同様の手順でクライアント証明書をインストールし、 (1)のブラウザを使用し(1)にアクセス(自マシンに対しhttpsアクセス)しましたが、 クライアント証明書が表示されませんでした。 【3.ご教授頂きたい事】 クライアントマシンのクライアント証明書が 表示されない原因、対処について教えてください。
- 締切済み
- ネットワーク
- PKI(公開鍵基盤)について教えて
現在個人的に、PKI(公開鍵基盤)を勉強中です。 PKI(公開鍵基盤)のテキストを読むと、だいたいCA(Certificate Authority)は階層構造になっていて、ユーザが、取引先の電子証明書(公開鍵証明書)の正当性を近くのCAに照会に行くと、取引先の電子証明書の正当性をチェックして返答すると同時に、CAが自らの正当性を証明するために、(CAがなりすましでないことを証明するために)、順次、上位のCAに照会をかけ、最後にルートCAにたどり着くと、ルートCAは自らの秘密鍵で自己署名を行って、その自己署名で、CAになりすましがないことを最終的に担保すると書いてあります。 そのような長いトランザクションを、取引先の電子証明書の正当性をチェックする都度行っていると、時間がかかりすぎて実用に耐えないような気がします。 もしかして、実際のCAは階層構造ではなく、ほとんど我々は、ルートCAに直接照会をかけているのでしょうか。
- ベストアンサー
- ネットワーク
- SSL での 公開鍵、秘密鍵
Gメールで、POP接続してメールを取り出すときは、 SSL(TLS)での接続となります。 ここで、RSA暗号を使う場合の、公開鍵を秘密鍵のセットは 接続した瞬間に作成されるのでしょうか? それとも、既に作ってある公開鍵と秘密鍵のセットが選ばれるのでしょうか? もし、既に作ってあるセットの中から選ぶ場合には、 鍵のセットはサーバーの中に何セットくらい用意されているのでしょうか? WireShark で、SSL の暗号化を解読してパケットの中を見る方法があるとのことで、 すこし、気になっています。 お分かりの方よろしくお願いいたします。 参考: https://www.softbanktech.jp/yko/2010/07/001129.html
- ベストアンサー
- ネットワーク
- クライアント証明書を必須にすると接続できない
社内のSSL環境を構築しておりますが、私の知識不足のためになかなかうまくいきません。 申し訳ありませんが、ご教授願えますでしょうか? ---テスト環境--- サーバA:www.XXXX.co.jp (Winodws Server 2008 R2 役割:IIS7.5、AD証明書サービス(スタンダート ルートCA)) サーバB:yyy.XXXX.co.jp (Winodws Server 2008 R2 役割:IIS7.5) クライアント1:IE7(WindowsXP)、IE9(Vista):クライアント証明書あり クライアント2:IE8(WindowsXP):クライアント証明書なし ---証明書--- サーバA(ルートCA認証局) |--サーバA:サーバAルートCAでサーバ証明書発行(IIS用:サイトのバインドに設定しSSLを設定(SSL設定:SSLが必須、クライアント証明書:必須)) |--サーバB:サーバAルートCAでサーバ証明書発行(IIS用:サイトのバインドに設定しSSLを設定(SSL設定:SSLが必須、クライアント証明書:必須)) |--クライアント1:サーバAルートCAでクライアント証明書発行 ---アクセス--- クライアント1→サーバAのサイト:表示/OK(正常にサイトを確認できる) クライアント2→サーバAのサイト:表示/NG(サイトを確認できない)クライアント証明書がないので正しい ※クライアント1→サーバBのサイト:表示/NG(403 13のエラーとなり接続できない)クライアント証明書はルートCAの証明があるのに接続できない クライアント2→サーバBのサイト:表示/NG(サイトを確認できない)クライアント証明書がないので正しい なぜサーバBのサイトへアクセスできないのでしょうか?ルートCAの証明書は有効となっているのですが?です。 ちなみにクライアント証明書のCRLは「http://www.XXXX.co.jp/」のcrlの場所となっています。 サーバBにAD証明書サービスをインストールし既存CAにてルートCAと利用すればよいのはわかるのですが、 インストールなしでできないものでしょうか?サーバを追加するたびにクライアント証明書を要求・発行しなくてもルートで承認している クライアントから接続できないのでしょうか? 証明書の発行、考えに問題があるのか分からないのですが、なにか回答があれば助かります。
- ベストアンサー
- ネットワーク
- 自己署名証明書によるSSL通信について教えてください!
SSL通信により、データを暗号化してWeb上でやりとりするシステムの構築を考えています。 そこで自己署名というのを考えているのですが、署名の流れがいまいち分かりません。 認証局利用の場合、私の理解では、 【サーバ側】 1.サーバ側でRSA秘密鍵を生成 2.RSA秘密鍵を元にCSRを作成 3.CSRファイルを認証局に送信 【認証局】 4.CA秘密鍵により暗号化し、サーバ証明書を作成 5.サーバ側にサーバ証明書を送信 【サーバ側】 6.クライアント側にサーバ証明書を送信 【クライアント側】 7.サーバ側よりサーバ証明書を受信する 8.認証局より公開鍵を取得する 9.認証局の公開鍵でサーバ証明書の暗号化された鍵(認証局の秘密鍵で暗号化されたもの)を復号する 10.復号した鍵により、サーバ証明書の暗号文を復号する となります。(間違いがある場合はご指摘下さい) では、自己署名を行う場合はどうなるのでしょうか? 単純にサーバ証明書を自分で作成すると考えてよろしいのでしょうか? CSRファイルの作成などもやはり行うのでしょうか? クライアント側の流れは変わらないのでしょうか? また、この操作は接続毎に毎回行うことになるのでしょうか? (秘密鍵、サーバ証明書は毎回変わるのでしょうか?) 初歩的な質問とは思いますが、よろしくお願いいたします。
- ベストアンサー
- ネットワーク