글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
WSE 2.0/3.0에서부터 인증서를 이용한 프로그래밍이 눈길을 끌기 시작하다가, 최근의 WCF에서는 분위기가 왠지 인증서가 "기본"이 된 것 같은 분위기입니다. 암호화 지원이 기본 모드가 된 것도 특징이지요.
인증서와 관련해서는 확인해야 될 사항들이 정말 많습니다. 저 같은 경우에도, 인증서 관련 작업과는 무관하게 아무 생각 없이 잠시 시스템 날짜를 변경했다가, 다시 복원하는 것을 잊어먹고 인증서 관련 작업을 하면서 꽤나 애를 먹은 적이 있었습니다.
인증서가 유효한지에 대한 정리를 해 놓은 간단한 글이 눈에 띄어서, 저도 나름대로 좀 더 자세하게 정리해 보려 합니다.
Dealing with SSL Certificate Validation Failures
; http://blogs.msdn.com/drnick/archive/2006/11/07/dealing-with-ssl-certificate-validation-failures.aspx
기본 뼈대는 위의 목차를 따르고, 좀 더 살을 붙여서 이야기 해나가겠습니다.
1. Has the certificate expired or been revoked?
인증서가 만료되었는지, 아니면 폐기되었는지를 확인해야 하는 것... 기본입니다.
일단 인증서가 만료되었는지는 아래 그림에서와 같이 해당 인증서의 유효 날짜를 보면 쉽게 알 수 있습니다.
문제는 폐기된 인증서인데요. 어떤 경우에 있어서는, 좀 더 보안을 확고히 하기 위해 반드시 CRL(Certificates Revocation List)를 확인하게 만들 수도 있습니다. 이 과정에서 CRL 파일을 구할 수 없는 경우 오류를 내는 경우도 있으므로 이런 것들을 모두 확인하셔야 합니다.
CRL에 관한 것은 다음의 토픽에서 좀 더 자세히 알아보실 수 있습니다.
6. CRL(Certificate Revocation List) 관리
; https://www.sysnet.pe.kr/2/0/414
2. Does the MMC Certificate Manager say that the certificate is valid?
개인적으로, 아직은 MMC 인증서 관리자와 IE의 인증서 보기에 대한 유효성 검사의 차이점은 잘 모르겠습니다. 하지만, 어쨌든 여러분이 인증서와 관련하여 문제가 있다면, 역시나 MMC 관리자를 통해서 유효한 인증서라고 표시가 되는지 다시 한번 확인해 보시는 것도 좋겠습니다. 이와 관련해서는 다음의 토픽을 참조하시면 도움이 되실 것입니다.
5.3 인증서 관리 - 인증서 MMC 관리자
; https://www.sysnet.pe.kr/2/0/395
3. Is the certificate in the LocalMachine store?
이것은 매우 빈번하게 실수할 수 있는 문제입니다. 예를 들어, 여러분들이 사용하는 인증서가 "MY" 영역에 등록이 된 경우에는, 보통의 IIS 서비스가 구동되는 서비스 계정에서는 접근이 안되므로 에러가 발생하게 됩니다. 따라서, 반드시 특정 사용자에 국한해서 사용되는 것이라면, 그 사용자의 "MY" 영역에 두도록 하고, 전역적으로 접근하도록 허용하고 싶다면 "Local Computer" 영역에 두도록 해야 합니다. 이 차이점 역시, "인증서 MMC 관리자"를 통해서 확인할 수 있습니다.
또한, 인증서 MMC 관리자를 통해서 해당 인증서가 정상적으로 "LocalMachine" 영역에 있다고 하더라도, 중요한 것은 실제 인증서 파일이 특정 사용자 계정이 사용하는 폴더에 저장되지 않았다는 것을 확인해야 합니다. 이에 관해서는 다음의 토픽을 참고하십시오.
인증서 설치 확인
; https://www.sysnet.pe.kr/2/0/429#check_cert_path
4. Have you registered the certificate to the address and port of your service?
당연하겠지만, 해당 서비스를 제공하고 있는 주소에 부합하는 인증서가 로컬에 등록되어져 있어야 할 것입니다. 역시 "인증서 MMC 관리자"를 통해서 해당 인증서가 등록되어져 있는지 확인할 수 있습니다. 사실 3번 문제를 확인하게 되면 4번 문제는 굳이 할 필요는 없는 듯 싶군요.
5. Does the registered thumbprint match the SHA1 thumbprint of the certificate?
최근의 인증서에서는 해시 알고리즘을 MD5보다는, 더 보안성이 좋은 SHA1을 쓰고 있는 추세입니다. 이는 WCF 및 Windows CardSpace에도 영향을 미치고 있는데요. 기본적으로 WCF는 thumbprint 값을 확인하는데, 무조건 SHA1 알고리즘이 사용되었다고 가정하고 동작을 합니다. 따라서 해당 인증서가 MD5 방식으로 손도장(thumbprint) 값을 가지고 있다면 오류가 발생하게 됩니다.
6. Does the certificate address match the address in your service URI?
(예전의 저를 포함해서 ^^) 대부분의 개발자들이 오류를 범하고 마는 부분입니다. 대표적으로, 서버 인증서의 경우 해당 URL로 접근할 수 있는 "도메인"까지도 인증서에 포함이 되어 발급됩니다. 예를 들어, 다음과 같은 인증서가 있다고 가정하는 경우,
위와 같은 SSL 인증서가 설치된 사이트를 Internet Explorer를 이용하여 "https://www.sysnet.pe.kr"라고 접근하면 상관이 없지만, "https://w32.sysnet.pe.kr"이라고 접근하게 되면 오류가 나게 됩니다. 물론 이러한 처리는 프로그램마다 다를 수 있습니다. 예를 들어, VS.NET 2005의 웹 참조 대화창에서는 웹 서비스 참조가 아예 안 되기도 합니다. (흔히들, 개발자 스스로의 PC에 인증서를 설치했다면 http://localhost/... 라고 웹 참조를 걸기도 하지요.)
7. Is the root certificate valid and in the trusted root store?
대개의 경우, 인증서 서비스를 통해서 SSL 인증서 또는 개인 인증서를 발급받게 됩니다. 따라서, 발급받은 그 인증서의 유효성은 루트 인증서가 유효하지 않으면 가치가 없는 것입니다. 그러니, 여러분들이 사용하게 될 인증서를 발급한 "인증 경로"상의 인증서들이 모두 올바른지 확인을 해봐야 합니다. 아시겠지만, 인증 경로는 다음 화면과 같이 인증서 등록 정보의 "Certificate Path"에서 확인할 수 있습니다.
8. Is the certificate revocation server reachable and functioning?
1번에서 이미 모두 설명을 드렸습니다. 해당 인증서가 폐기(revoked)되었는지에 대한 여부를 알기 위해서는 CDP를 알아내서 CRL 목록을 다운로드할 수 있어야 합니다. 어떤 서비스들에서는 CRL 목록을 확인하는 것이 기본 설정되어 있으며 이런 경우 CDP 접근을 할 수 없으면 아예 인증서 유효성 검사에 실패를 해버리는 경우가 있습니다.
"질문" 게시판의 "양덕진" 님이 질문하신 내용에 대해서 이렇게 정리를 하게 되었습니다. 좀 더 일찍 정리를 했어야 하는데, 이것을 설명하기 위한 선행 토픽("CRL 관리")도 준비해야 했고, 또한 그동안 개인적인 사정으로 인해 이렇게 늦어지게 되었네요. ^^
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]
[연관 글]
... 76 77 78 79 80 81 82 83 84 85 86 87 88 89 [90] ...
... 76 77 78 79 80 81 82 83 84 85 86 87 88 89 [90] ...