IIS 6의 ASP.NET MVC 사이트의 클라이언트 인증서 작업

StackOverflow https://stackoverflow.com/questions/122687

문제

클라이언트 인증서에 의해 인증을 구현하고 싶을 때 몇 가지 문제가 발생하고 있습니다.

먼저 몇 가지 사실

전체 사이트는 SSL을 사용하고 있습니다. IIS 6 (Windows Server 2003에서)을 사용하고 있으며 고객 인증서를 필요로하지 않도록 사이트를 구성했습니다. 그러나 대부분의 브라우저는 어떤 방식으로 구현되므로 사용자에게 엄격하게 필요한 경우에만 인증서를 요청할 수 있습니다. 이로 인해 인증 모델은 실제로 유용하지 않습니다.

내 자신의 제안

나의 첫 번째 아이디어는 그것을 설정하는 것이었다 HttpResponse.Status 속성이지만 첫 번째 공간 이전의 캐릭터가 정수가되기 위해 문자가 필요합니다. 클라이언트 인증서를 보낼 브라우저를받는 데 유용한 상태는 다음과 같습니다. 403.7 Client certificate required 따라서 이것은 작동하지 않습니다 (덮어 쓸 수 없다면).

또한 특정 경로에 대한 클라이언트 인증서를 요구하도록 IIS를 구성 할 것이라고 생각했지만 Cource는 라우팅이 아닌 실제 파일에서만 작동합니다.

가능한 솔루션은 특정 폴더를 만들고 솔루션보다 해킹에 대한 클라이언트 인증서를 요구하는 것입니다. 그래서 누군가가 더 나은 제안을한다면 이것을 피하고 싶습니다.

설명

Internet Explorer, Firefox 및 Chrome의 브라우저 응답을 테스트했습니다 (Chrome을 기본 브라우저로 사용하고 Firefox를 보조로 사용합니다). IIS에서 IIS에서 필요한 경우 브라우저 중 어느 것도 클라이언트 인증서를 요구하지 않습니다.

HTTP 상태 코드 403.7은 RFC 2616이 상태 코드를 처음 3 자리로만 정의하기 때문에 내 이해가 허용 되었기 때문입니다. IIS 6이 403.7을 반환하면 클라이언트 인증서가 필요할 때 IIS를 보내는 것이 요구 사항을 트리거하는 특수 모드로 보내야한다고 생각했습니다.

문제는 이제 물리적이 아닌 가상 경로가 주어진 인증서를 요구하기 위해 IIS를 구성하는 방법이라고 생각합니다.

도움이 되었습니까?

해결책

인증서가 단순히 요청되지 않고 서버가 보낸 인증서 quest 메시지에는 차이가 없습니다. 서버는 두 경우 모두 동일한 요청을하고 클라이언트가 필요한 인증서를 제공하지 않으면 핸드 셰이크를 종료합니다. 따라서 브라우저가 "요청"을 무시하는 것으로 보이면 "요구 사항"도 무시하는 것으로 보입니다.

다음을 확인하십시오.

  • 브라우저는 모든 인증서 요청을 무시하도록 구성되어 있습니까?
  • 브라우저가 사용자에게 프롬프트하지 않고 주어진 인증서를 사용하도록 구성되어 있습니까? (즉, 브라우저가 인증서를 보내지 않는다는 것을 어떻게 알 수 있습니까?)
  • 서버가 실제로 인증서를 요청하고 있습니까?

이 마지막 사례를 테스트하는 방법은 다음과 같습니다. OpenSSL (또한 가능합니다 Cygwin) 도구: 

openssl s_client -connect server.y.com:443 -msg

서버가 인증서 메시지를 보내면 클라이언트 인증을 요청하지 않으면없는 인증서 quest 메소드를 삽입합니다. s_client 출력은 다음과 같습니다.

<<< TLS 1.0 Handshake [length 0008], CertificateRequest
    0d 00 00 04 01 01 00 00

클라이언트가 HTTP 요청을 전송하기 전에 초기 SSL 핸드 셰이크가 완료되기 때문에 서버가 특정 경로에서만 클라이언트 인증을 사용하는 경우 어떻게 작동하는지 잘 모르겠습니다. 서버 가이 시점에서 새로운 핸드 셰이크를 요청하는 것이 합리적이지만, 어떤 서버가이를 지원하는지 테스트 한 적이 없습니다.

s_client를 통해 손으로 입력 할 수 있습니다.

GET /your/path/here HTTP/1.1[Enter]
Host: server.y.com:443[Enter]
[Enter]

인증서 Quessest 메시지가 전혀 표시되지 않으면 서버가 올바르게 설정되지 않습니다.

디렉토리 구조를 기반으로 보안 제약을 지정하는 것은 매우 일반적이며 실제로 보안 관리를 잘 단순화 할 수 있습니다. 이것이 당신을위한 솔루션을 제공한다면 그것에 대해 기분이 나쁘지 않습니다.

403.7은 HTTP 상태 코드가 아닙니다. 그게 일부 Microsoft "포옹, 확장 및 소화"Subterfuge입니까? 어쨌든, 이것은 애플리케이션 계층 문제가 아니라 전송 계층 문제이기 때문에 추구하기에 적합한 방향처럼 들리지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top