인증서에는 네트워크상에서 신원을 확인하는 데(인증 과정) 사용되는 정보가 들어 있습니다. 인증서는 ID의 기본 형태와 비슷하며 연결하기 전에 웹 서버와 사용자가 서로를 인증하는 데 사용합니다. 또한 인증서에는 클라이언트와 서버 간의 SSL(Secure Sockets Layer) 연결 설정에 사용되는 키 또는 암호화 값이 들어 있습니다. 이 연결을 통해 보내진 신용 카드 번호 같은 정보는 암호화되므로 인증받지 않은 조직 또는 사람이 훔쳐 보거나 사용할 수 없습니다.
SSL에 사용되는 인증서에는 형식과 목적에 따라 두 가지 종류가 있습니다. 클라이언트 인증서에는 사이트로 액세스를 요청하는 클라이언트에 대한 개인 정보가 들어 있어, 이 정보로 클라이언트의 신원을 확실하게 확인한 다음 사이트에 액세스를 허용합니다. 서버 인증서에는 서버에 대한 정보가 들어 있어, 클라이언트가 서버를 확실하게 확인한 다음 민감한 정보 등을 공유할 수 있도록 합니다.
웹 서버의 SSL 3.0 보안 기능을 활성화하려면 유효한 서버 인증서를 얻어서 설치해야 합니다. 서버 인증서는 웹 서버와 서버의 웹 컨텐트를 지원하는 조직에 대한 정보가 들어 있는 디지털 ID입니다. 서버 인증서를 사용하면 사용자들이 서버를 인증할 수 있으며, 웹 컨텐트의 유효성을 검사하고 보안 연결을 구축할 수 있습니다. 또한 서버 인증서에는 클라이언트와 서버 간의 보안 연결을 만드는 데 사용되는 공개 키가 들어 있습니다.
식별 방법으로서 서버 인증서의 성공은 사용자가 인증서에 포함된 정보의 유효성을 신뢰하는지 여부에 좌우됩니다. 예를 들어, 회사의 웹 사이트에 로그온하는 사용자는 회사의 서버 인증서의 내용을 보았더라도 신용 카드 정보 제공을 주저할 수 있습니다. 특히 회사가 오래되지 않았거나 잘 알려지지 않은 경우에 더욱 그렇습니다.
이러한 이유 때문에 인증서는 때로 인증 기관(CA)이라고 하는 서로 신뢰할 수 있는 타사 조직에 의해 발행되고 배서됩니다. 인증 기관의 주요 책임은 인증서를 찾는 사람들의 신원을 확인하여 인증서에 포함된 확인 정보의 유효성을 보증하는 것입니다.
또한 웹 사이트 사용자와 사용자 기관의 관계에 따라 자신의 서버 인증서를 발행할 수 있습니다. 예를 들어, 고용인 급료 및 재정 정보를 다루는 큰 기업의 인트라넷의 경우에 기업 경영진이 인증서 서버를 결정하고 확인 정보를 판단하고 서버 인증서를 발행할 책임을 위임할 수 있습니다. 자세한 내용은 서버 인증서 받기를 참조하십시오.
SGC(Server-Gated Cryptography)는 금융 기관을 위해 128비트 암호화를 사용하는 전세계의 보안 재무 트랜잭션 솔루션을 제공합니다. SGC는 금융 기관에서 IIS 수출용 버전으로 강력한 암호화를 사용할 수 있게 하는 SSL(Secure Sockets Layer)의 확장 기능입니다.
SGC(Server-Gated Cryptography)는 클라이언트 브라우저에서 실행되는 응용 프로그램을 필요로 하지 않으며, IIS 4.0 이상의 표준 수출용 버전에서 사용할 수 있습니다. SGC가 구성된 서버에서는 128비트와 40비트 암호화 세션을 모두 쉽게 사용할 수 있으므로 IIS의 여러 가지 버전이 필요 없습니다. IIS 4.0 이상의 버전에서는 SGC 기능이 기본적으로 제공되지만, 특별한 SGC 인증서에 대해서는 SGC가 있어야 합니다. 자세한 내용은 인증 기관에 문의하십시오. SGC에 대한 자세한 내용은 Server-Gated Cryptography(SGC)를 참조하십시오.
클라이언트 인증서는 클라이언트 정보가 들어 있는 전자 문서입니다. 서버 인증서와 마찬가지로, 이 인증서에는 이 정보 뿐 아니라 IIS의 SSL 3.0 보안 기능의 양식 부분인 암호화 키도 포함됩니다. 서버 및 클라이언트 인증서에서 이러한 키 또는 암호화 코드는 인터넷 같이 열린 네트워크상에 전송된 데이터를 암호화하고 암호를 해독하는 키 쌍을 형성합니다. 암호화에 대한 자세한 내용은 암호화 정보를 참조하십시오.
일반 클라이언트 인증서에는 사용자 신원, 인증 기관의 신원, 보안 통신을 위해 사용된 공개 키, 만기일과 일련 번호 등의 유효 정보가 포함됩니다. 보증 기관에서는 여러 형태의 클라이언트 인증서를 제공하며 그 인증서에는 필요한 인증 수준에 따라 다양한 정보가 들어 있습니다. 자세한 내용은 클라이언트 인증서 받기를 참조하십시오.
인증 기관이라고 하는 서로 신뢰하는 상업적인 조직에서 클라이언트 인증서를 얻을 수 있습니다. 인증서를 발급하기 전에 그 기관에서는 이름, 주소, 조직 이름 등의 ID 정보를 요구합니다. 이러한 정보의 범위는 인증서의 ID 확인 조건에 따라 다양합니다. ID에 대한 절대 확인을 위해 인증서가 필요하면 인증 기관은 부수적인 정보를 요구합니다. 이러한 정보를 수집하는 과정에서 개인 면접이나 공증인 배서 등을 요구할 수도 있습니다.
인증 기관 목록은 서버 인증서 받기를 참조하십시오.
참고 결국 인증서의 성공은 인증서를 받은 서버 관리자가 인증서를 발급한 기관을 믿는지와 기관이 인증서 소유자의 ID를 정확히 확인했는지의 여부에 따라 달라집니다. 그러나 이런 신뢰 문제를 떠나서, 인증서는 사용자나 서버의 신원, 신뢰, 의도에 대한 결론적 증거를 제공하지 않습니다.
웹 사이트 관리자는 CTL(인증서 신뢰 목록)을 유지함으로써 신뢰받는 인증 기관의 미리 정의된 목록에 대하여 클라이언트 인증서를 자동으로 확인할 수 있습니다.
예를 들어, 인트라넷 관리자는 네트워크의 각 부서에 대해 신뢰받는 인증 기관의 다른 목록을 만들 수도 있습니다. IIS는 그 부서에 대한 CTL에서 인증 기관이 제공한 클라이언트 인증서만을 수용합니다. 자세한 내용은 인증서 신뢰 목록 사용을 참조하십시오.
대부분의 유명한 인증 기관에는 예정된 만기일 이전에 해지된 현재 클라이언트 인증서 목록인 CRL(Certificate Revocation List)이 있습니다.
예를 들어, 인증 기관에서 사용자에게 클라이언트 인증서를 발급하고 나중에 사용자가 올바르지 않은 정보를 제출한 것으로 확인되면 그 기관은 그 사용자의 클라이언트 인증서를 해지할 수 있습니다. 그러나, 인증 기관은 클라이언트 인증서를 실제로 해지할 수 없으므로 해지된 클라이언트 인증서에 대한 정보를 CRL에 추가하여 웹 관리자에게 경고합니다. 해지 서비스 제공자에 대한 자세한 내용은 인증 기관에 문의하십시오.