SSL과 관련하여 인증서와 키의 차이점은 무엇입니까?
답변:
인증서에는 공개 키가 포함되어 있습니다.
인증서에는 공개 키를 포함 할뿐 아니라 발급자, 인증서 사용 대상 및 기타 유형의 메타 데이터와 같은 추가 정보가 포함됩니다.
일반적으로 인증서 자체는 CA의 개인 키를 사용하여 인증 기관 (CA)에 의해 서명됩니다. 인증서의 진위 여부를 확인합니다.
openssl명령을 디코딩 할 수 이것들을 파싱하거나 다음과 같은 온라인 유틸리티를 사용할 수 있습니다 : lapo.it/asn1js
회사 A에 키 페어가 있고 공개 사용을 위해 공개 키 (웹 사이트의 SSL)를 게시해야한다고 가정 해 보겠습니다.
- 회사 A는 자신의 키 쌍에 대한 인증서를 받으려면 인증 기관 (CA)에 인증서 요청 (CR)을 작성해야합니다.
- 회사 A의 키 쌍의 개인 키가 아닌 공개 키는 인증서 요청의 일부로 포함됩니다.
- 그런 다음 CA는 회사 A의 신원 정보를 사용하여 요청이 인증 발행에 대한 CA의 기준을 충족시키는 지 여부를 판별합니다.
CA가 요청을 승인하면 회사 A에 인증서를 발급합니다. 간단히 CA는 회사의 개인 키로 회사 A의 공개 키에 서명하여 인증을 확인합니다.
따라서 유효한 CA의 개인 키로 서명 된 회사 A의 공개 키를 회사 A의 인증서라고합니다.
예를 들어 설명하겠습니다.
일반적인 키 쌍 기반 PKI에는 개인 키와 공개 키가 있습니다.
인증서 기반 시스템에는 개인 키와 인증서가 있습니다. 인증서는 공개 키보다 많은 정보를 보유합니다.
데모 (인증서 및 개인 키를 생성 할 수 있음) : http://www.selfsignedcertificate.com/
개인 키 파일 및 인증서 파일을 열면 다운로드 할 수 있으며 인증서 파일에 아래와 같이 많은 정보가 포함되어 있습니다.
https://www.sslshopper.com/certificate-key-matcher.html 사이트에서 생성 된 인증서 (텍스트 편집기로 여는) 및 개인 키 (텍스트 편집기로 여는)를 일치시킬 수 있습니다.
인증서가 클라이언트의 개인 키와 일치하면 클라이언트는 해당 인증서가 클라이언트에 의해 제공되거나 클라이언트의 신뢰할 수있는 에이전트 (CA)에 의해 제공된다고 확신합니다.
그러나 개인 키 및 인증서 기반 통신에만 문제가 있습니다 .
누구나 자신의 인증서와 개인 키를 생성 할 수 있으므로 간단한 핸드 셰이크는 서버가 인증서의 공개 키와 일치하는 개인 키를 알고 있다는 것 외에는 서버에 대해 아무 것도 증명하지 못합니다. 이 문제를 해결하는 한 가지 방법은 클라이언트가 신뢰하는 하나 이상의 인증서 세트 를 갖도록 하는 것입니다. 인증서가 세트에 없으면 서버를 신뢰할 수 없습니다 .
이 간단한 접근 방식에는 몇 가지 단점이 있습니다. 서버는 인증서의 공개 키를 새 키로 대체하는 시간이 지남에 따라 더 강력한 키 ( "키 순환")로 업그레이드 할 수 있어야합니다. 불행히도, 이제 서버 구성 변경으로 인해 클라이언트 앱을 업데이트해야합니다. 서버가 앱 개발자의 제어를받지 않는 경우 (예 : 타사 웹 서비스 인 경우)에 특히 문제가됩니다. 이 방법은 앱이 웹 브라우저 나 이메일 앱과 같은 임의의 서버와 통신해야하는 경우에도 문제가 있습니다.
이러한 단점을 해결하기 위해 서버는 일반적으로 인증 기관 (CA)이라는 잘 알려진 발급자의 인증서로 구성됩니다. 호스트 플랫폼 (클라이언트)에는 일반적으로 신뢰하는 잘 알려진 CA 목록이 포함되어 있습니다. 서버와 마찬가지로 CA에는 인증서와 개인 키가 있습니다. 서버에 대한 인증서를 발급 할 때 CA는 개인 키를 사용하여 서버 인증서에 서명합니다. 그러면 클라이언트는 서버에 플랫폼에 알려진 CA에서 발급 한 인증서가 있는지 확인할 수 있습니다.
그러나 일부 문제를 해결하는 동안 CA를 사용하면 또 다른 문제가 발생합니다. CA는 많은 서버에 대한 인증서를 발급하기 때문에 원하는 서버와 통신 할 수있는 방법이 필요합니다. 이 문제를 해결하기 위해 CA에서 발급 한 인증서는 gmail.com과 같은 특정 이름 또는 * .google.com과 같은 와일드 카드 호스트 집합을 사용하여 서버를 식별합니다.
다음 예제는 이러한 개념을 좀 더 구체적으로 만듭니다. 명령 행의 아래 스 니펫에서 openssl 도구의 s_client 명령은 Wikipedia의 서버 인증서 정보를 확인합니다. HTTPS의 기본값이므로 포트 443을 지정합니다. 이 명령은 openssl s_client의 출력을 openssl x509로 보내며 X.509 표준에 따라 인증서에 대한 정보를 형식화합니다. 특히이 명령은 서버 이름 정보가 포함 된 제목과 CA를 식별하는 발급자를 요청합니다.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
RapidSSL CA가 * .wikipedia.org와 일치하는 서버에 대해 인증서가 발행되었음을 알 수 있습니다.
보다시피, CA가 서버로 보낸이 추가 정보로 인해 클라이언트는 서버와 통신 중인지 여부를 쉽게 알 수 있습니다.
SSL 인증서 는 신뢰할 수있는 인증 기관에서 가져와 웹 사이트의 보안 연결을 보증합니다. SSL 인증서에는 일반적으로 인증 로고와 컴퓨터로 전송 될 데이터를 암호화 및 암호 해독하는 데 필요한 공개 키가 포함됩니다. SSL 키 기능
세션 중에 여러 SSL 키 가 생성 될 수 있습니다. 이 키는 컴퓨터와주고받는 정보를 암호화하고 해독하는 데 사용되며 키는 정보가 수정 또는 변조되지 않았는지 확인하는 데 사용됩니다.
수명주기 차이
인증서는 SSL 키보다 오래 지속됩니다. SSL 인증서는 인증 기관에서 가져 오며 은행 및 비즈니스에서 정기적으로 갱신 할 수 있습니다. 반면 SSL 키 또는 세션 키는 세션 중에 고유하게 생성되며 세션이 종료되면 삭제됩니다.
자, 비 기술자들이 이해할 수 있도록 이것을 분류 해 봅시다.
이것을 이렇게 생각하십시오. 인증서는 은행의 안전 금고와 같습니다. 중요한 것들이 많이 포함되어 있습니다. 일반적으로 당신의 정체성을 담고있는 것들. 인증서에는 공개 키가 있으며 인증서를 열려면 개인 키가 필요합니다.
안전 금고도 인증서처럼 두 개의 열쇠를 열어야합니다.
안전 금고를 사용하면 은행 키는 은행에 있고 공개 키는 인증서와 함께 있기 때문에 공개 키와 같습니다. "인증서를 받으려면"필요한 개인 키가 있으며 안전 금고의 예에서는 공개 키 외에 개인 키가 필요합니다.
안전 금고를 실제로 열려면 먼저 신원 (인증서 요청과 같은 종류)을 확인해야합니다. 일단 식별되면 개인 키와 공개 키를 사용하여 안전 상자를 엽니 다. 이것은 인증서 요청을 한 다음 인증 기관에서 인증서를 얻는 것과 같습니다 (신뢰할 수 있고 올바른 키를 가지고있는 한).