다음 명령을 사용하여 키 쌍을 만들었습니다.
"%JAVA_HOME%\bin\keytool" -genkeypair -keysize 2048 -alias tomcat -keyalg RSA -sigalg SHA256withRSA
jdk/lib/security 폴더에 키 저장소가 있고 jre/lib/security 폴더에 또 다른 키 저장소가 있음을 확인했습니다. 나는 저장된 이들 중 하나가 방금 생성한 키 쌍을 보유할 것이라고 가정했습니다. 키 쌍은 로그인한 사용자 디렉터리에 생성된 기본 키 저장소에 생성되었습니다.
내 첫 번째 질문은 왜 사용자 디렉토리에 기본 키 저장소가 있습니까? 이상해 보입니다. 해당 키스토어를 이동할 수 있나요?
두 번째 질문은 키 저장소가 왜 그렇게 많은가입니다.
마지막 질문은 내 키 쌍이 기본 저장소의 유일한 키이므로 다른 곳으로 이동/복사해야 합니까?입니다. ICA의 서명이 필요하므로 그 자체만으로는 옳지 않은 것 같습니다.
답변1
Java는 업데이트할 때마다 기본 키 저장소를 덮어쓰므로(대부분의 경우 새 위치에 설치하고 이전 키 저장소를 지움) 패키지를 업데이트할 때마다 사용자가 생성한 개인 키가 삭제됩니다. 신뢰할 수 없는 CA 등을 삭제하기 위한 기본 신뢰 저장소의 변경 사항도 포함하므로 기본(가장 정상적인 방법)은 사용자 폴더에 항목을 저장하는 것입니다. 그렇게 하면 업데이트에서 격리됩니다. 또한 동일한 시스템의 모든 사용자가 다른 사용자의 개인 키에 액세스할 수 있거나 사용자 정의 CA를 허용하기 위해 기본 신뢰 저장소를 조작하는 경우 보안 문제가 될 수 있습니다.
Windows 인증서는 비슷한 방식으로 작동합니다. 기본값은 현재 사용자의 개인 저장소를 표시하는 것입니다. 새로운 개인 키 또는 신뢰할 수 있는 인증서는 현재 사용자에게만 영향을 주지만 시스템은 여전히 Windows와 함께 제공된 기본값을 갖습니다(그리고 모든 업데이트는 새 CA 또는 신뢰할 수 없는 인증서와 같은 기본값을 변경합니다).
사용자가 수행하는 작업은 동일한 시스템의 다른 사용자에게 영향을 주어서는 안 됩니다.
JRE와 JDK의 경우 첫 번째는 환경 running(즉, 애플리케이션의 표준 사용)을 위한 것이고, 후자는 환경을 위한 것이며 development요구 사항이 다릅니다. 애플리케이션 서버는 이와 *.jsp같은 페이지를 즉시 "컴파일"해야 하므로 JDK가 필요합니다. JDK에는 자체 JRE가 포함되어 있으므로 JRE가 작동하는 데 필요한 모든 것에 대한 자체 복사본이 있습니다. 서버와는 다르게 클라이언트(사용자)에 대한 지원을 제공해야 할 수 있으므로(예: JRE와 JDK가 서로 다른 버전을 사용할 수 있음) 공통 부분을 공유하면 방해가 될 수 있습니다.
입력한 동일한 명령 으로 키 저장소(이름 및 위치)를 변경할 수 있지만 -keystore file.jksJava가 동일한 키 저장소를 사용하려면 다른 명령이나 구성에서 동일한 파일을 참조해야 합니다. 별칭 이름을 지정했으므로 tomcat이를 애플리케이션 서버의 키 저장소로 사용할 것이라고 가정하므로 server.xml(또는 catalina.xml) 파일에서 키 저장소 위치를 구성해야 합니다.
/etc/ssl/서버의 키 저장소는 등과 같이 제한된 액세스(서버를 실행하는 사용자만 읽을 수 있음)가 있는 디렉터리에 있어야 합니다 .
파일 자체의 내용에 대해서는 서명이 필요하므로 먼저 자체 서명된 키 쌍을 생성한 다음(원하는 대로) CSR(인증서 서명 요청)을 생성하여 CA에 보냅니다. 그런 다음 전체 체인(새로 서명된 인증서와 CA의 인증서 체인)을 동일한 키 저장소의 동일한 별칭으로 가져와야 합니다. 이는 여전히 키 저장소의 단일 항목이지만 해당 별칭 아래에 여러 인증서(및 개인 키)가 있습니다.
서버가 다른 서버에 연결할 필요가 없다면 해당 키 저장소에는 다른 인증서가 포함되어서는 안 됩니다. 그리고 필요한 경우에도 별도의 신뢰 저장소(cacerts 파일과 마찬가지로 CA가 포함된 두 번째 키 저장소)가 있어야 합니다(또는 JRE의 기본 신뢰 저장소에 의존하거나 CA를 포함해야 함). 동일한 키스토어).