상호 인증 구성

  • 릴리스 버전: Xanadu
  • 업데이트 날짜 2024년 08월 01일
  • 읽기4분

    • 상호 인증은 SSL(Secure Sockets Layer) 인증서를 교환하여 신뢰를 설정합니다.

    SSL 핸드쉐이크 중에 서버는 해당 인증서를 클라이언트에 제공합니다. 그런 다음 서버 구성에 따라 클라이언트에서 인증서를 요청할 수 있습니다. 서버와 클라이언트 모두 인증서 유효성 검사 절차를 수행하여 제공된 인증서의 신뢰성과 무결성을 보장합니다.

    유효성 검사에 성공하면 HTTPS 연결을 시작하기 전에 승인이 교환됩니다.

    관리자는 인증 요청이 이행되기 전에 클라이언트 키 저장소를 설정하고 인증서를 생성하는 예비 작업을 수행합니다.

    경고:
    이 기능은 아웃바운드 https 연결에서만 상호 인증을 활성화합니다.

    키 스토어 생성

    인스턴스는 현재 개인 키와 공용 인증서 쌍을 포함하는 Java 키 스토어 파일 업로드를 지원하며, 공용 인증서에는 루트 인증서를 포함한 전체 체인이 포함됩니다.

    클라이언트 키 스토어를 설정하려면 다음을 수행합니다.

    • 신뢰할 수 있는 CA(인증 기관)에서 서명한 인증서가 필요합니다.
    • API 엔드포인트 공급자가 키 스토어를 생성하는 데 도움을 줄 수 있습니다.

    키 스토어를 생성해야 하는 경우 프로세스에는 명령줄 인터페이스 명령을 사용하여 새 키 스토어 파일을 생성하고, CSR(인증서 서명 요청)을 생성하고, 서명된 인증서를 가져오는 여러 단계가 포함됩니다. 도메인의 기본 인증서를 임포트하기 전에 루트 또는 중간 인증서를 먼저 임포트해야 합니다. 다음은 단계별 지침입니다.

    1. Java 키 스토어와 키 페어를 생성합니다.
      keytool -genkey -alias mydomain -keyalg RSA -keystore my.keystore
    2. 기존 Java 키 스토어에 대한 CSR을 생성합니다.
      keytool -certreq -alias mydomain -keystore my.keystore -file mydomain.csr
    3. CSR을 CA 서명 기관에 보내 서명된 인증서와 함께 중간 및 루트 인증서를 포함하는 인증서 파일에 서명하고 반환합니다.
    4. 루트 또는 중간 인증 기관 CA 인증서를 기존 Java 키 스토어로 임포트합니다.
      keytool -import -trustcacerts -alias root -file Thawte.crt -keystore my.keystore
      주:
      모든 인증서를 하나의 파일로 묶고 가져올 수 있습니다. 이것이 바람직한 옵션입니다. 이렇게하면 5를 건너 뛸 수 있습니다.
      keytool -import -alias mydomain -file merged.crt -keystore my.keystore
    5. 서명된 기본 인증서를 기존 Java 키 스토어로 임포트합니다.
      keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore my.keystore

    키 스토어 설정

    이제 키 스토어가 생성되었으므로 인증서 테이블에 업로드할 수 있습니다. 대상 시스템 정의 > 인증서 페이지에서 새로 만들기 를 클릭하고 다음 필드를 설정합니다.
    • 인증서 이름을 입력합니다.
    • 키 스토어를 활성으로 저장합니다.
    • 유형 = Java 키 저장소를 설정하십시오.
    • 키 스토어 암호를 제공합니다. 키 저장소를 만드는 데 사용된 암호입니다.
    제출을 클릭하여 Java 키 스토어 항목을 작성합니다.
    그림 1. 키 스토어

    신뢰할 수 있는 서버 인증서 지정

    HTTPS 웹 서비스 호출인 아웃바운드 SSL 연결 중에 SSL 연결 중에 서비스 공급자의 유효성을 보장하는 서비스 공급자가 제공하는 인증서를 지정할 수 있습니다. 예를 들어 인증서로 자신을 식별하는 보안 서비스에 연결하려고 시도하는 브라우저가 있습니다.

    신뢰할 수 있는 서버 인증서를 업로드하면 ServiceNow 연결 중인 서비스가 유효하고 안전한지 확인할 수 있습니다.

    "믿을 수 있는 스토어 인증서" 유형의 새 인증서 항목을 만들고 DER 형식의 인증서를 첨부하거나 PEM 형식을 복사하여 PEM 인증서 필드에 붙여넣습니다.

    프로토콜 프로파일

    그림 2. 인증서 교환
    • 클라이언트가 인증을 위해 서버 인증서를 요청하면 인증서 서명 요청(CSR)이 생성됩니다.
    • CSR에 응답하기 위해 서버는 두 개의 고유한 암호화 키, 즉 서버에 대한 메시지를 암호화하는 데 사용되는 공개 키와 메시지를 해독하는 데 사용되는 개인 키를 생성합니다. 두 키 모두 키 스토어에 보관됩니다.
    • 키는 서버에서 읽을 수 있도록 클라이언트 보안 메시지의 암호를 해독하는 데 사용됩니다. HTTPS가 될 모든 발신 연결은 키 스토어를 확인하여 인증을 확인하고, 공용 인증서를 제공하고, 신뢰 스토어 인증서를 사용하여 상호 신뢰를 다시 확인합니다.
    • 클라이언트와 서버 간의 보안 링크를 완료하기 위해 서버는 인증서를 해당 개인 키와 일치시킵니다. 서버만 개인 키에 액세스할 수 있기 때문에 서버는 클라이언트의 데이터를 해독할 수 있습니다.
    다음은 포트 443에서 com.glide.certificates.DBKeyStoreSocketFactory 소켓 팩토리에 MYHTTPS를 등록하는 명령의 예입니다. 데이터베이스 키 저장소 팩토리는 SSL 교환 프로세스 중에 상호 인증을 위한 클라이언트 인증서를 제공하는 데 사용됩니다.
    glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory"
glide.httpclient.protocol.myhttps.port = "443"
    위의 구성은 SSL 중에 사용자 지정 소켓 팩터리를 사용하고 인증서를 교환하는 아웃바운드 myhttps://host.domain.com/target URL에 영향을 줍니다.
    주:
    기본 HTTPS 프로토콜 소켓 팩토리를 재정의하면 모든 아웃바운드 HTTPS 연결에 영향을 줍니다. 이는 일반적으로 바람직하지 않습니다.

    서버는 인증서를 전송하여 응답합니다. 클라이언트가 수락하는 인증서입니까? 그렇다면 인증서를 수락하는 서버로 메시지가 전송되고 보안 채널이 시작됩니다. 인증서가 수락되지 않으면 인증에 루트 기관이 필요함을 의미할 수 있습니다.