Skip to main content
OnCommand Insight
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

SSL 인증서를 가져오는 중입니다

기여자
PDF

SSL 인증서를 추가하여 OnCommand Insight 환경의 보안을 강화하기 위한 향상된 인증 및 암호화를 활성화할 수 있습니다.

시작하기 전에

시스템이 최소 필수 비트 수준(1024비트)을 충족하는지 확인해야 합니다.

이 작업에 대해

참고

업그레이드하기 전에 볼트를 백업하는 것이 좋습니다.

"SecurityAdmin 도구"볼트 및 암호 관리에 대한 자세한 내용은 지침을 참조하십시오.

단계

  1. 원본 키 저장소 파일의 복사본을 만듭니다. cp c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore "c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore.old

  2. 키 저장소의 내용을 나열합니다. C:\Program Files\SANscreen\java64\bin\keytool.exe -list -v -keystore "c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore"

    키 저장소의 내용이 표시됩니다. 키 저장소에 인증서가 하나 이상 있어야 합니다. "ssl certificate".

  3. 를 삭제합니다 "ssl certificate": keytool -delete -alias "ssl certificate" -keystore c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore

  4. 새 키 생성: C:\Program Files\SANscreen\java64\bin\keytool.exe -genkey -alias "ssl certificate" -keyalg RSA -keysize 2048 -validity 365 -keystore "c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore"

    1. 성과 이름을 묻는 메시지가 나타나면 사용하려는 FQDN(정규화된 도메인 이름)을 입력합니다.

    2. 조직 및 조직 구조에 대한 다음 정보를 제공합니다.

      • 국가: 해당 국가의 두 글자 ISO 약어(예: US)

      • 시/도: 조직의 본사 소재지가 위치한 시/도의 이름(예: 매사추세츠주)

      • 지역: 조직의 본사 소재지(예: Waltham)의 이름입니다.

      • 조직 이름: 도메인 이름을 소유한 조직의 이름(예: NetApp)

      • 조직 단위 이름: 인증서를 사용할 부서 또는 그룹의 이름(예: 지원)

      • 도메인 이름/일반 이름: 서버의 DNS 조회에 사용되는 FQDN(예: www.example.com) 시스템이 다음과 유사한 정보로 응답합니다. Is CN=www.example.com, OU=support, O=NetApp, L=Waltham, ST=MA, C=US correct?

    3. 를 입력합니다 Yes CN(Common Name)이 FQDN과 같은 경우

    4. 키 암호를 묻는 메시지가 나타나면 암호를 입력하거나 Enter 키를 눌러 기존 키 저장소 암호를 사용합니다.

  5. 인증서 요청 파일 생성: C:\Program Files\SANscreen\java64\bin\keytool.exe -certreq -alias "ssl certificate" -keystore "c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore" -file c:\localhost.csr

    를 클릭합니다 c:\localhost.csr file 은 새로 생성된 인증서 요청 파일입니다.

  6. 를 제출합니다 c:\localhost.csr 승인을 위해 CA(인증 기관)에 파일을 저장합니다.

    인증서 요청 파일이 승인되면 에서 인증서를 반환하도록 합니다 .der 형식. 파일이 로 반환될 수도 있고 반환되지 않을 수도 있습니다 .der 파일. 기본 파일 형식은 입니다 .cer Microsoft CA 서비스의 경우.

    대부분의 조직의 CA는 루트 CA를 포함하여 신뢰할 수 있는 모델 체인을 사용합니다. 이 모델은 대개 오프라인 상태입니다. 이 인증서는 중간 CA라고 하는 몇 개의 하위 CA에 대해서만 인증서에 서명했습니다.

    전체 신뢰 체인에 대한 공개 키(인증서)를 얻어야 합니다. 즉, OnCommand Insight 서버의 인증서에 서명한 CA의 인증서와 조직 루트 CA에 등록하는 CA 간의 모든 인증서를 얻어야 합니다.

    일부 조직에서는 서명 요청을 제출할 때 다음 중 하나를 받을 수 있습니다.

    • 서명된 인증서와 신뢰 체인에서 모든 공개 인증서가 들어 있는 PKCS12 파일입니다

    • A .zip 개별 파일(서명된 인증서 포함)과 신뢰 체인에서 모든 공용 인증서를 포함하는 파일입니다

    • 서명된 인증서만

      공용 인증서를 얻어야 합니다.

  7. server.keystore에 대해 승인된 인증서를 가져옵니다. C:\Program Files\SANscreen\java64\bin\keytool.exe -importcert -alias OCI.hostname.com -file c:\localhost2.DER -keystore "c:\Program Files\SANscreen\wildfly\standalone\configuration\server.keystore"

    1. 메시지가 표시되면 키 저장소 암호를 입력합니다.

      다음 메시지가 표시됩니다. Certificate reply was installed in keystore

  8. 서버에 대해 승인된 인증서를 가져옵니다. trustore: C:\Program Files\SANscreen\java64\bin\keytool.exe -importcert -alias OCI.hostname.com -file c:\localhost2.DER -keystore "c:\Program Files\SANscreen\wildfly\standalone\configuration\server.trustore"

    1. 메시지가 표시되면 Trustore 암호를 입력합니다.

      다음 메시지가 표시됩니다. Certificate reply was installed in trustore

  9. 를 편집합니다 SANscreen\wildfly\standalone\configuration\standalone-full.xml 파일:

    다음 별칭 문자열을 대체합니다. alias="cbc-oci-02.muccbc.hq.netapp.com". 예를 들면 다음과 같습니다.

    <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="${VAULT::HttpsRealm::keystore_password::1}" alias="cbc-oci-02.muccbc.hq.netapp.com" key-password="${VAULT::HttpsRealm::key_password::1}"/>

  10. SANscreen 서버 서비스를 다시 시작합니다.

    Insight가 실행되면 자물쇠 아이콘을 클릭하여 시스템에 설치된 인증서를 볼 수 있습니다.

    "발급자" 정보와 일치하는 "발급 대상" 정보가 포함된 인증서가 표시되는 경우 자체 서명된 인증서가 설치되어 있는 것입니다. Insight 설치 관리자가 생성한 자체 서명 인증서의 만료 기간은 100년입니다.

    NetApp은 이 절차로 디지털 인증서 경고가 제거된다고 보장할 수 없습니다. NetApp은 최종 사용자 워크스테이션의 구성 방법을 제어할 수 없습니다. 다음과 같은 시나리오를 고려해 보십시오.

    • Microsoft Internet Explorer와 Google Chrome 모두 Windows에서 Microsoft의 기본 인증서 기능을 사용합니다.

      즉, Active Directory 관리자가 조직의 CA 인증서를 최종 사용자의 인증서 트뤼스토어로 푸시하면 OnCommand Insight 자체 서명된 인증서가 내부 CA 인프라에서 서명한 인증서로 교체되면 이러한 브라우저의 사용자에게 인증서 경고가 사라집니다.

    • Java 및 Mozilla Firefox에는 자체 인증서 저장소가 있습니다.

      시스템 관리자가 CA 인증서를 이러한 응용 프로그램의 신뢰할 수 있는 인증서 저장소에 자동으로 수집하지 않는 경우 자체 서명된 인증서가 교체되더라도 신뢰할 수 없는 인증서로 인해 Firefox 브라우저를 사용하면 인증서 경고가 계속 생성될 수 있습니다. 조직의 인증서 체인을 Trustore에 설치하는 것도 추가 요구 사항입니다.