저는 OpenSSL C API로 작업하려고합니다.이 모든 것에 비교적 익숙하지 않습니다. 많은 혼합 정보가 있습니다. 그래서 나는 아이디어 / 의견 / 설명을 요청하는 것이 현명하다고 생각합니다.
어쨌든 클라이언트 프로그램은 “TrustStore”가 포함 된 인증서 나 디렉토리를로드해야합니다. 서버의 CA 인증서 자체가 해당 서버에 대한 자체 SSL 인증서를 생성하는 경우?
그렇다면 중간 CA가 루트 CA 대신이 목적을 위해 작동합니까?
제가 올바른 길을 가고 있다고 생각합니다. 그러나 나는 이와 관련하여 상충되는 정보를 들었 기 때문에 실제 실수를 방지하기 위해 약간의 설명을 원했습니다. 일부는 클라이언트에 루트 CA 자체가 필요하다고 말하고 다른 출처에서는 논리적으로 보이는 보안상의 이유입니다.
클라이언트 연결과 관련하여 신뢰 체인이 작동하는 방식에 대해서는 일반적으로 약간 혼란 스럽습니다. 저는 실제로 CSR을 생성하고 웹 서버에 인증서를 설치하기 만하면 되었기 때문에 클라이언트 측 항목은 나에게 좀 새로운 것입니다.
이 질문은 원래 여기 에서 info-sec 커뮤니티에 물어볼 것을 제안했습니다.
댓글
- 잘못된 문구를 사용하고있는 것 같습니다. 자체 서명 된 인증서 는 발급자 인증서가 인증서 자체 인 인증서입니다. 아마도 대신 자신의 CA에서 서명 한 인증서를 의미합니다.이 경우 루트 CA는 일반적으로 신뢰 저장소에 저장되고 루트 CA가 서명 한 중간 인증서와 중간 인증서가 서명 한 리프 인증서가 TLS 핸드 셰이크 중에 전송됩니다. .
- SSL / TLS PKI는 어떻게 작동합니까?
답변
tl; dr 인증서에 CA:TRUE의 변형이 포함 된 경우 배포하는 것이 합리적이며 그렇지 않은 경우 배포해도 이점이 없습니다.
p>
신뢰 사슬 자체는 인증서 구조로 설명 할 수 있습니다.
서버의 인증서 (예 : 일반적으로 아파치에 사용하는 인증서) :
- 서버 인증서는 사용자가 제공 한 CSR을 기반으로 인증 기관에서 생성합니다. 해당 CSR에는 공개 키와 CA가 사용에 관심을 가질 수도 있고 사용하지 않을 수도있는 기타 정보가 포함되어 있습니다.
- CA는 귀하의 CSR을 받고 (일반적으로) 중간 CA를 사용하여 서명 된 인증서를 생성합니다. 인증서에는 두 개의 공개 키가 있습니다. 하나는 주체 (CSR에서 추출한 공개 키) 용이고 다른 하나는 CA의 중간 인증서 인 발급 당사자 용입니다.
- CA ” 중간 인증서는 그 자체로 서명 된 인증서 (몇 가지 특수 옵션 포함)이며 주체 키는 중간 CA의 공개 키 (서버 인증서의 발급자 공개 키에있는 것과 동일한 공개 키)가됩니다. 서명 (또는 발급) 키는 CA의 루트 인증서가됩니다 (또는 다른 중간 인증서가 됨).
- CA의 루트 인증서는 (일반적으로) 자체 서명 된 인증서입니다. 실제로 이는 발급자 및 제목 키가 동일한 공개 키임을 의미합니다.
야생적으로 인증서를 확인하여이를 확인할 수 있습니다. 예 :
$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 이 빌드가 구축하는 신뢰 체인은 다음과 같이 요약 할 수 있습니다 ( ” bottom “-Equifax 인증서) :
- 루트 CA (Equifax)는 일상적인 활동을 중간 CA (GeoTrust)에 위임하고이 사실을 나타내는 인증서에 서명합니다 (예 : CA 설정 : TRUE, KeyUsage : keyCertSign) 즉, 루트 CA는 중간 인증을 “신뢰”하여 대신 인증서를 발급합니다 (일련의 필수 유효성 검사 단계를 완료 한 후).
- 이 체인에서 중간 (Geotrust)는 추가로 Google CA (CN = Google Internet Authority G2)에 위임했습니다.
- 대리인 (Google 중개 CA라고도 함)은 CSR에 서명합니다. 이름 세트 (t CN 및 가능하면 주체 대체 이름), 개인 / 공개 키 쌍이 유효 / 신뢰됩니다 (여기서 신뢰는 주어진 이름에 대한 주장을 확인한 사실에서 비롯됩니다.이 경우 Google CA는 * .google.com에 대한 인증서).
(루트) CA는 일반적으로 자체 서명됩니다. CA는 사용자에게 인증서를 발급하지 않도록하는 일련의 프로세스와 절차를 준수하기 때문에 일반적으로 신뢰할 수 있습니다. 그들을 가져서는 안되는 사람. 그래서 나가서 내가 Google이라는 인증서를받을 수 없습니다.따라서 이것은 일종의 규칙이며 (공식 메커니즘에 의해 뒷받침되는 것임에도 불구하고) 자신의 CA를 시작하는 경우 루트 (및 중간) 인증서를 배포하면 다른 CA의 인증서를 배포하는 것과 똑같은 결과를 얻을 수 있습니다. 인증서를 발급합니다. 해당 CA에 의해 시스템에서 유효한 (즉, 신뢰할 수있는) 것으로 승인됩니다.
더 실용적인 용어로 트러스트 저장소 (openSSL 용)는 특정 명명 규칙을 사용하는 거의 많은 파일입니다. https://www.openssl.org/docs/faq.html#USER5 :
시기 인증서가 확인되었습니다. 루트 CA는 OpenSSL에 의해 “신뢰”되어야합니다. 이는 일반적으로 CA 인증서가 디렉토리 또는 파일에 있어야하며 관련 프로그램이이를 읽을 수 있도록 구성되어야 함을 의미합니다.
이 디렉토리는 / etc / ssl / certs입니다 (RH와 유사한 경우 / etc / pki와 같은 다른 디렉토리도 있습니다).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 는 다음과 같이 인증서를 상점에 추가하는 방법에 대한 추가 개요를 제공합니다. https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
짧은 버전은 update-ca-certificates 는 프로세스를 자동화하며 일반적으로 사용되는 도구입니다.
약간 더 긴 버전은 인증서를 해시로 저장해야한다는 것입니다 (예 : based openssl x509 -hash -in cert.pem의 출력에서) openSSL이 체인을 효율적으로 검증 할 수 있도록합니다.
https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html 입니다.
업데이트 됨 댓글의 질문에 응답 :
서버 인증서 이 논의에서는 신뢰 체인을 기반으로하지 않거나 신뢰할 수있는 것으로 정의됩니다. (예) curl https://google.com의 작동 방식에 대해 생각하면 이해하기가 조금 더 쉽습니다.
- curl은 Google에 대한 TLS 연결을 엽니 다. 인증서.
- curl은 해당 “최종 사용자”인증서 (예 : 서버의 인증서)를보고 특히 발급자를 찾습니다.
- 발급자가 “알려진”경우 신뢰 저장소, 나머지 신뢰 체인의 유효성이 확인됩니다 (즉, 서버 인증서 발급자의 인증서가 확인되고 그 에 자신이 아닌 다른 발급자가있는 경우 해당 발급자가 확인됩니다). 완전한 신뢰 체인을 검증 할 수있는 경우에만 유효한 인증서로 간주됩니다.
그러나 최종 사용자 인증서를 포함해야하는 경우 신뢰 체인을 배포하는 것은 절대적으로 비현실적입니다. 얼마나 많은 웹 사이트가 있는지에 대한 수치는 없지만 Alexa가 상위 100 만 개를 제공한다는 사실을 고려할 때 1 백만 개 이상이라고 가정 할 수 있습니다.
신뢰 체인 : 일반적으로 발급자 인증서가 있어야하지만 최종 인증서를 배포 할 필요는 없습니다. 발급자가 누구인지 알려주기 때문입니다.
그렇지 않은지 확인할 수 있습니다. ” 발행자 공개 키 (및이를 설정하는 신뢰 체인이 올바른 키임)를 확인하고 최종 사용자 (즉, 서버) 인증서가 실제로 발행자의 개인에 의해 서명되었는지 여부를 확인할 수 있기 때문입니다. 공개 키입니다.
아니요, 최종 사용자 인증서를 배포해서는 안되며 신뢰 체인 만 배포해야합니다. 또는 간단히 말해서 생성 한 인증서를 모두 배포해야합니다. BasicConstraints (합법적으로)는 최소한 CA : TRUE라고합니다. 해당 조건을 충족하지 않는 것은 배포하지 마십시오. 이는 시간과 디스크 공간을 낭비하기 때문입니다. -CA : TRUE라고 말하지 않는 모든 것은 그렇지 않은 것에 대해 검증 될 수 있습니다.
코멘트
답변
자체 서명 인증서는 정확히 다음과 같습니다. 내 자신에 서명했습니다 (자신의 신뢰 앵커입니다).
따라서 신뢰할 수 있으려면 응용 프로그램의 신뢰할 수있는 앵커 목록에 수동으로 명시 적으로 배치해야합니다. 수행 방법은 OS 및 응용 프로그램에 따라 다릅니다.
예를 들어, Windows의 내부 인증서 저장소를 사용하는 경우 자체 서명 된 인증서를 “신뢰할 수있는 루트 인증 기관”저장소에 저장해야합니다. 그렇지 않으면 인증서가 허용되지 않습니다. OpenSSL은 다른 애플리케이션 별 스토리지 시스템을 사용합니다. 인증서를 신뢰할 수있는 CA로 설치해야하지만 설치 방법은 사용중인 애플리케이션과 OS에 따라 크게 다릅니다 (이 도움말 에 대한 일반적인 지침).
댓글
- ” Trust Store ” 인증서는 Apache에 설치된 인증서와 동일합니다. 예를 들어 ‘ s 가장 혼란스러운 부분은 클라이언트 애플리케이션에서 링크해야하는 디렉토리 인 i ‘ ma
GNU/Linux사용자입니다./etc/ssl/certs. 그러나 그 과정이 정확히 무엇인지에 대한 명확한 설명을 찾을 수 없었습니다. 적어도 여기에서 제 질문을 이해하고 있습니다. 클라이언트가 연결하고있는 서버를 신뢰하도록합니다. - What i ‘ 정확히 시도하는 것은 CA를 생성하는 것입니다. 인증서가 CA (중간)에 의해 서명 된 것 같습니다.이 경우 CA가 신뢰 앵커라는 의미입니까? 중간 CA는 신뢰할 수있는 인증서 디렉토리에 설치해야합니까? 응답 해 주셔서 감사합니다.
- 따라서 귀하의 질문은 더 일반적입니다. 나는 ‘ 당신이 찾고있는 답변에 대한 링크와 함께 그것을 폐쇄 할 것을 제안했습니다.
/etc/ssl/certs디렉토리? 모두 공개 키를 포함하고 있습니까?