KR102025960B1

KR102025960B1 - 서버 네임 표시를 이용하지 않는 암시적 ssl 인증서 관리 기법

Info

Publication number: KR102025960B1
Application number: KR1020147020979A
Authority: KR
Inventors: 원석 유; 억 김; 제니 로랜스; 디 마르코 아니엘로 스코토; 야미니 자가디산; 웨이드 힐모
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2012-01-27
Filing date: 2013-01-21
Publication date: 2019-09-26
Also published as: CN104094554A; EP2807789A1; JP6058699B2; EP2807789A4; JP2015513810A; WO2013112389A1; EP2807789B1; US8738902B2; KR20140117449A; US20130198511A1; CN104094554B

Abstract

실시예는 IP 어드레스 및 포트만이 SSL 헬로우 연결에 존재하는 경우에 IP:포트-호스트네임 테이블을 사용하여 호스트네임을 식별하는 역 검색을 개시하며, 이는 예를 들여 SNI 비가용 클라이언트가 SSL 헬로우를 개시하는 경우에 이루질 수 있다. 호스트 네임이 성공적으로 검색되면, 네이밍 규칙이 사용되어 SSL 인증서의 관리 및 식별을 단순하게 한다. 서로 다른 타입의 SSL 인증서가 지원된다. 복수의 호스트네임 매치가 IP:포트-호스트네임 테이블에서 지정된 IP 어드레스 및 포트와 연관될 수 있다. 이러한 경우에 첫번째로 일치하는 호스트네임이 항상 네이밍 규칙와 함께 사용되어 관련된 SSL 인증서를 식별한다. 네이밍 규칙은 가장 일치하는 파일명을 먼저 검색하고 가장 덜 일치하는 파일명으로 진행하는 방식으로 적용된다.

Description

서버 네임 표시를 이용하지 않는 암시적 SSL 인증서 관리 기법{IMPLICIT SSL CERTIFICATE MANAGEMENT WITHOUT SERVER NAME INDICATION (SNI)}

SSL(Secure Sockets Layers)/ TLS(Transport Layer Security)는 주로 인터넷과 같은 비보안 네트워크를 통해 송신되는 비밀 데이터를 암호화하는 데 사용된다. HTTPS 프로토콜에서, 암호화된 데이터 타입은 URL, HTTP 헤더, 쿠키 및 폼(forms)을 통해 제출되는 데이터를 포함한다. SSL/TLS로 보안화되는 웹 페이지는 "https://"로 시작하는 URL을 가진다. SSL/TLS 보안 프로토콜은 애플리케이션 프로토콜 레이어 및 TCP/IP 레이어 사이에서 계층화되고, 이는 애플리케이션 데이터를 보안화한 후 전송 레이어에서 송신할 수 있다.

시퀀스화된 일련의 메시지를 포함하는 SSL/TLS 핸드세이크 프로토콜(SSL/TLS handshake protocol)은 데이터 전송 세션의 보안 파라미터를 협상(negotiate)하는 데 사용된다. SSL/TLS 핸드세이크는 웹 서버에 송신되는 초기 클라이언트 헬로우(Client Hello) 메시지로 시작한다. 클라이언트 헬로우 메시지는 버전 번호, 랜덤 생성 데이터, 세션 식별자, 클라이언트에서 이용가능한 사이퍼 수트(cipher suite, 암호화 방식)의 리스트 및 요청된 압축 알고리즘(requested compression algorithm)을 포함한다. SNI(Server Name Indication)는 TLS 확장에 의해 제공되며, 이는 클라이언트로 하여금 클라이언트 헬로우 메시지에서 이들이 접촉하고 있는 서버의 명칭을 제공하도록 한다. 호스트네임은 서버의 전체(fully qualified) DNS 호스트네임을 포함한다. 이러한 기능은 예를 들면, 단일한 기본 네트워크 어드레스(single underlying network address)에서 복수의 가상 서버를 호스트하는 서버에 대한 보안 연결을 용이하게 하는 데 바람직하다.

서버는 서버 헬로우 메시지를 포함하는 클라이언트 헬로우 메시지에 응답한다. 서버 헬로우 메시지는 버전 번호, 랜덤 생성 데이터, 세션 식별자, 새로운 또는 재개된(resumed) 세션 ID를 포함한다. 클라이언트가 세션이 재개되었다고 나타내지 않으면, 새로운 ID가 생성된다. 또한, 클라이언트가 세션이 재개되었다고 나타내나 서버가 그 세션을 재개할 수 없거나 재개하려고 하지 않는 경우에 새로운 세션 ID가 생성된다. 또한, 후자의 경우에는 새로운 세션 ID, 클라이언트와 서버 모두에 의해 지원되는 사이퍼 수트 및 압축 알고리즘을 생성한다. 사용하려는 압축 알고리즘(현재 지원되지 않음)을 특정한다.

또한, 서버는 자신의 SSL 인증서를 클라이언트에게 송신하는데, 이는 서버를 인증하고 프리마스터 시크릿(premaster secret)을 암호화하는 데 사용될 수 있는 서버의 공개 키를 포함한다. 클라이언트는 인증서에서 서버의 명칭을 확인하여 서버의 명칭이 연결하는 데 사용되는 클라이언트의 명칭과 일치하는지를 검증한다. 사용자가 www.contoso.com을 브라우저에 URL로서 입력한 경우에, 인증서는 www.contoso.com 또는 *.contoso.com의 서브젝트 명칭(subject name)을 포함한다. 이러한 명칭이 일치하지 않으면 브라우저가 사용자에게 경고할 것이고 서버는 신뢰성이 없다고 표시한다. 데이터를 암호화할 수 있는 것에 더하여, SSL/TLS는 또한 URL 내의 도메인 네임이 서버로부터 반환된 인증서의 서브젝트 명칭과 일치하는 것을 보증함으로써 클라이언트가 의도한 서버와 실제로 통신하고 있다는 것을 보증한다.

이후에 서버는 서버가 종료(finish)된다고 나타내며 클라이언트로부터의 응답을 기다리는 서버 헬로우 던(Server Hello Done) 메시지를 송신한다. 추가 메시지는 키 변경 및 SSL/TLS 핸드세이크를 검증하고 완료하는 데 사용된다.

일반적으로, 와일드카드 SSL 인증서 또는 복수의 서브젝트 명칭을 포함하는 SSL 인증서는 예외로 하고, SSL 인증서가 사이트의 도메인 네임에 대한 서브젝트와 일치하는 특정한 사이트에 대해 발행된다. 각각의 웹사이트가 자신의 고유한 SSL 인증서를 필요로 하기 때문에 이는 규모(scale)의 문제를 발생시킨다. 따라서, 수백만 개의 보안 웹사이트가 존재하는 경우에 수백만 개의 SSL 인증서가 요구된다. 복수의 웹사이트에 대해 책임이 있는 서버 관리자(administrators)가 모든 웹사이트에 대한 SSL 인증서를 관리하는 것은 매우 부담스러운 문제일 수 있다. SSL 인증서의 관리는 고 밀도 호스팅 또는 클라우드 서비스(high-density hosting or cloud service)를 지원하는 관리자에게 특히 어려울 있다. 추가로, SSL 인증서가 매년 기간이 만료하기 때문에, SSL 인증서의 지속적인 관리 및 일대일 인증서/웹사이트 연관성(associations)의 관리는 지속적이고 시각 소모적인 작업이다.

서버 관리자는 서버 상의 모든 웹사이트에 대한 인증서를 관리해야 한다. 전통적으로, 클라이언트가 SSL/TLS로 서버에 연결하는 경우에, 이는 IP:Port를 가진 네트워크 엔드 포인트만을 식별할 수 있다. 따라서, 모든 호스트 웹사이트에 대한 인증서를 관리하는 것에 추가하여, 각각의 사이트가 표준 SSL 포트(443)를 유지하기를 원하기 때문에 관리자는 각각의 웹사이트에 대해 대응하는 IP 어드레스를 생성해야한다. 이는 수백만 개의 웹 사이트를 호스트하는 관리자에게 규모의 문제를 일으키며, 이에 따라 수백만 개의 인증서 및 IP 어드레스를 관리해야 한다.

TLS의 확장에 의해, SNI는 이제 SSL 헬로우를 이용하여 도메인 네임(이는 때로는 가상 도메인 네임이라고 불림)을 송신할 수 있다. 도메인 네임에서, 네트워크 엔드포인트는 이제 모두 세 개의 정보 조각 즉, IP 어드레스, 포트 및 도메인 네임을 사용하여 고유하게 식별될 수 있다. 이는 동일한 IP 어드레스 및 포트가 일정하게 유지될 수 있기 때문에 관리자가 수백만 개의 IP 어드레스를 생성할 필요성을 없애며, 동시에 수백만 개의 고유한 도메인 네임이 웹 사이트를 차별화하는 데 사용될 있다. 그러나, 관리자는 여전히 수백만 개의 인증서를 생성하고 관리해야 하고, 수백만 개의 사이트 및 수백만 개의 인증서 사이의 일대일 연관성을 관리해야 한다.

SNI를 사용하는 경우에, 사이트에 대응하는 SSL 인증서가 네이밍 계약(naming contract)을 사용하여 포함될 수 있다. 예를 들어, SNI 가용 클라이언트(SNI-capable client)로부터의 SSL 핸드세이크는 특정한 도메인 네임으로 연결하려고 시도하고 있다는 것을 나타낸다. 그러한 하나의 시스템에서, 네이밍 계약은 SSL 인증서가 <virtual domain name>.pfx로 명명되어야 한다고 나타낸다. 예를 들어, www.contoso.com과 같은 도메인에 대해, 웹 서비스는 사이트에 대응하는 SSL 인증서의 명칭으로서 "www.contoso.com.pfx"를 사용할 수 있다. 이러한 ".pfx" 네이밍 규칙(naming convention)을 사용하는 시스템이 미국 특허 출원 제13/069,032호(제목 "Central and Implicit Certificate Management", 2011년 3월 22일 출원)에 설명되어 있으며, 이 출원의 개시내용은 전체적으로 본 명세서에 참조로서 포함된다.

이러한 네이밍 규칙은 시간 소모적인, 명시적인 일대일 매핑을 유지할 필요가 없게 하나, SSL 클라이언트 헬로우 시에 도메인 네임의 이용가능성에 강하게 의존하며, SNI 가용 클라이언트에 의해서만 제공된다. 모든 클라이언트에 걸친 SNI의 채택은 2011년 9월 현재 약 65%에서 75% 정도이고, 이는 모든 클라이언트 중 25% 내지 35%가 SNI 비가용(not SNI-capable) 상태를 유지하고 있다는 것이다. 결과적으로, SNI에 강한 의존성을 갖는 네이밍 규칙 단독으로는 일반적 소비(general consumption)를 대비하지 못한다.

본 요약은 이하의 발명을 실시하기 위한 구체적인 내용에서 더 기술될 개념을 선택하여 단순화된 형식으로 소개하기 위해 제공된다. 본 요약은 특허청구범위에 기재된 발명의 대상의 주요 특징 또는 핵심 특징을 밝히고자 하는 것이 아니며, 특허청구범위의 발명의 대상의 범위를 결정하는 것을 보조하는 데 사용하려는 것도 아니다.

실시예는 SSL 인증서의 관리를 간단하게 하는 네이밍 규칙을 사용하도록 SNI에 대한 강한 의존성을 감소시키고, 이에 따라 SNI 가용 및 SNI 비가용 브라우저 모두가 지원된다. 또한, 시스템은 서로 다른 타입의 SSL 인증서(예를 들면, 하나의 서브젝트 명칭을 가진 인증서, 스타 서브 도메인을 포함하는 하나의 서브젝트 명칭을 가진 인증서("와일드카드 인증서"라고 알려짐) 및 복수의 서브젝트 명칭을 가진 인증서)를 지원한다.

실시예는 IP:포트-호스트네임 역 검색 기능(IP:Port-to-hostname reverse lookup capability)을 제공한다. IP:포트-호스트네임 테이블이 웹 서버 내의 구성 옵션에 기초하여 생성된다. 테이블은 IP 어드레스/포트 번호 쌍을 하나 이상의 호스트네임과 연관시킨다. 이러한 테이블을 사용하여, SNI 비가용 클라이언트가 SSL 헬로우를 개시하는 경우에서와 같이, 웹 서버가 SSL 헬로우 연결에서의 IP 어드레스 및 포트만을 이용하여 호스트네임을 "역 검색"할 수 있다.

호스트 네임이 성공적으로 검색되면, 동일한 네이밍 규칙이 사용되어 SSL 인증서의 관리를 간단하게 한다. SSL 인증서와 사이트 간의 네이밍 규칙은 SNI에 대해 더 이상 강한 의존성을 갖지 않는다.

또한, 실시예는 상이한 타입의 SSL 인증서를 지원한다. 서버는 역 검색을 수행하고, 지정된 IP 어드레스/포트 번호와 일치하는 복수의 호스트네임이 존재할 수 있다. 이러한 경우에, 서버는 항상 첫번째로 일치하는 호스트네임(first matching hostname)을 사용할 것이고 네이밍 규칙을 연관된 SSL 인증서에 대한 검색에 적용한다. 웹 서버가 항상 첫번째로 일치하는 호스트네임을 사용할 수 있기 때문에, 서버는 사본(duplicates)이 존재하는지 알아보기 위해 전체적인 IP: 포트-호스트네임 테이블을 스캔할 필요가 없으며, 스캔은 첫번째 일치(first match)를 찾으면 종료될 것이다.

서버가 먼저 가장 많이 일치하는 파일명에서 가장 적게 일치하는 파일명으로 검색하는 방식으로 네이밍 규칙을 적용하기 때문에, 이러한 실시예는 모든 세 개의 타입의 SSL 인증서를 만족한다. 더 구체적으로, 서버는 먼저 "www.<hostnane>.pfx"의 파일명을 가진 대응하는 인증서를 검색하려고 할 것이다. 그러한 파일이 존재하지 않으면, 서버는 덜 일치하는 파일명 "_.<hostnane>.pfx"(여기서, 밑줄표시 문자 "_"는 "와일드카드 인증서" 내의 와일드카드를 의미함)을 자동으로 재시도할 것이다. 본 명세서의 예에서 사용되는, 밑줄표시 "_"는 네이밍 계약의 특정한 예이다. 그러나, 네이밍 규칙에 의해 임의의 문자가 와일드카드로서 정의될 수 있다는 것을 이해할 수 있을 것이다. 또한, 네이밍 규칙은 복수의 서브젝트 명칭을 포함하는 인증서에 대해, SSL 인증서 파일 자체가 동일하더라도, 서브젝트 명칭이 존재하는 만큼 많은 파일이 존재해야할 필요성이 있다는 것을 나타낸다.

전술한 구성에 기초하여, 웹 서버는 IP:포트-호스트네임 테이블을 성공적으로 생성할 수 있고, 또한 "역 검색"이 항상 첫번째로 일치하는 호스트에 의존하는 경우에도, SSL 동작(behavior)의 정확성을 성공적으로 유지하기 위해 SSL 인증서의 특정한 동작을 이용할 수 있다.

본 발명의 실시예의 전술한 및 다른 효과 및 특징을 더 명확히 하기 위해, 본 발명의 실시예에 대한 보다 구체적인 설명이 첨부된 도면을 참조하여 제공될 것이다. 이러한 도면은 본 발명의 단지 전형적인 실시예를 나타내며 이에 따라 발명의 범주를 제한하려는 것이 아니라는 것을 이해할 것이다. 본 발명은 첨부된 도면을 사용하여 추가적인 특징 및 세부사항과 함께 기술되고 설명될 것이다.
도 1은 일 실시예에 따라 SNI 가용 브라우저 및 SNI 비가용 브라우저 모두를 지원하는 시스템의 블록도이다.
도 2은 일 실시예에 따라 단일 명칭 SSL 인증서 또는 복수의 서브젝트 명칭을 가진 SSL 인증서를 포함하는 웹 서버와 통신하는 SNI 비가용 브라우저를 지원하는 시스템을 나타내는 블록도이다.
도 3은 일 실시예에 따라 와일드카드 SSL 인증서를 가진 웹 서버와 통신하는 SNI 비가용 브라우저를 지원하는 시스템을 나타내는 블록도이다.
도 4는 웹 서버 상의 SSL 인증서를 식별하는 방법 또는 프로세스의 흐름도이다.
도 5는 일 실시예에 따라 웹 서버 상의 SSL 인증서 파일 스토어에 복수의 서브젝트 명칭을 가지는 SSL 인증서 또는 단일 명칭 SSL 인증서를 저장하는 방법 또는 프로세스의 흐름도이다.
도 6은 일 실시예에 따라 웹 서버 상에 SSL 인증서 파일 스토어에 와일드카드 SSL 인증서를 저장하는 방법 또는 프로세서의 흐름도이다.
도 7은 도 1 내지 6의 예가 구현될 수 있는 적합한 컴퓨팅 및 네트워킹 환경의 예를 나타낸다.

SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 프로토콜이 브라우저 클라이언트와 웹 서버 사이의 인터넷을 통한 통신에 대한 보안성을 제공하기 위해 사용된다. SNI(Server Name Indication)는 TLS 프로토콜을 확장하여 브라우저가 도달하려고 하는 호스트네임을 나타낸다. SNI는 서버로 하여금 동일한 IP 어드레스 및 포트 번호에 대해 복수의 SSL 인증서를 사용하는 것을 가능하게 하고, 이는 복수의 보안 웹사이트가 동일한 IP 어드레스 및 포트에 의해 제공되게 한다(즉, https://). 일부 구식 브라우저 및 서버는 SNI를 지원하지 않는다.

세 개의 상이한 타입의 SSL 인증서(즉, 하나의 서브젝트 명칭을 가진 인증서, 스타 서브 도메인을 포함하는 하나의 서브젝트 명칭을 가진 인증서("와일드카드 인증서"로 알려짐) 및 복수의 서브젝트 명칭을 가진 인증서)가 존재한다. 본 명세서에 설명된 시스템 및 방법의 실시예는 세 가지 타입의 SSL 인증서 모두를 지원한다.

브라우저 클라이언트가 웹 사이트에 액세스를 시도하는 경우에, 서버는 브라우저로부터 SSL 헬로우 연결의 호스트네임을 검색한다. SNI 가용 브라우저는 연결을 설정하는 경우에, 호스트네임을 포함할 것이다. SNI 비가용 브라우저는 SSL 헬로우 연결을 개시하는 경우에는, 호스트 네임이 아니라, IP 어드레스 및 포트 번호가 SSL 헬로우 연결에 제공된다.

일 실시예에서, 웹 서버는 IP 어드레스 및 포트 번호를 호스트네임과 관련시키는 IP:포트-호스트네임 테이블을 생성한다. 호스트네임이 식별되면, 네이밍 규칙이 호스트네임에 적용되어 대응하는 SSL 인증서를 식별시킬 수 있다. 이러한 테이블을 사용하여, 웹 서버가 IP 어드레스 및 포트 번호의 역 검색을 수행하여 적합한 호스트네임을 찾을 수 있다. IP:포트-호스트네임 테이블로부터의 호스트네임을 사용하여, 웹 서버는 적합한 SSL 인증서를 검색할 수 있다.

웹 서버는 서버로 하여금 각각의 호스트네임에 대한 적합한 인증서를 찾게 하는 SSL 인증서에 대한 특정한 네이밍 규칙을 사용한다. 일 실시예에서, 확장자 "PFX"는 저장된 인증서 파일을 명명하기 위해 SSL 인증서의 호스트네임(들)에 추가된다. 예를 들어, SSL 인증서는 "<hostname>.pfx"로 명명되고 로컬 캐시 내의 웹 서버에 저장되거나 중앙 인증서 스토어나 파일 서버에 저장된다. 네이밍 규칙은 SSL 인증서의 관리를 간단하게 하는 데 사용된다. 네이밍 규칙은 서버로 하여금 호스트 네임에 기초하여 대응하는 SSL 인증서를 유추하게 하고, 이는 사이트와 SSL 인증서 사이의 명시적인 1 대 1 매핑의 관리(management)를 제거한다. 본 명세서의 예에서 "PFX"의 확장자가 사용되더라도, 임의의 다른 확장자도 SSL 인증서를 명명하는 데 사용될 수 있다는 것을 이해할 수 있을 것이다. 웹 서버는 적합한 확장자를 추가함으로써 변경된 호스트네임을 사용하여 SSL 인증서를 검색할 수 있다.

웹 서버의 실시예는 다른 타입의 SSL 인증서 전부를 지원한다. 서버가 IP:포트-호스트네임 테이블을 수행하는 경우에, 지정된 IP 어드레스 및 포트에 일치하는 복수의 호스트네임이 존재할 수 있다. 예를 들어, 이는 웹 서버가 동일한 IP 어드레스 및 포트에서 복수의 웹 페이지를 호스팅하는 경우에 발생할 수 있다. 복수의 호스트네임이 IP 어드레스 및 포트와 일치하는 경우에, 서버는 항상 첫번째로 일치하는 호스트네임을 사용할 것이고 네이밍 규칙(즉, "PFX" 확장자를 추가하는 것)을 그 호스트네임에 적용할 것이다. 이 실시예에서 웹 서버가 항상 첫번째로 일치하는 호스트네임을 사용할 수 있기 때문에, 실제로 서버는 사본이 존재하는지를 알아보기 위해 전체 IP:포트-호스트네임 테이블을 스캔할 필요가 없다. 대신에, 웹 서버는 첫번째의 IP:포트-호스트네임 일치(match)를 찾으면 테이블로부터 빠져나올 것이다.

IP:포트-호스트네임 테이블의 사용은 세 개의 타입의 SSL 인증서 모두를 이용하여 작업한다. 예를 들어, 복수의 서브 도메인을 포함하는 사이트에 대한 다음의 바인딩(IP/Port/Hostname)이 존재할 수 있다.

이러한 서브 도메인을 호스팅하는 웹사이트는 SSL 와일드카드 인증서를 사용할 수 있다. 이 경우에 와일드카드 인증서는 *.contoso.com에 관한 것이다. 네이밍 규칙을 사용하여 이러한 와일드카드 인증서가 "_.contoso.com.pfx"라는 명칭을 사용하여 저장될 것이며, 여기서 "PFX" 확장자가 호스트네임에 추가되었고 "_"는 와일드카드 인증서에서 스타 ("*")를 나타낸다.

웹 서버는 이러한 바인딩에 대해 다음의 IP:포트-호스트네임 테이블을 생성한다.

복수의 도메인을 가지는 사이트는 다음의 바인딩(IP/Port/Hostname)을 가질 수 있다.

이러한 복수의 도메인을 호스팅하는 웹사이트는 복수의 도메인을 포함하는 SSL 인증서를 사용할 수 있다. 이러한 경우에 SSL 인증서는 www.contoso.com 및 www.example.com 모두를 열거할 것이다. 네이밍 규칙을 사용하여, 이러한 인증서는 인증서에 열거된 도메인 각각에 네이밍 규칙을 적용함으로써 여러 번 저장될 것이다. 인증서는 "www.contoso.com.pfx"라는 명칭을 사용하여 한번 저장될 것이고, 이후에 "www.example.com.pfx"라는 명칭을 사용하여 두번째로 저장된다. 따라서, 일 실시예에서, 네이밍 규칙은 SSL 인증서 파일이 동일하더라도, 복수의 서브젝트 명칭을 가지는 SSL 인증서에 대해, 서브젝트 명칭이 존재하는 만큼 많은 "PFX" 파일이 존재해야 할 필요가 있다는 것을 나타낸다.

웹 서버는 이러한 바인딩을 위한 다음의 IP:포트-호스트네임 테이블을 생성할 것이다.

SNI 비가용 브라우저가 서버 상의 웹사이트에 도달하려고 시도하는 경우에, 브라우저는 IP 어드레스 및 포트 번호를 송신하나 호스트네임은 송신하지 않는다. 서버는 IP 어드레스 및 포트 번호를 사용하여 IP:포트-호스트네임 테이블 내의 호스트네임을 검색한다. 위의 표 1 및 표 2에 나타낸 바와 같이, IP 어드레스/포트 번호에 대응하는 복수의 인증서가 존재할 수 있다. 일 실시예에서, 웹 서버는 IP:포트-호스트네임 테이블 내에 열거된 제1 호스트네임을 사용하고 네이밍 규칙을 적용한다. 예를 들어, IP 어드레스/포트 번호에 대응하는 제1 호스트네임이 www.contoso.com이면, 서버는 파일명 "www.contoso.com.pfx"을 가진 대응하는 인증서를 먼저 검색할 것이다. 그러한 파일이 존재하지 않으면, 서버는 자동으로 "_.contoso.com.pfx"의 포맷을 가진 덜 일치하는 파일명을 사용하여 재시도할 것이다.

도 1은 일 실시예에 따라 SNI 가용 브라우저 및 SNI 비가용 브라우저 모두를 지원하는 시스템의 블록도이다. 서버(101)는 웹 서비스 인스턴스(102a-n)를 사용하여 복수의 테넌트에 대한 웹 사이트를 지원한다. 각각의 테넌트에 대한 엔드포인트가 IP 어드레스(IPn) 및 포트 번호(PORTn)를 사용하여 식별된다. 클라이언트 브라우저(103 및 104)는 IP 어드레스와 포트 번호를 사용하여 웹 사이트와 통신한다. 다른 실시예에서, 웹 서비스 인스턴스(102a-n) 중 하나 이상의 그룹이 둘 이상의 별개의 서버 상에 배치될 수 있다.

SSL 인증서는 보안 웹 사이트와 함께 사용하기 위해 SSL 인증서 스토어(105)에 유지될 수 있다. 멀티 테넌트 환경에서 SSL 인증서 스토어(105)는 서버(101) 상의 SSL 인증서의 관리를 간단하게 하는 데 사용될 수 있다. 각각의 웹 서비스 인스턴스(102)에 걸쳐 인증서를 복제하는 대신에, 웹 서비스(102)가 공통 스토어(105) 상의 SSL 인증서를 액세스할 수 있다. SSL 인증서는 전술한 네이밍 규칙을 사용하여 저장된다. 구체적으로, 단일 명칭 인증서 및 복수의 서브젝트 명칭을 가진 인증서가 인증서에 열거되는 각각의 도메인에 대한 www.domain.com.pfx 포맷을 사용하여 저장된다. 와일드카드 SSL 인증서는 인증서 내의 상위 레벨 도메인(top-level domain)에 대해 "_.domain.com.pfx" 포맷을 사용하여 저장된다. 다른 실시예에서, 각각의 웹 서비스(102)는 최근에 사용된 SSL 인증서와 같은 하나 이상의 SSL 인증서를 저장하는 데 사용되는 로컬 캐시를 포함할 수 있다.

SNI 가용 브라우저(104)가 웹 서비스(102)에 액세스하는 경우에, SSL 헬로우는 TLS 확장자(extension)에 호스트네임(예,"www.contoso.com")을 포함한다. 서버(101)는 이용가능한 경우에, 로컬 캐시에서 대응하는 인증서를 검색한다. 캐시 미스(cache miss)가 존재하면, 서버(101)는 호스트네임(www.contoso.com)을 사용하여 SSL 인증서 스토어(105)에서 인증서를 검색한다. 서버(101)는 네이밍 규칙(www.contoso.com.pfx)을 사용하여 파일 서버(105) 상에서 인증서를 검색한다.

SNI 비가용 브라우저(103)가 웹 서비스(102) 액세스하는 경우에, 호스트 네임을 송신하지 않고 IP 어드레스와 포트 번호만을 송신한다. IP 어드레스 및 포트는 항상 이용가능하나, 호스트네임은 비가용 SNI 브라우저(103)에서 이용할 수 없다. SSL 인증서를 찾기 위해, 서버(101)는 IP 어드레스/포트 번호를 사용하여 IP:포트-호스트네밍 매핑(106)에서 역 검색(reverse lookup)을 수행하여 적합한 호스트네임을 찾는다. 위의 표 1 및 2에 나타낸 바와 같이, IP 어드레스/포트 번호는 하나 이상의 호스트네임과 상관될 수 있다. 서버(101)는 IP:포트-호스트네임 매핑에서 첫번째로 열거된(first listed) 호스트네임(예, www.contoso.com)을 획득한다. 이어서 서버(101)는 네이밍 규칙(예, www.contoso.com.pfx)을 사용하여 원격 파일 서버(105) 상에서 SSL 인증서를 검색한다. 이러한 검색은, 존재한다면, 적합한 단일 명칭 SSL 인증서 또는 복수의 서브젝트 명칭을 가진 인증서를 식별한다. 첫번째 시도와 일치하는 SSL 인증서가 발견되지 않으면(즉, www.contoso.com.pfx), 서버(101)는 대안적인 네이밍 규칙(예,_.contoso.com.pfx)를 사용하여 원격 파일 서버(105)를 다시 검색한다. 이러한 검색은, 존재한다면, 적합한 와일드카드 SSL 인증서를 식별한다.

도 2는 일 실시예에 따라, 단일 명칭 SSL 인증서 또는 복수의 서브젝트 명칭을 가진 인증서를 포함하는 웹 서버(202)와 통신하는 SNI 비가용 브라우저(201)를 지원하는 시스템을 나타내는 블록도이다. 웹 서버(202)는 지원되는 IP 어드레스/포트 번호/ 호스트네임의 조합을 식별하는 IP:포트-호스트네임 매핑(203)을 포함한다. 또한, 웹 서버(202)는 하나 이상의 SSL 인증서를 보유하는 SSL 인증서 스토어(204)를 포함한다. SSL 인증서는 전술한 네이밍 규칙을 사용하여 명명되며, 여기서 "PFX" 확장자가 SSL 인증서에 열거된 도메인 네임에 부가된다. 복수의 서브젝트 명칭을 가진 SSL 인증서가 제공되는 경우에, 그 인증서는 인증서에 열거된 각각의 서브젝트 명칭에 대한 네이밍 규칙을 사용하여 여러 번 저장된다.

브라우저(201)는 SNI를 지원하지 않고, 이에 따라 SSL 헬로우에서 TLS 확장자의 호스트네임을 송신하지 않는다. 대신에, 브라우저(201)는 단지 IP 어드레스(Addr1) 및 포트 번호(Port#)를 웹 서버(202)로 송신한다. 서버(202)는 호스트네임이 제공되지 않았다고 판정한다. IP 어드레스/포트 번호를 사용하는 경우에, 서버(202)는 IP:포트-호스트네임 매핑(203)을 참조하여 브라우저(201)에 의해 송신된 정보와 연관된 호스트네임을 식별한다.

하나의 서브젝트 명칭을 가지는 SSL 인증서의 경우에, 인증서는 www.contoso.com 같은 하나의 도메인 네임과 함께 사용될 수 있다. IP:포트-호스트네임 테이블(203)의 경우에, 이러한 인증서에 대해서는 하나의 라인 아이템(line-item) 만이 존재할 것이다. 하나의 라인 아이템만이 존재하기 때문에, 웹 서버(202)는 네이밍 규칙을 사용하여 SSL 인증서 스토어(204)에서 그 도메인 네임을 검색할 것이다. SSL 인증서 스토어(204)에서 첫번째 일치(예, www.contoso.com.pfx)를 찾으면 웹 서버(202)는 SSL 인증서 검색을 종료할 것이다.

복수의 서브젝트 명칭을 가지는 SSL 인증서의 경우에, 인증서가 www.contoso.com, www.example.com 및 www.1.com과 같은 복수의 도메인 네임을 이용하여 작업하도록 디자인된다. 복수의 서브젝트 명칭을 가진 SSL 인증서를 그 인증서에 열거된 각각의 도메인에 대해 한번씩 저장한다. 따라서, 파일 www.contoso.com.pfx, www.example.com.pfx 및 www.1.com.pfx는 서로 다른 명칭 하에 저장되는 동일한 SSL 인증서의 사본이다.

IP:포트-호스트네임 테이블(203)의 경우에, 얼마나 많은 열거된 도메인이 웹 서버(202) 상에 구성되는지에 따라 이러한 인증서에 대한 복수의 라인 아이템이 존재할 수 있다. 웹 서버(202)는 테이블(203)에서의 첫번째 IP 어드레스/포트 명칭 일치에 관한 호스트네임(예, www.contoso.com)을 사용한다. 웹 서버(202)는 네이밍 규칙을 사용하여 SSL 인증서 스토어(204) 내에서 그 도메인 네임을 검색한다. 웹 서버(202)는 SSL 인증서 스토어(204) 내에서 첫번째 일치(예, www.contoso.com.pfx)를 찾으면 SSL 인증서 검색을 종료할 것이다.

브라우저(201)가 www.contoso.com 대신에 www.example.com 이나 www.1.com의 도메인에 도달하려하는 경우에도, 프로세스는 여전히 정확한 SSL 인증서를 획득할 것이다. 이러한 도메인은 모두 복수의 서브젝트 명칭을 가지는 동일한 SSL 인증서를 사용하기 때문에, 이러한 SSL 인증서는 복수의 명칭 하에 저장된다. 따라서, 동일한 SSL 인증서를 공유하는 임의의 도메인이 연관된 인증서를 검색하기 위한 검색 변수로 사용될 수 있다.

도 3은 일 실시예에 따라 와일드카드 SSL 인증서를 가지는 웹 서버(302)와 통신하는 SNI 비가용 브라우저(301)를 지원하는 시스템을 나타내는 블록도이다. 웹 서버(302)는 지원되는 IP 어드레스/포트 번호/호스트네임의 조합을 식별하는 IP:포트-호스트네임 매핑(303)을 포함한다. 또한, 웹 서버(302)는 하나 이상의 SSL 인증서를 보유하는 SSL 인증서 스토어(304)를 포함한다. SSL 인증서는 전술한 네이밍 규칙을 사용하여 명명되고, 여기서 "PFX" 확장자가 SSL 인증서에 열거된 도메인 네임에 부가된다. 또한, 와일드카드 SSL 인증서가 존재하는 경우에, 그 인증서는 인증서에 열거된 서브 도메인에 대한 네이밍 규칙에 따라 _.domain.pfx의 포맷을 사용하여 저장된다.

브라우저(301)는 SNI를 지원하지 않고, 이에 따라 SSL 헬로우에서 TLS 확장자의 호스트네임을 송신하지 않는다. 대신에, 브라우저(301)는 IP 어드레스(Addr1) 및 포트 번호(Port#)만을 송신한다. 서버(302)는 호스트네임이 제공되지 않았다고 판정한다. IP 어드레스/포트 번호를 사용하여, 서버(302)는 브라우저(301)에 의해 송신되는 정보와 연관된 호스트네임을 식별하기 위해 IP:포트-호스트네임 매핑(303)을 참조한다.

와일드카드 SSL 인증서의 경우에, 도메인 네임이 동일하게 유지되는 한 동일한 인증서가 복수의 서브 도메인에 대해 사용될 수 있다. 더 구체적으로, *.contoso.com을 가진 SSL 인증서 서브젝트 명칭이 서브 도메인(images.contoso.com, members.contoso.com, secure.contoso.com 등) 중 임의의 도메인에 대해 사용될 수 있다.

P:포트-호스트네임 테이블(303)의 경우에, 얼마나 많은 열거된 도메인이 웹 서버(302) 상에 구성되는지에 따라 이러한 인증서에 대한 복수의 라인 아이템이 존재할 수 있다. 웹 서버(302)는 테이블(303)에서의 첫번째 IP 어드레스/포트 명칭 일치에 대한 호스트네임(예, images.contoso.com)을 사용한다. 웹 서버(302)는 네이밍 규칙(즉, "PFX"를 호스트네임에 부가하는 것)을 사용하여 SSL 인증서 스토어(304)를 검색한다. 웹 서버(302)는 제1 디폴트 검색 파라미터(즉, images.contoso.com.pfx)를 사용하여 SSL 인증서 스토어(304) 내의 일치를 찾지 못할 것이다.

첫번째 시도가 실패하는 경우에, 웹 서버(302)는 와일드카드 문자(예, _.contoso.com.pfx)를 가지는 대안적 검색 폼(form)을 이용한다. 이러한 검색 파라미터는 스토어(304) 내의 _.contoso.com.pfx SSL 인증서에 대해 일치될 것이다. 웹 서버(402)는 SSL 인증서 스토어(304)에서 이러한 일치를 찾으면 SSL 인증서 검색을 종료할 것이다.

브라우저(301)가 images.contoso.com 대신에 member.contoso.com이나 secure.contoso.com 도메인에 도달하려하는 경우에도, 이러한 도메인 모두가 동일한 와일드카드 SSL 인증서를 사용하기 때문에 프로세스는 여전히 정확한 SSL 인증서를 획득할 것이다. 따라서, 상위 레벨 도메인에 대한 와일드카드 도메인 검색이 서브 도메인 중 임의의 도메인에 대한 적합한 인증서를 찾기 위한 검색 변수로서 사용될 수 있다.

복수의 도메인 네임이 존재하기 때문에, 전술한 재시도 로직으로 인해 첫번째 일치의 검색 시에 종료하는 것이 기능적으로 정확히 이루어진다. 네이밍 계약은 와일드카드 인증서가 _.contoso.com.pfx라고 명명된다는 것을 나타낸다. images.contoso.com이 첫번째로 일치하는 호스트네임이면, 서버는 먼저 images.contoso.com.pfx를 검색하려고 시도할 것이고, 이는 발견되지 않을 것이다. 이후에, 재시도 로직이 시작되고 _.contoso.com.pfx을 검색하려고 하나, 이는 발견되지 않을 것이다. *.contoso.com 인증서는 임의의 서브 도메인에 대해 사용될 수 있기 때문에, 당연히 이는 images.contoso.com에 관해 정확하게 동작한다.

도 3의 예에서 설명한 바와 같이, 첫번째로 일치하는 호스트네임은 images.contoso.com, members.contoso.com 또는 secure.contoso.com이다. 이들은 모두 초기에 "file not found(파일이 발견되지 않음)" 에러를 생성할 것이나, 웹 서버는 대안적인 _.contoso.com.pfx 검색을 사용하여 SSL 인증서를 정확하게 배치할 것이고, 이는 당연히 모든 서브 도메인에 관해 동작할 것이다.

도 4는 웹 서버 상의 SSL 인증서를 식별하는 방법 또는 프로세스의 흐름도이다. 단계(401)에서, 웹 서버는 클라이언트로부터 SSL 헬로우 메시지를 수신한다. 단계(402)에서, 웹 서버는 SSL 헬로우 메시지가 호스트네임을 포함하지 않는다고 판정한다. 단계(403)에서, SSL 헬로우 메시지와 연관된 IP 어드레스를 사용하여, 하나 이상의 대응하는 호스트네임이 IP 어드레스-호스트네임 매핑으로부터 식별된다. 웹 서버는 호스트네임 중 하나를 선택하여 SSL 인증서를 검색한다. 일 실시예에서, 선택된 호스트네임은 IP 어드레스-호스트네임 매핑 내의 하나 이상의 대응하는 호스트네임의 첫번째 열거된 호스트네임(예, images.contoso.com)이다.

단계(404)에서, 선택된 호스트네임은 파일 확장자(예, pfx)를 부가함으로써 수정되어 SSL 인증서 검색 명칭(예, images.contoso.com.pfx)을 생성한다. 단계(405)에서, 새롭게 생성된 SSL 인증서 검색 명칭이 SSL 인증서 스토어를 검색하는 데 사용된다. SSL 인증서가 SSL 인증서 검색 명칭에 대응하는 SSL 인증서 스토어에서 식별되는 경우에, 프로세스는 단계(409)로 진행하고, 그 SSL 인증서는 단계(410)에서 클라이언트에게 송신된다.

단계(406)에서 SSL 인증서에 대응하는 SSL 인증서가 식별되지 않으면, 단계(407)에서 SSL 인증서 검색 명칭이 수정되어 수정된 SSL 인증서 검색 명칭을 생성한다. SSL 인증서 검색 명칭은 SSL 인증서 검색 명칭에서 서브 도메인(예, image.)을 와일드카드 문자(예, "_")로 교체함으로써 수정될 수 있다. 수정된 SSL 인증서 검색 명칭(예, _.contoso.pfx)이 사용되어 SSL 인증서 스토어가 다시 검색된다(단계(408)). SSL 인증서가 수정된 SSL 인증서 검색 명칭에 대응하는 SSL 인증서 스토어에서 식별되면, 프로세스는 단계(409)로 진행하고, 그 SSL 인증서는 단게(410)에서 클라이언트에게 송신된다.

선택된 호스트네임 및 SSL 인증서 검색 명칭이 본 명세서에 설명된 네이밍 규칙을 사용하여(즉, 파일 확장자를 부가하고 와일드카드 문자의 선두에 추가하여(prepend)) 또는 저장된 SSL 인증서에 대한 검색을 지원하는 임의의 다른 적합한 수정을 사용하여 수정될 수 있다.

도 5는 일 실시예에 따라 단일 명칭 SSL 인증서 또는 복수의 서브젝트 명칭을 가진 인증서를 웹 서버 상의 SSL 인증서 파일 스토어에 저장하는 방법 또는 프로세스의 흐름도이다. 단계(501)에서, 예를 들어 SSL 인증서에 열거되는 웹 서버 상에서 호스팅되는 도메인을 식별함으로써 SSL 인증서가 웹 서버와 연관된 것으로 식별된다. 단계(502)에서, SSL 인증서 상에 열거된 하나 이상의 서브젝트 명칭이 식별된다. 단계(503)에서, 하나 이상의 열거된 서브젝트 명칭 각각에 대해, 연관된 SSL 인증서가 SSL 인증서 스토어에 저장된다. SSL 인증서가 저장될 때마다, 서로 다른 파일명이 사용된다. 각각의 파일명은 소정의 또는 열거된 서브젝트 명칭에 부가된 파일명 확장자를 포함한다.

도 6은 일 실시예에 따라 와일드카드 SSL 인증서를 웹 서버 상의 SSL 인증서 파일 스토어에 저장하는 방법 또는 프로세스의 흐름도이다. 단계(601)에서, 와일드카드 SSL 인증서는 웹 서버와 연관된 것으로 식별된다. 단계(602)에서, SSL 인증서에 열거된 상위 도메인 네임이 식별된다(예, *.contoso.com). 단계(603)에서, SSL 인증서가 상위 도메인 네임의 선두에 추가된 와일드카드 문자 및 열거된 호스트네임에 부가된 파일명 확장자(예, _.contoso.com.pfx)를 포함하는 파일명을 사용하여 SSL 인증서 스토어에 저장된다.

도 4의 단계(401) 내지 단계(410), 도 5의 단계(501) 내지 단계(503) 및 도 6의 단계(601) 내지 단계(603)는 동시에 및/또는 순차적으로 실행될 수 있다는 사실을 이해할 수 있을 것이다. 추가로, 각각의 단계가 임의의 순서로 수행될 수 있고, 한번 만 또는 반복적으로 수행될 수 있다는 사실을 이해할 수 있을 것이다.

도 7은 도 1 내지 6의 예가 구현될 수 있는 적합한 컴퓨팅 및 네트워크 환경의 예를 나타낸다. 컴퓨팅 시스템 환경(700)은 단지 적합한 컴퓨팅 환경의 일 예이며 본 발명의 용도나 기능의 범주에 관한 임의의 제한을 제시하려는 것이 아니다. 본 발명은 수많은 다른 일반적인 범용 또는 전용 컴퓨팅 시스템 환경이나 구성과 함께 동작가능하다. 본 발명과 함께 사용하는 데 적합할 수 있는 공지의 컴퓨팅 시스템, 환경 및/또는 구성의 예는 개인 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩톱 장치, 태블릿 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋톱 박스, 프로그램 가능한 가전기기, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전술한 시스템 또는 장치 중 임의의 것을 포함하는 분산형 컴퓨팅 환경 등을 포함하나 이에 한정되는 것을 아니다.

본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어에 대한 일반적인 맥으로 설명될 수 있다. 일반적으로, 프로그램 모듈은 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함하며, 특정한 태스크를 수행하거나 특정한 추상 데이터 타입을 구현한다. 또한, 본 발명은 통신 네트워크를 통해 연결된 원격 프로세싱 장치에 의해 태스크가 수행되는 분산형 컴퓨팅 환경에서 실현될 수 있다. 분산형 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및/또는 원격 컴퓨터 저장 매체에 배치될 수 있다.

도 7은 본 발명의 다양한 측면을 구현하는 예시적인 시스템은 컴퓨터(700) 형태의 전용 컴퓨팅 장치를 포함할 수 있다. 컴포넌트는 프로세싱 유닛(701), 시스템 메모리 및, 데이터 저장소(702)를 포함하는 다양한 시스템 컴포넌트들을 프로세싱 유닛(701)에 연결하는 시스템 버스(703)를 포함할 수 있으나 여기에 제한되지는 않는다. 시스템 버스(703)는 메모리 버스나 메모리 제어기, 병렬 버스, 임의의 다양한 버스 아키텍처를 사용하는 지역 버스를 포함하는 여러 종류의 버스 구조를 취할 수 있다. 예로써, 이러한 아키텍쳐는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 메자닌 버스(Messanine bus)로도 알려진 PCI(Peripheral Component Interconnect) 버스를 포함하지만, 여기에 한정되지는 않는다.

컴퓨터(700)는 다양한 컴퓨터 판독가능 매체(704)를 포함한다. 컴퓨터 판독가능 매체(704)는 컴퓨터(700)에 의해 액세스가능한 임의의 이용가능한 매체로서, 휘발성 및 비휘발성 매체, 착탈식 및 비착탈식 매체를 모두 포함한다. 예컨대, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체와 통신 매체를 포함할 수 있으나, 이에 제한되지는 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조체, 프로그램 모듈 또는 기타 데이터와 같은 정보 저장을 위한 방법이나 기법에서 구현될 수 있는 휘발성 및 비휘발성, 착탈식 및 비착탈식 매체를 모두 포함하는 하드웨어 저장 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리, 기타 메모리 기법, CD-ROM, DVD 또는 기타 광학 디스크 저장부, 자기 카세트, 자기 테이프, 자기 디스크 저장부 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터(700)에 의해 액세스가능한 임의의 매체를 포함하지만, 여기에 한정되지는 않는다. 통신 매체는 전형적으로 컴퓨터 판독가능 명령어, 데이터 구조체, 프로그램 모듈, 반송파나 기타 전송 메커니즘과 같은 변조된 데이터 신호 내의 데이터를 구현하고, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"란 신호 내에 정보를 인코딩하도록 그 특성 세트 중 하나 이상이 변경된 신호를 의미한다. 예컨대, 통신 매체는 무선 네트워크나 직접-무선 접속(direct-wired connection), 음향, RF, 적외선 및 기타 무선 매체와 같은 무선 매체를 포함하지만, 여기에 한정되지는 않는다. 이들의 임의의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함된다. 컴퓨터 판독가능 매체는 컴퓨터, 프로그램 제품(예를 들면, 컴퓨터 저장 매체 상에 저장되는 소프트웨어)로서 구현될 수 있다.

시스템 메모리(702)는 ROM과 RAM과 같은 휘발성 및/또는 비휘발성 메모리의 형태인 컴퓨터 저장 매체를 포함한다. 예를 들어, 시작 중에 컴퓨터(700) 내의 구성요소 사이의 정보 전달을 돕는 기본 경로를 포함하는 BIOS가 전형적으로 ROM에 저장된다. RAM은 전형적으로 프로세싱 유닛(701)에 의해 현재 작동되고 있거나 즉시 액세스가능한 프로그램 모듈 및/또는 데이터를 포함한다. 예컨대, 데이터 저장소(702)는 운영체제, 애플리케이션 프로그램, 기타 프로그램 모듈, 프로그램 데이터를 나타낸다.

또한, 데이터 저장소(702)는 다른 착탈식/비착탈식 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수도 있다. 예를 들어, 데이터 저장소(702)는 비착탈식, 비휘발성 자기 매체로부터 판독/기록할 수 있는 하드 디스크 드라이브, 비휘발성 자기 매체, 착탈식, 비휘발성 자기 디스크로부터 판독/기록할 수 있는 자기 디스크 드라이브, CD ROM이나 기타 광학 매체와 같은 착탈식, 비휘발성 광학 디스크로부터 판독/기록할 수 있는 광학 디스크 드라이브일 수 있다. 기타 예시적인 동작 환경에서 사용될 수 있는 착탈식/비착탈식, 휘발성/비휘발성 컴퓨터 저장 매체로는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM 등이 있으나, 여기에 제한되지는 않는다. 전술하고 도 7에 도시한 드라이브 및 그와 연관된 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조체, 프로그램 모듈 및 기타 컴퓨터(700)를 위한 데이터의 저장을 제공한다.

사용자는 사용자 인터페이스(705) 또는 태블릿, 전자 디지타이저, 마이크로폰, 키보드 및/또는 일반적으로 마우스, 트랙볼, 터치 패드라고 지칭되는 같은 포인팅 장치를 통해 명령 및 정보를 입력할 수 있다. 기타 입력 장치는 조이스틱, 게임 패드, 위성 접시, 스캐너 등을 포함할 수 있다. 또한, 음성 입력 또는 NUI(natural user interface)가 사용될 수 있다. 이들 및 다른 입력 장치들은 흔히 시스템 버스(703)에 연결되는 사용자 입력 인터페이스(705)를 통해 프로세싱 유닛(701)에 연결되나, 병렬 포트, 게임 포트, 또는 USB 등과 같은 다른 인터페이스와 버스 구조에 의해 연결될 수도 있다. 모니터(706) 또는 다른 타입의 디스플레이 장치도 비디오 인터페이스와 같은 인터페이스를 통해 시스템 버스(703)에 연결된다. 또한, 모니터는(706)는 터치 스크린 패널 등과 통합될 수 있다. 모니터 및/또는 터치 스크린 패널이 컴퓨팅 장치(700)가 삽입되는 하우징(예를 들면 태블릿 타입 개인용 컴퓨터)에 물리적으로 연결될 수 있다. 또한, 컴퓨팅 장치(700)와 같은 컴퓨터는 스피커 및 프린터와 같은 다른 병렬 출력 장치를 포함할 수 있는데, 이들은 출력 병렬 인터페이스 등을 통해 연결될 수 있다.

컴퓨터(700)는 원격 컴퓨터와 같은 하나 이상의 원격 컴퓨터에 대한 논리적 연결부(707)를 사용하여 네트워킹된 환경에서 동작할 수 있다. 원격 컴퓨터는 개인용 컴퓨터, 휴대용 장치, 서버, 라우터, 네트워크 PC, 피어 장치(peer device) 또는 기타 공통 네트워크 노드일 수 있으며, 통상적으로 컴퓨터(700)에 대해 전술한 모든 구성요소의 전부 또는 많은 것을 포함한다. 도 7에 도시한 논리적 연결부는 하나 이상의 LAN 및 하나 이상의 WAN을 포함하나, 다른 네트워크도 포함할 수 있다. 이러한 네트워킹 환경은 사무실, 기업의 컴퓨터 네트워크, 인트라넷, 인터넷에서 흔하게 찾아볼 수 있다.

LAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(700)는 네트워크 인터페이스나 어댑터(707)를 통해 LAN에 연결될 수 있다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(700)는 전형적으로 인터넷과 같은 WAN을 통한 통신을 설정하는 기타 수단 또는 모뎀을 포함한다. 모뎀은 내장형일 수도 있고 외장형일 수도 있는데 네트워크 인터페이스(707) 또는 다른 적합한 메커니즘을 통해 시스템 버스(703)에 연결될 수 있다. 인터페이스 및 안테나를 포함하는 것과 같은 무선 네트워킹 컴포넌트는 액세스 포인트나 피어어 컴퓨터와 같은 적합한 장치를 통해 WAN이나 LAN에 연결될 수 있다. 네트워킹 환경에서, 컴퓨터(700)에 대해 도시된 프로그램 모듈 또는 그의 일부는 원격 메모리 저장 장치에 저장될 수 있다. 예컨대, 도시된 네트워크 연결은 예시적이며, 컴퓨터 사이의 통신 링크를 수립하는 다른 수단이 사용될 수도 있다.

본 발명의 청구 대상이 구조적 특성 및/또는 방법적 동작에 특유한 표현을 이용하여 기술되었지만, 첨부하는 특허청구범위에 정의된 청구 대상은 전술한 구체적인 특성이나 동작으로 제한되지 않는다. 오히려, 전술한 구체적인 특성이나 동작은 청구항을 구현하는 예시적인 형태로서 개시된 것이다.

Claims

웹 서버에 의해 수행되는 방법으로서,
SSL 헬로우 메시지(Hello message)를 클라이언트로부터 수신하는 단계와,
상기 SSL 헬로우 메시지가 호스트네임을 포함하지 않는다고 판정하는 단계와,
상기 SSL 헬로우 메시지와 연관된 IP 어드레스 및 포트를 사용하여 IP:포트-호스트네임 매핑으로부터 하나 이상의 대응하는 호스트네임을 식별하는 단계와,
선택된 대응하는 호스트네임을 수정하여 SSL 인증서 검색 명칭을 생성하는 단계와,
상기 SSL 인증서 검색 명칭을 사용하여 SSL 인증서 스토어를 검색하는 단계
를 포함하는 방법.
제1항에 있어서,
상기 SSL 인증서 검색 명칭에 대응하는 SSL 인증서를 상기 SSL 인증서 스토어에서 식별하는 단계와,
상기 SSL 인증서를 상기 클라이언트에게 송신하는 단계
를 더 포함하는 방법.
제1항에 있어서,
상기 선택된 대응하는 호스트네임은 상기 IP:포트-호스트네임 매핑에서 상기 하나 이상의 대응하는 호스트네임 중 첫번째로 열거된 호스트네임인
방법.
제1항에 있어서,
네이밍 규칙(naming convention)을 사용하여 파일명 확장자(file-name extension)를 상기 선택된 대응하는 호스트네임에 추가함으로써 상기 선택된 대응하는 호스트네임을 수정하여 상기 SSL 인증서 검색 명칭을 생성하는 단계
를 더 포함하는 방법.
제4항에 있어서,
상기 파일명 확장자는 .pfx인
방법.
제1항에 있어서,
상기 SSL 인증서 스토어 내에 상기 SSL 인증서 검색 명칭에 대응하는 SSL 인증서가 없다고 판정하는 단계와,
상기 SSL 인증서 검색 명칭을 수정하여 수정된 SSL 인증서 검색 명칭을 생성하는 단계와,
상기 수정된 SSL 인증서 검색 명칭을 사용하여 상기 SSL 인증서 스토어를 검색하는 단계
를 더 포함하는 방법.
제6항에 있어서,
네이밍 규칙(naming convention)를 사용하여 상기 SSL 인증서 검색 명칭의 서브 도메인을 와일드카드 문자(wildcard character)로 교체함으로써 상기 SSL 인증서 검색 명칭을 수정하는 단계
를 더 포함하는 방법.
제7항에 있어서,
상기 와일드카드 문자는 밑줄표시 문자(underscore character)인
방법.
제1항에 있어서,
상기 IP:포트-호스트네임 매핑은 IP:포트를 복수의 호스트네임에 연관시키는 엔트리를 포함하는
방법.
제1항에 있어서,
상기 IP:포트-호스트네임 매핑은 포트 번호와 짝지워진 IP 어드레스를 호스트네임과 연관시키는 하나 이상의 엔트리를 포함하는
방법.
제4항에 있어서,
상기 웹 서버와 연관되는 SSL 인증서를 식별하는 단계와,
상기 SSL 인증서에 열거되는 하나 이상의 호스트네임을 식별하는 단계와,
상기 하나 이상의 열거된 호스트네임 각각에 대해, 상기 열거된 호스트네임에 부가되는(append) 상기 파일명 확장자를 포함하는 파일명을 사용하여 상기 연관된 SSL 인증서를 상기 SSL 인증서 스토어에 저장하는 단계
를 더 포함하는 방법.
제4항에 있어서,
상기 웹 서버와 연관된 와일드카드 SSL 인증서를 식별하는 단계와,
상기 SSL 인증서에 열거된 상위 도메인 네임을 식별하는 단계와,
상기 상위 도메인 네임의 선두에 추가된(prepend) 와일드카드 문자 및 열거된 호스트네임에 부가된(append) 상기 파일명 확장자를 포함하는 파일명을 사용하여 상기 SSL 인증서 스토어에 상기 연관된 SSL 인증서를 저장하는 단계
를 더 포함하는 방법.
하나 이상의 프로세서와,
시스템 메모리와,
상기 하나 이상의 프로세서에 의해 실행되는 경우에 상기 프로세서로 하여금 SSL 인증서를 식별하는 방법을 수행하게 하는 컴퓨터 실행가능 명령어가 저장된 하나 이상의 컴퓨터 판독가능 저장 매체
를 포함하되,
상기 프로세서는
SSL 헬로우 메시지를 클라이언트로부터 수신하고,
상기 SSL 헬로우 메시지와 연관된 IP 어드레스 및 포트를 사용하여 IP:포트-호스트네임 매핑으로부터 하나 이상의 대응하는 호스트네임을 식별하고,
선택된 대응하는 호스트네임을 수정하여 SSL 인증서 검색 명칭을 생성하고,
상기 SSL 인증서 검색 명칭을 사용하여 SSL 인증서 스토어를 검색하도록 동작하는
컴퓨터 시스템.
제13항에 있어서,
상기 프로세서는 또한
상기 SSL 인증서 검색 명칭에 대응하는 SSL 인증서를 상기 SSL 인증서 스토어에서 식별하고,
상기 SSL 인증서를 상기 클라이언트에게 송신하도록 동작하는
컴퓨터 시스템.
제13항에 있어서,
상기 프로세서는 또한
네이밍 규칙을 사용하여 파일명 확장자를 상기 선택된 대응하는 호스트네임에 추가함으로써 상기 선택된 대응하는 호스트네임을 수정하여 상기 SSL 인증서 검색 명칭을 생성하도록 동작하는
컴퓨터 시스템.
제13항에 있어서,
상기 프로세서는 또한
상기 SSL 인증서 스토어 내에 상기 SSL 인증서 검색 명칭에 대응하는 SSL 인증서가 없다고 판정하고,
상기 SSL 인증서 검색 명칭을 수정하여 수정된 SSL 인증서 검색 명칭을 생성하고,
상기 수정된 SSL 인증서 검색 명칭을 사용하여 상기 SSL 인증서 스토어를 검색하도록 동작하는
컴퓨터 시스템.
제15항에 있어서,
상기 컴퓨터 시스템은 웹 서버를 포함하고,
상기 프로세서는 또한
상기 웹 서버와 연관되는 SSL 인증서를 식별하고,
상기 SSL 인증서에 열거되는 하나 이상의 호스트네임을 식별하고,
상기 하나 이상의 열거된 호스트네임 각각에 대해, 상기 열거된 호스트네임에 부가되는(append) 상기 파일명 확장자를 포함하는 파일명을 사용하여 상기 연관된 SSL 인증서를 상기 SSL 인증서 스토어에 저장하도록 동작하는
컴퓨터 시스템.
제15항에 있어서,
상기 컴퓨터 시스템은 웹 서버를 포함하고,
상기 프로세서는 또한
상기 웹 서버와 연관된 와일드카드 SSL 인증서를 식별하고,
상기 SSL 인증서에 열거된 상위 도메인 네임을 식별하고,
상기 상위 도메인 네임의 선두에 추가된(prepend) 와일드카드 문자 및 열거된 호스트네임에 부가된(append) 상기 파일명 확장자를 포함하는 파일명을 사용하여 상기 SSL 인증서 스토어에 상기 연관된 SSL 인증서를 저장하도록 동작하는
컴퓨터 시스템.
컴퓨팅 시스템의 하나 이상의 프로세서에 의해 실행되는 경우에 상기 컴퓨팅 시스템으로 하여금 웹 서버상에서 SSL 인증서를 식별하는 방법을 수행하게 하는 컴퓨터 실행가능 명령어가 저장된 하나 이상의 컴퓨터 판독가능 저장 매체로서,
상기 방법은
SSL 헬로우 메시지를 클라이언트로부터 수신하는 단계와,
상기 SSL 헬로우 메시지와 연관된 IP 어드레스 및 포트를 사용하여 IP:포트-호스트네임 매핑으로부터 하나 이상의 대응하는 호스트네임을 식별하는 단계와,
파일명 확장자를 추가함으로서 선택된 대응하는 호스트네임을 수정하여 SSL 인증서 검색 명칭을 생성하는 단계와,
상기 SSL 인증서 검색 명칭을 사용하여 SSL 인증서 스토어를 검색하는 단계를 포함하는
하나 이상의 컴퓨터 판독가능 저장 매체.
제19항에 있어서,
상기 방법은
상기 SSL 인증서 스토어 내에 상기 SSL 인증서 검색 명칭에 대응하는 SSL 인증서가 없다고 판정하는 단계와,
상기 SSL 인증서 검색 명칭을 수정하여 수정된 SSL 인증서 검색 명칭을 생성하는 단계와,
상기 수정된 SSL 인증서 검색 명칭을 사용하여 상기 SSL 인증서 스토어를 검색하는 단계를 더 포함하는
하나 이상의 컴퓨터 판독가능 저장 매체.