과정이 어떻게 진행되는지 이해해주십시오. 나는 웹 브라우저가 verisign, Entrust, Comodo와 같은 CA (Certificate Authority)의 루트 인증서를 가지고 있다는 것을 이해하지만 사용자가 보안 페이지에 액세스 할 때 정확히 무엇이 발생합니까? 웹 브라우저가 CA 서버에 요청을 보내서 인증을 확인하거나 브라우저의 CA 루트 인증서를 사용하여 인증서를 확인합니까?웹 사이트 보안 (SSL 사용)을 위해 디지털 인증서를 사용할 경우 어떻게 작동합니까?
일부 HTTP 스니퍼를 사용하고 gmail에 로그인했지만 (로그인 페이지가 안전함) Google 이외의 다른 웹 사이트로 이동하는 요청을 보지 못했지만 이는 CA의 루트 인증서 만 사용한다는 의미입니까?
브라우저/OS 구성에 따라 다릅니다. 기본적으로 브라우저 나 OS에는 신뢰할 수있는 루트 권한 목록이 있습니다 (Mozilla는 자체 목록이 있으며 Internet Explorer는 Windows를 사용합니다).
SSL 핸드 셰이크가 발생하면 신뢰할 수있는 기관 중 하나가 서명했는지 여부와 서버 이름이 인증서의 이름과 일치하는지 확인하기 위해 사이트 인증서가 검사됩니다.
다음은 브라우저 또는 OS 구성에 따라 다릅니다. CA에는 해지 목록 기능 (인증서가 여전히 좋은지 물어볼 수있는 큰 목록 또는 별도 서비스 (OCSP))이 있습니다. 브라우저/OS가이를 확인하도록 구성된 경우이 추가 단계가 발생합니다.
Firefox와 Windows는 OCSP 서비스가 사용 가능한 경우 기본적으로 OCSP 서비스를 확인하고 기본적으로 CRL 목록을 확인하지 않습니다.
CA는 웹 서버 인증서에 서명합니다. 브라우저는 이미 (루트 인증서에있는) CA 공개 키를 가지고 있기 때문에 CA에 액세스하지 않고 인증서를 인증 할 수 있습니다. CA 액세스가 필요한 유일한 것은 인증서가 취소되었는지 확인하는 것입니다.
인증 기관은 개인 키로 서명 된 인증서를 발급합니다. 귀하의 브라우저는 신뢰할 수있는 CA를 위해 공개 키를 저장합니다. 보안 트랜잭션 요청을 받으면 브라우저는 공개 키로 연결된 호스트가 제공 한 인증서의 루트를 확인하여 일치하는 개인 키로 실제로 서명되었는지 확인합니다.
호스트는 신뢰할 수있는 제 3 자 (CA)가 서명 한 인증서를 저장하며 브라우저는 동일한 제 3 자의 공개 키를 저장합니다. 거래가 시작되면 호스트는 브라우저가 확인할 수 있도록 해당 인증서를 제시하면됩니다. 신뢰할 수있는 제 3자가 트랜잭션 시간을 개입 할 필요가 없습니다.
이것은 PGP와 같은 시스템으로, 통신하는 사람의 공개 키를 얻으려면 제 3 자에게 문의해야합니다. PGP를 사용하면 데이터를 암호화/해독하기 때문에 시스템이 다르게 작동 할 수 있습니다. 인증서를 사용하면 신원을 인증하는 것뿐입니다.
좋은 답변, 나는 CA의 후속 조치는 전형적으로 verisign.com, godaddy.com 등입니다 ... 요즘 어디에서나 나타나고있는 것처럼 보입니다. 브라우저가 브라우저를 "신뢰"하기 전에 CA의 인증서를 미리 설치해야하므로 이론적으로 자신의 CA를 설정하고 스푸핑을 시작할 수 없습니다. 엔터프라이즈 보안의 경우 사용자가 브라우저 보안 경고없이 SSL과 함께 사용할 CA 인증서를 설치하게 할 수 있습니다. –
감사합니다 - 이것은 5 ~ 10 분 또는 검색 후 내가 웹에서 찾은 최고의 대답이었습니다. 매우 감사. –
웹 브라우저에는 신뢰할 수있는 루트 인증서 목록이 있습니다. 이들은 CA의 공개 키입니다. 브라우저는 이러한 CA의 개인 키가 실제로 비공개이며, 해당 개인 키 중 하나 (혐의 웹 서버의 인증서 포함)에 의해 암호화 된 것이 실제로 CA에서 왔음을 신뢰할 수 있다고 말합니다.
인증서에는 CA의 개인 키로 암호화 된 웹 서버의 공개 키와 웹 서버 주소 (및 회사 이름 등)가 들어 있습니다. 이 암호화는 웹 사이트 소유자가 CA에서 인증서를 구입할 때 한 번 수행됩니다. 그런 다음 웹 사이트 소유자는 https 요청을 할 때 인증서를 보관하여 사용자에게 보냅니다.브라우저는 웹 서버가 보낸 인증서의 암호를 해독하기 위해 CA의 공개 키 (이미 컴퓨터에있는)를 사용할 수 있고 인증서에 https 서비스 호스트와 일치하는 호스트 주소가 포함되어 있음을 해독 된 인증서에서 확인하므로, 브라우저는 호스트의 공용 키 (CA의 공개 키를 사용하여 암호 해독 됨)가 인증 된 것으로 결론 내립니다. 웹 호스트가 일상적으로 제공하는 인증서는 여전히 호스트를 스푸핑하는 임의의 사람이 올 수도 있지만 최소한 통신하려는 https 서비스 호스트의 인증 된 공개 키가 들어 있다고 확신 할 수 있습니다.
그러면 호스트의 공개 키로 암호화 된 데이터 (신용 카드 번호 등)를 보낼 수 있으며 호스트의 개인 키만 데이터를 해독 할 수 있습니다. 거래 중 CA와의 통신이 필요하지 않았습니다.
많은 곳에서 암호화 및 암호 해독이라고하는 것은 실제로 * 서명하고 * 서명을 확인하는 것입니다. "* [...]에 대해서는 여전히 임의의 사람이 올 수 있습니다. [...] *": 브라우저가 인증서의 호스트 이름도 확인하는 이유입니다. – Bruno
브루노에게 설명해 주셔서 감사합니다. "서명"이 실제로 무언가를 암호화하지 않습니까? Verisign이 인증서에 서명 한 사실은 Verisign의 공개 키가 서명을 해독 할 수 있다는 것입니다. 이 서명에는 웹 서버의 IP 주소와 도메인 이름이 포함되어 있으므로 개인 키로 암호화를 사용하는 CA 만 웹 호스트의 IP/DN을 인증서에 넣을 수 있습니다. –
내가 이해하는 바대로 확인은 인증서 요청의 정보를 인증서 요청/수신자의 발신자와 비교하는 CA의 행위를 나타내며 브라우저의 인증서 내용 비교 (CA의 공개 키를 사용하여 해독 됨) 인증서를 제시하는 웹 호스트의 IP 주소 및 도메인 이름 저는 전문가가 아니므로 가르쳐야 할 필요가 있습니다. 도움을 주셔서 감사합니다! –
CA에서 제공 한 인증서는 웹 서버 (예 : IIS)에 설치되고 해당 웹 응용 프로그램에 매핑됩니다. 브라우저가 CA에 연결되는 이유는 알 수 없습니다. – Cerebrus