[{"data":1,"prerenderedAt":1787},["ShallowReactive",2],{"sc:header-data-ko":3,"sc:footer-data-ko":101,"glossary-posts-ko":139,"content-ko-list-c077398beed29":1786},{"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",{"ko":10},{"title":11,"url":12,"alt":13},"홈","/ko","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"ko":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"ko":22},{"title":23,"url":24},"가격","/ko/pricing",{"name":26,"languages":27},"partner",{"ko":28},{"title":29,"url":30},"파트너","/ko/partner",{"name":32,"languages":33,"children":36},"support-hub",{"ko":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",{"ko":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"ko":50},{"title":51,"url":52},"FAQ","/ko/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"ko":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",{"ko":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",{"ko":74},{"title":75,"url":76},"용어집","/ko/glossary",{"name":78,"languages":79},"blog",{"ko":80},{"title":81,"url":82},"블로그","/ko/blog",{"name":84,"languages":85},"events",{"ko":86},{"title":87,"url":88},"이벤트","/ko/events",{"name":90,"languages":91},"about",{"ko":92},{"title":93,"url":94},"회사 소개","/ko/about-us",{"name":96,"languages":97},"contact",{"ko":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksKo":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,476,845,1101,1338],{"id":141,"title":142,"author":143,"body":144,"cta":143,"description":433,"eventid":143,"extension":456,"hideInRecent":457,"layout":458,"meta":459,"moment":143,"navigation":471,"path":472,"seo":473,"stem":474,"tags":143,"webcast":457,"__hash__":475},"content_ko/glossary/cryptography.md","암호 기술",null,{"type":145,"value":146,"toc":432},"minimal",[147,152,165,171,199,204,226,230,233,236,245,248,256,295,299,302,305,308,312,315,319,322,325,329,333,336,362,366,369,386,390,393,397,400,404,407,412],[148,149,151],"h2",{"id":150},"키를-사용하는-암호화의-두-가지-유형","키를 사용하는 암호화의 두 가지 유형",[153,154,155,156,160,161,164],"p",{},"키를 사용하는 암호화는 크게 ",[157,158,159],"strong",{},"대칭 암호화","와 ",[157,162,163],{},"비대칭 암호화","로 나뉩니다.",[166,167,169],"h3",{"id":168},"대칭-암호화",[157,170,159],{},[172,173,174,181,187,193],"ul",{},[175,176,177,180],"li",{},[157,178,179],{},"키 사용",": 암호화와 복호화에 동일한 키를 사용합니다.",[175,182,183,186],{},[157,184,185],{},"속도",": 일반적으로 더 빠르고 효율적입니다.",[175,188,189,192],{},[157,190,191],{},"보안",": 주된 과제는 당사자 사이에서 키를 안전하게 공유하는 일입니다.",[175,194,195,198],{},[157,196,197],{},"예",": AES(Advanced Encryption Standard), DES(Data Encryption Standard).",[166,200,202],{"id":201},"비대칭-암호화",[157,203,163],{},[172,205,206,211,216,221],{},[175,207,208,210],{},[157,209,179],{},": 키 쌍, 즉 암호화에 쓰는 공개 키와 복호화에 쓰는 개인 키를 사용합니다.",[175,212,213,215],{},[157,214,185],{},": 연산이 더 복잡하기 때문에 대칭 암호화보다 느립니다.",[175,217,218,220],{},[157,219,191],{},": 개인 키는 결코 공유되지 않으므로 키 배포 측면에서 더 안전합니다.",[175,222,223,225],{},[157,224,197],{},": RSA(Rivest-Shamir-Adleman), ECC(Elliptic Curve Cryptography).",[166,227,229],{"id":228},"더-안전하다고-평가되는-암호화-방식","더 안전하다고 평가되는 암호화 방식",[153,231,232],{},"충분한 키 길이의 최신 알고리즘을 사용하는 한 현재의 어떤 컴퓨터도 암호를 해독할 수 없다는 점에서, 두 방식 모두 안전하다고 봅니다.",[153,234,235],{},"어느 쪽이 더 나은지는 사용 사례에 따라 다르지만, 많은 사용 사례에서 비대칭 암호화가 필요합니다. 비대칭 암호화는 키 쌍, 즉 암호화에 쓰는 공개 키와 복호화에 쓰는 개인 키를 사용하기 때문입니다. 개인 키는 비밀로 유지되며 공유할 필요가 전혀 없으므로 보안이 한층 강화됩니다.",[166,237,239,240],{"id":238},"대용량-데이터에-적합한-암호화-방식","대용량 데이터에 적합한 암호화 방식 ",[241,242],"a",{"href":243,"id":244},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[153,246,247],{},"대칭 암호화입니다. 더 빠르기 때문입니다.",[166,249,251,252],{"id":250},"하이브리드-암호화의-일반적인-절차","하이브리드 암호화의 일반적인 절차 ",[241,253],{"href":254,"id":255},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[257,258,259,265,271,277,283,289],"ol",{},[175,260,261,264],{},[157,262,263],{},"키 생성",": 발신자가 실제 메시지를 암호화할 새 대칭 키(세션 키라고도 합니다)를 생성합니다.",[175,266,267,270],{},[157,268,269],{},"메시지 암호화",": 발신자가 대칭 키로 평문 메시지를 암호화하여 암호문을 만듭니다.",[175,272,273,276],{},[157,274,275],{},"키 암호화",": 이어서 발신자가 수신자의 공개 키로 그 대칭 키를 암호화합니다(비대칭 암호화).",[175,278,279,282],{},[157,280,281],{},"전송",": 발신자가 암호화된 메시지(암호문)와 암호화된 대칭 키를 함께 수신자에게 보냅니다.",[175,284,285,288],{},[157,286,287],{},"키 복호화",": 수신자가 자신의 개인 키로 대칭 키를 복호화합니다.",[175,290,291,294],{},[157,292,293],{},"메시지 복호화",": 마지막으로 수신자가 복호화한 대칭 키로 암호문을 복호화하여 원래의 평문을 얻습니다.",[148,296,298],{"id":297},"해싱-알고리즘","해싱 알고리즘",[153,300,301],{},"해싱 알고리즘은 크기에 상관없이 입력 데이터를 고정 길이의 문자열로 변환하는 수학 함수이며, 그 결과는 보통 문자와 숫자가 이어진 형태입니다. 이 출력값을 해시 값 또는 다이제스트라고 합니다.",[166,303,304],{"id":304},"충돌",[153,306,307],{},"해싱에서 충돌은 서로 다른 두 데이터가 같은 해싱 알고리즘에서 동일한 해시 값을 만들어 낼 때 발생합니다. 해싱 알고리즘의 주된 목적은 서로 다른 데이터 입력을 고유하게 표현하는 것이므로, 충돌은 문제가 될 수 있습니다.",[166,309,311],{"id":310},"mac","MAC",[153,313,314],{},"메시지 인증 코드(MAC): 암호 기술에서 MAC은 메시지를 인증하고 그 무결성을 보장하는 데 쓰이는 짧은 정보입니다. 메시지가 변경되지 않았음을 검증하고 발신자의 신원을 확인해 줍니다.",[166,316,318],{"id":317},"mac과-hmac의-차이","MAC과 HMAC의 차이",[153,320,321],{},"MAC: 블록 암호 또는 해시 함수를 사용하여 메시지의 무결성과 진위성을 검증하는 코드를 가리키는 일반 용어입니다.",[153,323,324],{},"HMAC: 암호학적 해시 함수와 비밀 키를 사용하는 특정한 유형의 MAC으로, 더 강력한 보안 속성을 제공합니다.",[148,326,328],{"id":327},"비대칭-암호","비대칭 암호",[166,330,332],{"id":331},"메시지-서명의-일반적인-절차","메시지 서명의 일반적인 절차",[153,334,335],{},"메시지 서명은 메시지의 진위성과 무결성을 검증하는 데 사용하는 암호학적 절차입니다.",[257,337,338,344,350,356],{},[175,339,340,343],{},[157,341,342],{},"해시 생성:"," 발신자가 암호학적 해시 함수(예: SHA-256)를 사용하여 메시지의 고유한 디지털 지문(해시)을 생성합니다. 이 해시는 메시지의 내용을 고유하게 나타냅니다.",[175,345,346,349],{},[157,347,348],{},"서명:"," 발신자가 이 해시를 자신의 개인 키로 암호화하여 디지털 서명을 만듭니다. 덕분에 발신자의 개인 키에 접근할 수 있는 사람만 서명을 생성할 수 있습니다.",[175,351,352,355],{},[157,353,354],{},"전송:"," 디지털 서명을 메시지에 첨부하여 둘 다 수신자에게 보냅니다. 검증에 필요한 발신자의 공개 키도 함께 제공합니다.",[175,357,358,361],{},[157,359,360],{},"검증:"," 수신자가 발신자의 공개 키로 디지털 서명을 복호화하여 원래의 해시를 얻습니다. 이어서 수신한 메시지로 새 해시를 생성하여 복호화한 해시와 비교합니다. 두 값이 일치하면 메시지가 변경되지 않았음이 확인되고 발신자의 신원도 검증됩니다.",[166,363,365],{"id":364},"비대칭-암호화의-세-가지-기능","비대칭 암호화의 세 가지 기능",[153,367,368],{},"공개 키 암호 방식이라고도 하는 비대칭 암호화는 통신과 데이터를 보호하는 데 여러 중요한 역할을 합니다.",[257,370,371,376,381],{},[175,372,373],{},[157,374,375],{},"암호화와 복호화",[175,377,378],{},[157,379,380],{},"디지털 서명",[175,382,383],{},[157,384,385],{},"키 교환",[166,387,389],{"id":388},"rsa","RSA",[153,391,392],{},"RSA는 Rivest-Shamir-Adleman의 약자로, 안전한 데이터 전송에 널리 쓰이는 공개 키 암호 시스템입니다. 1977년에 이를 발표한 발명자 Ronald Rivest, Adi Shamir, Leonard Adleman의 이름을 딴 것입니다.",[166,394,396],{"id":395},"diffie-hellman","Diffie-Hellman",[153,398,399],{},"Diffie-Hellman 키 교환은 공개 채널을 통해 암호 키를 안전하게 교환하기 위해 암호 기술에서 사용하는 방법입니다. 1976년 Whitfield Diffie와 Martin Hellman이 개발했습니다. Diffie-Hellman 키 교환의 주된 목적은 두 당사자가 이후의 통신을 암호화하는 데 쓸 공유 비밀 키를 안전하게 만들어 내도록 하는 것입니다.",[166,401,403],{"id":402},"digital-signature-algorithmdsa","Digital Signature Algorithm(DSA)",[153,405,406],{},"Digital Signature Algorithm(DSA)은 디지털 서명을 생성하고 검증하는 데 사용하는 공개 키 암호 알고리즘입니다. 미국 국립표준기술연구소(NIST)가 1991년에 Digital Signature Standard(DSS)의 일부로 제안했습니다.",[408,409,411],"h4",{"id":410},"작동-방식","작동 방식",[257,413,414,420,426],{},[175,415,416,419],{},[157,417,418],{},"키 생성:"," DSA는 서명용 개인 키와 검증용 공개 키로 이루어진 키 쌍을 생성합니다.",[175,421,422,425],{},[157,423,424],{},"서명",": 발신자가 자신의 개인 키로 메시지에 디지털 서명을 만듭니다. 이 서명은 메시지와 개인 키 모두에 대해 고유합니다.",[175,427,428,431],{},[157,429,430],{},"검증",": 수신자가 발신자의 공개 키로 서명의 진위성을 검증하며, 이를 통해 메시지의 무결성과 출처도 확인합니다.",{"title":433,"searchDepth":434,"depth":434,"links":435},"",2,[436,444,449],{"id":150,"depth":434,"text":151,"children":437},[438,440,441,442,443],{"id":168,"depth":439,"text":159},3,{"id":201,"depth":439,"text":163},{"id":228,"depth":439,"text":229},{"id":238,"depth":439,"text":239},{"id":250,"depth":439,"text":251},{"id":297,"depth":434,"text":298,"children":445},[446,447,448],{"id":304,"depth":439,"text":304},{"id":310,"depth":439,"text":311},{"id":317,"depth":439,"text":318},{"id":327,"depth":434,"text":328,"children":450},[451,452,453,454,455],{"id":331,"depth":439,"text":332},{"id":364,"depth":439,"text":365},{"id":388,"depth":439,"text":389},{"id":395,"depth":439,"text":396},{"id":402,"depth":439,"text":403},"md",false,"post",{"lang":460,"titleClass":461,"blogtitlepic":462,"socialimg":463,"customExcerpt":464,"asideNav":465,"maxContent":471},"ko","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","인증서를 등록할 때 핵심 과제는 인증서를 요청하는 디바이스나 사용자를 어떻게 인증하는가입니다. 인증 기관은 인증서를 통해 인증서 소유자가 특정 속성을 갖추고 있으며 그 진위성을 확인했음을 보증합니다",{"menuItems":466},[467,469],{"href":468,"text":298},"#해싱-알고리즘",{"href":470,"text":328},"#비대칭-암호",true,"/glossary/cryptography",{"title":142,"description":433},"glossary/cryptography","PmSL-DGzTmUJLFs7NvRfhrljKZFRYxQEC9p11WFNSOo",{"id":477,"title":478,"author":143,"body":479,"cta":143,"description":483,"eventid":143,"extension":456,"hideInRecent":457,"layout":458,"meta":829,"moment":143,"navigation":471,"path":841,"seo":842,"stem":843,"tags":143,"webcast":457,"__hash__":844},"content_ko/glossary/enrollment-methods.md","등록 방식",{"type":145,"value":480,"toc":816},[481,484,487,490,519,609,611,615,625,628,646,648,651,655,658,661,682,686,689,692,705,709,712,715,718,721,724,727,736,739,743,746,749,755,759,768,771,774,777,794,806,809,812],[153,482,483],{},"따라서 인증서 등록 프로토콜의 핵심 속성은 인증서 요청자를 어떻게 인증하는가에 있습니다. 인증서를 어디에 사용하는지에 따라 어떤 프로토콜이 더 유리한지가 달라집니다.",[153,485,486],{},"또 하나의 중요한 속성은 실제 보급 정도입니다. 의도한 사용 사례에서 등록 방식이나 프로토콜은 CA 쪽과 클라이언트 쪽 모두에서 지원되어야 합니다.",[153,488,489],{},"가장 널리 쓰이는 등록 프로토콜은 다음과 같습니다.",[172,491,492,498,501,504,510,513,516],{},[175,493,494],{},[241,495,497],{"href":496},"scep","SCEP",[175,499,500],{},"ACME",[175,502,503],{},"EST",[175,505,506],{},[241,507,509],{"href":508},"microsoft-rpc-dcom","Microsoft의 RPC/DCOM",[175,511,512],{},"Microsoft의 SOAP",[175,514,515],{},"CA 웹 페이지에서의 수동 등록",[175,517,518],{},"기타 독자 프로토콜",[520,521,522,523],"table",{},"\n    ",[524,525,526,522,548,529,569,522,589],"tbody",{},[527,528,529,530,529,533,529,536,529,539,529,542,529,545,522],"tr",{},"\n        ",[531,532],"th",{},[531,534,535],{},"Microsoft 독자 규격 DCOM 및 RPC",[531,537,538],{},"WS-Trust Enrollment Extension에 의한 SOAP 등록",[531,540,541],{},"Automatic Certificate Management Environment(ACME)",[531,543,544],{},"Simple Certificate Enrollment Protocol(SCEP)",[531,546,547],{},"Enrollment over Secure Transport(EST)",[527,549,529,550,529,554,529,557,529,560,529,563,529,566,522],{},[551,552,553],"td",{},"사양",[551,555,556],{},"Microsoft OpenSpec1",[551,558,559],{},"Microsoft OpenSpec2",[551,561,562],{},"RFC 8555",[551,564,565],{},"비공식, 현재는 RFC 8894",[551,567,568],{},"RFC 7030(+ …)",[527,570,529,571,529,574,529,577,529,580,529,583,529,586,522],{},[551,572,573],{},"구현",[551,575,576],{},"서버 측: Active Directory CS, 클라이언트 측: Windows",[551,578,579],{},"서버 측: ADCS, 그 밖에는 불명, 클라이언트 측: Windows",[551,581,582],{},"서버 측: Let’s Encrypt, 클라이언트 측: 다수",[551,584,585],{},"서버 구현과 클라이언트 구현 모두 다수",[551,587,588],{},"보급 저조",[527,590,529,591,529,594,529,597,529,600,529,603,529,606,522],{},[551,592,593],{},"인증",[551,595,596],{},"AD 인증",[551,598,599],{},"AD 인증\\*(형식상 사용자 이름과 비밀번호가 AD에 없을 수도 있습니다)",[551,601,602],{},"DNS 인증",[551,604,605],{},"“SCEP 챌린지”",[551,607,608],{},"CBA 또는 HTTP Basic/Digest 인증",[148,610,497],{"id":496},[166,612,614],{"id":613},"역사와-사양","역사와 사양",[153,616,617,618,624],{},"Simple Certificate Enrollment Protocol(SCEP)은 Cisco가 처음 고안했습니다. 당시에는 표준이 없었는데도 MDM 시스템에서 널리 채택되었습니다. Cisco는 더 나아가 SCEP을 대체할 후속 프로토콜인 Enrollment over Secure Transport(EST)까지 설계했습니다. 그래서 EST는 RFC 7030으로 훨씬 일찍 공개 표준이 되었고, SCEP은 한참 뒤인 ",[241,619,623],{"href":620,"rel":621},"https://www.rfc-editor.org/rfc/rfc8894.html",[622],"nofollow","RFC 8894","에서야 표준화되었습니다. 그때 SCEP은 이미 MDM 시스템의 인증서 등록을 위한 사실상의 표준이었습니다.",[166,626,627],{"id":627},"기술",[153,629,630,631,635,636,640,641,645],{},"SCEP은 HTTP 기반입니다. SCEP 요청은 암호화하고 서명한 ",[241,632,634],{"href":633},"important-data-formats#pkcs7","PKCS#7","이며, GET 또는 POST 요청으로 SCEP 서비스에 전송됩니다. 서비스는 마찬가지로 암호화하고 서명한 PKCS#7 형태의 SCEP 응답을 반환합니다. 요청에는 ",[241,637,639],{"href":638},"important-data-formats#pkcs10","PKCS#10"," 인증서 서명 요청이 들어 있고, 응답에는 발급된 ",[241,642,644],{"href":643},"important-data-formats#x509","X.509 인증서","가 들어 있습니다.",[166,647,593],{"id":593},[153,649,650],{},"PKCS#10 요청에는 \"SCEP 챌린지\"가 들어 있으며, 이는 해당 SCEP 서비스에 따라 달라지는 대역 외 방식으로 서명 요청을 인증하고 인가합니다. 오늘날 실제로 쓰이는 SCEP 챌린지는 세 가지입니다.",[408,652,654],{"id":653},"정적-scep-챌린지","정적 SCEP 챌린지",[153,656,657],{},"가장 단순한 방법은 고정된 암호 문구입니다. PKCS#10의 SCEP 챌린지가 SCEP 서비스에 미리 저장된 값과 일치하면 인증서가 발급되고, 그렇지 않으면 요청이 거부됩니다. 이 방법의 문제는 요청된 인증서의 속성이 요청자와 일치하는지를 사실상 확인할 수 없다는 점입니다. 이 문제에는 CVE까지 등록되어 있습니다.",[153,659,660],{},"이러한 방식은 다시 다음과 같이 구분할 수 있습니다.",[257,662,663,670,676],{},[175,664,665,669],{},[666,667,668],"em",{},"직접"," SCEP 등록에서는 인증서를 등록받을 개체가 SCEP 서비스와 직접 통신합니다. 예를 들어 MDM 시스템이 어떤 Android 휴대폰에 \"SecurePassword\"라는 SCEP 챌린지로 SCEP 등록을 수행하라고 지시합니다. Android 휴대폰은 올바른 값이 담기기를 기대하며 CSR을 생성하고, SCEP 챌린지로 \"SecurePassword\"를 넣습니다. 그런 다음 CSR을 SCEP 서비스로 보내고 발급된 인증서를 돌려받습니다.",[175,671,672,675],{},[666,673,674],{},"투명 SCEP 프록시","는 HTTP 리버스 프록시와 같습니다. SCEP은 암호화되고 서명되어 있으므로 프록시는 SCEP 요청이나 응답의 내용을 들여다볼 수도, 수정할 수도 없지만, 네트워크 경계를 기준으로 누가 언제 인증서를 등록할 수 있는지는 통제할 수 있습니다.",[175,677,678,681],{},[666,679,680],{},"프로토콜 어댑터 SCEP 프록시","는 다른 시스템을 대신해 SCEP으로 인증서를 요청하는 시스템입니다. 예를 들어 JAMF 같은 MDM 시스템이 어떤 iPhone을 대신해 SCEP 서비스에 인증서를 요청할 수 있습니다. 인증서와 개인 키를 받고 나면 다른 프로토콜로 인증서를 배포할 수 있습니다. 이렇게 하면 SCEP 챌린지에 접근하는 것은 MDM 시스템뿐이며, MDM 시스템이 인증서의 내용도 통제할 수 있습니다.",[408,683,685],{"id":684},"동적-scep-챌린지","동적 SCEP 챌린지",[153,687,688],{},"이 경우 각 SCEP 챌린지는 단 한 번의 인증서 요청에만 유효합니다. 덕분에 SCEP 서비스는 해당 SCEP 요청을 식별하고, 요청된 인증서 속성이 그 요청에 허용된 값과 일치하는지 검증할 수 있습니다.",[153,690,691],{},"MDM 시스템과 SCEP CA가 요청에 사용할 SCEP 챌린지를 합의하는 방식은 실무에서 대체로 두 가지입니다.",[257,693,694,702],{},[175,695,696,697],{},"MDM 시스템이 SCEP 요청에 필요한 일회용 코드를 SCEP 서비스에 요청합니다.\n",[257,698,699],{},[175,700,701],{},"Microsoft NDES가 그 예입니다. NDES는 AD 자격 증명으로 인증하는 별도의 \"admin\" 페이지를 제공합니다. 이 관리 페이지에 접근할 때마다 SCEP 요청 한 건에만 쓸 수 있는 새 일회용 코드를 생성해 표시합니다. 다만 이 구성으로 사용할 때 NDES는 인증서의 속성을 전혀 확인하지 않는데, 일회용 코드가 범용이기 때문입니다.",[175,703,704],{},"MDM 시스템이 관리 대상 시스템에 SCEP으로 인증서를 요청하라고 지시할 때 일회용 코드를 생성합니다. SCEP 요청이 SCEP 서비스에 도착하면, 서비스는 보통 웹 훅으로 MDM 시스템에서 일회용 코드를 가져와 요청의 SCEP 챌린지와 일치하는지 확인해야 합니다. 이 프로토콜에는 표준이 없으므로 MDM 시스템과 SCEP 서비스가 어떤 형식을 쓸지 합의해야 하며, 요청의 속성을 검사하는지 여부도 구현에 따라 달라집니다.",[408,706,708],{"id":707},"서명된-메타데이터","서명된 메타데이터",[153,710,711],{},"SCEP 챌린지에는 사실상 길이 제한이 없습니다. 따라서 사람이 이해할 수 있는 \"암호 문구\"일 필요가 없고 BLOB일 수도 있습니다.",[153,713,714],{},"Intune은 서명하고 암호화한 XML을 SCEP 챌린지로 사용합니다. Intune은 인증서를 등록하려 할 때 이 XML을 서버 측에서 만들어 클라이언트 디바이스로 보내고, 디바이스는 SCEP 요청을 생성합니다.",[153,716,717],{},"SCEP 서비스는 PKCS#10 요청 전체를 Intune SCEP 챌린지 서비스로 보내야 합니다. SCEP 챌린지 서비스는 XML을 복호화할 개인 키와, 그것이 정품 Intune 서비스에서 생성되었는지 확인할 공개 키를 가지고 있습니다.",[153,719,720],{},"XML에는 주체(Subject)가 어떤 형태여야 하는지 같은 요청 관련 메타데이터가 들어 있습니다. 이 정보는 한편으로는 SCEP 구성 프로필에서, 다른 한편으로는 인증서를 발급받을 사용자나 디바이스의 구체적인 개체 데이터에서 도출됩니다.",[153,722,723],{},"예를 들어 SCEP 구성 프로필이 주체를 CN={{DeviceId}}로 설정했다고 해 보겠습니다. 아이디가 xyz인 디바이스가 인증서를 요청하면 XML에는 주체가 CN=xyz여야 한다고 기록됩니다. 그러면 SCEP 챌린지 서비스가 XML의 정보와 PKCS#10 요청의 주체를 비교합니다. 주체가 다르면 검증에 실패하고, 이 항목과 나머지 속성이 일치하면 성공합니다.",[153,725,726],{},"SCEP 서비스는 검증에 성공한 경우에만 인증서를 발급합니다.",[153,728,729,730,735],{},"Microsoft는 이 검증을 설명하는 ",[241,731,734],{"href":732,"rel":733},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[622],"문서","를 제공합니다.",[153,737,738],{},"Microsoft NDES는 추가 NDES 정책 모듈로 이를 지원하며, 다른 SCEP CA가 이를 기본으로 지원하는지는 제품에 따라 다릅니다.",[148,740,742],{"id":741},"microsoft-rpcdcom","Microsoft RPC/DCOM",[166,744,745],{"id":745},"역사",[153,747,748],{},"Microsoft Active Directory Certificate Services(ADCS)는 \"Microsoft CA\"라고만 불리기도 하며, Windows Server에 내장된 인증 기관 소프트웨어입니다. 이 소프트웨어는 원래 지난 천 년의 끝 무렵에 개발되었고 이후 10~15년 동안 계속 기능이 추가되었습니다.",[153,750,751,752,754],{},"대안으로는 Microsoft의 SOAP이나 ",[241,753,497],{"href":496},"이 있으며, Microsoft는 각각 웹 등록(Web Enrollment)과 NDES라고 부릅니다.",[166,756,758],{"id":757},"사양과-보급","사양과 보급",[153,760,761,762,767],{},"그동안 Microsoft가 ",[241,763,766],{"href":764,"rel":765},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[622],"Microsoft OpenSpec에 사양을 공개","하기는 했지만, 이 프로토콜을 구현한 다른 CA 시스템은 알려진 바가 없습니다. 클라이언트 쪽에서는 Windows가 이 프로토콜을 기본으로 지원하며, 다른 플랫폼은 지원되지 않습니다.",[166,769,627],{"id":770},"기술-1",[153,772,773],{},"주된 등록 방식은 RPC나 DCOM을 기반으로 하는 독자 프로토콜입니다.",[153,775,776],{},"자동 등록도 이 프로토콜을 사용합니다. 자동 등록이 작동하려면 다음이 필요합니다.",[172,778,779,782,785,788,791],{},[175,780,781],{},"도메인에 가입된 디바이스,",[175,783,784],{},"자동 등록을 활성화하는 그룹 정책,",[175,786,787],{},"독립 실행형이 아닌 엔터프라이즈 CA,",[175,789,790],{},"그 CA가 등록하는 인증서 템플릿,",[175,792,793],{},"그리고 해당 템플릿에 대해 사용자나 디바이스가 가진 등록 및 자동 등록 권한.",[153,795,796,797,801,802,805],{},"자동 등록을 확인하는 기본 간격은 8시간이지만, ",[798,799,800],"code",{},"certutil -pulse","나 대개 더 효과적인 ",[798,803,804],{},"gpupdate -force","로 강제할 수 있습니다.",[166,807,593],{"id":808},"인증-1",[153,810,811],{},"이 프로토콜은 Active Directory에 내장된 인증 프로토콜을 사용합니다. 즉, 사용자와 컴퓨터가 자신의 AD 자격 증명으로 인증합니다.",[813,814,815],"style",{},"\n    table {border: 2px solid white}\n    th, td {border: solid black; padding-left: 1em; padding-right: 1em; font-size: smaller}\n",{"title":433,"searchDepth":434,"depth":434,"links":817},[818,823],{"id":496,"depth":434,"text":497,"children":819},[820,821,822],{"id":613,"depth":439,"text":614},{"id":627,"depth":439,"text":627},{"id":593,"depth":439,"text":593},{"id":741,"depth":434,"text":742,"children":824},[825,826,827,828],{"id":745,"depth":439,"text":745},{"id":757,"depth":439,"text":758},{"id":770,"depth":439,"text":627},{"id":808,"depth":439,"text":593},{"lang":460,"seoTitle":830,"titleClass":461,"socialimg":831,"blogtitlepic":832,"customExcerpt":833,"keywords":834,"asideNav":835,"maxContent":471},"인증서 등록 방식: 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":836},[837,839],{"href":838,"text":497},"#scep",{"href":840,"text":742},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":478,"description":483},"glossary/enrollment-methods","c_PCZiUoYb29ufMlH_44w9zLiCG-Q8hmpC14tYZa2E4",{"id":846,"title":847,"author":143,"body":848,"cta":143,"description":433,"eventid":143,"extension":456,"hideInRecent":457,"layout":458,"meta":1079,"moment":143,"navigation":471,"path":1097,"seo":1098,"stem":1099,"tags":143,"webcast":457,"__hash__":1100},"content_ko/glossary/important-data-formats.md","주요 데이터 형식",{"type":145,"value":849,"toc":1062},[850,854,873,880,883,887,890,893,896,899,903,906,910,913,916,924,927,931,939,942,945,948,959,962,975,978,981,984,987,990,999,1003,1006,1009,1012,1023,1027,1030,1033,1041,1044,1052,1055],[148,851,853],{"id":852},"x509","X.509",[153,855,856,857,860,861,866,867,872],{},"X.509는 디지털 인증서의 ",[666,858,859],{},"바로 그"," 표준입니다. 예전에는 ",[241,862,865],{"href":863,"rel":864},"https://www.rfc-editor.org/rfc/rfc4880",[622],"OpenPGP"," 같은 경쟁 규격도 있었지만 요즘은 훨씬 덜 쓰입니다. 그런데 사실 X.509가 정확한 표준 이름은 아닙니다. X.509는 ITU-T 표준이고, 실제로 중요한 정의는 ITU-T가 아닌 IETF의 표준, 즉 ",[241,868,871],{"href":869,"rel":870},"https://www.rfc-editor.org/rfc/rfc5280",[622],"RFC 5280","에 들어 있습니다. 이 RFC는 X.509를 바탕으로 \"인터넷용 PKI 프로파일\"을 정의하는데, 실무에서 의미가 있는 프로파일은 이것뿐입니다.",[153,874,875,876,879],{},"디지털 인증서는 비대칭 암호 기술, 특히 디지털 서명을 활용합니다. 오늘날 디지털 인증서의 가장 흔한 사용 사례는 서버 인증입니다. 누구나 이미 디지털 인증서를 써 봤지만, 그것이 X.509 인증서인 줄은 대개 모르고 지나갑니다. HTTP",[157,877,878],{},"S"," 웹 사이트에 접속할 때마다 브라우저는 웹 서버와 TLS 연결을 맺습니다. 웹 서버는 X.509 인증서로 자신이 누구인지 증명합니다. 예를 들어 은행 계좌에서 돈을 이체하려고 은행 웹 사이트에 접속할 때, 사용자는 자신이 통신하는 상대가 정말 그 은행인지 확신하고 싶어 합니다. 공격자는 은행 웹 사이트를 사칭해 사용자의 비밀번호와 보안 코드를 읽어 낸 다음 자신이 통제하는 계좌로 돈을 옮기려 할 수 있습니다. HTTPS는 이를 막는 데 도움이 되는데, 공격자에게는 은행 웹 서버의 X.509 인증서가 없기 때문입니다. 브라우저가 특정 도메인에 HTTPS로 접속하고 있다고 알려 주면, 인증서는 그 도메인을 소유한 주체의 웹 서버에 정말로 연결되어 있음을 보증합니다.",[153,881,882],{},"인증서는 이를 어떻게 해낼까요? 인증서에는 몇 가지 메타데이터와 암호 키 쌍의 공개 키, 그리고 인증 기관의 서명이 들어 있습니다. 이 세 부분을 차례로 살펴보겠습니다.",[166,884,886],{"id":885},"x509-인증서의-구성-요소","X.509 인증서의 구성 요소",[408,888,889],{"id":889},"메타데이터",[153,891,892],{},"X.509 인증서의 메타데이터에는 무엇보다 인증서가 언제까지 유효한지, 어떤 용도로 쓰여야 하는지, 누구에게 발급되었는지가 담깁니다. 특히 TLS 서버 인증서라면 웹 서버의 도메인이 들어 있습니다. 브라우저는 접속하려던 도메인과 인증서의 도메인을 비교합니다. 둘이 일치하지 않으면 브라우저는 진행하지 않고 경고를 표시합니다. 인증서가 만료된 경우에도 경고를 표시합니다.",[153,894,895],{},"이상하게도 브라우저는 TLS 없이 HTTP 사이트에 접속할 때는 경고를 표시하지 않는 경우가 많았습니다. 그쪽이 오히려 덜 안전한데도 말입니다. 유효하지 않은 X.509 인증서를 쓰는 웹 서버에 접속했다면 단순한 구성 오류일 수 있고 연결을 엿보는 공격자로부터는 실제로 안전할 수도 있는 반면, HTTP 연결은 아무런 보호도 제공하지 않습니다.",[153,897,898],{},"이 문제에도 인증서 피닝 같은 진전이 있기는 합니다. 다만 이는 고급 주제이므로, X.509 인증서에 들어 있는 나머지 두 요소를 살펴보겠습니다.",[408,900,902],{"id":901},"공개-키","공개 키",[153,904,905],{},"인증서에는 비대칭 키 쌍의 공개 부분이 들어 있습니다. 암호 기술 덕분에 웹 서버는, 다른 사용 사례라면 일반적으로 인증서 소유자는, 키 쌍의 개인 부분도 함께 가지고 있음을 접속하는 클라이언트나 그 누구에게도 노출하지 않고 증명할 수 있습니다. 따라서 클라이언트는 웹 서버가 인증서를 복사한 제삼자가 아니라 실제 소유자임을 확신할 수 있습니다. 인증서 자체를 복사하는 일은 사실 꽤 쉬운데, 웹 서버가 접속을 시도하는 모든 상대에게 인증서 사본을 보내기 때문입니다. 반면 개인 키를 훔치는 일은 어렵거나 불가능합니다. 개인 키는 웹 서버를 벗어나지 않기 때문입니다. 개인 키 탈취를 더 어렵게 만드는 방법으로는 HSM과 TPM 등이 있습니다.",[408,907,909],{"id":908},"인증-기관의-서명","인증 기관의 서명",[153,911,912],{},"메타데이터는 인증서가 해당 사용 사례에 적합한지 클라이언트가 확인할 수 있게 해 줍니다. 공개 키는 상대방이 실제로 인증서의 소유자임을 보여 줍니다. 그런데 공격자도 새 키 쌍과 새 인증서를 만들어 이 두 조건을 충족시킬 수 있습니다. 그렇다면 클라이언트는 그 인증서가 신뢰할 만한지 어떻게 알 수 있을까요?",[153,914,915],{},"인증서에는 인증 기관(CA) 인증서에 속한 다른 키 쌍의 암호학적 서명이 들어 있습니다. CA 인증서 역시 같은 방식으로 확인할 수 있으며, 그 인증서도 또 다른 인증서로 서명되어 있습니다. 클라이언트는 이 \"신뢰 체인\"을 이른바 리프 인증서에서 Root CA 인증서까지 따라 올라갈 수 있습니다. Root CA 인증서는 자체 서명되어 있다는 점, 즉 인증서의 서명이 자기 자신의 키 쌍에서 나왔다는 점으로 알아볼 수 있습니다. 보통 이 과정은 한두 단계에 그치므로 관여하는 CA 인증서도 한두 개뿐입니다.",[153,917,918,919,923],{},"CA는 ",[241,920,922],{"href":921},"enrollment-methods/","인증서를 발급할"," 때 메타데이터가 올바른지 신중하게 확인해야 합니다. 예를 들어 자기 도메인의 TLS 서버 인증서를 받으려면, 자신이 정말 그 도메인의 소유자임을 CA에 증명해야 합니다. 이 확인이 얼마나 철저한지에 따라 기본 인증서를 받을지 Extended Validation(EV) 인증서를 받을지가 정해집니다.",[153,925,926],{},"브라우저와 운영 체제는 저마다 미리 정의된 신뢰할 수 있는 Root CA 목록을 함께 제공합니다. 사용자나 관리자는 신뢰할 수 있는 Root CA를 추가할 수 있습니다. 어떤 Root CA는 특정 용도로만 신뢰되고, 어떤 Root CA는 더 포괄적인 신뢰를 받습니다. 클라이언트는 신뢰 체인이 신뢰할 수 있는 Root CA에서 끝나는지 확인합니다. 그렇고, 신뢰 체인의 모든 인증서가 여전히 유효하며, 메타데이터상 용도에 맞게 쓰이고 있다면, 웹 서버의 리프 인증서는 신뢰되고 연결이 수립됩니다.",[166,928,930],{"id":929},"x509-인증서의-유효성","X.509 인증서의 유효성",[153,932,933,934,938],{},"X.509 인증서는 결국 신뢰를 어떻게 확립하느냐의 문제입니다. 앞서 설명했듯이 신뢰의 한 가지 기준은 인증서가 신뢰할 수 있는 Root CA까지 체인으로 이어져야 한다는 점입니다. 또 하나는 유효 기간 안에 있어야 한다는 점입니다. 보통은 만료되지 않았다는 뜻이지만, 대개 기술적 오류 때문에 인증서가 아직 유효해지지 않은 경우도 있습니다. 그리고 기준이 하나 더 있습니다. 인증서를 발급한 CA가 그것을 해지하지 않았어야 합니다. 이 자체로 하나의 주제가 되므로 ",[241,935,937],{"href":936},"other-stuff/certificate-lifecycle-management","별도의 문서","에서 다룹니다.",[148,940,634],{"id":941},"pkcs7",[153,943,944],{},"PKCS#7은 암호 데이터 형식의 맥가이버 칼이라 할 만하며, 암호화된 메시지, 서명된 메시지, 서명하고 암호화한 메시지, 인증서, 개인 키 등 사실상 무엇이든 담을 수 있습니다",[153,946,947],{},"이 점은 이 형식의 큰 단점이기도 합니다. 애플리케이션이나 사용자가 PKCS#7을 받아도 그것만으로는 무엇을 해야 할지 분명하지 않습니다. 중요한 사용 사례를 몇 가지 들면 다음과 같습니다.",[172,949,950,953,956],{},[175,951,952],{},"S/MIME 메시지는 기본적으로 본문이나 첨부 파일이 PKCS#7인 이메일입니다.",[175,954,955],{},"SCEP 요청과 응답은 둘 다 실제로는 PKCS#7 서명 메시지입니다.",[175,957,958],{},"EST 응답은 CMS 메시지입니다.",[166,960,961],{"id":961},"인코딩",[153,963,964,965,969,970,974],{},"흔한 파일 확장자는 .p7b(",[241,966,968],{"href":967},"asn.1-and-pem#der-encoding","DER 인코딩","), .p7s(서명된 메시지 또는 메시지 서명), .p7m(서명되었거나 암호화된 메시지)입니다. 라벨이 \"PKCS7\"인 ",[241,971,973],{"href":972},"asn.1-and-pem#pem-encoding","PEM 인코딩","도 정의되어 있지만 거의 쓰이지 않습니다.",[166,976,977],{"id":977},"도구",[153,979,980],{},"Windows에서는 PKCS#7 메시지를 더블 클릭으로 열 수 있고 Crypto-shell 확장이 내용을 표시해 줍니다. 다만 대개는 그 안에서 인증서와 개인 키만 꺼낼 수 있고 메시지 내용은 꺼낼 수 없습니다.",[153,982,983],{},"OpenSSL 같은 도구로 이런 파일을 다른 형식으로 변환할 수 있습니다.",[148,985,639],{"id":986},"pkcs10",[153,988,989],{},"PKCS#10에 정의된 인증서 서명 요청(CSR)은 인증 기관(CA)에서 받고자 하는 인증서의 내용을 기술한 파일입니다. 구조는 X.509 인증서와 비슷하지만 CA의 서명이 없습니다. 대신 인증서 요청자의 서명이 들어 있습니다. 그래도 형식 자체가 다르므로 자체 서명 인증서와 같지는 않습니다.",[153,991,992,993,998],{},"바이너리 DER 인코딩으로 만들 수도 있고, ",[241,994,997],{"href":995,"rel":996},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[622],"\"CERTIFICATE REQUEST\" 라벨을 사용해"," PEM 인코딩으로 만들 수도 있습니다.",[148,1000,1002],{"id":1001},"pkcs12","PKCS#12",[153,1004,1005],{},"PKCS#12는 특히 Windows 환경에서 PFX라고도 합니다. 그래서 흔한 파일 확장자는 .pfx와 .p12입니다. 여기에는 X.509 인증서와, 기술적으로 강제되지는 않지만 거의 언제나 그에 대응하는 개인 키가 들어 있습니다.",[153,1007,1008],{},"PKCS#12 파일의 데이터는 보통 비밀번호로 암호화됩니다. 개인 키만 암호화되는 경우가 많아서, 애플리케이션이 허용한다면 비밀번호를 몰라도 인증서를 꺼낼 수 있습니다. 다만 대부분의 애플리케이션은 이를 허용하지 않습니다. Windows 환경에서는 인증서와 개인 키를 파일 하나에 담을 때 PKCS#12가 가장 흔한 방식인 반면, Linux 환경에서는 PEM 인코딩된 PKCS#8 파일이 더 흔합니다.",[153,1010,1011],{},"표준이 인증서와 개인 키를 중첩된 \"세이프백\"에 저장하는 방법을 여러 가지로 제공하기 때문에, PKCS#12 파일에는 다음과 같은 호환성 문제가 있습니다.",[172,1013,1014,1017,1020],{},[175,1015,1016],{},"Windows는 PKCS#12의 개인 키를 그 파일에서 추출한 모든 인증서에 연결해 버리는 것으로 악명이 높습니다. 원래 대응하는 인증서 하나에만 연결해야 하는데 그렇지 않습니다. PKCS#12에 인증서 체인이 들어 있으면 Windows가 CA 인증서의 개인 키를 가지고 있다고 표시할 수도 있습니다.",[175,1018,1019],{},"macOS에서는 암호 알고리즘이 너무 최신이면 PKCS#12 파일을 가져올 수 없습니다.",[175,1021,1022],{},"받는 쪽 애플리케이션이 인증서를 추출할 수 있게 하려면 PKCS#12 파일 안의 인증서를 암호화해야 할 때가 있습니다. 그런데 일부 애플리케이션은 아주 오래되고 약한 알고리즘만 지원합니다. 어차피 공개된 정보이므로 보통은 문제가 되지 않지만, OpenSSL 3.x는 이렇게 오래되고 취약한 알고리즘을 지원하지 않아 해당 PKCS#12를 열기를 거부합니다.",[148,1024,1026],{"id":1025},"asn1과-pem","ASN.1과 PEM",[153,1028,1029],{},"Abstract Syntax Notation One(ASN.1)은 데이터 구조를 기술하는 데 쓰는 언어입니다. 정수나 시퀀스 같은 기본 데이터 타입이 미리 정의되어 있고, 프로토콜이나 파일 형식을 만드는 사람은 이를 조합해 사용자 정의 데이터 타입을 정의할 수 있습니다.",[166,1031,968],{"id":1032},"der-인코딩",[153,1034,1035,1040],{},[241,1036,1039],{"href":1037,"rel":1038},"https://www.itu.int/rec/T-REC-X.680/",[622],"ITU-T 표준 X.680","은 ASN.1로 규정된 데이터에 대해 여러 인코딩 방식을 정의합니다. X.509 관련 데이터에서 가장 중요한 인코딩은 DER입니다. 타입을 인코딩하는 방법이 하나뿐이므로 타입의 바이너리 DER 표현을 해싱하면 언제나 같은 값이 나오기 때문인데, 이는 예를 들어 ASN.1로 인코딩된 데이터에 서명할 때 중요합니다.",[166,1042,973],{"id":1043},"pem-인코딩",[153,1045,1046,1047,1051],{},"전부는 아니지만 상당수의 X.509 관련 파일 형식은 DER 인코딩으로 바이너리 저장할 수도 있고, DER 인코딩 위에 ",[241,1048,973],{"href":1049,"rel":1050},"https://datatracker.ietf.org/doc/html/rfc7468",[622],"을 추가로 적용할 수도 있습니다. PEM은 ASCII 문자만 사용하므로 클립보드로 손쉽게 복사해 붙여 넣을 수 있고, 그것이 아직 중요하던 수십 년 전에는 이메일로 보낼 수도 있었습니다.",[166,1053,977],{"id":1054},"도구-1",[153,1056,1057,1058,1061],{},"ASN.1로 인코딩된 파일이 있는데 그것이 어떤 타입인지 모르거나 그 타입을 다루는 애플리케이션이 없더라도, 원시 ASN.1 구조를 디코딩해 내용을 확인할 수는 있습니다. Windows에서는 내장 도구인 certutil이 ",[798,1059,1060],{},"certutil -decode"," 명령으로 이를 처리할 수 있습니다.",{"title":433,"searchDepth":434,"depth":434,"links":1063},[1064,1068,1072,1073,1074],{"id":852,"depth":434,"text":853,"children":1065},[1066,1067],{"id":885,"depth":439,"text":886},{"id":929,"depth":439,"text":930},{"id":941,"depth":434,"text":634,"children":1069},[1070,1071],{"id":961,"depth":439,"text":961},{"id":977,"depth":439,"text":977},{"id":986,"depth":434,"text":639},{"id":1001,"depth":434,"text":1002},{"id":1025,"depth":434,"text":1026,"children":1075},[1076,1077,1078],{"id":1032,"depth":439,"text":968},{"id":1043,"depth":439,"text":973},{"id":1054,"depth":439,"text":977},{"lang":460,"seoTitle":1080,"titleClass":461,"blogtitlepic":1081,"socialimg":1082,"customExcerpt":1083,"keywords":1084,"asideNav":1085,"maxContent":471},"주요 데이터 형식: 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":1086},[1087,1089,1091,1093,1095],{"href":1088,"text":853},"#x509",{"href":1090,"text":634},"#pkcs7",{"href":1092,"text":639},"#pkcs10",{"href":1094,"text":1002},"#pkcs12",{"href":1096,"text":1026},"#asn1과-pem","/glossary/important-data-formats",{"title":847,"description":433},"glossary/important-data-formats","ivXd1SO8BOUD54VBTgi-k9ABk_qjkpe8PQ1PYx5TjDk",{"id":1102,"title":1103,"author":143,"body":1104,"cta":143,"description":433,"eventid":143,"extension":456,"hideInRecent":457,"layout":458,"meta":1328,"moment":143,"navigation":471,"path":1334,"seo":1335,"stem":1336,"tags":143,"webcast":457,"__hash__":1337},"content_ko/glossary/public-key-infrastructure.md","공개 키 기반 구조",{"type":145,"value":1105,"toc":1317},[1106,1110,1118,1121,1152,1156,1159,1163,1166,1197,1200,1204,1207,1227,1230,1234,1241,1255,1261,1275,1279,1284,1297,1302,1314],[148,1107,1109],{"id":1108},"신뢰의-확립","신뢰의 확립",[166,1111,1113,1114,1117],{"id":1112},"클라이언트가-특정-root-ca에-대한-신뢰를-표명하는-방식","클라이언트가 특정 Root CA에 대한 신뢰를 ",[157,1115,1116],{},"표명","하는 방식",[153,1119,1120],{},"클라이언트는 인증서 신뢰 체인을 거치는 과정을 통해 특정 Root 인증 기관(CA)에 대한 신뢰를 나타냅니다. 작동 방식은 다음과 같습니다.",[172,1122,1123,1129,1135,1141,1146],{},[175,1124,1125,1128],{},[157,1126,1127],{},"사전 설치된 루트 인증서",": 대부분의 운영 체제와 웹 브라우저에는 신뢰할 수 있는 CA의 루트 인증서가 미리 설치되어 함께 제공됩니다. 이 루트 인증서는 신뢰할 수 있는 루트 저장소에 보관됩니다.",[175,1130,1131,1134],{},[157,1132,1133],{},"인증서 검증",": 클라이언트가 서버에 연결하면, 예를 들어 웹 사이트를 방문하면 서버가 자신의 TLS 인증서를 제시합니다. 이 인증서는 보통 Intermediate CA가 서명하고, 그 Intermediate CA는 다시 Root CA가 서명합니다.",[175,1136,1137,1140],{},[157,1138,1139],{},"신뢰 체인 검증",": 클라이언트는 제시된 인증서가 신뢰할 수 있는 Root CA의 서명을 받았는지 확인하여 신뢰 체인을 검증합니다. 체인에 포함된 Intermediate CA가 신뢰할 수 있는지도 함께 확인합니다.",[175,1142,1143,1145],{},[157,1144,380],{},": 체인의 각 인증서는 바로 위 CA가 디지털 서명합니다. 클라이언트는 해당 CA의 공개 키로 이 서명들을 검증하여 인증서가 변조되지 않았음을 확인합니다.",[175,1147,1148,1151],{},[157,1149,1150],{},"신뢰 판단",": 신뢰 체인 전체가 유효하고 신뢰할 수 있는 Root CA로 거슬러 올라간다면, 클라이언트는 서버의 인증서를 신뢰합니다. 그러면 안전한 통신을 이어 갈 수 있습니다.",[166,1153,1155],{"id":1154},"단일-root-ca-대신-intermediate-ca를-두는-이점","단일 Root CA 대신 Intermediate CA를 두는 이점",[153,1157,1158],{},"인프라 PKI에서는 오히려 단일 Root가 유리할 수도 있습니다.",[166,1160,1162],{"id":1161},"intermediate-ca가-인증서를-취득하는-방식","Intermediate CA가 인증서를 취득하는 방식",[153,1164,1165],{},"Intermediate 인증 기관(CA)은 Root CA에 의한 교차 서명이라는 과정을 거쳐 자신의 인증서를 취득합니다. 작동 방식은 다음과 같습니다.",[257,1167,1168,1174,1180,1186,1191],{},[175,1169,1170,1173],{},[157,1171,1172],{},"인증서 서명 요청(CSR)",": Intermediate CA를 구축하려는 조직이 CSR을 생성합니다. 이 CSR에는 Intermediate CA의 공개 키와 식별 정보가 담깁니다.",[175,1175,1176,1179],{},[157,1177,1178],{},"Root CA에 제출",": CSR을 신뢰할 수 있는 Root CA에 제출합니다.",[175,1181,1182,1185],{},[157,1183,1184],{},"확인",": Root CA는 Intermediate 인증서를 요청한 조직의 신원과 적법성을 확인합니다.",[175,1187,1188,1190],{},[157,1189,424],{},": 확인이 끝나면 Root CA가 자신의 개인 키로 CSR에 서명하여 Intermediate 인증서를 만듭니다. 이렇게 서명된 인증서는 Intermediate CA를 Root CA에 연결하여 신뢰 체인을 형성합니다.",[175,1192,1193,1196],{},[157,1194,1195],{},"발급",": Root CA는 서명한 Intermediate 인증서를 요청한 조직에 발급하고, 그 조직은 이를 사용해 최종 개체 인증서, 예를 들어 웹 사이트용 TLS 인증서에 서명할 수 있습니다.",[153,1198,1199],{},"이 과정을 통해 Intermediate CA는 이미 브라우저와 운영 체제가 신뢰하는 Root CA와 연결되어 있다는 사실만으로 신뢰를 얻습니다.",[166,1201,1203],{"id":1202},"인증서-체인과-그-작동-방식","인증서 체인과 그 작동 방식",[153,1205,1206],{},"신뢰 체인이라고도 하는 인증서 체인은 디지털 인증서의 진위성과 신뢰성을 보장하는 일련의 인증서입니다. 작동 방식은 다음과 같습니다.",[172,1208,1209,1215,1221],{},[175,1210,1211,1214],{},[157,1212,1213],{},"검증 과정",": 웹 브라우저 같은 클라이언트가 서버에 연결하면 서버가 자신의 최종 개체 인증서를 제시합니다. 그러면 클라이언트는 인증서 체인을 확인하여 각 인증서가 체인의 다음 인증서로 서명되어 있는지를 루트 인증서에 이르기까지 검사합니다.",[175,1216,1217,1220],{},[157,1218,1219],{},"신뢰 체인",": 체인의 각 인증서는 바로 위 인증서의 공개 키로 검증됩니다. 이 과정은 클라이언트가 이미 신뢰하는 루트 인증서에 도달할 때까지 이어집니다.",[175,1222,1223,1226],{},[157,1224,1225],{},"신뢰 확립",": 체인 전체가 유효하고 신뢰할 수 있는 루트 인증서로 거슬러 올라간다면, 클라이언트는 최종 개체 인증서를 신뢰하고 안전한 통신을 이어 갑니다.",[153,1228,1229],{},"이 구조는 최종 개체 인증서가 정당하며 신뢰할 수 있는 기관이 발급했음을 보장하여, 디지털 통신의 무결성과 보안을 유지합니다.",[166,1231,1233],{"id":1232},"basic-constraints-확장이-해결하려는-문제","Basic Constraints 확장이 해결하려는 문제",[153,1235,1236,1237,1240],{},"디지털 인증서의 ",[157,1238,1239],{},"Basic Constraints"," 확장은 서로 다른 유형의 인증서와 공개 키 기반 구조(PKI) 안에서의 역할을 구분하는 문제를 다룹니다. 작동 방식은 다음과 같습니다.",[172,1242,1243,1249],{},[175,1244,1245,1248],{},[157,1246,1247],{},"인증 기관(CA) 식별",": 해당 인증서가 CA 인증서인지 최종 개체 인증서인지를 지정합니다. CA 인증서는 다른 인증서를 발급할 수 있지만 최종 개체 인증서는 그럴 수 없으므로, 이 구분은 매우 중요합니다.",[175,1250,1251,1254],{},[157,1252,1253],{},"경로 길이 제약",": 인증서 체인에서 이 CA 아래에 존재할 수 있는 Intermediate CA의 수를 제한할 수 있습니다. 덕분에 비효율적이고 잠재적으로 안전하지 않은, 지나치게 긴 인증서 체인을 막을 수 있습니다.",[153,1256,1257,1260],{},[157,1258,1259],{},"해결되는 문제",":",[172,1262,1263,1269],{},[175,1264,1265,1268],{},[157,1266,1267],{},"허가되지 않은 인증서 발급 방지",": 어떤 인증서가 CA 역할을 할 수 있는지 명확히 표시함으로써, 최종 개체 인증서가 다른 인증서를 발급하지 못하게 막아 PKI의 무결성을 지킵니다.",[175,1270,1271,1274],{},[157,1272,1273],{},"인증서 체인 길이 관리",": 경로 길이를 제한하면 인증서 체인이 관리 가능하고 안전한 범위에 머물러, 긴 체인에 따르는 잠재적 취약점을 막을 수 있습니다",[166,1276,1278],{"id":1277},"이-문제를-해결하는-데-쓰이는-메커니즘"," 이 문제를 해결하는 데 쓰이는 메커니즘",[153,1280,1236,1281,1283],{},[157,1282,1239],{}," 확장은 CA 인증서와 최종 개체 인증서를 구분하고 인증서 체인 길이를 관리하는 문제를 해결하기 위해 다음 메커니즘을 사용합니다.",[172,1285,1286,1292],{},[175,1287,1288,1291],{},[157,1289,1290],{},"CA 플래그",": 이 플래그는 해당 인증서가 인증 기관(CA) 인증서인지 최종 개체 인증서인지를 나타냅니다. 플래그가 TRUE로 설정되어 있으면 다른 인증서에 서명하는 데 사용할 수 있으며, 이는 CA 인증서임을 뜻합니다. FALSE로 설정되어 있으면 최종 개체 인증서이며 다른 인증서를 발급할 수 없습니다.",[175,1293,1294,1296],{},[157,1295,1253],{},": 유효한 인증 경로에서 이 인증서 뒤에 올 수 있는, 자체 발급이 아닌 Intermediate 인증서의 최대 개수를 지정합니다. 이 제약을 설정하면 확장이 인증서 체인의 길이를 제한하여 체인이 관리 가능하고 안전한 범위에 머물도록 합니다.",[153,1298,1299,1260],{},[157,1300,1301],{},"이 메커니즘의 작동 방식",[172,1303,1304,1309],{},[175,1305,1306,1308],{},[157,1307,1290],{},": 인증서를 발급할 때 의도한 용도에 맞게 CA 플래그를 설정합니다. 인증서 검증 과정에서 클라이언트는 이 플래그를 확인하여 해당 인증서가 다른 인증서를 발급할 수 있을 만큼 신뢰할 수 있는지 판단합니다.",[175,1310,1311,1313],{},[157,1312,1253],{},": 이 값은 검증 과정에서 확인되며, 인증서 체인이 지정된 길이를 넘지 않도록 보장합니다. 체인이 너무 길면 해당 인증서는 유효하지 않은 것으로 간주됩니다.",[153,1315,1316],{},"이러한 메커니즘은 허가된 인증서만 다른 인증서를 발급할 수 있게 하고 지나치게 긴 인증서 체인을 막음으로써, 공개 키 기반 구조(PKI)의 무결성과 보안을 유지하는 데 기여합니다.",{"title":433,"searchDepth":434,"depth":434,"links":1318},[1319],{"id":1108,"depth":434,"text":1109,"children":1320},[1321,1323,1324,1325,1326,1327],{"id":1112,"depth":439,"text":1322},"클라이언트가 특정 Root CA에 대한 신뢰를 표명하는 방식",{"id":1154,"depth":439,"text":1155},{"id":1161,"depth":439,"text":1162},{"id":1202,"depth":439,"text":1203},{"id":1232,"depth":439,"text":1233},{"id":1277,"depth":439,"text":1278},{"lang":460,"seoTitle":1329,"titleClass":461,"socialimg":1330,"blogtitlepic":1331,"customExcerpt":1332,"keywords":1333,"maxContent":471},"공개 키 기반 구조에서의 신뢰 확립: PKI 인증서 신뢰 모델","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","인증서 체인, Root CA와 Intermediate CA, 안전한 인증서 검증으로 PKI에서 신뢰를 확립하십시오.","PKI 신뢰 확립, 공개 키 기반 구조 신뢰, 인증서 신뢰 체인, Root CA 신뢰, Intermediate CA 신뢰, PKI 신뢰 모델, 인증서 검증, 신뢰할 수 있는 루트 인증서, 안전한 인증서 확인, 신뢰 체인 검증","/glossary/public-key-infrastructure",{"title":1103,"description":433},"glossary/public-key-infrastructure","bPcTlTwXITSNo2CKNVcVkKZ_2w0K1NsDIMRBUgHgroA",{"id":1339,"title":1340,"author":143,"body":1341,"cta":143,"description":433,"eventid":143,"extension":456,"hideInRecent":457,"layout":458,"meta":1776,"moment":143,"navigation":471,"path":1782,"seo":1783,"stem":1784,"tags":143,"webcast":457,"__hash__":1785},"content_ko/glossary/use-cases-for-certificates.md","인증서 사용 사례",{"type":145,"value":1342,"toc":1761},[1343,1347,1351,1365,1369,1401,1405,1435,1439,1445,1451,1455,1507,1511,1515,1529,1533,1545,1549,1552,1566,1570,1576,1587,1592,1603,1609,1620,1624,1644,1648,1651,1655,1674,1678,1695,1700,1719,1723,1726,1758],[148,1344,1346],{"id":1345},"transport-layer-securitytls","Transport Layer Security(TLS)",[166,1348,1350],{"id":1349},"클라이언트가-서버에서-인증서를-받을-때-던져야-할-두-가지-질문","클라이언트가 서버에서 인증서를 받을 때 던져야 할 두 가지 질문",[257,1352,1353,1359],{},[175,1354,1355,1358],{},[157,1356,1357],{},"이 인증서는 유효하고 신뢰할 수 있는가?"," 클라이언트는 인증서가 신뢰할 수 있는 인증 기관(CA)에서 발급되었고 만료되거나 해지되지 않았는지 검증해야 합니다. 여기에는 인증서의 유효 기간을 확인하고, 클라이언트가 신뢰하는 CA가 서명했는지 확인하는 일이 포함됩니다.",[175,1360,1361,1364],{},[157,1362,1363],{},"이 인증서는 서버의 신원과 일치하는가?"," 클라이언트는 Common Name(CN)이나 Subject Alternative Name(SAN) 같은 인증서의 세부 정보가 서버의 도메인 이름과 일치하는지 확인해야 합니다. 이를 통해 그 인증서가 정말 클라이언트가 연결하려는 서버를 위한 것임을 확인할 수 있습니다.",[166,1366,1368],{"id":1367},"클라이언트가-인증서의-신뢰성을-검증하는-방식","클라이언트가 인증서의 신뢰성을 검증하는 방식",[257,1370,1371,1377,1383,1389,1395],{},[175,1372,1373,1376],{},[157,1374,1375],{},"인증서 신뢰 체인 확인",": 클라이언트는 서버의 인증서, 모든 Intermediate 인증서, 루트 인증서로 이루어진 인증서 체인을 검증합니다. 체인의 각 인증서는 한 단계 위의 기관이 서명해야 하며, 최종적으로 신뢰할 수 있는 루트 인증서로 이어져야 합니다.",[175,1378,1379,1382],{},[157,1380,1381],{},"인증서의 유효 기간 검증",": 클라이언트는 인증서의 유효 기간을 확인하여 만료되었거나 아직 유효해지지 않았는지 살핍니다. 여기에는 인증서의 \"Not Before\"와 \"Not After\" 날짜를 확인하는 일이 포함됩니다.",[175,1384,1385,1388],{},[157,1386,1387],{},"인증서와 서버 신원 대조",": 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인합니다. 이로써 인증서가 클라이언트가 연결하려는 서버를 위한 것임이 확인됩니다.",[175,1390,1391,1394],{},[157,1392,1393],{},"해지 여부 확인",": 클라이언트는 인증서 해지 목록(CRL)을 조회하거나 Online Certificate Status Protocol(OCSP)을 사용하여 인증서가 해지되었는지 확인합니다. 해지된 인증서는 더 이상 신뢰되지 않습니다.",[175,1396,1397,1400],{},[157,1398,1399],{},"디지털 서명 검증",": 클라이언트는 인증서의 디지털 서명을 검증하여 변조되지 않았음을 확인합니다. 여기에는 발급 CA의 공개 키로 암호학적 서명을 대조하는 일이 포함됩니다.",[166,1402,1404],{"id":1403},"클라이언트가-서버를-인증서의-진짜-소유자로-검증하는-방식","클라이언트가 서버를 인증서의 진짜 소유자로 검증하는 방식",[257,1406,1407,1413,1419,1424,1430],{},[175,1408,1409,1412],{},[157,1410,1411],{},"인증서 체인 검증",": 클라이언트는 체인의 각 인증서가 신뢰할 수 있는 인증 기관(CA)의 서명을 받았는지 확인하며 인증서 체인을 검증합니다. 이 체인은 서버의 인증서에서 시작해 신뢰할 수 있는 루트 인증서에서 끝납니다.",[175,1414,1415,1418],{},[157,1416,1417],{},"도메인 이름 대조",": 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인합니다. 이로써 인증서가 클라이언트가 연결하려는 서버를 위한 것임이 보장됩니다.",[175,1420,1421,1423],{},[157,1422,1399],{},": 클라이언트는 발급 CA의 공개 키로 인증서의 디지털 서명을 검증합니다. 이로써 인증서가 변조되지 않았으며 실제로 신뢰할 수 있는 CA가 발급했음이 보장됩니다.",[175,1425,1426,1429],{},[157,1427,1428],{},"인증서 유효 기간",": 클라이언트는 인증서의 유효 기간을 확인하여 현재 유효하며 만료되지 않았는지 살핍니다.",[175,1431,1432,1394],{},[157,1433,1434],{},"해지 상태 확인",[166,1436,1438],{"id":1437},"인증서의-신뢰성을-이미-확인했는데도-소유-여부가-중요한-이유","인증서의 신뢰성을 이미 확인했는데도 소유 여부가 중요한 이유",[153,1440,1441,1444],{},[157,1442,1443],{},"인증서의 유효성과 신뢰",": 이 단계는 인증서가 신뢰할 수 있는 인증 기관(CA)에서 발급되었고, 유효 기간 안에 있으며, 해지되지 않았음을 확인합니다. 인증서가 정당하며 변조되지 않았음을 확인하는 것입니다.",[153,1446,1447,1450],{},[157,1448,1449],{},"서버 신원 확인",": 인증서가 유효하고 신뢰할 수 있더라도, 그것이 지금 연결하려는 서버의 것인지도 확인해야 합니다. 여기에는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인하는 일이 포함됩니다. 이 단계는 인증서가 바로 그 서버를 위한 것임을 보장하여, 공격자가 다른 도메인의 유효한 인증서를 제시하는 중간자 공격을 막아 줍니다.",[166,1452,1454],{"id":1453},"클라이언트가-이-질문에-답하는-두-가지-방법과-각-방법에서-나오는-두-가지-결과","클라이언트가 이 질문에 답하는 두 가지 방법과 각 방법에서 나오는 두 가지 결과",[257,1456,1457,1483],{},[175,1458,1459,1462,1463,1466,1260,1469],{},[157,1460,1461],{},"Domain Name System(DNS) 검증",": 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인합니다. ",[1464,1465],"br",{},[157,1467,1468],{},"결과",[172,1470,1471,1477],{},[175,1472,1473,1476],{},[157,1474,1475],{},"일치",": 이름이 일치하면 클라이언트는 인증서가 해당 서버를 위한 것이라고 확신하고 연결을 이어 갈 수 있습니다. ",[175,1478,1479,1482],{},[157,1480,1481],{},"불일치",": 이름이 일치하지 않으면 클라이언트는 대개 연결을 끊거나 보안 위험 가능성을 알리는 경고를 표시합니다.",[175,1484,1485,1488,1489,1491,1260,1493],{},[157,1486,1487],{},"공개 키 기반 구조(PKI) 검증",": 클라이언트는 발급 인증 기관(CA)의 공개 키로 인증서의 디지털 서명을 검증합니다. ",[1464,1490],{},[157,1492,1468],{},[172,1494,1495,1501],{},[175,1496,1497,1500],{},[157,1498,1499],{},"유효한 서명",": 서명이 유효하면 인증서가 변조되지 않았으며 신뢰할 수 있는 CA가 발급했음이 확인됩니다.",[175,1502,1503,1506],{},[157,1504,1505],{},"유효하지 않은 서명",": 서명이 유효하지 않으면 클라이언트는 연결을 끊거나, 인증서가 손상되었거나 위조되었을 수 있음을 알리는 경고를 표시합니다.",[166,1508,1510],{"id":1509},"사용할-방법을-결정하는-요인","사용할 방법을 결정하는 요인",[153,1512,1513],{},[157,1514,1461],{},[172,1516,1517,1523],{},[175,1518,1519,1522],{},[157,1520,1521],{},"사용 시점",": 이 방법은 TLS 핸드셰이크의 일부로 언제나 사용됩니다. 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)을 서버의 도메인 이름과 대조하여 일치하는지 확인합니다.",[175,1524,1525,1528],{},[157,1526,1527],{},"결정 요인",": 이는 TLS 프로토콜의 표준 절차이며, 안전한 연결을 수립할 때 클라이언트가 자동으로 수행합니다.",[153,1530,1531],{},[157,1532,1487],{},[172,1534,1535,1540],{},[175,1536,1537,1539],{},[157,1538,1521],{},": 이 방법도 TLS 핸드셰이크 중에 언제나 사용됩니다. 클라이언트는 발급 인증 기관(CA)의 공개 키로 인증서의 디지털 서명을 검증합니다.",[175,1541,1542,1544],{},[157,1543,1527],{},": 이 역시 TLS 프로토콜의 또 다른 표준 절차입니다. 클라이언트는 인증서가 유효하며 변조되지 않았는지 확인하기 위해 이 검사를 자동으로 수행합니다.",[148,1546,1548],{"id":1547},"서버가-클라이언트에-보내야-할-인증서","서버가 클라이언트에 보내야 할 인증서",[153,1550,1551],{},"TLS 핸드셰이크 중에 서버는 다음 인증서를 클라이언트에 보내야 합니다.",[172,1553,1554,1560],{},[175,1555,1556,1559],{},[157,1557,1558],{},"최종 개체 인증서",": 서버 자신의 인증서로, 클라이언트에게 자신의 신원을 증명합니다.",[175,1561,1562,1565],{},[157,1563,1564],{},"Intermediate 인증서",": 최종 개체 인증서를 신뢰할 수 있는 루트 인증서에 연결하는 인증서입니다. 서버의 인증서에서 신뢰할 수 있는 루트 인증서까지 이어지는 신뢰 체인을 형성하는 데 쓰입니다.",[148,1567,1569],{"id":1568},"domain-validation-인증서와-extended-validation-인증서","Domain Validation 인증서와 Extended Validation 인증서",[153,1571,1572,1575],{},[157,1573,1574],{},"Domain Validation(DV) 인증서","는 인증 기관(CA)이 신청자가 해당 도메인을 통제하고 있는지 확인하는 유형의 TLS 인증서입니다. 확인은 보통 다음과 같은 방법으로 이루어집니다.",[172,1577,1578,1581,1584],{},[175,1579,1580],{},"도메인의 관리 연락처로 보낸 이메일에 회신하기.",[175,1582,1583],{},"DNS TXT 레코드 추가하기.",[175,1585,1586],{},"웹 서버에 파일 업로드하기.",[153,1588,1589],{},[157,1590,1591],{},"주요 특징",[172,1593,1594,1597,1600],{},[175,1595,1596],{},"빠른 발급: 최소한의 검증만 필요하므로 대개 몇 분 안에 빠르게 발급할 수 있습니다.",[175,1598,1599],{},"기본적인 보안: 암호화를 제공하고, 인증서를 요청한 주체가 도메인을 통제하고 있다는 기본적인 보증을 제공합니다.",[175,1601,1602],{},"비용 효율: 흔히 더 저렴하거나 무료여서 소규모 웹 사이트와 개인 프로젝트에서도 쉽게 쓸 수 있습니다.",[153,1604,1605,1608],{},[157,1606,1607],{},"Extended Validation(EV) 인증서","는 더 엄격한 검증 절차를 요구하는 상위 등급의 TLS 인증서입니다. CA는 인증서를 요청한 주체의 법적, 물리적, 운영상 실체를 확인합니다. 여기에는 다음이 포함됩니다.",[172,1610,1611,1614,1617],{},[175,1612,1613],{},"해당 주체의 법적 신원과 지위 확인.",[175,1615,1616],{},"해당 주체의 물리적, 운영상 실재 확인.",[175,1618,1619],{},"해당 주체가 그 도메인을 사용할 배타적 권리를 가지고 있는지 확인.",[153,1621,1622],{},[157,1623,1591],{},[172,1625,1626,1632,1638],{},[175,1627,1628,1631],{},[157,1629,1630],{},"높은 보증 수준",": 철저한 심사를 거치므로 사용자에게 가장 높은 수준의 신뢰와 보증을 제공합니다.",[175,1633,1634,1637],{},[157,1635,1636],{},"눈에 보이는 표시",": 일부 브라우저에서는 EV 인증서가 주소 표시줄에 조직 이름을 표시하곤 했으나, 지금은 흔하지 않습니다.",[175,1639,1640,1643],{},[157,1641,1642],{},"한층 높은 신뢰",": 금융 기관이나 전자 상거래 사이트처럼 민감한 정보를 다루는 웹 사이트에 적합합니다.",[166,1645,1647],{"id":1646},"안전성-비교"," 안전성 비교",[153,1649,1650],{},"Extended Validation(EV) 인증서는 거치는 검증 절차가 엄격하기 때문에 일반적으로 Domain Validation(DV) 인증서보다 안전하다고 봅니다. 비교하면 다음과 같습니다.",[153,1652,1653],{},[157,1654,1574],{},[172,1656,1657,1663,1668],{},[175,1658,1659,1662],{},[157,1660,1661],{},"검증 수준",": 도메인 통제 여부만 확인합니다.",[175,1664,1665,1667],{},[157,1666,191],{},": 기본적인 암호화와 보증을 제공합니다.",[175,1669,1670,1673],{},[157,1671,1672],{},"사용 사례",": 개인 웹 사이트, 블로그, 소규모 사업체에 적합합니다.",[153,1675,1676],{},[157,1677,1607],{},[172,1679,1680,1685,1690],{},[175,1681,1682,1684],{},[157,1683,1661],{},": 해당 주체의 법적, 물리적, 운영상 실체를 확인합니다.",[175,1686,1687,1689],{},[157,1688,191],{},": 철저한 심사를 거치므로 더 높은 수준의 신뢰와 보증을 제공합니다.",[175,1691,1692,1694],{},[157,1693,1672],{},": 금융 기관, 전자 상거래 사이트를 비롯해 민감한 정보를 다루는 모든 웹 사이트에 적합합니다.",[153,1696,1697],{},[157,1698,1699],{},"EV 인증서가 더 안전한 이유",[172,1701,1702,1708,1714],{},[175,1703,1704,1707],{},[157,1705,1706],{},"철저한 심사",": EV 인증서는 광범위한 검증을 요구하므로 악의적인 주체가 발급받기가 더 어렵습니다.",[175,1709,1710,1713],{},[157,1711,1712],{},"신뢰 표시",": 지금은 흔하지 않지만, EV 인증서는 브라우저 주소 표시줄에 조직 이름을 표시하여 사용자에게 눈에 보이는 보증을 제공하곤 했습니다.",[175,1715,1716,1718],{},[157,1717,1630],{},": 상세한 확인 절차를 통해 인증서 뒤에 있는 주체가 정당함을 보장하므로, 피싱을 비롯한 공격의 위험이 줄어듭니다.",[148,1720,1722],{"id":1721},"ocsp-stapling을-사용한-해지-확인-절차","OCSP Stapling을 사용한 해지 확인 절차",[153,1724,1725],{},"OCSP Stapling은 지연을 줄이고 프라이버시를 개선하여 표준 OCSP 절차를 보완합니다. 작동 방식은 다음과 같습니다.",[257,1727,1728,1734,1740,1746,1752],{},[175,1729,1730,1733],{},[157,1731,1732],{},"서버가 OCSP 응답을 요청",": 웹 서버가 인증 기관(CA)이 운영하는 OCSP 응답자에게 자기 인증서의 해지 상태를 주기적으로 요청합니다. 이 요청은 클라이언트가 연결할 때마다가 아니라 백그라운드에서 이루어집니다.",[175,1735,1736,1739],{},[157,1737,1738],{},"OCSP 응답자가 응답을 제공",": OCSP 응답자는 인증서의 상태, 예를 들어 \"good\", \"revoked\", \"unknown\"을 나타내는 서명되고 타임스탬프가 찍힌 OCSP 응답을 돌려보냅니다. 서버는 이 응답을 캐시에 저장합니다.",[175,1741,1742,1745],{},[157,1743,1744],{},"응답을 첨부한 TLS 핸드셰이크",": 웹 브라우저 같은 클라이언트가 서버에 연결을 시작하면, 서버는 캐시에 저장해 둔 OCSP 응답을 TLS 핸드셰이크에 포함합니다. 이를 핸드셰이크에 응답을 \"스테이플링\"한다고 합니다.",[175,1747,1748,1751],{},[157,1749,1750],{},"클라이언트가 OCSP 응답을 검증",": 클라이언트는 첨부된 OCSP 응답을 검증합니다. 응답은 CA가 서명했으므로 클라이언트는 그 유효성을 신뢰할 수 있습니다. 응답이 인증서가 해지되었음을 나타내면 클라이언트는 안전한 연결을 수립하지 않습니다.",[175,1753,1754,1757],{},[157,1755,1756],{},"주기적인 갱신",": 서버는 TLS 핸드셰이크에서 언제나 최신 상태를 제공할 수 있도록 캐시에 저장한 OCSP 응답을 계속 주기적으로 갱신합니다.",[153,1759,1760],{},"이 절차는 클라이언트가 별도로 OCSP 요청을 보낼 필요를 줄여 주므로 성능과 프라이버시가 개선됩니다.",{"title":433,"searchDepth":434,"depth":434,"links":1762},[1763,1771,1772,1775],{"id":1345,"depth":434,"text":1346,"children":1764},[1765,1766,1767,1768,1769,1770],{"id":1349,"depth":439,"text":1350},{"id":1367,"depth":439,"text":1368},{"id":1403,"depth":439,"text":1404},{"id":1437,"depth":439,"text":1438},{"id":1453,"depth":439,"text":1454},{"id":1509,"depth":439,"text":1510},{"id":1547,"depth":434,"text":1548},{"id":1568,"depth":434,"text":1569,"children":1773},[1774],{"id":1646,"depth":439,"text":1647},{"id":1721,"depth":434,"text":1722},{"lang":460,"seoTitle":1777,"titleClass":461,"socialimg":1778,"blogtitlepic":1779,"customExcerpt":1780,"keywords":1781,"maxContent":471},"Transport Layer Security(TLS): 인증서 사용 사례와 검증","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","서버를 확인하고 인증서 체인으로 신뢰를 쌓으며 안전한 암호화 연결을 보장하는 TLS 인증서로 웹 사이트와 사용자를 보호하십시오.","TLS 인증서, Transport Layer Security, 인증서 사용 사례, TLS 인증서 검증, 인증서 신뢰 체인, DV 인증서, EV 인증서, 서버 인증, 안전한 연결, OCSP Stapling","/glossary/use-cases-for-certificates",{"title":1340,"description":433},"glossary/use-cases-for-certificates","-S5BhiCiVMwSuFpULUOWbzy4evxLtHjeFWpWQ9n2L-I",{"list":139,"authors":143},1790098990042]