openSSL을 사용하여 로컬로 SSL 인증서를 생성 할 수있을 때 SSL 인증서를 구매해야하는 이유를 이해하는 데 어려움이 있습니다. 구입 한 인증서와 로컬로 생성 한 테스트 인증서의 차이점은 무엇입니까? 그냥 큰 사기입니까?
답변
한마디-신뢰. 브라우저가 신뢰하는 제공 업체의 SSL 인증서는 사용자가 본인이라고 말하기 위해 최소한 기본 확인을 수행했음을 의미합니다.
그렇지 않으면 google.com 또는 yourbank.com에 대한 자체 인증서를 만들어서 가장 할 수 있습니다.
유료 인증서는 자체 서명 (보통)을 통한 추가 암호화 수준을 제공하지 않습니다. 그러나 자체 서명 된 인증서로 인해 브라우저에 오류가 발생합니다.
예, SSL의 일부는 사기 (verisign 인증서와 verisign이 최대 100 배 더 비싼 geotrust)이지만 전부는 아닙니다.
이것이 모두 내부적 인 것이라면, 자신 만의 트러스트 방법을 사용할 수 있기 때문에 유료 인증서가 필요하지 않습니다 (예 : 아무것도하지 않거나 지문 확인).
답변
SSL 인증서의 요점은 브라우저가 HTTPS 트랜잭션에 대한 서버의 공개 키를 신뢰할 수있는 수준으로 신뢰하도록하는 것입니다.
먼저 인증서를 사용하지 않으면 어떻게 될지 살펴 보겠습니다. 대신, 서버는 공개 키를 일반 텍스트로 보내고 브라우저는이를 사용하여 암호화 된 통신을 시작합니다 (먼저 자신의 공개 키를 암호화하여 안전하게 전송하는 것입니다). 내가 공격자와 중간에 갇혀 있다면 어떨까요? 나는 즉시 공개 키를 내 것으로 교체하고, 브라우저와 암호화 된 연결을하고, 내가받는 모든 것들을 해독하고, 공개 키로 그것을 암호화하고, (응답 유형 트래픽의 경우 그 반대) 전송할 수 있습니다. 아무도 공개 키를 미리 알지 못했기 때문에 아무도 그 차이를 알지 못했습니다.
브라우저가 공개 키를 신뢰할 수있는 방법이 필요하다는 것을 알았습니다. 이를 수행하는 한 가지 방법은 등록 된 모든 공개 키를 브라우저에 저장하는 것입니다. 물론, 누군가 공개 키를 등록 할 때마다 업데이트가 필요하며 이로 인해 팽창이 발생할 수 있습니다. DNS 서버 1 에 공개 키를 보관할 수도 있지만 DNS 서버도 스푸핑 할 수 있으며 DNS는 안전한 프로토콜이 아닙니다.
따라서 남은 유일한 옵션은 서명 메커니즘을 통해 신뢰를 “연결”하는 것입니다. 브라우저에는 몇 개의 CA에 대한 세부 정보가 저장되며 인증서는 다른 인증서 체인과 함께 전송되며, 각 인증서는 다음 인증서에 서명하고 루트 / 신뢰 / 내장 CA로 이동합니다. 인증서를 서명하기 전에 도메인이 자신의 소유인지 확인하는 것은 CA의 일입니다.
CA가되는 것은 사업이기 때문에 비용이 청구됩니다. 다른 것보다 더 많은 것.
자체 인증서를 만든 경우 다음과 유사한 오류가 발생합니다.
서명되지 않은 인증서에는 가치가 없습니다. 마치 연필과 소책자, 버락 오바마라고 주장하는 여권을 그리는 것과 같습니다. 아무도 그것을 믿지 않을 것입니다.
1. 결국, 도메인을 등록 할 때 DNS 항목이 작성됩니다. 공개 키를 동시에 등록 할 수있는보다 강력한 프로토콜을 사용하는 것은 흥미로운 개념입니다.
답변
귀하의 질문에 대한 답변은 독자에 따라 다릅니다. 전체 인증서 시스템은 “신뢰”를 기반으로하기 때문에 사용자는 인증서를 스스로 증명하거나이 확인을 수행 한 서드 파티를 신뢰하고 서명함으로써 성공을 보여줄 수 있어야합니다. 당신의 증명서. 내가 사용한 “인증서 증명”이라는 용어는 약간 부정확합니다. 긴 버전은 “인증서 소유자임을 증명하고 사용할 수 있음”이어야합니다.
모든 사용자가 귀하를 개인적으로 알고 있고 자신이 인증서를 발급했음을 증명할 수있는 기술적 능력이있는 경우 “인증 된”공급자의 인증서를 기술적으로 사용할 필요가 없습니다. 이 경우 자체 서명 된 인증서가 해당 공급자 중 하나의 인증서보다 낫습니다.
그러나 대부분의 경우 사용자가이 프로세스를 스스로 수행 할 가능성은 없습니다. 이 SSL 공급자는 시장에 나옵니다. 이들은 이러한 검사를 수행하고 인증서에 서명하여 검사 결과를 표현할 수있는 서비스를 제공합니다. SSL 공급자는 인증서를 서명함으로써 자체 서명 정책에 따라 인증서 발급자 신원을 확인했음을 나타냅니다. 따라서 사용자는이 정책이 정확하고 공급자를 신뢰할 수 있는지 결정해야합니다.
답변
요점은 인증서가 자체 생성 인 경우 일반 사용자가 진실성을 확인할 방법이 없다는 것입니다. 구매 한 인증서의 경우 최소한 인증서 내부에 인쇄 된 내용이 올바른지 확인한다고 가정합니다. 아이디어 : 전화 및 주소를 인증서에 입력하면 CA는이를 확인하려고하지만 거의하지 않습니다.
또한 구매 인증서는 추적 가능하므로 사용자는 인증서의 출처를 항상 추적 할 수 있으며 자체 서명 된 인증서는 임의의 ID 일뿐입니다.
많은 시스템에서 과거에는 권한 부여 된 CA의 “코드 서명”이 필요했습니다. 정책 기반이지만 자체 서명 된 인증서가 너무 많아서 더 이상 100 % 시행되지 않습니다.
답변
조직적인 것만으로는 기술적 인 차이가 없습니다 (자체의 보안 수준은 그다지 안전하지 않습니다). CA의 인증서는 브라우저 표준 설치의 일부가 아닙니다. 따라서 대부분의 사람들이 인증서에 연결하는 것이 불편합니다. 그러나 내부 네트워크 용 인증서를 구입하는 것은 의미가 없습니다.
답변
신뢰로 귀착됩니다. “인증 된”SSL 공급자는 서버 자체의 자체 서명 인증서와 비교하여 평판이 좋을 것입니다.
조직에 자체 인증서 서명이있는 경우 이는 완벽하게 허용되며 사용자에게 인증서 키 체인을 신뢰할 수있는 소스로 사용하는 경우 경고를 발생시키지 않아야하지만 외부에서 사용하려고하면 여전히 경고를 생성합니다.
결론 : 내부 사용의 경우 유료 고객에게 외부 적으로 제공하는 경우 경고가없는 것이 안심입니다. 공인 거래처를 통해 금융 거래를하는 것이 안전합니까, 아니면 모르는 거리에 서있는 사람이 있습니까?
답변
최근 LetsEncrypt 는 유효한 인증서를 생성하기 위해 명령 줄 도구를 사용할 수 있다고 발표했습니다.
확인 이메일, 복잡한 구성 편집, 만료 된 인증서가 웹 사이트를 손상시키지 않습니다. 물론 Let ‘s Encrypt는 인증서를 무료로 제공하기 때문에 지불을 주선 할 필요가 없습니다.
해당 인증서가 주요 브라우저에서 유효한지 궁금한 사람들은 예입니다.
2015 년 10 월 19 일, IdenTrust가 중간 인증서를 크로스 서명하여 Let ‘s Encrypt에서 발급 한 모든 인증서를 모든 주요 브라우저에서 신뢰할 수있게했습니다. [20]
….. 2016 년 3 월 8 일, Let ‘s Encrypt는 7 개월의 존재 후 백만 번째 인증서를 발급했습니다. [39]
2016 년 4 월 12 일 왼쪽 베타를 암호화합시다.
시스템 관리자 및 개발자를위한 링크 :
https://letsencrypt.org/getting-started/
블록 체인 기술의 시대와 제 3 자 트러스트 시스템의 제거로 인해, 선택된 몇몇 당국에 의한 고가의 인증서 발행에 의문이 제기되기 시작한 때가되었습니다.
Letsencrypt는 블록 체인 기술과 관련이 없지만 올바른 방향으로 시작합니다. 값 비싼 인증 기관에 매년 높은 수수료를 지불해야 할 필요성이 논리적으로 끝나고 있습니다.