상호 인증 구성

  • 릴리스 버전: Yokohama
  • 업데이트 날짜 2025년 01월 30일
  • 읽기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 연결에 영향을 줍니다. 이것은 일반적으로 바람직하지 않습니다.

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