안녕하세요. 다른 누구도 대답하지 않았으므로이 문제를 해결할 것입니다.하지만 공정한 경고 - 저는 Java/UNIX 개발자이며, 여러분이 묻는 것은 Microsoft가 제공하는 것입니다. 그러나 여기 몇 가지 답변입니다 :
1 - CN = 응용 프로그램 서버 - NLB 호스트 이름과 도메인 캘리포니아에서 '서버 인증'목적 인증서를 발급
목적은 다소 Microsoft의 특정 사항입니다. 이 말이 맞지만, 또한 일반적인 "키 사용"이 필요할 수도 있습니다. SSL 인증서의 경우 일반적으로 keyEncipherment 또는 keyAgreement를 사용합니다. 때때로 사이트는 digitalSignature를 사용합니다. 세 가지 모두 RFC에서 유효하지만, 때로는 Microsoft가 어떤 작업에 대해 wierd입니다. Microsoft CA를 사용하고 있다면 SSL 인증서에 대한 인증서 프로필이 있는지 확인한 다음 사용하십시오.
2 - '클라이언트 인증' 목적을 가진 프런트 엔드 상자의 인증서를 발급하십시오.
# 1과 동일 - 모든 인증서에는 일종의 기본 키 사용이 필요합니다. 언급하고있는 필드는 확장 된 용도로 필요하며 필수 항목은 아닙니다.
3 - 백엔드 인증서의 공용 키를 프런트 엔드 노드의 저장소 (또는 그 반대로)으로 가져옵니다.
Microsoft 특정 사안 인 경우에만. 적절한 PKI에서는 SSL에 서명 한 신뢰할 수있는 CA의 인증서를 가져와야하지만 모든 종점 (예 : 백 엔드 인증서)을 프런트 엔드로 가져올 필요가 없습니다.신뢰할 수있는 CA 체인 만 구성하여 사용해보고 작동시킬 수 있는지 확인해보십시오. 그러면 장기적으로 아키텍처가 훨씬 더 확장 가능해질 것입니다.
4 - 전송 보안
5 net.tpc 사용하는 WCF 구성 - 클라이언트 엔드 포인트 동작을 구성 (clientCredentials 섹션)
- 서비스 동작 (serviceCredentials 섹션)
6을 구성
나에게 좋은 소리 ...
거기에서, 나는 당신이 다른 것을 놓친 적이 있다고 생각하지 않습니다. 열쇠는 일반적으로 애매한 오류 메시지를 통해 작동합니다. 모든 시스템은 SSL 핸드 셰이크가 실패 할 때 무엇이 잘못되었는지를 알려주는 자체적 인 방법이 없기 때문에 무엇이 잘못되었는지 이해하고 있습니다.
설명하는 문제에서 보안 아키텍처가 인증서 상태 확인을 수행해야한다고 말합니다. 이는 CA가 인증서를 폐기했는지 여부를 시스템에서 확인할 수있게 해주는 추가 기능입니다. (CRL 또는 OCSP) 작업을 수행하는 데 상당히 많은 인프라가 필요하므로 위험을 감수하려는 위험과 위험 가능성에 대해 팀원이 심각하게 논의하지 않아야한다고 말하지는 않습니다. 나오다.
어떤 호스트 이름 프론트 엔드 인증서를 발급 받아야합니까?
그들이 나타내는 서버의 호스트 이름.
호스트 이름에 관한 것 - 일부 시스템은 정규화 된 도메인 이름을 사용하지 않으면 제대로 작동하지 않습니다. 다른 사람들은 그렇게 까다 롭지 않습니다. 어쨌든 - 인증서의 주체 DN은 그것이 나타내는 서비스, 응용 프로그램 또는 서버를 고유하게 설명해야합니다.
프런트 엔드 노드는 DMZ에 있으므로 도메인 (CA)에 액세스 할 수 없습니다. 이 문제가 발생합니까?
문제가 없습니다.
무명 - 앞에서 설명한 인증서 상태 확인을 수행해야합니다. 인증서 상태를 확인해야하는 경우 엔드 포인트 (예 : DMZ)에서 인증서 상태 (CRL 또는 OCSP 서버)에 대한 정보를 가져와야합니다. 복잡한 인프라에서는 일반적으로 OCSP 서버에 대한 경로를 열어 고정 도메인 이름이나 IP에 대한 HTTP GET을 수행하므로 방화벽에서 경로를 여는 것이 그리 나쁘지 않습니다.
내가 말했듯이, 그것은 중류, 심각한 위험 완화 유형 솔루션이 될 것입니다. 귀하의 시스템에 과도 할 수 있습니다. 귀하의 시스템이 보증되는지 여부를 알려주지는 않습니다.