http 대 https의 차이점은 무엇입니까? SSL 암호화 프로세스에 대한 자세한 설명

인터넷이 급속도로 발전하면서 많은 사람들이 위챗 마케팅 과 공식 계정 홍보를 원하지만, 온라인 마케팅이 효과적이지 않다고 불평합니다 . 사실, 뉴미디어 전문가들이 온라인 마케팅을 효과적으로 하는 가장 좋은 방법은 검색 엔진을 통해 트래픽을 유도하는 것 입니다.

따라서 검색 엔진은 오늘날 가장 인기 있는 온라인 마케팅 방법 중 하나입니다.

또한 검색 엔진 Google과 Baidu는 https가 검색 엔진 순위 메커니즘에 포함되어 있다고 공개적으로 밝혔습니다.

특히 전자상거래 웹사이트의 경우 , 검색 순위 향상뿐만 아니라 사용자 웹사이트 보안 강화에도 도움이 되는 HTTPS 암호화 프로토콜을 사용하는 것이 좋습니다.

하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol) HTTP 프로토콜은 웹 브라우저와 웹 서버 간에 정보를 전송하는 데 사용됩니다. HTTP 프로토콜은 콘텐츠를 일반 텍스트로 전송하며 어떠한 형태의 데이터 암호화도 제공하지 않습니다. 공격자가 웹 브라우저와 웹 서버 간의 연결을 가로채는 경우 HTTP 프로토콜은 프로토콜은 신용 카드 번호, 비밀번호 및 기타 결제 정보와 같은 일부 민감한 정보를 전송하는 데 적합하지 않습니다.

HTTP 프로토콜의 이러한 결함을 해결하기 위해 다른 프로토콜인 보안 소켓 레이어 하이퍼텍스트 전송 프로토콜 HTTPS를 사용해야 합니다. 데이터 전송의 보안을 위해 HTTPS는 HTTP에 SSL 프로토콜을 추가하고 SSL은 인증서를 사용하여 확인합니다. 서버. , 브라우저와 서버 간의 통신을 암호화합니다.

XNUMX. HTTP와 HTTPS의 기본 개념

HTTP: 인터넷에서 가장 널리 사용되는 네트워크 프로토콜입니다. 클라이언트 측 및 서버 측 TCP(요청 및 응답 표준)입니다. WWW 서버에서 로컬 브라우저로 하이퍼텍스트를 전송하는 데 사용됩니다. 서버는 더 많은 효율적이며 결과적으로 네트워크 전송이 줄어듭니다.

HTTPS: 보안 HTTP 채널로, HTTP의 보안 버전, 즉 HTTP에 SSL 계층을 추가한 것으로 HTTPS의 보안 기반이 SSL이므로 암호화의 세부 내용에는 SSL이 필요합니다.

HTTPS 프로토콜의 주요 기능은 데이터 전송의 보안을 보장하기 위해 정보 보안 채널을 설정하는 것과 웹사이트의 신뢰성을 확인하는 두 가지 유형으로 나눌 수 있습니다.

XNUMX. HTTP와 HTTPS의 차이점은 무엇입니까?

HTTP 프로토콜에 의해 전송되는 데이터는 암호화되지 않은 일반 텍스트이므로 HTTP 프로토콜을 사용하여 개인 정보를 전송하는 것은 매우 안전하지 않습니다. 이러한 개인 데이터를 암호화하여 전송할 수 있도록 넷스케이프는 SSL을 설계했습니다. HTTPS용 (Secure Sockets Layer) 프로토콜은 HTTP 프로토콜이 전송하는 데이터를 암호화하기 위해 탄생했습니다.

즉, HTTPS 프로토콜은 SSL+HTTP 프로토콜로 구성된 네트워크 프로토콜로 암호화된 전송 및 신원 인증을 수행할 수 있으며 http 프로토콜보다 안전합니다.

HTTPS와 HTTP의 주요 차이점은 다음과 같습니다.

• 1. https 프로토콜은 인증서 신청을 위해 ca로 이동해야 하며 일반적으로 무료 인증서가 거의 없기 때문에 소정의 수수료가 필요합니다.
• 2. http는 하이퍼텍스트 전송 프로토콜이며 정보는 일반 텍스트로 전송되며 https는 보안 SSL 암호화 전송 프로토콜입니다.
• 3. http와 https는 완전히 다른 연결 방식과 다른 포트를 사용하는데 전자는 80, 후자는 443입니다.
• 4. http의 연결은 매우 간단하고 stateless하며, HTTPS 프로토콜은 SSL+HTTP 프로토콜로 구성된 네트워크 프로토콜로 HTTP 프로토콜보다 안전한 암호화 전송 및 신원 인증을 수행할 수 있습니다.

XNUMX. HTTPS 및 SSL 암호화 프로세스에 대한 자세한 설명

HTTPS가 정보를 암호화하여 제XNUMX자가 민감한 정보를 얻는 것을 방지할 수 있다는 사실을 우리는 모두 알고 있습니다. 따라서 많은 은행 웹사이트나 이메일, 보안 수준이 더 높은 기타 서비스에서 HTTPS 프로토콜을 사용할 것입니다.

1. 클라이언트가 HTTPS 요청을 시작합니다.

즉, 사용자가 브라우저에 https URL을 입력한 다음 서버의 포트 443에 연결합니다.

2. 서버 구성

HTTPS 프로토콜을 사용하는 서버에는 디지털 인증서 세트가 있어야 하며, 이 인증서는 직접 만들거나 조직에 적용할 수 있습니다.차이점은 계속 액세스하려면 먼저 자신이 발급한 인증서를 클라이언트에서 확인해야 한다는 점입니다. 신뢰할 수 있는 회사에서 적용한 인증서는 그렇지 않으며 프롬프트 페이지가 팝업됩니다.

이 인증서는 사실 공개키와 개인키의 쌍으로 공개키와 개인키를 이해하지 못한다면 열쇠와 자물쇠로 상상할 수 있지만 이 키를 가진 사람은 세상에서 단 한 명뿐이다. , 당신은 자물쇠 머리를 다른 사람에게 잠글 수 있습니다. 다른 사람들은 이 자물쇠를 사용하여 중요한 것을 잠그고 당신에게 보낼 수 있습니다. 당신만이 이 열쇠를 가지고 있기 때문에 이 자물쇠로 잠긴 물건을 당신만 볼 수 있기 때문입니다.

3. 인증서 보내기

이 인증서는 실제로 공개 키이지만 인증 기관, 만료 시간 등과 같은 많은 정보를 포함합니다.

4. 클라이언트 파싱 인증서

이 부분의 작업은 클라이언트의 TLS에 의해 수행되며 먼저 발급 기관, 만료 시간 등 공개 키가 유효한지 여부를 확인합니다. 예외가 발견되면 경고 상자가 나타나 다음과 같이 알려줍니다. 인증서에 문제가 있습니다.

인증서에 문제가 없으면 임의의 값을 생성한 후 인증서로 임의의 값을 암호화한다. 위에서 언급한 바와 같이 임의의 값을 자물쇠로 잠그어 열쇠가 없으면 잠긴 것을 볼 수 없도록 한다. 가치 내용.

5. 암호화된 정보의 전송

이 부분은 인증서로 암호화된 임의의 값을 전송하는데, 목적은 서버가 이 임의의 값을 얻도록 하고, 이 임의의 값을 통해 클라이언트와 서버 간의 통신을 암호화 및 복호화할 수 있도록 하는 것입니다.

6. 서비스 세그먼트 복호화 정보

서버는 개인키로 복호화한 후 클라이언트가 보낸 임의의 값(개인키)을 획득하여 그 값을 통해 대칭적으로 내용을 암호화하는데, 이와 같이 개인키를 모르면 내용을 얻을 수 없으며, 클라이언트와 서버 모두 개인 키를 알고 있으므로 암호화 알고리즘이 충분히 강력하고 개인 키가 충분히 복잡하다면 데이터는 충분히 안전합니다.

7. 암호화된 정보의 전송

정보의 이 부분은 서비스 세그먼트의 개인 키로 암호화된 정보이며 클라이언트 측에서 복원할 수 있습니다.

8. 클라이언트 복호화 정보

클라이언트는 서비스 세그먼트가 보낸 정보를 미리 생성된 개인키로 복호화하여 복호화된 내용을 얻게 되며, 제XNUMX자가 그 전 과정에서 데이터를 감시한다 해도 소용이 없다.

넷째, HTTPS에 대한 검색엔진의 태도

Baidu는 사용자 개인 정보의 "제2010자" 스니핑 및 하이재킹을 해결하기 위해 전체 사이트 HTTPS 암호화 검색 서비스를 출시했습니다. 실제로 이미 5년 2014월 Google은 HTTPS 웹 페이지를 크롤링하는 HTTPS 암호화 검색 서비스를 제공하기 시작했습니다. 이번 호에서 Baidu는 9년 XNUMX월 발표에서 "Baidu는 HTTPS 웹 페이지를 적극적으로 크롤링하지 않을 것"이라고 밝혔고 Google은 알고리즘 업데이트에서 "같은 조건에서 HTTPS 암호화 기술을 사용하는 사이트가 더 나은 검색 순위를 가질 것입니다. 이점"이라고 알고리즘 업데이트에서 밝혔습니다.

그렇다면 이러한 환경에서 웹사이트 소유자는 "위험한" HTTPS 프로토콜을 채택해야 할까요? 그리고 HTTPS는 검색 엔진 SEO 에 어떤 영향을 미칠까요 ?

1. 구글의 태도

HTTPS 사이트의 포함에 대한 구글의 태도는 HTTP 사이트의 그것과 다르지 않으며 검색 순위 알고리즘에서 "보안 암호화 사용 여부"(HTTPS)를 참조 요소로 고려하기까지 합니다. HTTPS 암호화 기술을 사용하는 웹 사이트는 더 나은 결과를 얻을 수 있습니다. 전시 기회가 더 많고 순위도 비슷한 사이트의 HTTP 사이트보다 유리합니다.

그리고 구글은 "모든 웹마스터가 HTTP 대신 HTTPS 프로토콜을 사용할 수 있기를 바란다"고 분명히 밝혔는데, 이는 "모든 곳에서 HTTPS"라는 목표를 달성하겠다는 의지를 보여줍니다.

2. 바이두의 태도

과거 Baidu의 기술은 "https 페이지를 적극적으로 크롤링하지 않을 것"이라고 말하면서 상대적으로 후진적이었지만 "많은 https 페이지를 포함할 수 없다"에 대해 "걱정"하기도 했습니다. 2014년 9월 16일까지 Baidu는 "https 사이트를 구축하는 방법." "https 사이트의 Baidu 친화성 향상"을 위한 네 가지 제안과 구체적인 조치를 제공하는 "Baidu에 친숙함" 문제에 대한 기사가 게시되었습니다.

1. Baidu 검색 엔진에서 인덱싱해야 하는 https 페이지에 대해 http 액세스 가능한 버전을 만듭니다.

2. 방문자는 사용자 에이전트로 식별되며, 바이두 더블스파이더는 HTTP 페이지로 리디렉션됩니다. 일반 사용자가 바이두 검색 엔진을 통해 이 페이지에 접속하면 301 리디렉션을 통해 해당 HTTPS 페이지로 이동합니다. 이미지에서 위쪽은 바이두에 의해 색인된 HTTP 버전이고, 아래쪽은 사용자가 클릭했을 때 자동으로 리디렉션되는 HTTPS 버전입니다.

3. http 버전은 홈페이지용으로만 만들어지는 것이 아니라 다른 중요한 페이지들도 http 버전으로 만들어 서로 연결해야 하는데 이런 일이 일어나서는 안 됩니다: 홈페이지 http 페이지의 링크가 여전히 https 페이지로 연결되는 Baiduspider가 계속 크롤링할 수 없게 만듭니다.—— 전체 사이트에 대해 하나의 홈 페이지만 포함할 수 있는 상황이 발생했습니다.

4. 뉴스처럼 암호화가 필요하지 않은 콘텐츠는 서브도메인을 사용하여 호스팅할 수 있습니다. 예를 들어, 알리페이 웹사이트에서는 핵심 암호화 콘텐츠는 HTTPS로 호스팅되는 반면, 바이두스파이더가 직접 크롤링할 수 있는 콘텐츠는 서브도메인에 호스팅됩니다.

아래 링크의 Computer Science House의 테스트에 따르면 HTTP와 연결을 설정하는 데 114밀리초, HTTPS와 연결을 설정하는 데 436밀리초, SSL 부분에 네트워크 지연 및 오버헤드를 포함하여 322밀리초가 걸립니다. ssl 자체의 암호화 및 복호화(서버는 클라이언트의 정보에 따라 새로운 마스터 키 생성 여부를 결정하고, 서버는 마스터 키에 응답하고 마스터 키로 인증된 메시지를 클라이언트에 반환, 서버는 클라이언트에게 디지털 서명과 공개 키를 요청함).

XNUMX. HTTPS는 HTTP보다 얼마나 많은 리소스를 소비합니까?

HTTPS는 실제로 SSL/TLS 위에 구축된 HTTP 프로토콜입니다. 따라서 HTTPS가 HTTP에 비해 서버 리소스를 얼마나 더 많이 사용하는지 비교하려면 SSL/TLS 자체가 얼마나 많은 서버 리소스를 소비하는지가 중요하다고 천웨이량은 생각합니다.

HTTP는 TCP 3방향 핸드셰이크를 사용하여 연결을 설정하고 클라이언트와 서버는 XNUMX개의 패킷을 교환해야 합니다.

9개의 TCP 패킷 외에 HTTPS도 SSL 핸드셰이크에 필요한 12개의 패킷을 추가해야 하므로 총 XNUMX개의 패킷이 있습니다.

SSL 연결이 설정되면 이후 암호화 방식은 CPU 부하가 낮은 3DES와 같은 대칭 암호화 방식으로 변경됩니다. SSL 연결 설정에 사용되는 비대칭 암호화 방식과 비교했을 때, 대칭 암호화의 CPU 부하는 무시할 수 있을 정도입니다. 그러나 이로 인해 문제가 발생할 수 있는데, SSL 세션을 자주 재구축해야 하는 경우 서버 성능에 치명적인 영향을 미칠 수 있습니다. HTTPS keepalive를 활성화하면 단일 연결의 성능 문제를 완화할 수 있지만, 동시 접속 사용자가 많은 대규모 웹사이트의 경우 로드 밸런싱 기반의 전용 SSL 종료 프록시가 필수적입니다. 웹 서비스는 SSL 종료 프록시 뒤에 배치됩니다. SSL 종료 프록시는 F5와 같은 하드웨어 기반일 수도 있고, 위키피디아에서 사용하는 Nginx와 같은 소프트웨어 기반일 수도 있습니다.

그렇다면 HTTPS를 도입하면 서버 리소스 사용량이 얼마나 증가할까요? 2010년 1월 , Gmail은 HTTPS를 전면 도입했습니다. 프런트엔드 SSL 처리 서버의 CPU 사용률은 1% 미만으로 증가했고, 연결당 메모리 사용량은 20KB 미만이었으며, 네트워크 트래픽은 2% 미만으로 증가했습니다. Gmail은 분산 처리를 위해 N개의 서버를 사용하는 것으로 추정되므로 CPU 사용률 데이터는 큰 의미가 없습니다. 연결당 메모리 사용량과 네트워크 트래픽 데이터가 더 중요합니다. 또한, 해당 기사에서는 단일 코어가 초당 약 1500건의 핸드셰이크(1024비트 RSA 기준)를 처리할 수 있다고 언급하는데, 이는 매우 의미 있는 수치입니다.

XNUMX. HTTPS의 장점

공격자가 시작할 곳을 찾지 못하는 것은 바로 HTTPS가 매우 안전하기 때문입니다.웹마스터의 관점에서 HTTPS의 장점은 다음과 같습니다.

1. SEO 측면

구글은 2014년 8월 "HTTPS로 암호화된 사이트가 동등한 HTTP 사이트보다 검색 결과에서 더 높은 순위를 차지할 것"이라며 검색 엔진 알고리즘을 조정했다.

2. 보안

HTTPS가 절대적으로 안전한 것은 아니지만 루트 인증서를 마스터하는 조직과 암호화 알고리즘을 마스터하는 조직도 메시지 가로채기(man-in-the-middle) 공격을 수행할 수 있지만 HTTPS는 다음과 같은 이점이 있는 현재 아키텍처에서 여전히 가장 안전한 솔루션입니다.

(1) HTTPS 프로토콜을 사용하여 사용자와 서버를 인증하여 데이터가 올바른 클라이언트와 서버로 전송되도록 합니다.

(2) HTTPS 프로토콜은 SSL+HTTP 프로토콜로 구성된 네트워크 프로토콜로 암호화된 전송 및 신원 인증을 수행할 수 있으며 HTTP 프로토콜보다 안전하므로 전송 과정에서 데이터 도난 및 변경을 방지하고 데이터의 무결성.

(3) HTTPS는 현재 아키텍처에서 가장 안전한 솔루션으로 절대적으로 안전한 것은 아니지만 메시지 가로채기(man-in-the-middle) 공격의 비용이 크게 증가합니다.

XNUMX. HTTPS의 단점

HTTPS는 큰 장점이 있지만 여전히 몇 가지 단점이 있는데, 구체적으로 다음 두 가지가 있습니다.

1. SEO 측면

ACM CoNEXT 데이터에 따르면 HTTPS 프로토콜을 사용하면 페이지 로딩 시간이 거의 50% 증가하고 전력 소비가 10%에서 20% 증가합니다. 또한 HTTPS 프로토콜도 캐시에 영향을 미치고 데이터 오버헤드 및 전력 소비를 증가시킵니다. , 심지어 기존 보안 조치도 영향을 받으며 그에 따라 영향을 받습니다.

또한 HTTPS 프로토콜의 암호화 범위가 상대적으로 제한되어 해커 공격, 서비스 거부 공격, 서버 하이재킹에 거의 영향을 미치지 않습니다.

가장 중요한 것은 SSL 인증서의 신용 체인 시스템이 안전하지 않다는 것입니다. 특히 일부 국가에서 CA 루트 인증서를 제어할 수 있는 경우 메시지 가로채기(man-in-the-middle) 공격이 가능합니다.

2. 경제적 측면

(1) SSL 인증서는 돈이 필요합니다. 인증서가 강력할수록 비용이 높아집니다. 개인 웹사이트는 무료 SSL 인증서를 사용할 수 있습니다.

(2) SSL 인증서는 일반적으로 IP에 바인딩해야 하며 여러 도메인 이름을 동일한 IP에 바인딩할 수 없습니다. IPv4 리소스는 이러한 소비를 지원할 수 없습니다(SSL에는 이 문제를 부분적으로 해결할 수 있는 확장이 있지만 번거롭고 브라우저가 필요하며, 운영 체제 지원, Windows XP는 XP의 설치 기반을 고려할 때 이 확장을 지원하지 않습니다. 이 기능은 거의 쓸모가 없습니다.

(3) HTTPS 연결 캐싱은 HTTP만큼 효율적이지 않으며 트래픽이 많은 웹 사이트는 필요하지 않으면 사용하지 않으며 트래픽 비용이 너무 높습니다.

(4) HTTPS 연결 서버측 리소스 소모가 훨씬 더 많고 방문자가 조금 더 많은 웹사이트를 지원하려면 더 많은 투자가 필요합니다 HTTPS를 사용하는 경우 대부분의 컴퓨팅 리소스가 유휴 상태라는 가정을 기반으로 한 VPS의 평균 비용 위로.

(5) HTTPS 프로토콜의 핸드셰이크 단계는 시간이 많이 걸리고 웹사이트의 해당 속도에 부정적인 영향을 미치므로 필요하지 않은 경우 사용자 경험을 희생할 이유가 없습니다.

XNUMX. 웹사이트를 HTTPS로 암호화해야 합니까?

Google과 Baidu는 모두 "HTTPS를 다르게 바라보지만" 이것이 웹마스터가 웹사이트 프로토콜을 HTTPS로 변환해야 한다는 의미는 아닙니다!

먼저 구글에 대해 이야기하자면 구글은 "HTTPS 암호화 기술을 사용하는 웹사이트가 더 높은 순위를 차지할 수 있다"고 계속 강조하고 있지만, 이것이 '숨은 의도'임을 배제할 수는 없다.

한 외국 분석가는 이 문제에 대해 다음과 같이 말했습니다. Google이 이러한 움직임(알고리즘 업데이트, 검색 엔진 순위에 대한 참조 요소로 HTTPS 암호화 기술을 사용할지 여부)을 한 이유는 사용자의 검색 경험과 인터넷을 개선하기 위한 것이 아닐 수 있습니다. 보안 문제는 '프리즘 게이트' 스캔들로 '손실'을 만회하기 위한 것으로, '보안 임팩트 랭킹' 기치를 높이 들고 'HTTPS'를 외치며 '자아를 희생하라'는 기치 아래 전형적인 이기적인 행동이다. 모든 곳에서" "슬로건을 선택한 다음, 대다수의 웹마스터가 HTTPS 프로토콜 캠프에 기꺼이 참여할 수 있습니다.

웹사이트가 전자상거래 / 소규모 비즈니스 플랫폼, 금융, 소셜 네트워킹 또는 기타 분야에 속하는 경우 HTTPS 프로토콜을 사용하는 것이 가장 좋습니다. 블로그, 홍보 웹사이트, 정보 사이트 또는 뉴스 웹사이트인 경우에는 무료 SSL 인증서를 사용할 수 있습니다.

XNUMX. 웹마스터는 HTTPS 사이트를 어떻게 구축합니까?

HTTPS 사이트 구축에 관해서는 SSL 프로토콜을 언급해야 합니다. SSL은 Netscape가 채택한 최초의 네트워크 보안 프로토콜이며, 공개 키 기술을 사용하여 TCP/IP(Transmission Communication Protocol)에서 구현되는 보안 프로토콜입니다. , SSL은 다양한 종류의 네트워크를 폭넓게 지원하며 XNUMX가지 기본 보안 서비스를 제공하며 모두 공개 키 기술을 사용합니다.

HTTPS 사이트 구축에 관해서는 SSL 프로토콜을 언급해야 합니다. SSL은 Netscape가 채택한 최초의 네트워크 보안 프로토콜이며, 공개 키 기술을 사용하여 TCP/IP(Transmission Communication Protocol)에서 구현되는 보안 프로토콜입니다. , SSL은 다양한 종류의 네트워크를 폭넓게 지원하며 XNUMX가지 기본 보안 서비스를 제공하며 모두 공개 키 기술을 사용합니다.

1. SSL의 역할

(1) 데이터가 올바른 클라이언트와 서버로 전송되도록 사용자와 서버를 인증합니다.

(2) 데이터를 암호화하여 데이터가 도중에 도난당하는 것을 방지합니다.

(3) 데이터의 무결성을 유지하고 전송 과정에서 데이터가 변경되지 않도록 합니다.

SSL 인증서는 SSL 통신에서 양 당사자의 신원을 확인하는 디지털 파일을 말하며 일반적으로 서버 인증서와 클라이언트 인증서로 구분됩니다. 우리가 일반적으로 말하는 SSL 인증서는 주로 서버 인증서를 의미합니다. SSL 인증서는 신뢰할 수 있는 디지털 인증 기관 CA(VeriSign, GlobalSign, WoSign 등)에서 발급, 서버 인증 및 데이터 전송 암호화 기능으로 서버의 신원을 확인한 후 발급, Extended Validation(EV) SSL 인증서로 구분, OV(조직 유효성 검사) SSL 인증서 및 DV(도메인 이름 확인 유형) SSL 인증서입니다.

2. SSL 인증서 신청을 위한 3가지 주요 단계

SSL 인증서를 신청하는 세 가지 주요 단계가 있습니다.

(1) CSR 파일을 만듭니다.

소위 CSR은 신청자가 생성한 인증서 보안 요청 인증서 요청 파일입니다.생산 과정에서 시스템은 두 개의 키를 생성합니다. 하나는 CSR 파일인 공개 키이고 다른 하나는 개인 키입니다. 서버에 저장되는 것입니다.

CSR 파일을 만들기 위해 신청자는 WEB SERVER 문서, 일반 APACHE 등을 참조하고 OPENSSL 명령줄을 사용하여 KEY+CSR2 파일을 생성하고 Tomcat, JBoss, Resin 등은 KEYTOOL을 사용하여 JKS 및 CSR 파일을 생성하고 IIS는 보류 중인 요청 및 CSR 파일.

(2), CA 인증

CSR을 CA에 제출하면 CA에는 일반적으로 두 가지 인증 방법이 있습니다.

①.도메인명 인증 : 일반적으로 관리자의 메일함을 인증하는 방식으로 빠르지만 발급된 인증서에 기업명이 포함되어 있지 않습니다.

②, 기업 문서 인증: 기업의 영업 허가증을 제공해야 하며 일반적으로 3-5영업일이 소요됩니다.

위의 두 가지 방법을 동시에 인증해야 하는 인증서도 있는데 이를 EV 인증서라고 하는데 이 인증서는 IE2 이상 브라우저의 주소창을 초록색으로 만들 수 있어 인증도 가장 까다롭다.

(3) 인증서 설치

CA로부터 인증서를 받은 후 서버에 배포할 수 있으며 일반적으로 APACHE 파일은 KEY+CER을 파일에 직접 복사한 다음 HTTPD.CONF 파일을 수정하며 TOMCAT 등은 인증서 CER을 가져와야 합니다. CA에서 발행한 파일을 JKS 파일로 복사하고 서버에 복사한 다음 SERVER.XML을 수정합니다. IIS는 보류 중인 요청을 처리하고 CER 파일을 가져와야 합니다.

XNUMX. 무료 SSL 인증서 추천

SSL 인증서를 사용하면 정보 보안이 강화될 뿐만 아니라 웹사이트에 대한 사용자 신뢰도도 높아집니다. 하지만 많은 웹사이트 소유자들이 웹사이트 구축 비용 때문에 SSL 인증서 도입을 망설입니다. 온라인 시장에서는 무료 서비스가 항상 활발하게 제공되고 있으며, 무료 호스팅 옵션이 있는 것처럼 무료 SSL 인증서도 존재합니다. 최근 모질라, 시스코, 아카마이, 아이덴트러스트, EFF, 그리고 미시간 대학교의 연구원들이 '렛츠 인크립트(Let's Encrypt)' CA 프로젝트를 시작하여 올여름부터 웹사이트에 무료 SSL 인증서와 인증서 관리 서비스를 제공할 계획이라고 발표했습니다(단, 고급 및 복잡한 인증서는 유료입니다). 이 프로젝트는 인증서 설치 과정을 간소화하여 설치 시간을 20~30초로 단축합니다.

복잡한 인증서가 필요한 대형 및 중형 웹사이트인 경우가 많으며 개인 블로그와 같은 소규모 사이트에서는 무료 SSL 인증서를 먼저 시도할 수 있습니다.

아래에서 천웨이량의 블로그는 클라우드플레어 SSL과 네임칩과 같은 몇 가지 무료 SSL 인증서를 더 소개합니다.

1. 클라우드플레어 SSL

CloudFlare는 미국에서 CDN 서비스를 제공하는 웹사이트로, 전 세계에 자체 CDN 서버 노드를 가지고 있습니다. 국내외 많은 대기업이나 웹사이트에서 CloudFlare의 CDN 서비스를 이용하고 있습니다. 물론 국내 웹마스터들이 가장 많이 사용하는 는 CloudFlare의 무료 CDN입니다.또한 매우 좋습니다.CloudFlare에서 제공하는 무료 SSL 인증서는 UniversalSSL, 즉 범용 SSL입니다.사용자는 인증 기관에 인증서를 신청 및 구성하지 않고도 SSL 인증서를 사용할 수 있습니다.CloudFlare는 SSL 암호화를 제공합니다. 모든 사용자(무료 사용자 포함), 웹 인터페이스 5분 이내에 인증서가 설정되고 24시간 이내에 자동 배포가 완료되어 웹 사이트 트래픽에 대해 ECDSA(Elliptic Curve Digital Signature Algorithm) 기반 TLS 암호화 서비스를 제공합니다.

2. 이름싸다

NameCheap은 2000년에 설립된 선도적인 ICANN 인증 도메인 이름 등록 및 웹사이트 호스팅 회사로 무료 DNS 확인, URL 전달(원래 URL 숨길 수 있음, 301 리디렉션 지원) 및 기타 서비스를 제공합니다. 또한 NameCheap은 수년간의 SSL 인증서 무료 서비스.

3. 암호화하자

Let's Encrypt는 최근 큰 인기를 끌고 있는 무료 SSL 인증서 발급 프로젝트입니다. Let's Encrypt는 ISRG에서 제공하는 무료 무료 공공 복지 프로젝트로 인증서가 자동으로 발급되지만 인증서의 유효 기간은 90일입니다.개인 사용 또는 임시 사용에 적합하며 브라우저에서 자체 서명된 인증서를 신뢰할 수 없다는 메시지를 더 이상 참을 필요가 없습니다.

사실 천웨이량의 블로그도 최근에 렛츠인크립트를 사용할 계획이라고 해요 ^_^

Let's Encrypt 무료 SSL 인증서 신청 방법에 대한 자세한 내용은 " Let's Encrypt 인증서 신청 방법 " 문서를 참조하십시오 .