사람들은 말하곤했습니다.
cer-X.509 표준 형식으로 저장된 인증서. 이 인증서에는 공개 및 개인 키와 함께 인증서 소유자에 대한 정보가 포함되어 있습니다.
pfx-개인 교환 형식을 나타냅니다. 단일 파일에서 공용 및 개인 개체를 교환하는 데 사용됩니다. .cer 파일에서 pfx 파일을 만들 수 있습니다. 소프트웨어 게시자 인증서를 만드는데도 사용할 수 있습니다.
** got ref from this link cer, pvk 및 pfx 파일의 차이점은 무엇입니까? **
그러나 CERT 파일을 사용해야 할 때와 PFX 파일을 사용해야 할 때를 말하는 사람은 없습니다. 가능하다면 CERT 파일을 가져와야 할 때와 PFX 파일을 가져와야 할 때 상황을 논의하십시오. 감사.
답변:
.pfx에는 관련 인증서에 대한 공개 및 개인 키가 모두 포함됩니다 (조직 외부에서 공유하지 마십시오). 웹 사이트의 TLS / SSL, 메시지 또는 인증 토큰 디지털 서명 또는 파트너 시스템 인증에 사용할 수 있습니다. .cer 파일에는 공개 키만 있습니다 (일반적으로 통합 파트너와 교환하는 것입니다). 토큰 또는 클라이언트 인증 요청을 확인하는 데 사용할 수 있으며 SSL 핸드 셰이크에서 서버로부터 HTTP 클라이언트가 수신 한 것입니다.
약간 다르게 작동하는 2 개의 시나리오 :
시나리오 1 :
SSL을 사용하여 HTTPS를 통해 웹 페이지 (서버)에 액세스하는 웹 브라우저 (클라이언트).
서버에는 두 키가 모두 포함 된 .PFX 파일이 있습니다. 클라이언트는 서버의 웹 사이트에 연결하고 서버는 SSL 핸드 셰이크의 일부로 공개 키 (.CER 파일)의 사본을 클라이언트에 보냅니다. 그런 다음 클라이언트는 "SESSION-Key"를 생성하고 서버에서받은 공개 키를 사용하여 암호화합니다. 그런 다음 세션 키가 서버로 다시 전송되고 해독되어 진위를 확인합니다. 성공적으로 성공하면 클라이언트와 서버 모두 대칭 암호화를 사용하여 통신하기 위해 "세션 키"를 공유합니다 (즉, 클라이언트와 서버 모두 이제 동일한 세션 키를 사용하여 서로간에 모든 메시지를 암호화하고 해독합니다. 주소 표시 줄에 URL을 입력하고 웹 페이지가 나타나는 시간 사이에 웹 브라우저의 배경에서 수행됩니다.
시나리오 2 :
응용 프로그램 (클라이언트)이 SSH를 사용하여 FTP 사이트 (서버)
또는
원격 데스크톱 (클라이언트 대 서버)에 연결합니다
(두 예제 모두 적용됨).
이 시나리오에서는 모두 클라이언트와 서버가 됩니다 자신의 개인 및 공개 키 쌍을
(서버가 두 키를 가지고 있으며, 클라이언트는 공개 키가있는 경우에만 설명하는 것이,이 스레드에서 언급 된 다른 예는 달리)
이제 설명을 위해 키 쌍에 다음과 같은 레이블을 지정합니다.
A1 및 A2 = 각각 서버 개인 및 공개 키로
B1 및 B2 = 각각 클라이언트 개인 및 공개 키로
이 모델을 사용하여이 스레드의 이전 게시물은 서버에 A1 및 A2 ( .PFX 파일 )가 있고 클라이언트와 A2 ( .CER ) 사본 만 공유하는 경우에 대해 설명했습니다.
FTP 또는 SSH 연결 (다른 예가 있음)은 전체 클라이언트-서버 통신에서 A1 , A2 , B1 및 B2 키로 구성됩니다. 예를 들어
-클라이언트가 FTP 서버에 연결합니다.
-서버는 클라이언트에게 공개 키 (A2)의 사본을 보냅니다.
-클라이언트는 자체 공개 키 (B2)를 서버로 다시 보내 핸드 셰이크를 완료합니다.
-이제 비대칭 암호화를 사용 합니다.
서버는 이제 A1 , ( 자체 비공개 ), A2 ( 자체 공개 ), B2 사본 ( 클라이언트 공개 )
클라이언트는 이제 B1 , ( 자체 비공개 ), B2 ( 자체 공개 ) 및 A1 사본 ( 서버의 공개 )
클라이언트-서버 통신 :
클라이언트는 A2 (서버 공개 키)를 사용하여 서버에 바인딩 된 메시지를 암호화하고, 서버는 A1 (서버 개인 키)을 사용하여 메시지를 암호화합니다.
서버-클라이언트 통신 :
서버는 B2 (클라이언트 공개 키)를 사용하여 클라이언트에 바인딩 된 메시지를 암호화하고, 클라이언트는 B1 (클라이언트 개인 키)을 사용하여 메시지를 해독합니다.
.CER 및 .PFX 파일 유형과 관련하여 서버에는 조직 외부에 배포해서는 안되는 자체 .PFX가 있습니다. 대신 .CER 파일을 클라이언트에 배포해야합니다.
자세한 정보는 여기에서 찾을 수 있습니다 :
https://www.digicert.com/ssl-cryptography.htm
그리고 여기 :
/server/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client
앞서 언급했듯이 cer 파일은 공개 키일 뿐이지 만 pfx 파일에는 공개 키와 개인 키가 모두 포함되어 있기 때문에 문제는 약간의 사과와 오렌지입니다.
따라서 더 공정한 질문은 언제 pem 파일이 아닌 pfx 파일을 사용 하겠느냐하는 것입니다. pfx 파일이 지나치게 복잡하다는 비판을 받았다는 점을 감안할 때 두 번째 질문에 대한 공정한 대답은 다음과 같습니다. IIS를 실행 중이고 해당 구성이 절대적으로 다른 것을 사용할 수없는 경우에만 pfx 파일을 사용하고 싶을 것입니다. .
출처 : https://en.wikipedia.org/wiki/PKCS_12 (참조 된 각주는 Peter Gutmann의 기사입니다.)
SSL은 비동기 암호화를 사용합니다. 즉, 키 쌍을 "소유하는"서버에 하나의 키 (개인 키)가 제공되고 다른 키 (공개 키)는 자유롭게 배포됩니다.
비공개 키로 암호화 된 데이터는 공개 키로 만 복호화 할 수있는 반면 공개 키로 암호화 된 데이터는 개인 키로 만 복호화 할 수 있기 때문에 비동기식이라고합니다. 따라서 소유자에게 안전하게 무언가를 보내려면 그의 개인 키로 암호화하면 그가이를 해독 할 수있는 유일한 사람이됩니다. 소유자가 무언가를 보냈다는 것을 증명하려면 개인 키로 암호화하고 공개 키를 가진 사람은 누구나 암호를 해독 할 수 있습니다. (인증서가 설치되면 일반적으로 브라우저 또는 이메일 도구를 통해 백그라운드에서 수행됩니다.)
소유자는 개인 키를 비공개로 유지하기를 원하므로 암호로 보호되고 소유 서버에만 제공됩니다 (종종 PFX 또는 P12 파일). 그러나 공개 키는 자유롭게 배포됩니다 (종종 CER 파일로).