>

클라이언트와 서버를 안전하게 연결하는 가장 좋은 방법에 대해 읽고 있습니다.

이 튜토리얼 을 통해 인증서 (및 키 저장소)가 제공되지 않은 것 같습니다 서버에 제공되지만 클라이언트에도 제공됩니다.

이 안전하지 않습니까? 클라이언트에 인증서 파일 (키 저장소에 있음)이 있으면 모든 서버 개인 키가 없습니까?

결국 내가 원하는 것은 클라이언트와 서버 사이에 보안/암호화 된 연결을 유지하는 반면 클라이언트 자체는 서버에 인증 된 클라이언트임을 증명하는 것입니다. 이것이 올바른 방법입니까?

감사합니다!

  • 답변 # 1

    보리스가 첫 번째 의견에서 언급했듯이 키 저장소에는 인증 할 키가 포함되고 신뢰 저장소에는 이름에서 알 수 있듯이 신뢰할 수있는 인증서가 포함됩니다.

    먼저 인증서에는 개인 키가 포함될 필요가 없습니다. 공개 키가있는 ID 일뿐입니다 (CA와 같은 신뢰할 수있는 당사자가 서명 한 것임). 그렇기 때문에 적절히 사용하면 안전하지 않습니다. 적절한 방법은 무엇입니까? 여기에 간다 :

    질문에 대답하기 전에, 즉 서버뿐만 아니라 클라이언트도 인증되는 경우 일반적인 경우를 고려해 봅시다 : 클라이언트 만 서버를 인증합니다. 이 시나리오에는 인증 기관 (CA), 서버 (S) 및 클라이언트 (C)의 세 당사자가 있습니다. 작동 시키려면 다음을 수행해야합니다.

    <올>

    CA에 대한 키 쌍을 생성하고 일부 ca.jks 에 저장 .

    ca.jks 에서 인증서 (공개 키만 포함하고 공개 키만 포함)를 내보내십시오.  다른 jks 파일, 즉 truststore.jks 로 가져옵니다. .

    S에 대한 다른 키 쌍을 생성하여 일부 server.jks 에 저장하십시오. .

    CA의 개인 키로 S의 인증서에 서명하십시오. 이 절차를 수행하려면 server.jks 에서 CSR (인증서 서명 요청)을 생성해야합니다. ca.jks 로 csr 파일에 서명하십시오.  서명 된 인증서를 포함하는 일부 crt (또는 원하는대로 pem) 파일을 생성합니다. 마지막으로이 crt 파일을 server.jks 로 다시 가져와야합니다. . 이전과 동일한 별칭을 사용해야합니다.

    server.jks 사용  S에서 키 저장소로, truststore.jks  C에서 신뢰 저장소로.

    와이즈 비즈 유지  안전한 곳에. 신뢰의 근원입니다.

    이런 식으로 C는 인증서가 신뢰 저장소에 있으므로 CA를 신뢰합니다. S는 CA가 서명 한 인증서를 가지고 있으므로 C도 S를 신뢰합니다. 즉, S는 C에 의해 인증됩니다.

    원하는 것을 달성하기 위해, 즉 두 당사자가 서로 인증을 받으려면 CA1과 CA2의 두 인증 기관이 있습니다. (물론 동일 할 수도 있지만, 완전성을 위해 이와 같이 작성하고 있습니다.) 위의 절차를 두 번 수행해야합니다. 한 번은 CA = CA1, 한 번은 CA = CA2입니다. 첫 번째는 정확히 위와 같습니다. 두 번째는 ca.jks 를 만듭니다. , CA2로 서명하고 CA의 공개 키를 S의 신뢰 저장소로 사용하십시오 (C와 S의 역할이 바뀌었을뿐입니다). 이렇게하면 두 당사자가 서로 인증하게됩니다.

    내가 말했듯이, 당신은 매우 편리하고 합리적인 동일한 CA를 사용할 수 있습니다.

    나는 이것이 긴 대답이라는 것을 알고 있지만 대부분의 세부 사항을 생략하고 간단하게 만들려고 노력했다. 도움이 되길 바랍니다.

    편집 :다시 혼동하지 마십시오. 클라이언트는 자신의 개인 키를 사용하여 자신의 키 저장소에 저장된 자신을 인증합니다. 인증서는 이미 공개 된 것입니다 ...

    물론, 일부 도둑이 키 스토어 파일을 훔친 경우, 자신을 실제 클라이언트로 모방 할 수 있습니다. 서버는 자신이 누구와 통신하는지 알 수 없으며 인증서 만 확인합니다. 이러한 시나리오의 경우 발급 된 인증서를 해지 할 수 있습니다. 웹에서 해지를 검색하십시오. 간단히 말해 클라이언트의 키 저장소를 도난당한 경우 모든 키 자료를 재생성하는 대신 해지를 통해 서버에이를 알려줍니다.

    이에 대한 한 가지 경우는 인증서가 공개 키를 ID와 바인딩하는 것입니다. 일반적인 경우 인 웹 서버의 경우 인증서는 공개 키를 호스트 이름과 바인드합니다. 즉, 호스트 이름은 ID입니다. 따라서 abc.com이 xyz.com 용으로 발급 된 인증서를 사용하는 경우 abc.com에 연결하려고하면 브라우저에 오류가 발생합니다. Java 세계에서는이를 호스트 이름 확인이라고합니다. 와이즈 비즈  인증서 필드는 이러한 ID에 사용됩니다. (opensl 또는 키 저장소를 사용하여 생성 할 때 공통 이름을 요청할 수 있으며 매우 중요합니다.) 클라이언트가 실제로 고정 IP 또는 일부 유효한 도메인 이름을 가진 서버 인 경우이를 사용할 수 있습니다. 이런 식으로 도둑이 다른 IP 또는 도메인에서 연결을 시도하기 때문에 서버는 호스트 이름 확인을 통해이를 감지합니다. 그러나 일반적으로 클라이언트에는 안정적인 ID가 없으므로이 기술을 사용하기가 매우 어렵 기 때문에 도둑이 실제 클라이언트를 모방 할 수 있습니다.

    client.jks

관련 자료

  • 이전 compilation - C의 객체 파일은 무엇입니까?
  • 다음 VBA 변수에 SQL MAX (날짜)를 할당하는 방법