기술적 SEO는 다른 모든 최적화 노력의 기초를 형성하며, 보안 결함이 있는 웹사이트는 방문자의 관심을 끌거나 SERP의 최상위에 오르기 어렵습니다.
이전 포스팅에서 데이터의 중요성에 대해 다루었습니다. HTTPS로 이동. 이제 웹사이트에 저장된 정보를 손상시키고 검색 성능에 영향을 줄 수 있는 SSL/TLS 인증서와 잠재적인 오류를 자세히 살펴보겠습니다. 우리는 SSL/TLS 오류가 무엇인지 다루고 모든 종류의 오류를 해결하기 위한 솔루션을 제공할 것입니다.
SSL/TLS란 무엇입니까?
SSL(Secure Sockets Layer)은 네트워크 전반에 걸쳐 정보의 안전한 이동을 보장하며 TLS(Transport Layer Security)는 SSL의 업데이트된 버전입니다. 둘 다 사용자 브라우저와 웹사이트 간의 정보를 보호하는 표준 암호화 기술을 나타냅니다. SSL은 1995년에 도입되었으며 1999년에 TLS로 업그레이드되어 민감한 데이터 보호에 대한 수요 증가에 부응했습니다.
SSL/TLS 용어는 HTTPS(Hypertext Transfer Protocol Secure)와 상호 연결됩니다. HTTPS 연결은 웹사이트가 SSL 또는 TLS 기술을 통해 데이터를 전송한다는 것을 의미합니다.
프로토콜은 지속적으로 업데이트되어 모든 이전 버전이 더 이상 사용되지 않습니다. 이에 대해서는 오래된 SSL/TLS 문제를 설명할 때 더 자세히 논의하겠습니다. 중요한 점은 다른 모든 버전이 TLS보다 열등하므로 최신 버전의 TLS를 사용하는 것이 가장 좋다는 것입니다.
SSL/TLS가 웹사이트 순위에 미치는 영향
Google은 사용자 보안을 최우선 순위로 두고 SSL/TLS 인증서 관련 요구사항을 강화합니다. HTTPS는 2014년부터 순위 신호. 다른 검색 엔진에서는 보안이 순위에 어떤 영향을 미치는지 별로 언급하지 않았으며 2014년에는 빙도 발표했다 HTTPS 웹사이트의 순위를 더 높일 계획은 없었습니다.
그러나 보안 프로토콜과 암호화의 가치를 과소평가해서는 안 됩니다. 취약점으로 인해 사용자 데이터가 노출될 수 있고, SSL/TLS 인증서 문제로 인해 웹 사이트에 접근할 수 없게 될 수 있으며, 브라우저에 표시되는 보안 경고로 인해 잠재적인 방문자가 겁을 먹을 수 있습니다.
2017년, 구글 크롬이 시작되었습니다. '안전하지 않음' 경고 표시 민감한 정보(신용 카드 정보 또는 비밀번호)를 요구하는 HTTPS가 아닌 페이지에서 XNUMX년 후에는 보안 프로토콜로 전환하지 않은 모든 웹사이트를 "안전하지 않음"으로 표시하기 시작했습니다. 이제 HTTPS 페이지는 탐색 시간의 90% 이상 Chrome에서.
가장 널리 사용되는 브라우저는 자물쇠 아이콘을 사용하여 안전하지 않은 웹 페이지를 표시합니다. Safari에서는 웹 사이트가 안전하게 암호화된 경우에만 해당 웹 페이지를 볼 수 있으며 Firefox에서는 취소선 자물쇠가 로그인 기능이 있는 HTTP 페이지에 대해 신호를 보냅니다.
SSL/TLS의 이점과 이를 채택하지 않을 경우의 위험성이 표면적으로 드러나는 반면, 실제로 세상은 100% HTTPS와는 거리가 멀습니다. 그만큼 2018 보고서 미국 기업의 웹 서버 중 32% 이상이 SSL/TLS 암호화 등급이 가장 낮고 7% 이상이 취약하고 더 이상 사용되지 않는 프로토콜을 사용하는 것으로 나타났습니다.
암호화하자 전무이사가 설명한다 프로토콜을 관리하기 어렵다는 사실로 인해 SSL/TLS 채택률이 낮습니다. 그러나 SSL/TLS 인증서 획득 및 관리를 자동화하여 웹사이트 소유자에게 큰 도움을 주는 Let's Encrypt와 같은 솔루션이 있습니다. 다양한 유용한 도구를 마음대로 사용할 수 있으므로 웹사이트 보안을 적절하게 유지하는 것이 그리 어렵지 않습니다.
SSL/TLS 오류 유형 및 해결 방법
적절한 암호화의 중요성을 깨닫고 SSL/TLS 인증서를 갖고 있다고 해서 문제가 발생하지 않을 것이라는 보장은 없습니다. 사이트에 주요 SSL/TLS 취약점이 있는지 정기적으로 검사하세요. SE 순위 도구를 사용하면 빠르게 이 작업을 수행할 수 있습니다. 웹사이트 SEO 감사.
왼쪽 탐색 모음에서 웹사이트 감사를 열고 다음으로 이동합니다. 웹 사이트 보안 섹션 문제 보고서 탭 :
좀 더 자세한 현장 점검을 원하시면, 웹사이트 감사 체크리스트. 여기에는 수행해야 할 모든 기본 점검 사항이 포함되어 있습니다. 그래서 당신은 아무것도 놓치지 않을 것입니다.
이제 다양한 SSL/TLS 문제를 분석하고 각각에 대해 가능한 솔루션을 살펴보겠습니다.
1. 만료된 웹사이트 보안 인증서
모든 SSL/TLS 인증서는 수명이 제한되어 있으며 계속 증가하는 보안 문제로 인해 수년에 걸쳐 계속 축소됩니다. 유효기간은 2011년 2015년, 2018년 2020년, 398년 13년으로 단축됐다. XNUMX년 XNUMX월부터 신규 인증서 유효기간은 XNUMX일(XNUMX개월)에 불과하다. Apple은 Safari가 만료 날짜가 더 긴 인증서를 허용하지 않을 것이라고 처음으로 발표했습니다. Google과 Mozilla는 곧 이 결정을 따랐습니다.
인증서 만료 정보는 브라우저를 통해 누구에게나 공개됩니다.
SSL/TLS 인증서가 만료되면 어떻게 되나요? 귀하의 웹사이트에 접속할 수 없게 되며, 해당 웹사이트를 방문하려는 사용자는 브라우저에 경고 메시지를 보게 됩니다. 이로 인해 방문자는 유턴하게 되고 귀하의 비즈니스는 트래픽, 수익 및 평판 손실에 직면할 수 있습니다.
어떻게 고치는 지
이러한 상황을 방지하려면 만료 날짜를 모니터링하고 적시에 인증서를 업데이트하십시오. 다음과 같은 자동화된 솔루션이 있습니다. 암호화하자. or AWS 인증서 관리자 SSL/TLS 인증서와 다음과 같은 모니터링 도구를 추적하는 데 도움이 됩니다. 세마텍스트 인증서가 만료되기 전에 여러 경고를 보냅니다. 많은 인증서 발급자는 자동 갱신을 설정할 수 있는 기회도 제공합니다.
하지만 웹사이트 보안 인증서가 만료된 경우 어떻게 문제를 해결할 수 있을까요? 인증서를 수동으로 갱신하거나 새 인증서를 구입해야 합니다. 갱신하거나 구매할 때마다 웹사이트의 신원과 현재 암호화 버전이 검증됩니다. 이 프로세스는 여러 단계를 거칩니다.
- 인증서 유형 선택. 대부분의 발급 기관은 내부 네트워크부터 대규모 웹사이트까지 다양한 요구에 맞는 여러 옵션을 제공합니다. 인증서를 갱신하고 다른 유형으로 전환하고 싶지 않은 경우에는 이 단계가 적용되지 않습니다. 와일드카드 인증서 웹사이트에 하위 도메인을 추가할 때). 인증서를 구입할 때 온라인에서 판매되는 사기성 인증서가 있으므로 사이트를 보안 위험에 빠뜨릴 수 있다는 점에 유의하십시오. 구매하기 전에 발급기관에 대해 알아보세요. 설정할 수 있습니다 CAA 레코드 신뢰할 수 없는 인증 기관을 피하기 위해. 신뢰할 수 있는 일부 CA는 다음과 같습니다. Digicert, 글로벌사인, 섹 티고, 트 웨테.
- 인증서 서명 요청(CSR) 생성. 호스팅 공급자로부터 CSR을 생성해야 합니다. 프로세스는 매우 간단하지만 웹 호스트에 따라 다릅니다. 결과적으로 SSL/TLS 공급자와 함께 업로드할 CRS와 사용 중인 OS에서 찾을 수 있는 개인 키 파일이 있습니다.
- 인증서 활성화 및 유효성 검사. 이메일, CNAME 레코드 또는 확인 파일을 통해 도메인 소유권을 확인해야 합니다. 이 프로세스는 공급자에 따라 다르므로 웹 호스트를 통해 세부 정보를 확인할 수 있습니다.
- 확인. 인증서를 설치한 후 SSL/TLS 검사를 실행하여 모든 것이 올바르게 작동하는지 확인하세요. 온라인 확인 도구의 예는 다음과 같습니다.
이 시점에서 HTTPS로 전환 중이고 인증서가 처음 설치되는 경우 웹사이트의 HTTP 트래픽을 HTTPS 버전으로 리디렉션하고 보안 버전을 웹마스터 도구에 추가해야 합니다. 이러한 기술에 대해 자세히 알아보려면 웹사이트를 HTTPS로 이동하는 것에 대한 게시물.
향후 인증서 만료를 방지하려면 만료 알림을 무시하지 말고 편의를 위해 인증서 관리 솔루션을 찾으세요.
2. 비활성 인증서
이 SSL 연결 오류는 브라우저가 아직 유효하지 않은 SSL 인증서를 수신할 때 발생합니다. 요즘에는 인증서 관리자를 사용하여 서버 인증서를 처리하는 것이 일반적입니다. 관리자는 배포 시점부터 유효 기간이 시작되는 새 인증서를 자동으로 배포합니다. 그러나 잘못된 구성이나 기타 요인으로 인해 클라이언트 시스템의 시계가 5분 늦게 설정되면 클라이언트는 인증서를 거부합니다. 이러한 상황은 머신의 시계가 동기화되지 않은 API 클라이언트에서 특히 흔히 발생합니다. 이 SSL 오류로 인해 웹사이트와 사용자 브라우저 사이에 보안 연결을 설정할 수 없어 실망스러울 수 있습니다.
어떻게 고치는 지
아직 활성화되지 않은 인증서를 배포하지 않으려면 서버에 인증서를 배포하기 전에 유효성 시작 시간을 확인하세요. 또한 인증서 관리자를 사용하여 인증서를 관리하는 경우 새 인증서의 세부정보와 함께 인증서 변경에 대한 알림을 수신하는지 확인하세요.
모든 중간 및 루트 인증서가 서버에 제대로 설치되었는지 확인하여 인증서 체인이 검증되었는지 확인하세요. 중간 인증서가 없거나 잘못 설치된 경우 비활성 인증서 오류가 발생할 수 있습니다.
인증서가 올바르게 설치되어 활성화되었는지 확인하려면 다음과 같은 온라인 SSL/TLS 인증서 유효성 검사 도구를 사용하세요. SSL 검사기 or Digicert. 이러한 도구는 인증서 체인 또는 설치와 관련된 문제를 식별하는 데 도움이 됩니다.
3. 폐지된 증명서
이 SSL 오류는 웹사이트에 설치된 SSL/TLS 인증서가 만료일 전에 발급 인증서 기관에 의해 무효화되었을 때 발생합니다. 이는 일반적으로 보안 문제나 인증서 소유자의 요청으로 인해 발생합니다.
인증 기관은 해지된 인증서 목록을 유지 관리합니다. 개인 키가 손상된 징후를 보이거나 인증서가 발급된 도메인이 더 이상 작동하지 않는 경우 인증서가 취소됩니다.
클라이언트가 서버와의 연결을 시작하려고 시도할 때 인증서에 문제가 있는지 확인하고 이 확인의 일부는 인증서가 서버에 없는지 확인하는 것입니다. CRL (인증서 해지 목록). 체인의 인증서 중 하나라도 CRL에 있으면 브라우저는 이를 거부합니다. 각 브라우저에는 각 인증서의 해지 상태를 확인하는 서로 다른 메커니즘이 있습니다.
어떻게 고치는 지
세부 정보를 수동으로 검토하여 인증서의 해지 상태를 확인할 수 있습니다.
브라우저의 주소 표시줄에 있는 자물쇠를 클릭하여 시작하세요. 로 이동 세부 정보 섹션을 선택하고 CRL 배포 지점 옵션을 선택합니다.
CA의 CRL을 다운로드합니다. 그런 다음 CRL을 통해 인증서의 일련 번호를 검색하여 인증서가 해지되지 않았는지 확인하세요.
CRL에서 잠재적으로 많은 해지된 인증서 목록을 다운로드하는 대신 발급 CA에 쿼리할 수 있습니다. OCSP 인증서의 일련 번호를 사용하여 서버. 그러면 인증서가 취소되었는지 여부를 나타내는 응답이 승격됩니다. 아직 이 방법을 사용하지 않았다면 구현에 대한 이 가이드를 읽어보세요. OCSP 응답자.
그런 다음 인증서가 취소된 경우 새 인증서를 받아야 합니다. 교체 인증서를 요청하려면 인증서 공급자나 발급 CA에 문의하세요. 새로운 인증서 서명 요청(CSR)을 생성하고 새로운 SSL/TLS 인증서를 얻는 데 도움을 줄 것입니다.
4. 신뢰할 수 없는 인증 기관
이 특정 SSL 인증서 오류는 일반적으로 CA가 널리 인식되지 않거나 클라이언트의 신뢰 저장소에 필요한 루트 또는 중간 인증서가 부족한 경우에 발생합니다. SSL 신뢰 체인을 설정하는 동안 브라우저가 로컬로 신뢰할 수 있는 루트 인증서를 찾을 수 없으면 서버의 인증서를 신뢰하지 않습니다. 이 문제는 자체 서명된 인증서를 사용할 때에도 발생할 수 있습니다. 브라우저가 인증서를 신뢰할 수 없기 때문입니다.
어떻게 고치는 지
이 TLS 오류를 방지하려면 먼저 신뢰할 수 있는 인증 기관에서 인증서를 구매하고 있는지 확인하세요. Let's Encrypt, DigiCert 또는 Comodo와 같은 평판이 좋은 CA는 대부분의 브라우저 및 장치의 신뢰할 수 있는 CA 목록에 포함될 가능성이 높습니다.
SSL/TLS 인증서에 서명하는 데 사용된 CA 인증서가 유효하고 만료되지 않았는지 확인하세요. 만료되거나 해지된 CA 인증서로 인해 신뢰할 수 없는 CA 오류가 발생할 수 있습니다. CA 자체에서 CA 인증서를 확인하여 유효성을 확인하세요.
여러 장치와 다양한 브라우저에서 웹사이트의 SSL/TLS 인증서를 테스트하세요. 이 SSL 오류는 신뢰 저장소에 필요한 루트 또는 중간 인증서가 없는 특정 플랫폼이나 브라우저에서 발생할 수 있습니다.
신뢰할 수 없는 CA 오류가 지속되면 SSL/TLS 인증서에 필요한 누락된 루트 또는 중간 인증서를 식별하십시오. CA 또는 해당 문서에서 이러한 인증서를 얻어 웹 서버에 설치하십시오. 인증서 체인이 완전하고 올바르게 구성되었는지 확인하십시오.
웹 사이트에 자체 서명된 인증서를 사용하려면 브라우저의 신뢰 저장소에 인증서를 수동으로 추가해야 합니다. 당신은 참조 할 수 있습니다 이 가이드 예를 들어 CA 인증서를 Chrome 및 Firefox에 신뢰할 수 있는 루트 인증 기관으로 추가하는 방법을 알아보세요.
5. 오래된 보안 프로토콜
암호화 기술은 수년에 걸쳐 발전하므로 보안 위험과 잠재적인 해커 공격도 마찬가지입니다. 이것이 SSL/TLS 인증서 수명 주기가 단축되는 이유 중 하나이며 버전이 업데이트되고 이전 버전이 더 이상 사용되지 않고 안전하지 않다고 발표된 이유이기도 합니다.
TLS는 SSL(당시 버전 3.0)의 업그레이드로 도입되었으므로 모든 TLS 버전이 SSL보다 안전합니다. 프로토콜의 최신 버전은 1.3년에 출시된 TLS 2018입니다. 이 프로토콜은 향상된 암호화 알고리즘을 갖추고 있으며 핸드셰이크에 단 한 번의 왕복만 필요합니다(즉, 브라우저가 웹 사이트 서버에 더 쉽게 연결됨을 의미).
2020년부터 모든 주요 브라우저에 경고 표시 TLS 1.0 또는 1.1을 사용하고 사용자의 액세스를 차단하는 웹사이트의 경우. 그렇다면 현재 TLS 버전을 사용하고 이전 버전을 비활성화하는 것이 좋습니다.
어떻게 고치는 지
웹사이트에서 사용하는 프로토콜 버전을 확인하는 방법에는 여러 가지가 있습니다.
- . 보안 Chrome DevTools의 탭:
- 타사 검사기에서. 그 중 일부는 활성화된 TLS 및 SSL 버전에 대한 정보를 제공합니다.
최신 버전의 TLS를 활성화하려면 먼저 웹사이트가 이를 사용하도록 구성되어 있는지 확인하세요. 실행 SSL 서버 테스트 과를 확인 구성 결과 섹션:
그런 다음 호스팅 제공업체에 문의하여 최신 프로토콜 버전을 활성화하기 위해 수행해야 할 작업을 알아보세요. 일반적으로 서버의 구성 파일에 올바른 프로토콜을 지정해야 합니다.
예를 들어 사이트가 Nginx 서버에서 실행되는 경우 nginx.conf 파일을 편집하고 설치한 TLS 버전을 지정해야 합니다. 업그레이드된 프로토콜을 추가하고 더 이상 사용되지 않는 모든 버전을 비활성화합니다. 구성 줄은 다음과 같습니다.
ssl_protocols TLSv1.2 TLSv1.3;
귀하의 사이트가 TLS 1.2 또는 1.3을 지원하지 않는 것으로 확인되면 웹 호스트에 문의하여 다른 요금제로 업그레이드해야 할 수도 있습니다.
6. 인증서 이름 불일치
인증서 이름 불일치는 일반적으로 SSL/TLS 인증서의 도메인 이름이 사용자가 브라우저에 입력한 이름과 일치하지 않을 때 발생합니다. 사용자에게 다음과 같은 경고가 표시됩니다.
어떻게 고치는 지
이러한 SSL 오류의 원인과 해결 방법을 살펴보겠습니다.
- 귀하의 웹사이트는 내부 도메인 이름을 통해 접속되고 있습니다 인증서에 지정되지 않은 것(예: 귀하의웹사이트.로컬호스트, 그러나 귀하의 인증서에는 당신의 웹사이트.com). 이 SSL 오류를 해결하려면 단일 인증서에 여러 호스트 이름을 포함할 수 있는 SAN(주체 대체 이름) 인증서를 받으세요. 인증 기관이 다른 일부 계획에서는 SAM을 사용하지 못할 수도 있습니다.
- 귀하의 웹사이트는 "www"가 있거나 없이 평가될 수 있습니다. 하지만 인증서에는 도메인 이름이 하나만 지정되어 있습니다. 'www'를 사용할지 여부를 결정하는 것이 중요합니다. 도메인 이름, 모든 트래픽을 선택한 버전으로 전달하고 선택한 버전(“www” 포함 또는 제외)에 따라 SSL/TLS 인증서를 받습니다. 기사에서 이것이 귀하의 SEO에 어떤 영향을 미치는지에 대한 자세한 내용을 제공합니다. www 및 www가 아닌 도메인 이름. SAN이 포함된 인증서도 여기서 솔루션입니다.
- 귀하의 웹사이트는 다른 사람들과 IP 주소를 공유합니다. 별도의 프로토콜이 없습니다. 대부분의 리소스 전용 IP가 필요하지 않습니다 (많은 이메일을 보내지 않는 한) 공유된 이메일은 더 낮은 가격으로 제공됩니다. 공유 IP가 있는 경우 프로토콜 확장자에 도메인 이름을 표시해야 합니다. SNI(서버 이름 표시). SNI를 사용하면 서버는 여러 사이트에서 공유되는 기본 인증서를 선택하는 대신 특정 호스트 이름에 고유한 TLS 인증서와 해당 개인 키를 선택합니다.
- 귀하의 웹사이트 호스팅 제공업체에는 사전 구성된 설정이 있습니다. 귀하의 도메인 이름에 SSL/TLS를 강제합니다. 이 문제를 해결하려면 공급자에게 연락하여 인증서를 귀하의 인증서로 교체하도록 하거나 다른 공급자로 전환하는 것을 고려해야 합니다.
온라인 확인 도구를 통해 SSL/TLS 인증서로 어떤 도메인 이름이 보호되는지 확인할 수 있습니다. 예를 들어:
7. 오래된 암호화 알고리즘
사용자가 웹사이트에 액세스하면 브라우저는 핸드셰이크라는 프로세스를 통해 TLS 인증서를 인증합니다. 각 연결을 암호화하는 알고리즘인 암호화 제품군은 이 프로세스의 시작에서 중요한 역할을 합니다. 브라우저는 지원하는 암호화 제품군을 전달하고 서버는 가장 안전한 암호화 제품군으로 응답합니다. 서버에 구성된 암호화 제품군이 충분히 안전하지 않은 경우 브라우저는 "사용되지 않는 암호화" 경고를 표시합니다.
암호 제품군에는 각각 특정 암호화 기능을 나타내는 여러 암호가 포함되어 있습니다. TLS 1.3 이전에는 XNUMX개의 암호로 구성된 가장 권장되는 조합이 있었습니다.
- 에 대한 알고리즘 키 교환 서버와 브라우저 사이(ECDHE)
- A 디지털 서명 인증서 인증에 도움이 되는 정보(ECDSA)
- 보안을 위한 암호 데이터 전송 (AES-256-GCM)
- 에 대한 알고리즘 메시지 인증 (SHA384)
TLS 1.3 암호화 제품군은 두 개의 후자 암호화로만 구성됩니다. 이 버전은 기본적으로 오래된 키 교환 및 인증 알고리즘을 지원하지 않습니다. 보안 연결을 위해 TLS 1.2를 계속 사용할 수 있지만 이 버전에서 허용되는 암호화의 품질이 다양하므로 사이버 공격에 취약할 수 있습니다. 최신 버전의 TLS를 사용하면 암호의 변동성이 줄어들고 전체 핸드셰이크 프로세스가 더 빠르고 간단하며 안전해집니다.
어떻게 고치는 지
오래된 암호화 알고리즘을 사용하고 있지 않은지 확인해야 합니다. 서버에서 어떤 암호 제품군이 활성화되어 있는지 알아보려면 SSL/TLS 서버 테스트를 온라인으로 실행할 수 있습니다.
TLS에서 취약한 암호가 여전히 지원된다는 사실을 알게 되면 서버 구성에서 이를 비활성화해야 합니다. 웹사이트에 연결할 때 어떤 암호 브라우저가 우선순위를 정할지를 나타내기 위해 암호 순서 기본 설정을 설정하는 것도 좋습니다. 그러기 위해서는 먼저 다음 사항을 확인하세요. 암호의 보안 등급 그리고 암호 문자열.
8. 일반 SSL/TLS 프로토콜 오류
이 오류는 일반적으로 클라이언트와 서버 간의 SSL/TLS 핸드셰이크 프로세스에 문제가 있음을 나타냅니다. 이는 본질적으로 클라이언트나 서버가 보안 규칙을 설정할 수 없음을 의미합니다. 이는 잘못 구성된 SSL/TLS 설정, 오래된 소프트웨어, 브라우저 관련 문제, 장치의 잘못된 날짜 또는 시간, 콘텐츠 전송 네트워크(CDN) 문제 등 다양한 이유로 발생할 수 있습니다.
이 TLS 오류는 사용자가 웹 사이트에 액세스할 수 없도록 하기 때문에 모든 경우에 사용자에게 실망스러울 수 있습니다.
어떻게 고치는 지
다음은 이러한 TLS 오류를 해결하기 위해 취할 수 있는 몇 가지 단계입니다.
암호화 알고리즘이 업데이트되었는지 확인하는 것부터 시작하세요. 예를 들어, NSA가 처음 개발한 SHA-1 암호화 표준은 2005년 이후 더 이상 사용되지 않는 것으로 간주되었습니다. SSL 인증서 암호화에 널리 사용되지만 현재는 안전하지 않은 것으로 간주됩니다. 이것이 바로 브라우저가 이 암호화를 사용하는 SSL 인증서를 신뢰하지 않을 수 있는 이유입니다. 이 문제를 해결하려면 인증서를 업데이트하거나 새 인증서를 취득하는 것이 좋습니다. 이전 섹션에서는 이를 수행하는 방법에 대한 지침을 제공했습니다.
다음으로, 서버와 클라이언트가 호환되는 암호화 알고리즘을 사용하도록 구성되어 있는지 확인하세요. 오래되었거나 약한 알고리즘으로 인해 TLS 핸드셰이크 오류가 발생할 수 있습니다. 예를 들어, 서버가 최신 암호화 제품군을 지원하고 SSL 2.0 및 SSL 3.0과 같은 더 이상 사용되지 않고 안전하지 않은 프로토콜을 비활성화했는지 확인하세요. 이에 대해서는 이전 섹션에서 자세히 다루었습니다.
참고 사항 : 이 오류는 사용자 장치의 시스템 날짜 및 시간이 올바르지 않거나, 브라우저 확장 프로그램 또는 추가 기능이 SSL/TLS 연결을 방해하거나, 사용자의 브라우저 설정이 오래된 경우와 같이 클라이언트 측에서 자주 발생합니다.
웹사이트 보안 수준을 높이세요
단순한 사실은 견고한 웹사이트 보안 조치 없이는 갈 수 없으며, 사이버 공격과 데이터 노출로부터 사이트를 보호하는 주요 측면 중 하나는 적절한 SSL/TLS 구성 및 관리입니다. 최신 TLS 버전으로 업데이트하고, 인증서 만료 날짜에 대한 경고를 설정하고, 가장 안전한 암호화를 활성화하고, 프로토콜의 취약점을 정기적으로 검사하는 것이 좋습니다. 사이버 위협은 계속 진화하므로 사용자가 웹 사이트에 얼마나 안전하게 연결하는지 추적해야 합니다.
- SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
- PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
- PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
- 플라톤ESG. 자동차 / EV, 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
- BlockOffsets. 환경 오프셋 소유권 현대화. 여기에서 액세스하십시오.
- 출처: https://seranking.com/blog/ssl-tls-errors/
