[{"data":1,"prerenderedAt":1763},["ShallowReactive",2],{"sc:header-data-ja":3,"sc:footer-data-ja":101,"glossary-posts-ja":139,"content-ja-list-c077398beed29":1762},{"lang":4,"home":5,"navigation":14,"contact":95},"en",{"name":6,"imgLight":7,"img":8,"languages":9},"home","/products/scepman/scepman-logo-all-white.svg","/products/scepman/scepman-logo-rgb.svg",{"ja":10},{"title":11,"url":12,"alt":13},"ホーム","/ja","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"ja":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"ja":22},{"title":23,"url":24},"価格","/ja/pricing",{"name":26,"languages":27},"partner",{"ja":28},{"title":29,"url":30},"パートナー","/ja/partner",{"name":32,"languages":33,"children":36},"support-hub",{"ja":34},{"title":35},"Support Hub",[37,53,68],{"name":38,"children":39},"support-hub-group-1",[40,47],{"name":41,"target":42,"languages":43},"docs","_blank",{"ja":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"ja":50},{"title":51,"url":52},"FAQ","/ja/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"ja":59},{"title":60,"url":61},"Support Ticket","https://support.scepman.com/support/tickets/new?ticket_form=technical_support_request_%28scepman%29",{"name":63,"target":42,"languages":64},"drop-a-question",{"ja":65},{"title":66,"url":67},"Drop a Question","https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29",{"name":69,"children":70},"support-hub-group-3",[71,77],{"name":72,"languages":73},"glossary",{"ja":74},{"title":75,"url":76},"用語集","/ja/glossary",{"name":78,"languages":79},"blog",{"ja":80},{"title":81,"url":82},"ブログ","/ja/blog",{"name":84,"languages":85},"events",{"ja":86},{"title":87,"url":88},"イベント","/ja/events",{"name":90,"languages":91},"about",{"ja":92},{"title":93,"url":94},"会社概要","/ja/about-us",{"name":96,"languages":97},"contact",{"ja":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksJa":132},"sales@SCEPman.com",[105],{"img":106,"alt":107,"url":108},"/products/scepman/scepman-logo-yellow.svg","SCEPman Logo","/",[110,114,118],{"icon":111,"url":112,"title":113},"fa-x-twitter","https://twitter.com/scepman_","X",{"icon":115,"url":116,"title":117},"fa-youtube","https://www.youtube.com/channel/UCKnLYxlQFhzdXkDADV_Unrg","Youtube",{"icon":119,"url":120,"title":121},"fa-linkedin","https://www.linkedin.com/showcase/scepman","LinkedIn",[123,126,129],{"title":124,"url":125,"target":42},"Privacy","https://www.glueckkanja.com/en/privacy",{"title":127,"url":128,"target":42},"Imprint","https://www.glueckkanja.com/en/imprint",{"title":130,"url":131,"target":42},"Contact & Locations","https://www.glueckkanja.com/en/company/contact-and-locations",[133,135,137],{"title":134,"url":125,"target":42},"プライバシー",{"title":136,"url":128,"target":42},"法的情報",{"title":138,"url":131,"target":42},"お問い合わせと拠点",[140,464,830,1084,1316],{"id":141,"title":142,"author":143,"body":144,"cta":143,"description":421,"eventid":143,"extension":444,"hideInRecent":445,"layout":446,"meta":447,"moment":143,"navigation":459,"path":460,"seo":461,"stem":462,"tags":143,"webcast":445,"__hash__":463},"content_ja/glossary/cryptography.md","暗号技術",null,{"type":145,"value":146,"toc":420},"minimal",[147,151,164,169,197,201,223,226,229,232,241,244,252,291,294,297,301,304,308,311,315,318,321,324,327,330,355,358,361,378,382,385,389,392,396,399,403],[148,149,150],"h2",{"id":150},"鍵を用いる暗号化の2つの種類",[152,153,154,155,159,160,163],"p",{},"鍵を用いる暗号化には、大きく分けて",[156,157,158],"strong",{},"対称暗号化","と",[156,161,162],{},"非対称暗号化","の2種類があります。",[165,166,167],"h3",{"id":158},[156,168,158],{},[170,171,172,179,185,191],"ul",{},[173,174,175,178],"li",{},[156,176,177],{},"鍵の使い方","：暗号化と復号に同一の鍵を使用します。",[173,180,181,184],{},[156,182,183],{},"速度","：一般に高速で効率的です。",[173,186,187,190],{},[156,188,189],{},"セキュリティ","：主な課題は、当事者の間で鍵を安全に共有することです。",[173,192,193,196],{},[156,194,195],{},"例","：AES（Advanced Encryption Standard）、DES（Data Encryption Standard）。",[165,198,199],{"id":162},[156,200,162],{},[170,202,203,208,213,218],{},[173,204,205,207],{},[156,206,177],{},"：鍵ペア、すなわち暗号化に用いる公開鍵と復号に用いる秘密鍵を使用します。",[173,209,210,212],{},[156,211,183],{},"：計算がより複雑なため、対称暗号化に比べて低速です。",[173,214,215,217],{},[156,216,189],{},"：秘密鍵が共有されることはないため、鍵の配布においてより安全です。",[173,219,220,222],{},[156,221,195],{},"：RSA（Rivest-Shamir-Adleman）、ECC（Elliptic Curve Cryptography）。",[165,224,225],{"id":225},"安全性がより高いとされる暗号化方式",[152,227,228],{},"十分な鍵長の最新アルゴリズムを使用している限り、現在のコンピューターでは暗号を解読できないという意味で、どちらの方式も安全だと考えられています。",[152,230,231],{},"どちらの暗号化が優れているかはユースケース次第ですが、多くのユースケースでは非対称暗号化が求められます。非対称暗号化は鍵ペア、すなわち暗号化に用いる公開鍵と復号に用いる秘密鍵を使用するからです。秘密鍵は秘匿されたままで共有する必要がないため、セキュリティが高まります。",[165,233,235,236],{"id":234},"大量データに適した暗号化方式","大量データに適した暗号化方式 ",[237,238],"a",{"href":239,"id":240},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[152,242,243],{},"対称暗号化です。処理が高速なためです。",[165,245,247,248],{"id":246},"ハイブリッド暗号化の一般的な流れ","ハイブリッド暗号化の一般的な流れ ",[237,249],{"href":250,"id":251},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[253,254,255,261,267,273,279,285],"ol",{},[173,256,257,260],{},[156,258,259],{},"鍵の生成","：送信者は、実際のメッセージを暗号化するための新しい対称鍵（セッションキーとも呼ばれます）を生成します。",[173,262,263,266],{},[156,264,265],{},"メッセージの暗号化","：送信者はその対称鍵で平文のメッセージを暗号化し、暗号文を作成します。",[173,268,269,272],{},[156,270,271],{},"鍵の暗号化","：続いて送信者は、受信者の公開鍵を使って対称鍵を暗号化します（非対称暗号化）。",[173,274,275,278],{},[156,276,277],{},"送信","：送信者は、暗号化されたメッセージ（暗号文）と暗号化された対称鍵の両方を受信者に送ります。",[173,280,281,284],{},[156,282,283],{},"鍵の復号","：受信者は自身の秘密鍵を使って対称鍵を復号します。",[173,286,287,290],{},[156,288,289],{},"メッセージの復号","：最後に受信者は、復号した対称鍵で暗号文を復号し、元の平文を取り出します。",[148,292,293],{"id":293},"ハッシュアルゴリズム",[152,295,296],{},"ハッシュアルゴリズムとは、任意の大きさの入力データを固定長の文字列に変換する数学的な関数です。この文字列は通常、英字と数字の並びになります。この出力はハッシュ値またはダイジェストと呼ばれます。",[165,298,300],{"id":299},"コリジョン衝突","コリジョン（衝突）",[152,302,303],{},"ハッシュにおけるコリジョンとは、異なる2つのデータが同じハッシュアルゴリズムで同一のハッシュ値を生成することをいいます。ハッシュアルゴリズムの第一の目的は、異なる入力データを一意に表現することにあるため、これは問題になり得ます。",[165,305,307],{"id":306},"mac","MAC",[152,309,310],{},"メッセージ認証コード（MAC）とは、暗号技術において、メッセージを認証しその完全性を保証するために用いられる短い情報です。メッセージが改変されていないことを検証し、送信者の身元を確認します。",[165,312,314],{"id":313},"macとhmacの違い","MACとHMACの違い",[152,316,317],{},"MAC：ブロック暗号またはハッシュ関数を用いて、メッセージの完全性と真正性を検証するコードの総称です。",[152,319,320],{},"HMAC：暗号学的ハッシュ関数と秘密鍵を用いるMACの一種で、より強固なセキュリティ特性を備えています。",[148,322,323],{"id":323},"非対称暗号",[165,325,326],{"id":326},"メッセージ署名の一般的な流れ",[152,328,329],{},"メッセージ署名は、メッセージの真正性と完全性を検証するための暗号技術上の処理です。",[253,331,332,338,344,349],{},[173,333,334,337],{},[156,335,336],{},"ハッシュの生成","：送信者は、暗号学的ハッシュ関数（SHA-256など）を用いて、メッセージ固有のデジタル指紋（ハッシュ）を生成します。このハッシュはメッセージの内容を一意に表します。",[173,339,340,343],{},[156,341,342],{},"署名","：送信者はこのハッシュを自身の秘密鍵で暗号化し、デジタル署名を作成します。これにより、送信者の秘密鍵にアクセスできる者だけが署名を生成できることが保証されます。",[173,345,346,348],{},[156,347,277],{},"：デジタル署名がメッセージに添付され、両者がまとめて受信者に送られます。検証用に送信者の公開鍵も提供されます。",[173,350,351,354],{},[156,352,353],{},"検証","：受信者は送信者の公開鍵でデジタル署名を復号し、元のハッシュを取り出します。続いて受信したメッセージから新たにハッシュを生成し、復号したハッシュと比較します。両者が一致すれば、メッセージが改変されていないことが確認され、送信者の身元も検証されます。",[165,356,357],{"id":357},"非対称暗号化の3つの機能",[152,359,360],{},"公開鍵暗号とも呼ばれる非対称暗号化は、通信とデータの保護においていくつかの重要な機能を担います。",[253,362,363,368,373],{},[173,364,365],{},[156,366,367],{},"暗号化と復号",[173,369,370],{},[156,371,372],{},"デジタル署名",[173,374,375],{},[156,376,377],{},"鍵交換",[165,379,381],{"id":380},"rsa","RSA",[152,383,384],{},"RSAはRivest-Shamir-Adlemanの略で、安全なデータ伝送のために広く利用されている公開鍵暗号方式です。1977年にこの方式を発表した考案者、Ronald Rivest、Adi Shamir、Leonard Adlemanの名にちなんで名付けられました。",[165,386,388],{"id":387},"diffie-hellman","Diffie-Hellman",[152,390,391],{},"Diffie-Hellman鍵交換は、公開された通信路を介して暗号鍵を安全にやり取りするために暗号技術で用いられる方式です。1976年にWhitfield DiffieとMartin Hellmanによって開発されました。Diffie-Hellman鍵交換の主な目的は、二者が以後の通信の暗号化に使用できる共有秘密鍵を、安全に生成できるようにすることです。",[165,393,395],{"id":394},"digital-signature-algorithmdsa","Digital Signature Algorithm（DSA）",[152,397,398],{},"Digital Signature Algorithm（DSA）は、デジタル署名の生成と検証に用いられる公開鍵暗号アルゴリズムです。1991年に米国国立標準技術研究所（NIST）がDigital Signature Standard（DSS）の一部として提案しました。",[400,401,402],"h4",{"id":402},"仕組み",[253,404,405,410,415],{},[173,406,407,409],{},[156,408,259],{},"：DSAは鍵ペア、すなわち署名用の秘密鍵と検証用の公開鍵を生成します。",[173,411,412,414],{},[156,413,342],{},"：送信者は自身の秘密鍵を使ってメッセージにデジタル署名を作成します。この署名はメッセージと秘密鍵の両方に固有のものです。",[173,416,417,419],{},[156,418,353],{},"：受信者は送信者の公開鍵を使って署名の真正性を検証し、それによってメッセージの完全性と出所を確認します。",{"title":421,"searchDepth":422,"depth":422,"links":423},"",2,[424,432,437],{"id":150,"depth":422,"text":150,"children":425},[426,428,429,430,431],{"id":158,"depth":427,"text":158},3,{"id":162,"depth":427,"text":162},{"id":225,"depth":427,"text":225},{"id":234,"depth":427,"text":235},{"id":246,"depth":427,"text":247},{"id":293,"depth":422,"text":293,"children":433},[434,435,436],{"id":299,"depth":427,"text":300},{"id":306,"depth":427,"text":307},{"id":313,"depth":427,"text":314},{"id":323,"depth":422,"text":323,"children":438},[439,440,441,442,443],{"id":326,"depth":427,"text":326},{"id":357,"depth":427,"text":357},{"id":380,"depth":427,"text":381},{"id":387,"depth":427,"text":388},{"id":394,"depth":427,"text":395},"md",false,"post",{"lang":448,"titleClass":449,"blogtitlepic":450,"socialimg":451,"customExcerpt":452,"asideNav":453,"maxContent":459},"ja","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","証明書を登録する際の中心的な課題は、証明書を要求するデバイスやユーザーをどのように認証するかです。認証局は証明書によって、その所有者が特定の属性を備えていること、およびその真正性を確認済みであることを示します",{"menuItems":454},[455,457],{"href":456,"text":293},"#ハッシュアルゴリズム",{"href":458,"text":323},"#非対称暗号",true,"/glossary/cryptography",{"title":142,"description":421},"glossary/cryptography","rGiEzVI8nwNB7QloRThbaiI4TdGcuRElJvCoTOP9ppk",{"id":465,"title":466,"author":143,"body":467,"cta":143,"description":471,"eventid":143,"extension":444,"hideInRecent":445,"layout":446,"meta":814,"moment":143,"navigation":459,"path":826,"seo":827,"stem":828,"tags":143,"webcast":445,"__hash__":829},"content_ja/glossary/enrollment-methods.md","登録方式",{"type":145,"value":468,"toc":801},[469,472,475,478,507,597,599,602,612,615,633,635,638,642,645,648,669,673,676,679,692,695,698,701,704,707,710,713,722,725,729,732,735,741,744,753,756,759,762,779,791,794,797],[152,470,471],{},"したがって、証明書登録プロトコルの中核となる特性は、証明書の要求者をどのように認証するかという点にあります。証明書の用途によって、どのプロトコルが有利かは変わります。",[152,473,474],{},"もう1つの重要な特性は、実際にどれだけ普及しているかです。対象とするユースケースにおいて、登録方式またはプロトコルが認証局側とクライアント側の両方でサポートされている必要があります。",[152,476,477],{},"代表的な登録プロトコルは次のとおりです。",[170,479,480,486,489,492,498,501,504],{},[173,481,482],{},[237,483,485],{"href":484},"scep","SCEP",[173,487,488],{},"ACME",[173,490,491],{},"EST",[173,493,494],{},[237,495,497],{"href":496},"microsoft-rpc-dcom","MicrosoftのRPC/DCOM",[173,499,500],{},"MicrosoftのSOAP",[173,502,503],{},"認証局のWebページでの手動登録",[173,505,506],{},"その他の独自プロトコル",[508,509,510,511],"table",{},"\n    ",[512,513,514,510,536,517,557,510,577],"tbody",{},[515,516,517,518,517,521,517,524,517,527,517,530,517,533,510],"tr",{},"\n        ",[519,520],"th",{},[519,522,523],{},"Microsoft独自のDCOMおよびRPC",[519,525,526],{},"WS-Trust Enrollment ExtensionによるSOAP登録",[519,528,529],{},"Automatic Certificate Management Environment（ACME）",[519,531,532],{},"Simple Certificate Enrollment Protocol（SCEP）",[519,534,535],{},"Enrollment over Secure Transport（EST）",[515,537,517,538,517,542,517,545,517,548,517,551,517,554,510],{},[539,540,541],"td",{},"仕様",[539,543,544],{},"Microsoft OpenSpec1",[539,546,547],{},"Microsoft OpenSpec2",[539,549,550],{},"RFC 8555",[539,552,553],{},"非公式、現在はRFC 8894",[539,555,556],{},"RFC 7030（+ …）",[515,558,517,559,517,562,517,565,517,568,517,571,517,574,510],{},[539,560,561],{},"実装",[539,563,564],{},"サーバー側：Active Directory CS、クライアント側：Windows",[539,566,567],{},"サーバー側：ADCS、他にもあるか不明、クライアント側：Windows",[539,569,570],{},"サーバー側：Let’s Encrypt、クライアント側：多数",[539,572,573],{},"サーバー実装もクライアント実装も多数",[539,575,576],{},"普及は進んでいない",[515,578,517,579,517,582,517,585,517,588,517,591,517,594,510],{},[539,580,581],{},"認証",[539,583,584],{},"AD認証",[539,586,587],{},"AD認証\\*（形式上は、ユーザー名とパスワードがADに存在しない場合もあります）",[539,589,590],{},"DNS認証",[539,592,593],{},"「SCEPチャレンジ」",[539,595,596],{},"CBA、またはHTTP BasicもしくはDigest認証",[148,598,485],{"id":484},[165,600,601],{"id":601},"歴史と仕様",[152,603,604,605,611],{},"Simple Certificate Enrollment Protocol（SCEP）を最初に考案したのはCiscoです。当時は標準がなかったにもかかわらず、MDMシステムで広く採用されました。Ciscoはさらに歩を進め、SCEPを置き換える後継プロトコルとしてEnrollment over Secure Transport（EST）を設計しています。そのためESTはRFC 7030として早くから公開標準になりましたが、SCEPが",[237,606,610],{"href":607,"rel":608},"https://www.rfc-editor.org/rfc/rfc8894.html",[609],"nofollow","RFC 8894","で標準化されたのはずっと後のことで、その時点ではすでにMDMシステムにおける証明書登録の事実上の標準になっていました。",[165,613,614],{"id":614},"技術",[152,616,617,618,622,623,627,628,632],{},"SCEPはHTTPベースです。SCEPリクエストは、暗号化および署名された",[237,619,621],{"href":620},"important-data-formats#pkcs7","PKCS#7","であり、GETまたはPOSTリクエストでSCEPサービスに送信されます。サービスはSCEPレスポンスを返しますが、これもやはり暗号化および署名されたPKCS#7です。リクエストには",[237,624,626],{"href":625},"important-data-formats#pkcs10","PKCS#10","の証明書署名要求が含まれ、レスポンスには発行された",[237,629,631],{"href":630},"important-data-formats#x509","X.509証明書","が含まれます。",[165,634,581],{"id":581},[152,636,637],{},"PKCS#10リクエストには「SCEPチャレンジ」が含まれ、SCEPサービスごとに異なる帯域外の方法によって署名要求を認証および認可します。今日実際に使われているSCEPチャレンジは3種類あります。",[400,639,641],{"id":640},"静的scepチャレンジ","静的SCEPチャレンジ",[152,643,644],{},"最も単純なのは固定のパスフレーズです。PKCS#10内のSCEPチャレンジがSCEPサービスに保存された既定値と一致すれば証明書が発行され、一致しなければ要求は拒否されます。この方式の問題は、要求された証明書の属性が要求者と合致しているかどうかをほとんど検証できない点にあります。この問題についてはCVEも登録されています。",[152,646,647],{},"これらの方式はさらに次のように区別できます。",[253,649,650,657,663],{},[173,651,652,656],{},[653,654,655],"em",{},"直接"," SCEP登録の場合、証明書の登録対象となるエンティティがSCEPサービスと直接通信します。たとえばMDMシステムが、あるAndroid端末に対してSCEPチャレンジ「SecurePassword」を使ったSCEP登録を指示します。Android端末はCSRを生成し、できれば正しい値を設定したうえで、SCEPチャレンジとして「SecurePassword」を付加します。そしてCSRをSCEPサービスへ送信し、発行された証明書を受け取ります。",[173,658,659,662],{},[653,660,661],{},"透過型SCEPプロキシ"," は、HTTPのリバースプロキシとよく似たものです。SCEPは暗号化および署名されているため、プロキシがSCEPのリクエストやレスポンスの中身を実際に参照したり変更したりすることはできませんが、ネットワークの境界に基づいて、誰がいつ証明書を登録できるかを制御できます。",[173,664,665,668],{},[653,666,667],{},"プロトコルアダプター型SCEPプロキシ"," は、他のシステムに代わってSCEPで証明書を要求するシステムです。たとえばJAMFのようなMDMシステムが、あるiPhoneに代わってSCEPサービスに証明書を要求できます。証明書と秘密鍵を受け取った後は、別のプロトコルでその証明書を配布できます。この方法であれば、SCEPチャレンジにアクセスできるのはMDMシステムだけであり、証明書の内容も制御できます。",[400,670,672],{"id":671},"動的scepチャレンジ","動的SCEPチャレンジ",[152,674,675],{},"この場合、各SCEPチャレンジは1回の証明書要求にのみ有効です。これによりSCEPサービスはSCEPリクエストを識別し、要求された証明書の属性がその要求に許可されたものと一致するかを検証できます。",[152,677,678],{},"MDMシステムとSCEP認証局が、ある要求に使うSCEPチャレンジについて合意する方法は、実務上おおむね2つあります。",[253,680,681,689],{},[173,682,683,684],{},"MDMシステムが必要に応じて、SCEPリクエスト用のワンタイムコードをSCEPサービスに要求します。\n",[253,685,686],{},[173,687,688],{},"その一例がMicrosoft NDESです。NDESには、AD資格情報で認証される独立した「管理者」ページがあります。このページにアクセスするたびに、1回のSCEPリクエストに使える新しいワンタイムコードが生成され、表示されます。ただしこの構成で使う場合、ワンタイムコードは汎用的なものであるため、NDESは証明書の属性を一切検証しません。",[173,690,691],{},"MDMシステムが、管理対象システムにSCEPでの証明書要求を指示する際にワンタイムコードを生成します。SCEPリクエストがSCEPサービスに届くと、サービスは通常Webフックを使ってMDMシステムからワンタイムコードを取得し、リクエスト内のSCEPチャレンジと一致するかを確認する必要があります。このやり取りには標準がないため、MDMシステムとSCEPサービスが何らかの形式について合意しなければならず、リクエストの属性が検証されるかどうかは実装次第です。",[400,693,694],{"id":694},"署名付きメタデータ",[152,696,697],{},"SCEPチャレンジの長さには事実上の制限がありません。そのため、人が読める「パスフレーズ」である必要はなく、BLOBであってもかまいません。",[152,699,700],{},"IntuneはSCEPチャレンジとして、署名および暗号化されたXMLを使用します。証明書を登録してSCEPリクエストを作成させたいときに、サーバー側でこのXMLを生成し、クライアントデバイスへ送ります。",[152,702,703],{},"SCEPサービスは、PKCS#10リクエスト全体をIntuneのSCEPチャレンジサービスへ送信しなければなりません。SCEPチャレンジサービスは、XMLを復号するための秘密鍵と、それが正規のIntuneサービスによって作成されたことを確認するための公開鍵を保持しています。",[152,705,706],{},"XMLには、Subjectがどのような値であるべきかといった、リクエストに関するメタデータが含まれます。この情報は、一方ではSCEP構成プロファイルから、他方では証明書の発行対象となるユーザーまたはデバイスの個別のオブジェクトデータから導き出されます。",[152,708,709],{},"たとえば、SCEP構成プロファイルでSubjectにCN={{DeviceId}}が設定されているとします。IDがxyzのデバイスが証明書を要求すると、XMLにはSubjectがCN=xyzであるべきだと記載されます。SCEPチャレンジサービスは、XMLの情報とPKCS#10リクエスト内のSubjectを比較します。Subjectが異なれば検証は失敗し、これと他の属性が一致すれば成功します。",[152,711,712],{},"SCEPサービスは、検証に成功した場合にのみ証明書を発行します。",[152,714,715,716,721],{},"Microsoftは、この検証について解説した",[237,717,720],{"href":718,"rel":719},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[609],"記事","を公開しています。",[152,723,724],{},"Microsoft NDESは追加のNDESポリシーモジュールでこれに対応します。他のSCEP認証局がこれをネイティブにサポートしているかどうかは製品によります。",[148,726,728],{"id":727},"microsoft-rpcdcom","Microsoft RPC/DCOM",[165,730,731],{"id":731},"歴史",[152,733,734],{},"Microsoft Active Directory Certificate Services（ADCS）は、単に「Microsoft CA」と呼ばれることもあり、Windows Serverに組み込まれた認証局ソフトウェアです。このソフトウェアはもともと前世紀の終わりに開発され、その後10年から15年ほどにわたって機能が追加されてきました。",[152,736,737,738,740],{},"代替となるのはMicrosoftのSOAPや",[237,739,485],{"href":484},"で、MicrosoftはそれぞれをWeb Enrollment、NDESと呼んでいます。",[165,742,743],{"id":743},"仕様と普及状況",[152,745,746,747,752],{},"その後Microsoftが",[237,748,751],{"href":749,"rel":750},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[609],"Microsoft OpenSpecで仕様","を公開したとはいえ、このプロトコルを実装した他の認証局システムを当社は把握していません。クライアント側では、Windowsがこのプロトコルを標準でサポートしており、他のプラットフォームはサポート対象外です。",[165,754,614],{"id":755},"技術-1",[152,757,758],{},"主要な登録方式は、RPCまたはDCOMをベースとする独自プロトコルです。",[152,760,761],{},"自動登録もこのプロトコルを使用します。自動登録を機能させるには、次の条件が必要です。",[170,763,764,767,770,773,776],{},[173,765,766],{},"ドメインに参加したデバイス",[173,768,769],{},"グループポリシーで自動登録が有効になっていること",[173,771,772],{},"（スタンドアロンではなく）エンタープライズ認証局であること",[173,774,775],{},"その認証局が証明書テンプレートを発行していること",[173,777,778],{},"ユーザーまたはデバイスがそのテンプレートに対する登録および自動登録の権限を持っていること",[152,780,781,782,786,787,790],{},"自動登録を確認する既定の間隔は8時間ですが、",[783,784,785],"code",{},"certutil -pulse","、あるいは多くの場合それ以上に有効な",[783,788,789],{},"gpupdate -force","で強制実行できます。",[165,792,581],{"id":793},"認証-1",[152,795,796],{},"このプロトコルはActive Directoryに組み込まれた認証プロトコルを使用します。つまり、ユーザーとコンピューターはAD資格情報で認証されます。",[798,799,800],"style",{},"\n    table {border: 2px solid white}\n    th, td {border: solid black; padding-left: 1em; padding-right: 1em; font-size: smaller}\n",{"title":421,"searchDepth":422,"depth":422,"links":802},[803,808],{"id":484,"depth":422,"text":485,"children":804},[805,806,807],{"id":601,"depth":427,"text":601},{"id":614,"depth":427,"text":614},{"id":581,"depth":427,"text":581},{"id":727,"depth":422,"text":728,"children":809},[810,811,812,813],{"id":731,"depth":427,"text":731},{"id":743,"depth":427,"text":743},{"id":755,"depth":427,"text":614},{"id":793,"depth":427,"text":581},{"lang":448,"seoTitle":815,"titleClass":449,"socialimg":816,"blogtitlepic":817,"customExcerpt":818,"keywords":819,"asideNav":820,"maxContent":459},"証明書の登録方式：SCEP、ACME、EST、Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","SCEP、ACME、EST、Microsoft RPC、手動による証明書登録の仕組みを解説します。安全な証明書発行のために、PKIの登録プロトコルを比較しましょう。","証明書の登録方式, SCEP, ACME, EST, Microsoft RPC, 証明書登録プロトコル, PKIにおける証明書登録, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, Microsoftの証明書登録",{"menuItems":821},[822,824],{"href":823,"text":485},"#scep",{"href":825,"text":728},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":466,"description":471},"glossary/enrollment-methods","2KbeehRa9ZEqX9Y_3uq5FEElDroYimRpDMMWBEv-ITc",{"id":831,"title":832,"author":143,"body":833,"cta":143,"description":421,"eventid":143,"extension":444,"hideInRecent":445,"layout":446,"meta":1062,"moment":143,"navigation":459,"path":1080,"seo":1081,"stem":1082,"tags":143,"webcast":445,"__hash__":1083},"content_ja/glossary/important-data-formats.md","主要なデータ形式",{"type":145,"value":834,"toc":1045},[835,839,858,865,868,872,875,878,881,884,887,890,893,896,899,907,910,914,922,925,928,931,942,945,958,961,964,967,970,973,982,986,989,992,995,1006,1010,1013,1016,1024,1027,1035,1038],[148,836,838],{"id":837},"x509","X.509",[152,840,841,842,845,846,851,852,857],{},"X.509はデジタル証明書の",[653,843,844],{},"まさに標準","です。かつては",[237,847,850],{"href":848,"rel":849},"https://www.rfc-editor.org/rfc/rfc4880",[609],"OpenPGP","のような対抗規格もありましたが、現在ではあまり使われていません。とはいえ、正確にはX.509が正しい標準というわけではありません。X.509は実際にはITU-Tの標準であり、本当に重要な定義はITU-TではなくIETFの標準、すなわち",[237,853,856],{"href":854,"rel":855},"https://www.rfc-editor.org/rfc/rfc5280",[609],"RFC 5280","に含まれています。このRFCはX.509に基づく「インターネット向けPKIプロファイル」を定義しており、実務上意味を持つのはこのプロファイルだけです。",[152,859,860,861,864],{},"デジタル証明書は非対称暗号、とりわけデジタル署名を利用します。今日のデジタル証明書の最も一般的なユースケースはサーバー認証です。誰もがすでに証明書を使ったことがありますが、それがX.509証明書だと意識していない場合がほとんどでしょう。HTTP",[156,862,863],{},"S","のWebサイトにアクセスするたびに、ブラウザーはWebサーバーとのTLS接続を確立します。Webサーバーは自身が何者であるかを証明するためにX.509証明書を使います。たとえば銀行のWebサイトにアクセスして口座から送金するとき、利用者は通信相手が本当に自分の銀行であることを確かめたいはずです。攻撃者は銀行のWebサイトになりすまし、利用者のパスワードとTANを読み取って、自分が管理する口座へ送金しようとするかもしれません。攻撃者は銀行のWebサーバーのX.509証明書を持っていないため、HTTPSはこれを防ぐのに役立ちます。ブラウザーが特定のドメインにHTTPS接続していると表示している場合、証明書によって、そのドメインを所有する者のWebサーバーに本当に接続していることが保証されます。",[152,866,867],{},"証明書はどのようにしてそれを実現するのでしょうか。証明書にはいくつかのメタデータ、暗号鍵ペアの公開鍵、そして認証局による署名が含まれます。この3つの部分を順に見ていきましょう。",[165,869,871],{"id":870},"x509証明書の内容","X.509証明書の内容",[400,873,874],{"id":874},"メタデータ",[152,876,877],{},"X.509証明書のメタデータには、とりわけ、どの期間有効か、証明書を何に使うべきか、誰に対して発行されたかといった情報が含まれます。特にTLSサーバー証明書の場合は、Webサーバーのドメインが含まれます。ブラウザーは、アクセスしようとしたドメインと証明書内のドメインを比較します。一致しない場合、ブラウザーは処理を続行せず、警告を表示します。証明書が期限切れの場合も警告を表示します。",[152,879,880],{},"奇妙なことに、TLSのないHTTPサイトにアクセスした場合、ブラウザーは警告を表示しないことが多くありました。こちらのほうがさらに安全性は低いにもかかわらずです。無効なX.509証明書を持つWebサーバーにアクセスした場合、それは単なる設定ミスかもしれず、通信を盗聴する攻撃者からは実際には保護されている可能性があります。一方、HTTP接続はまったく保護を提供しません。",[152,882,883],{},"もっとも、この問題については証明書ピン留めなど、改善も進んでいます。ただしこれは高度なテーマなので、X.509証明書に含まれる残り2つの要素を見ていきましょう。",[400,885,886],{"id":886},"公開鍵",[152,888,889],{},"証明書には非対称鍵ペアの公開部分が含まれます。この暗号技術によって、Webサーバー（用途が異なる場合は一般に証明書の保持者）は、鍵ペアの秘密部分も保有していることを、接続してくるクライアントやその他の誰にもそれを明かさずに証明できます。これによりクライアントは、そのWebサーバーが証明書をコピーしただけの者ではなく、本当に証明書の所有者であることを確信できます。実のところ証明書自体のコピーはかなり容易です。Webサーバーは接続を試みるすべての相手に証明書のコピーを送るからです。一方、秘密鍵はWebサーバーから外に出ることがないため、盗み出すのは困難または不可能です。HSMやTPMなど、秘密鍵の窃取をさらに困難にする手段もいくつかあります。",[400,891,892],{"id":892},"認証局による署名",[152,894,895],{},"メタデータにより、クライアントはその証明書が特定の用途に適しているかを確認できます。公開鍵は、通信相手が実際に証明書の所有者であることを示します。しかし攻撃者も、新しい鍵ペアと新しい証明書を作れば、この2つの条件を満たせてしまいます。では、クライアントはその証明書が信頼できるとどうやって判断するのでしょうか。",[152,897,898],{},"証明書には、認証局（CA）の証明書に属する別の鍵ペアによる暗号署名が含まれます。CA証明書も同じ方法で検証でき、やはり別の証明書によって署名されています。クライアントはこの「信頼チェーン」を、いわゆるリーフ証明書からルートCA証明書までたどることができます。ルートCA証明書は自己署名されていること、つまり証明書の署名が自身の鍵ペアによるものであることで識別できます。通常この過程は1段階か2段階であり、関与するCA証明書は1つか2つだけです。",[152,900,901,902,906],{},"認証局は",[237,903,905],{"href":904},"enrollment-methods/","証明書を発行する","際に、メタデータが正しいことを慎重に確認しなければなりません。たとえば自社ドメインのTLSサーバー証明書を取得したい場合、自分が本当にそのドメインの所有者であることを認証局に証明する必要があります。この確認がどれだけ厳格かによって、基本的な証明書かExtended Validation（EV）証明書かが決まります。",[152,908,909],{},"各ブラウザーとオペレーティングシステムには、あらかじめ定義された信頼されたルートCAの一覧が付属しています。ユーザーや管理者は、信頼されたルートCAを追加できます。特定の用途に限って信頼されるルートCAもあれば、より広範に信頼されるものもあります。クライアントは、信頼チェーンが信頼されたルートCAで終端しているかを確認します。終端しており、信頼チェーン内のすべての証明書がまだ有効で、メタデータがその用途どおりに使われていることを示していれば、Webサーバーのリーフ証明書は信頼され、接続が確立されます。",[165,911,913],{"id":912},"x509証明書の有効性","X.509証明書の有効性",[152,915,916,917,921],{},"X.509証明書は、確立されるべき信頼がすべてです。すでに述べたとおり、信頼の判断基準の1つは、証明書が信頼されたルートCAまでチェーンでつながっていることです。もう1つは、有効期間内であることです。これは通常、期限切れでないことを意味しますが、多くは技術的な誤りによって、証明書がまだ有効になっていない場合もあります。そしてもう1つ基準があります。証明書を発行した認証局がそれを失効させていないことです。これはそれ自体で1つのテーマになるため、",[237,918,920],{"href":919},"other-stuff/certificate-lifecycle-management","別の記事","で解説しています。",[148,923,621],{"id":924},"pkcs7",[152,926,927],{},"PKCS#7は暗号データ形式における万能ナイフのような存在で、暗号化されたメッセージ、署名されたメッセージ、署名および暗号化されたメッセージ、証明書、秘密鍵など、事実上あらゆるものを格納できます。",[152,929,930],{},"これはこの形式の大きな欠点でもあります。アプリケーションやユーザーがPKCS#7を受け取っても、それをどう扱えばよいかはそれだけでは分かりません。重要なユースケースをいくつか挙げます。",[170,932,933,936,939],{},[173,934,935],{},"S/MIMEメッセージは、基本的にPKCS#7を本文または添付ファイルとする電子メールです。",[173,937,938],{},"SCEPのリクエストとレスポンスは、いずれも実際にはPKCS#7の署名付きメッセージです。",[173,940,941],{},"ESTのレスポンスはCMSメッセージです。",[165,943,944],{"id":944},"エンコード",[152,946,947,948,952,953,957],{},"一般的なファイル拡張子は、.p7b（",[237,949,951],{"href":950},"asn.1-and-pem#der-encoding","DERエンコード","）、.p7s（署名付きメッセージまたはメッセージ署名）、.p7m（署名または暗号化されたメッセージ）です。ラベル「PKCS7」を用いた",[237,954,956],{"href":955},"asn.1-and-pem#pem-encoding","PEMエンコード","も定義されていますが、ほとんど使われません。",[165,959,960],{"id":960},"ツール",[152,962,963],{},"WindowsではPKCS#7メッセージをダブルクリックで開くことができ、暗号シェル拡張が内容を表示します。ただし通常取り出せるのは証明書とその秘密鍵だけで、メッセージの内容は取り出せません。",[152,965,966],{},"OpenSSLなどのツールを使えば、これらのファイルを別の形式に変換できます。",[148,968,626],{"id":969},"pkcs10",[152,971,972],{},"PKCS#10で定義される証明書署名要求（CSR）は、認証局（CA）から取得したい証明書の内容を記述したファイルです。X.509証明書に似た構造を持ちますが、認証局による署名がありません。代わりに証明書要求者の署名が含まれます。とはいえ形式は異なるため、自己署名証明書と同じものではありません。",[152,974,975,976,981],{},"バイナリのDERエンコードにすることも、",[237,977,980],{"href":978,"rel":979},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[609],"「CERTIFICATE REQUEST」ラベルを用いて","PEMエンコードにすることもできます。",[148,983,985],{"id":984},"pkcs12","PKCS#12",[152,987,988],{},"PKCS#12は、特にWindows環境ではPFXとしても知られています。そのため一般的なファイル拡張子は.pfxと.p12です。X.509証明書と、技術的に強制されているわけではないものの、ほぼ必ず対応する秘密鍵を格納します。",[152,990,991],{},"PKCS#12ファイル内のデータは通常、パスワードで暗号化されます。多くの場合、暗号化されるのは秘密鍵だけなので、アプリケーションが対応していればパスワードを知らなくても証明書を取り出せます（ただし多くのアプリケーションは対応していません）。Windows環境では証明書とその秘密鍵をファイルに保存する方法としてPKCS#12が最も一般的ですが、Linux環境ではPEMエンコードされたPKCS#8ファイルのほうが一般的です。",[152,993,994],{},"この標準は、入れ子になった「safebag」に証明書と秘密鍵を格納する方法を数多く用意しているため、PKCS#12ファイルには次のような互換性の問題があります。",[170,996,997,1000,1003],{},[173,998,999],{},"Windowsは、PKCS#12内の秘密鍵を、本来対応する1つの証明書だけでなく、そのファイルから取り出したすべての証明書に関連付けることで知られています。PKCS#12に証明書チェーンが含まれている場合、WindowsはCA証明書の秘密鍵を保持していると表示することがあります。",[173,1001,1002],{},"macOSでは、暗号アルゴリズムが新しすぎるとPKCS#12ファイルをインポートできません。",[173,1004,1005],{},"受け取り側のアプリケーションが証明書を取り出せるようにするため、PKCS#12ファイル内の証明書を暗号化する必要がある場合があります。ただし、非常に古く脆弱なアルゴリズムにしか対応していないものもあります。情報自体はいずれにせよ公開されるものなので、通常これは問題になりません。しかしOpenSSL 3.xはこうした古く脆弱なアルゴリズムをサポートしておらず、そのPKCS#12を開くことを拒否します。",[148,1007,1009],{"id":1008},"asn1とpem","ASN.1とPEM",[152,1011,1012],{},"Abstract Syntax Notation One（ASN.1）は、データ構造を記述するための言語です。整数やシーケンスといった定義済みの基本データ型があり、プロトコルやファイル形式の設計者は、それらを使って独自のデータ型を定義できます。",[165,1014,951],{"id":1015},"derエンコード",[152,1017,1018,1023],{},[237,1019,1022],{"href":1020,"rel":1021},"https://www.itu.int/rec/T-REC-X.680/",[609],"ITU-T標準X.680","は、ASN.1で規定されたデータに対する複数のエンコード方式を定義しています。X.509関連のデータで最も重要なエンコードはDERです。型のエンコード方法が一通りしかないため、型のバイナリDER表現のハッシュは常に同じ値になるからです。これは、たとえばASN.1でエンコードされたデータに署名する際に重要になります。",[165,1025,956],{"id":1026},"pemエンコード",[152,1028,1029,1030,1034],{},"X.509関連のファイル形式の多くは、すべてではありませんが、DERエンコードでバイナリとして保存することも、DERエンコードの上にさらに",[237,1031,956],{"href":1032,"rel":1033},"https://datatracker.ietf.org/doc/html/rfc7468",[609],"を適用することもできます。PEMはASCII文字だけを使うため、クリップボードで簡単にコピー＆ペーストでき、数十年前にまだそれが重要だった頃には電子メールで送ることもできました。",[165,1036,960],{"id":1037},"ツール-1",[152,1039,1040,1041,1044],{},"ASN.1でエンコードされたファイルがあり、その型が分からない場合や、その型を扱えるアプリケーションがない場合でも、生のASN.1構造をデコードして中身を確認できます。Windowsでは、組み込みツールのcertutilが",[783,1042,1043],{},"certutil -decode","コマンドでこれを行えます。",{"title":421,"searchDepth":422,"depth":422,"links":1046},[1047,1051,1055,1056,1057],{"id":837,"depth":422,"text":838,"children":1048},[1049,1050],{"id":870,"depth":427,"text":871},{"id":912,"depth":427,"text":913},{"id":924,"depth":422,"text":621,"children":1052},[1053,1054],{"id":944,"depth":427,"text":944},{"id":960,"depth":427,"text":960},{"id":969,"depth":422,"text":626},{"id":984,"depth":422,"text":985},{"id":1008,"depth":422,"text":1009,"children":1058},[1059,1060,1061],{"id":1015,"depth":427,"text":951},{"id":1026,"depth":427,"text":956},{"id":1037,"depth":427,"text":960},{"lang":448,"seoTitle":1063,"titleClass":449,"blogtitlepic":1064,"socialimg":1065,"customExcerpt":1066,"keywords":1067,"asideNav":1068,"maxContent":459},"主要なデータ形式：X.509、PKCS、ASN.1、PEMの解説","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","X.509、PKCS 7、PKCS 10、PKCS 12、ASN.1、PEMなど、暗号技術と証明書に欠かせない形式を解説します。","主要なデータ形式, X.509証明書, PKCS形式, PKCS 7, PKCS 10, PKCS 12, ASN.1, PEM形式, デジタル証明書, 公開鍵基盤, PKIの形式",{"menuItems":1069},[1070,1072,1074,1076,1078],{"href":1071,"text":838},"#x509",{"href":1073,"text":621},"#pkcs7",{"href":1075,"text":626},"#pkcs10",{"href":1077,"text":985},"#pkcs12",{"href":1079,"text":1009},"#asn1とpem","/glossary/important-data-formats",{"title":832,"description":421},"glossary/important-data-formats","HC8S81PU9acVS5YFhgcy5OxqgF3K9-914PQxRO1klCY",{"id":1085,"title":1086,"author":143,"body":1087,"cta":143,"description":421,"eventid":143,"extension":444,"hideInRecent":445,"layout":446,"meta":1306,"moment":143,"navigation":459,"path":1312,"seo":1313,"stem":1314,"tags":143,"webcast":445,"__hash__":1315},"content_ja/glossary/public-key-infrastructure.md","公開鍵基盤（PKI）",{"type":145,"value":1088,"toc":1295},[1089,1092,1100,1103,1134,1138,1141,1145,1148,1178,1181,1184,1187,1206,1209,1213,1220,1234,1239,1253,1257,1262,1275,1280,1292],[148,1090,1091],{"id":1091},"信頼の確立",[165,1093,1095,1096,1099],{"id":1094},"クライアントが特定のルートcaへの信頼を表明する仕組み","クライアントが特定のルートCAへの信頼を",[156,1097,1098],{},"表明","する仕組み",[152,1101,1102],{},"クライアントは、証明書の信頼チェーンを用いる一連の処理を通じて、特定のルート認証局（CA）への信頼を示します。その仕組みは次のとおりです。",[170,1104,1105,1111,1117,1123,1128],{},[173,1106,1107,1110],{},[156,1108,1109],{},"プリインストールされたルート証明書","：ほとんどのオペレーティングシステムとWebブラウザーには、信頼された認証局のルート証明書があらかじめ組み込まれています。これらのルート証明書は、信頼されたルートストアに格納されます。",[173,1112,1113,1116],{},[156,1114,1115],{},"証明書の検証","：クライアントがサーバーに接続すると（Webサイトを閲覧する場合など）、サーバーは自身のTLS証明書を提示します。この証明書は通常、中間CAによって署名されており、その中間CAはさらにルートCAによって署名されています。",[173,1118,1119,1122],{},[156,1120,1121],{},"信頼チェーンの検証","：クライアントは、提示された証明書が信頼されたルートCAによって署名されているかを確認し、信頼チェーンを検証します。あわせて、チェーン内の中間CAが信頼されているかも確認します。",[173,1124,1125,1127],{},[156,1126,372],{},"：チェーン内の各証明書は、その上位にある認証局によってデジタル署名されています。クライアントは認証局の公開鍵を使ってこれらの署名を検証し、証明書が改ざんされていないことを確かめます。",[173,1129,1130,1133],{},[156,1131,1132],{},"信頼の判断","：信頼チェーン全体が有効で、信頼されたルートCAまでさかのぼれる場合、クライアントはサーバーの証明書を信頼します。これにより安全な通信が開始できます。",[165,1135,1137],{"id":1136},"単一のルートcaではなく中間caを使う利点","単一のルートCAではなく中間CAを使う利点",[152,1139,1140],{},"インフラストラクチャー向けのPKIでは、単一のルートのほうが有利な場合もあります。",[165,1142,1144],{"id":1143},"中間caが証明書を取得する仕組み","中間CAが証明書を取得する仕組み",[152,1146,1147],{},"中間認証局（CA）は、ルートCAによるクロス署名と呼ばれる手順を通じて自身の証明書を取得します。その仕組みは次のとおりです。",[253,1149,1150,1156,1162,1167,1172],{},[173,1151,1152,1155],{},[156,1153,1154],{},"証明書署名要求（CSR）","：中間CAを構築したい組織がCSRを生成します。このCSRには、中間CAの公開鍵と識別情報が含まれます。",[173,1157,1158,1161],{},[156,1159,1160],{},"ルートCAへの提出","：CSRを信頼されたルートCAに提出します。",[173,1163,1164,1166],{},[156,1165,353],{},"：ルートCAは、中間証明書を要求している組織の身元と正当性を検証します。",[173,1168,1169,1171],{},[156,1170,342],{},"：検証が完了すると、ルートCAは自身の秘密鍵でCSRに署名し、中間証明書を作成します。この署名済み証明書によって中間CAがルートCAに結び付けられ、信頼チェーンが確立されます。",[173,1173,1174,1177],{},[156,1175,1176],{},"発行","：ルートCAは署名した中間証明書を要求元の組織に発行し、組織はそれを使ってエンドエンティティ証明書（WebサイトのTLS証明書など）に署名できるようになります。",[152,1179,1180],{},"この手順により、中間CAは、すでにブラウザーとオペレーティングシステムから信頼されているルートCAとのつながりによって信頼されることになります。",[165,1182,1183],{"id":1183},"証明書チェーンとその仕組み",[152,1185,1186],{},"証明書チェーンは信頼チェーンとも呼ばれ、デジタル証明書の真正性と信頼性を保証する証明書の連なりです。その仕組みは次のとおりです。",[170,1188,1189,1195,1201],{},[173,1190,1191,1194],{},[156,1192,1193],{},"検証の流れ","：クライアント（Webブラウザーなど）がサーバーに接続すると、サーバーは自身のエンドエンティティ証明書を提示します。続いてクライアントは証明書チェーンを確認し、各証明書がチェーン内の次の証明書によってルート証明書まで順に署名されていることを検証します。",[173,1196,1197,1200],{},[156,1198,1199],{},"信頼チェーン","：チェーン内の各証明書は、その上位にある証明書の公開鍵を使って検証されます。この処理は、クライアントがすでに信頼しているルート証明書に到達するまで続きます。",[173,1202,1203,1205],{},[156,1204,1091],{},"：チェーン全体が有効で、信頼されたルート証明書までさかのぼれる場合、クライアントはエンドエンティティ証明書を信頼し、安全な通信が開始できます。",[152,1207,1208],{},"この仕組みによって、エンドエンティティ証明書が正当であり、信頼できる機関から発行されたことが保証され、デジタル通信の完全性とセキュリティが維持されます。",[165,1210,1212],{"id":1211},"basic-constraints拡張が解決しようとする問題","Basic Constraints拡張が解決しようとする問題",[152,1214,1215,1216,1219],{},"デジタル証明書の",[156,1217,1218],{},"Basic Constraints","拡張は、公開鍵基盤（PKI）における証明書の種類とその役割を区別するという課題に対処します。その仕組みは次のとおりです。",[170,1221,1222,1228],{},[173,1223,1224,1227],{},[156,1225,1226],{},"認証局（CA）の識別","：その証明書がCA証明書かエンドエンティティ証明書かを示します。CA証明書は他の証明書を発行できるのに対し、エンドエンティティ証明書は発行できないため、この区別は極めて重要です。",[173,1229,1230,1233],{},[156,1231,1232],{},"パス長の制約","：証明書チェーンにおいて、このCAの下位に存在できる中間CAの数を制限できます。これにより、非効率でセキュリティ上の懸念もある過度に長い証明書チェーンを防げます。",[152,1235,1236],{},[156,1237,1238],{},"解決される問題：",[170,1240,1241,1247],{},[173,1242,1243,1246],{},[156,1244,1245],{},"不正な証明書発行の防止","：どの証明書が認証局として振る舞えるかを明示することで、エンドエンティティ証明書が他の証明書を発行するのを防ぎ、PKIの完全性を保ちます。",[173,1248,1249,1252],{},[156,1250,1251],{},"証明書チェーン長の管理","：パス長を制限することで証明書チェーンを扱いやすく安全な範囲に保ち、長いチェーンに伴う潜在的な脆弱性を防ぎます。",[165,1254,1256],{"id":1255},"これらの問題を解決する仕組み"," これらの問題を解決する仕組み",[152,1258,1215,1259,1261],{},[156,1260,1218],{},"拡張は、CA証明書とエンドエンティティ証明書を区別し、証明書チェーンの長さを管理するという課題を、次の仕組みで解決します。",[170,1263,1264,1270],{},[173,1265,1266,1269],{},[156,1267,1268],{},"CAフラグ","：このフラグは、その証明書が認証局（CA）の証明書かエンドエンティティ証明書かを示します。フラグがTRUEに設定されている場合、その証明書は他の証明書の署名に使用でき、CA証明書であることを表します。FALSEの場合はエンドエンティティ証明書であり、他の証明書を発行できません。",[173,1271,1272,1274],{},[156,1273,1232],{},"：有効な証明書パスにおいて、この証明書の後に続けられる自己発行以外の中間証明書の最大数を指定します。この制約を設定することで、拡張は証明書チェーンの長さを制限し、扱いやすく安全な状態に保ちます。",[152,1276,1277],{},[156,1278,1279],{},"これらの仕組みの働き：",[170,1281,1282,1287],{},[173,1283,1284,1286],{},[156,1285,1268],{},"：証明書の発行時に、想定される用途に応じてCAフラグが設定されます。証明書の検証処理において、クライアントはこのフラグを確認し、その証明書が他の証明書を発行するものとして信頼できるかを判断します。",[173,1288,1289,1291],{},[156,1290,1232],{},"：検証処理の中でこの値が確認され、証明書チェーンが指定された長さを超えていないことが検査されます。チェーンが長すぎる場合、その証明書は無効と見なされます。",[152,1293,1294],{},"これらの仕組みによって、他の証明書を発行できるのは権限を与えられた証明書だけとなり、過度に長い証明書チェーンも防がれるため、公開鍵基盤（PKI）の完全性とセキュリティが維持されます。",{"title":421,"searchDepth":422,"depth":422,"links":1296},[1297],{"id":1091,"depth":422,"text":1091,"children":1298},[1299,1301,1302,1303,1304,1305],{"id":1094,"depth":427,"text":1300},"クライアントが特定のルートCAへの信頼を表明する仕組み",{"id":1136,"depth":427,"text":1137},{"id":1143,"depth":427,"text":1144},{"id":1183,"depth":427,"text":1183},{"id":1211,"depth":427,"text":1212},{"id":1255,"depth":427,"text":1256},{"lang":448,"seoTitle":1307,"titleClass":449,"socialimg":1308,"blogtitlepic":1309,"customExcerpt":1310,"keywords":1311,"maxContent":459},"公開鍵基盤における信頼の確立：PKIの証明書信頼モデル","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","証明書チェーン、ルートCAと中間CA、そして安全な証明書検証によって、PKIにおける信頼を確立します。","PKIにおける信頼の確立, 公開鍵基盤の信頼, 証明書の信頼チェーン, ルートCAの信頼, 中間CAの信頼, PKI信頼モデル, 証明書の検証, 信頼されたルート証明書, 安全な証明書検証, 信頼チェーンの検証","/glossary/public-key-infrastructure",{"title":1086,"description":421},"glossary/public-key-infrastructure","cWsJRfpL19wmYTrhKn9HrhJlUtXMV6BSQbYfqsv66BA",{"id":1317,"title":1318,"author":143,"body":1319,"cta":143,"description":421,"eventid":143,"extension":444,"hideInRecent":445,"layout":446,"meta":1752,"moment":143,"navigation":459,"path":1758,"seo":1759,"stem":1760,"tags":143,"webcast":445,"__hash__":1761},"content_ja/glossary/use-cases-for-certificates.md","証明書のユースケース",{"type":145,"value":1320,"toc":1737},[1321,1325,1328,1342,1345,1377,1380,1410,1413,1419,1425,1429,1482,1485,1490,1504,1509,1521,1524,1527,1541,1545,1551,1562,1567,1578,1584,1595,1599,1619,1623,1626,1630,1649,1653,1670,1675,1695,1699,1702,1734],[148,1322,1324],{"id":1323},"transport-layer-securitytls","Transport Layer Security（TLS）",[165,1326,1327],{"id":1327},"クライアントがサーバーから証明書を受け取る際に確認すべき2つの問い",[253,1329,1330,1336],{},[173,1331,1332,1335],{},[156,1333,1334],{},"その証明書は有効で信頼できるか","。クライアントは、証明書が信頼された認証局（CA）によって発行され、期限切れでも失効済みでもないことを検証する必要があります。これには、証明書の有効期間の確認と、クライアントが信頼する認証局によって署名されていることの確認が含まれます。",[173,1337,1338,1341],{},[156,1339,1340],{},"その証明書はサーバーの身元と一致するか","。クライアントは、Common Name（CN）やSubject Alternative Name（SAN）といった証明書の内容が、サーバーのドメイン名と一致することを確かめる必要があります。これにより、その証明書が接続しようとしているサーバーのために発行されたものであることを確認できます。",[165,1343,1344],{"id":1344},"クライアントによる証明書の信頼性の検証",[253,1346,1347,1353,1359,1365,1371],{},[173,1348,1349,1352],{},[156,1350,1351],{},"証明書の信頼チェーンの確認","：クライアントは、サーバーの証明書、中間証明書、ルート証明書からなる証明書チェーンを検証します。チェーン内の各証明書は、その1つ上位の機関によって署名されていなければならず、最終的に信頼されたルート証明書に行き着く必要があります。",[173,1354,1355,1358],{},[156,1356,1357],{},"証明書の有効期間の検証","：クライアントは証明書の有効期間を確認し、期限切れでないこと、およびまだ有効になっていない状態でないことを確かめます。これには、証明書の「Not Before」と「Not After」の日付の確認が含まれます。",[173,1360,1361,1364],{},[156,1362,1363],{},"証明書とサーバーの身元の照合","：クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確かめます。これにより、その証明書が接続先のサーバーのために発行されたものであることが確認できます。",[173,1366,1367,1370],{},[156,1368,1369],{},"失効の確認","：クライアントは、証明書失効リスト（CRL）への問い合わせ、またはOnline Certificate Status Protocol（OCSP）の利用によって、証明書が失効していないかを確認します。失効した証明書はもはや信頼されません。",[173,1372,1373,1376],{},[156,1374,1375],{},"デジタル署名の検証","：クライアントは証明書のデジタル署名を検証し、改ざんされていないことを確かめます。これには、発行元の認証局の公開鍵に照らして暗号署名を確認する作業が含まれます。",[165,1378,1379],{"id":1379},"クライアントによるサーバーが証明書の真の所有者であることの検証",[253,1381,1382,1388,1394,1399,1405],{},[173,1383,1384,1387],{},[156,1385,1386],{},"証明書チェーンの検証","：クライアントは証明書チェーンを検証し、チェーン内の各証明書が信頼された認証局（CA）によって署名されていることを確かめます。このチェーンはサーバーの証明書から始まり、信頼されたルート証明書で終わります。",[173,1389,1390,1393],{},[156,1391,1392],{},"ドメイン名の照合","：クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確認します。これにより、その証明書が接続先のサーバーのために発行されたものであることが保証されます。",[173,1395,1396,1398],{},[156,1397,1375],{},"：クライアントは、発行元の認証局の公開鍵を使って証明書のデジタル署名を検証します。これにより、証明書が改ざんされておらず、信頼された認証局から確かに発行されたものであることが保証されます。",[173,1400,1401,1404],{},[156,1402,1403],{},"証明書の有効期間","：クライアントは証明書の有効期間を確認し、現時点で有効であり期限切れでないことを確かめます。",[173,1406,1407,1370],{},[156,1408,1409],{},"失効状態の確認",[165,1411,1412],{"id":1412},"証明書の信頼性を確認済みでも所有者の確認が重要な理由",[152,1414,1415,1418],{},[156,1416,1417],{},"証明書の有効性と信頼","：この手順では、証明書が信頼された認証局（CA）によって発行され、有効期間内にあり、失効していないことを確認します。これにより、その証明書が正当であり、改ざんされていないことが確かめられます。",[152,1420,1421,1424],{},[156,1422,1423],{},"サーバーの身元の検証","：証明書が有効で信頼できるとしても、それが接続先のサーバーのものであることも確認しなければなりません。そのために、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確かめます。この手順によって、その証明書が特定のサーバーのために発行されたものであることが保証され、攻撃者が別のドメインの有効な証明書を提示する中間者攻撃を防げます。",[165,1426,1428],{"id":1427},"クライアントがこの問いに答える2つの方法とそれぞれで生じる2つの結果","クライアントがこの問いに答える2つの方法と、それぞれで生じる2つの結果",[253,1430,1431,1458],{},[173,1432,1433,1436,1437,1440,1443,1444],{},[156,1434,1435],{},"Domain Name System（DNS）による検証","：クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確認します。 ",[1438,1439],"br",{},[156,1441,1442],{},"結果","：",[170,1445,1446,1452],{},[173,1447,1448,1451],{},[156,1449,1450],{},"一致","：名前が一致すれば、クライアントはその証明書が当該サーバーのために発行されたものだと確信して接続を継続できます。 ",[173,1453,1454,1457],{},[156,1455,1456],{},"不一致","：名前が一致しない場合、クライアントは接続を終了するか警告を表示し、セキュリティ上のリスクがある可能性を示します。",[173,1459,1460,1463,1464,1466,1443,1468],{},[156,1461,1462],{},"公開鍵基盤（PKI）による検証","：クライアントは、発行元の認証局（CA）の公開鍵を使って証明書のデジタル署名を検証します。 ",[1438,1465],{},[156,1467,1442],{},[170,1469,1470,1476],{},[173,1471,1472,1475],{},[156,1473,1474],{},"署名が有効","：署名が有効であれば、その証明書が改ざんされておらず、信頼された認証局から発行されたことが確認できます。",[173,1477,1478,1481],{},[156,1479,1480],{},"署名が無効","：署名が無効な場合、クライアントは接続を終了するか警告を表示し、その証明書が侵害または偽造されている可能性を示します。",[165,1483,1484],{"id":1484},"使用する方法を決める要因",[152,1486,1487],{},[156,1488,1489],{},"Domain Name System（DNS）による検証：",[170,1491,1492,1498],{},[173,1493,1494,1497],{},[156,1495,1496],{},"用途","：この方法はTLSハンドシェイクの一部として常に使用されます。クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）をサーバーのドメイン名と照合し、一致することを確認します。",[173,1499,1500,1503],{},[156,1501,1502],{},"決定要因","：これはTLSプロトコルの標準的な一部であり、安全な接続を確立する際にクライアントが自動的に実行します。",[152,1505,1506],{},[156,1507,1508],{},"公開鍵基盤（PKI）による検証：",[170,1510,1511,1516],{},[173,1512,1513,1515],{},[156,1514,1496],{},"：この方法もTLSハンドシェイク中に常に使用されます。クライアントは、発行元の認証局（CA）の公開鍵を使って証明書のデジタル署名を検証します。",[173,1517,1518,1520],{},[156,1519,1502],{},"：これもTLSプロトコルの標準的な一部です。クライアントは、証明書が有効で改ざんされていないことを確かめるため、この確認を自動的に実行します。",[148,1522,1523],{"id":1523},"サーバーがクライアントに送るべき証明書",[152,1525,1526],{},"TLSハンドシェイクにおいて、サーバーは次の証明書をクライアントに送る必要があります。",[170,1528,1529,1535],{},[173,1530,1531,1534],{},[156,1532,1533],{},"エンドエンティティ証明書","：サーバー自身の証明書であり、クライアントに対して自身の身元を証明します。",[173,1536,1537,1540],{},[156,1538,1539],{},"中間証明書","：エンドエンティティ証明書を信頼されたルート証明書に結び付ける証明書です。サーバーの証明書から信頼されたルート証明書までの信頼チェーンを確立するのに役立ちます。",[148,1542,1544],{"id":1543},"domain-validation証明書とextended-validation証明書","Domain Validation証明書とExtended Validation証明書",[152,1546,1547,1550],{},[156,1548,1549],{},"Domain Validation（DV）証明書","は、認証局（CA）が申請者によるドメインの管理権限を検証するタイプのTLS証明書です。検証は通常、次の方法で行われます。",[170,1552,1553,1556,1559],{},[173,1554,1555],{},"ドメインの管理者連絡先に送られたメールに返信する。",[173,1557,1558],{},"DNSのTXTレコードを追加する。",[173,1560,1561],{},"Webサーバーにファイルをアップロードする。",[152,1563,1564],{},[156,1565,1566],{},"主な特徴：",[170,1568,1569,1572,1575],{},[173,1570,1571],{},"迅速な発行：検証が最小限で済むため、多くの場合数分以内に発行できます。",[173,1573,1574],{},"基本的なセキュリティ：暗号化と、ドメインが証明書の要求者によって管理されているという基本的な保証を提供します。",[173,1576,1577],{},"費用対効果：安価または無料であることが多く、小規模なWebサイトや個人のプロジェクトでも利用しやすくなっています。",[152,1579,1580,1583],{},[156,1581,1582],{},"Extended Validation（EV）証明書","は、より厳格な検証手続きを要する上位のTLS証明書です。認証局は、証明書を要求する主体の法的、物理的、運用上の実在性を検証します。これには次の確認が含まれます。",[170,1585,1586,1589,1592],{},[173,1587,1588],{},"主体の法的な身元と状態の確認。",[173,1590,1591],{},"主体の物理的および運用上の実在の検証。",[173,1593,1594],{},"主体がそのドメインを使用する排他的な権利を有していることの確認。",[152,1596,1597],{},[156,1598,1566],{},[170,1600,1601,1607,1613],{},[173,1602,1603,1606],{},[156,1604,1605],{},"高い保証水準","：徹底した審査を伴うため、利用者に最も高い水準の信頼と保証を提供します。",[173,1608,1609,1612],{},[156,1610,1611],{},"視覚的な表示","：一部のブラウザーでは、かつてEV証明書がアドレスバーに組織名を表示していましたが、現在ではあまり見られません。",[173,1614,1615,1618],{},[156,1616,1617],{},"信頼の向上","：金融機関やeコマースサイトなど、機微な情報を扱うWebサイトに適しています。",[165,1620,1622],{"id":1621},"安全性の比較"," 安全性の比較",[152,1624,1625],{},"Extended Validation（EV）証明書は、厳格な検証手続きを経るため、一般にDomain Validation（DV）証明書より安全だと考えられています。両者を比較すると次のようになります。",[152,1627,1628],{},[156,1629,1549],{},[170,1631,1632,1638,1643],{},[173,1633,1634,1637],{},[156,1635,1636],{},"検証水準","：ドメインの管理権限のみを検証します。",[173,1639,1640,1642],{},[156,1641,189],{},"：基本的な暗号化と保証を提供します。",[173,1644,1645,1648],{},[156,1646,1647],{},"ユースケース","：個人のWebサイト、ブログ、小規模事業者に適しています。",[152,1650,1651],{},[156,1652,1582],{},[170,1654,1655,1660,1665],{},[173,1656,1657,1659],{},[156,1658,1636],{},"：主体の法的、物理的、運用上の実在性を検証します。",[173,1661,1662,1664],{},[156,1663,189],{},"：徹底した審査により、より高い水準の信頼と保証を提供します。",[173,1666,1667,1669],{},[156,1668,1647],{},"：金融機関、eコマースサイト、機微な情報を扱うあらゆるWebサイトに適しています。",[152,1671,1672],{},[156,1673,1674],{},"EV証明書のほうが安全な理由：",[170,1676,1677,1683,1689],{},[173,1678,1679,1682],{},[156,1680,1681],{},"徹底した審査","：EV証明書は広範な検証を必要とするため、悪意ある主体が取得するのは困難です。",[173,1684,1685,1688],{},[156,1686,1687],{},"信頼の指標","：現在ではあまり見られませんが、EV証明書はかつてブラウザーのアドレスバーに組織名を表示し、利用者に目に見える保証を与えていました。",[173,1690,1691,1694],{},[156,1692,1693],{},"より高い保証水準","：詳細な検証手続きによって証明書の背後にいる主体が正当であることが確かめられ、フィッシングをはじめとする攻撃のリスクを減らせます。",[148,1696,1698],{"id":1697},"ocspステープリングによる失効確認の流れ","OCSPステープリングによる失効確認の流れ",[152,1700,1701],{},"OCSPステープリングは、遅延を減らしプライバシーを高めることで、標準のOCSPの仕組みを改善します。その仕組みは次のとおりです。",[253,1703,1704,1710,1716,1722,1728],{},[173,1705,1706,1709],{},[156,1707,1708],{},"サーバーがOCSPレスポンスを要求","：Webサーバーは、自身の証明書の失効状態をOCSPレスポンダー（認証局が運用するサーバー）に定期的に問い合わせます。この要求はバックグラウンドで行われ、クライアント接続のたびに行われるわけではありません。",[173,1711,1712,1715],{},[156,1713,1714],{},"OCSPレスポンダーが応答を返す","：OCSPレスポンダーは、証明書の状態（「good」「revoked」「unknown」など）を示す、署名済みでタイムスタンプ付きのOCSPレスポンスを返します。サーバーはこのレスポンスをキャッシュします。",[173,1717,1718,1721],{},[156,1719,1720],{},"ステープルされたレスポンスを伴うTLSハンドシェイク","：クライアント（Webブラウザーなど）がサーバーへの接続を開始すると、サーバーはキャッシュしたOCSPレスポンスをTLSハンドシェイクに含めます。これがレスポンスをハンドシェイクに「ステープルする」と呼ばれる動作です。",[173,1723,1724,1727],{},[156,1725,1726],{},"クライアントがOCSPレスポンスを検証","：クライアントはステープルされたOCSPレスポンスを検証します。レスポンスは認証局によって署名されているため、クライアントはその有効性を信頼できます。レスポンスが証明書の失効を示していれば、クライアントは安全な接続を確立しません。",[173,1729,1730,1733],{},[156,1731,1732],{},"定期的な更新","：サーバーはキャッシュしたOCSPレスポンスを定期的に更新し続け、TLSハンドシェイクの際に常に最新の状態を提示できるようにします。",[152,1735,1736],{},"この仕組みによってクライアントが個別にOCSP要求を行う必要が減り、性能とプライバシーが向上します。",{"title":421,"searchDepth":422,"depth":422,"links":1738},[1739,1747,1748,1751],{"id":1323,"depth":422,"text":1324,"children":1740},[1741,1742,1743,1744,1745,1746],{"id":1327,"depth":427,"text":1327},{"id":1344,"depth":427,"text":1344},{"id":1379,"depth":427,"text":1379},{"id":1412,"depth":427,"text":1412},{"id":1427,"depth":427,"text":1428},{"id":1484,"depth":427,"text":1484},{"id":1523,"depth":422,"text":1523},{"id":1543,"depth":422,"text":1544,"children":1749},[1750],{"id":1621,"depth":427,"text":1622},{"id":1697,"depth":422,"text":1698},{"lang":448,"seoTitle":1753,"titleClass":449,"socialimg":1754,"blogtitlepic":1755,"customExcerpt":1756,"keywords":1757,"maxContent":459},"Transport Layer Security（TLS）：証明書のユースケースと検証","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","サーバーを検証し、証明書チェーンで信頼を築き、暗号化された安全な接続を実現するTLS証明書によって、Webサイトと利用者を保護します。","TLS証明書, Transport Layer Security, 証明書のユースケース, TLS証明書の検証, 証明書の信頼チェーン, DV証明書, EV証明書, サーバー認証, 安全な接続, OCSPステープリング","/glossary/use-cases-for-certificates",{"title":1318,"description":421},"glossary/use-cases-for-certificates","MHMxCZ_QvmKsV5GQ8T_sXmLRUQbfUKFQWbFLsZtt9to",{"list":139,"authors":143},1790098990237]