문제

사파리가 “Safari가 서버에 대한 보안 연결을 설정할 수 없습니다”(영문: Safari Can’t Establish a Secure Connection to the Server)를 띄우며 페이지를 열지 못합니다. 어떨 땐 한 사이트, 어떨 땐 손대는 모든 HTTPS 사이트입니다. 메시지는 인증서 문제처럼 들리지만, 실은 사파리가 암호화 핸드셰이크가 실패했다고 말하는 포괄적 방식입니다 — 그리고 핸드셰이크는 틀린 시계, 애플 규칙을 어긴 인증서, 프로토콜 불일치, 중간의 네트워크 장비 때문에 실패할 수 있습니다. 요령은 추측하지 않는 것입니다. 잘못이 내 기기에 있는지 서버에 있는지 가려내는 것 — 그 둘은 완전히 다른 수리이기 때문입니다.

증상

  • 전체 오류: “Safari가 서버에 대한 보안 연결을 설정할 수 없습니다.”
  • 같은 페이지가 같은 기기의 크롬·파이어폭스에선 멀쩡히 열립니다 — 또는, 의미심장하게도, 거기서도 안 열립니다.
  • 아이폰·아이패드도 비슷한 문구, 맥에선 (위험하게) 그냥 통과 클릭할 수 있는 인증서 경고 시트가 함께 뜨기도 합니다.
  • 날짜 변경, 새 백신·VPN, 네트워크 전환, 카페·호텔 와이파이 접속 뒤에 시작됐습니다.
  • 터미널에서 같은 호스트로 curl·openssl s_client는 성공 — 화살표가 다시 클라이언트를 가리킵니다.

첫 질문: 모든 사이트인가, 한 사이트인가?

이 하나의 갈림이 모든 걸 정합니다. 어떤 설정도 건드리기 전에 먼저 답하세요.

모든 HTTPS 사이트가 실패한다. 세상의 서버가 동시에 다 고장 났을 리 없습니다. 내 기기나 네트워크의 무언가가 모든 핸드셰이크를 오염시키는 중입니다. 로컬을 보세요:

  1. 시계. TLS 인증서는 “not before”와 “not after” 두 날짜 사이에서만 유효합니다. 맥·아이폰의 날짜가 틀리면 — 죽은 시계 배터리, 수동 설정, 여행 뒤 잘못된 시간대 — 지구상 모든 인증서가 만료됐거나 아직 유효하지 않게 보이고, 모든 연결이 실패합니다. 날짜·시간을 자동으로 두고 재시도하세요. 가장 흔한 원인이고 배제에 10초면 됩니다.
  2. 로컬 TLS 가로채기. ‘HTTPS 검사’·‘웹 실드’를 켠 백신, 회사 프록시, 자녀 보호 필터는 내 TLS를 가로채 자기 인증서를 제시하는 방식으로 작동합니다. 그 끼워 넣은 인증서가 신뢰되지 않으면(또는 도구가 오작동하면) 모든 사이트가 실패합니다. TLS 검사 기능을 끄고 테스트하세요.
  3. DNS·VPN. 탈취되거나 깨진 리졸버, 또는 연결을 망가뜨리는 무언가를 통과시키는 VPN은 인증서가 문제 되기도 전에 핸드셰이크를 깰 수 있습니다. 다른 네트워크로 바꾸거나 VPN을 꺼서 격리하세요.

특정 한 사이트만 실패한다. 이제 증거는 내 맥이 아니라 그 사이트의 인증서·서버를 가리킵니다. 다음 절로.

한 사이트일 때: 애플의 더 엄격한 규칙

사람들이 놀라는 지점: 크롬에서 되는 인증서가 사파리에선 거부될 수 있습니다. 애플이 다른 클라이언트는 강제하지 않는 요구를 강제하기 때문입니다. 그중 셋이 피해의 대부분을 냅니다:

  • 398일 한도. 2020년 9월 1일 이후, 애플 플랫폼은 유효기간이 398일을 넘는 공개 신뢰 TLS 서버 인증서를 불신합니다. 관리자가 수명이 긴 인증서를 넣었다면(일부 내부 CA는 아직 2~3년 인증서를 발급합니다), 사파리는 대놓고 거부하는데 더 낡거나 관대한 클라이언트는 어깨를 으쓱하고 받아들입니다.
  • 인증서 투명성(CT). 애플은 공개 신뢰 인증서가 공개 CT 로그에 기록됐음을 SCT를 달아 증명하도록 요구합니다. 그 과정 밖에서 발급됐거나 — CT를 건너뛰는 사설 CA가 발급했다면 — 사파리에서 실패합니다. (크롬도 자체 CT 강제가 있어 이건 양쪽에서 깨지는 경우가 많습니다. NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED 참고.)
  • TLS 1.2 최소. 애플은 2020년 자사 플랫폼 전반에서 TLS 1.0·1.1을 퇴출했습니다. 그 낡은 프로토콜만 제공하는 서버는 사파리가 협상할 게 없어, 버전별 오류 대신 보안 연결 오류가 납니다. 크롬 대응 코드는 ERR_SSL_VERSION_OR_CIPHER_MISMATCH입니다.

나머지 고전적 단일 사이트 원인은 평범한 인증서 실패입니다: 만료된 인증서, 이름 불일치, 사슬의 중간 인증서 누락(서버가 리프만 제시해 사파리가 신뢰 루트까지 경로를 못 만드는 경우). 이것들은 브라우저 전반에서 뜹니다 — 크롬 라벨은 NET::ERR_CERT_AUTHORITY_INVALID, 파이어폭스는 SEC_ERROR_UNKNOWN_ISSUER입니다. 다른 브라우저는 사이트를 여는데 사파리만 유독 불편해한다면, 398일 규칙이나 CT를 먼저 의심하세요. 그게 애플 고유의 것이니까요.

DechoNet으로 진단

  • SSL 점검은 사이트의 실인증서를 브라우저처럼 검사합니다 — 만료일, 전체 사슬, 유효기간, 중간 인증서 제시 여부를 읽어 — 인증서가 만료됐는지, 398일 수명을 넘었는지, 사슬 고리가 빠졌는지 한 번에 보여줍니다. “사파리가 진짜 인증서 결함에 엄격한 것”과 “내 맥 시계가 틀린 것”을 곧바로 가릅니다.
  • DNS 점검은 호스트명이 기대한 주소로 풀리는지 확인합니다. 모든 사이트가 실패하고 리졸버 탈취가 의심되면, 인증서를 탓하기 전에 그 이름이 실제로 무엇을 가리키는지 여기서 확인하세요.

해결 체크리스트

  • 문제 기기의 날짜·시간·시간대를 자동으로 설정. 무엇보다 먼저 재시도.
  • 범위 판정: 오류가 모든 HTTPS 사이트에 나는가, 한 사이트인가? 모든 사이트 → 시계·백신 TLS 검사·DNS/VPN을 보라. 한 사이트 → 그 인증서를 보라.
  • 백신의 ‘HTTPS/SSL 검사’·‘웹 보호’ 기능을 끄고 테스트 — 멀쩡한 기기에서 전체 사이트 실패의 최상위 원인.
  • 실패하는 단일 사이트는 SSL 점검에 넣어: 인증서가 만료되지 않았는지, 398일을 넘지 않는지, 전체 중간 사슬을 제시하는지 확인.
  • 터미널에서 같은 호스트 테스트: openssl s_client -connect example.com:443 -servername example.com. 이게 성공하는데 사파리가 실패하면, 문제는 서버가 아니라 사파리·macOS 신뢰 설정에 있습니다.
  • 사파리 캐시·웹사이트 데이터를 지우고, 확장 프로그램을 하나씩 꺼보세요 — 오작동하는 확장이 특정 사이트의 TLS를 깰 수 있습니다.

언제 넘길까

  • SSL 점검이 만료됐거나, 398일을 넘거나, 중간 인증서가 빠진 인증서를 보여주면, 수정은 서버 운영자의 몫입니다 — 규정에 맞는 수명으로 재발급하고, CT에 기록하고, 전체 사슬을 설치해야 합니다. 클라이언트는 서버의 인증서를 고칠 수 없습니다.
  • 사파리만 빼고 모든 브라우저가 사이트를 여는데 SSL 점검은 인증서가 유효하고 CT에 기록됐다고 하면, 남은 애플 고유 용의자는 프로토콜이나 애플이 더는 받지 않는 cipher입니다. 서버 운영자가 현대적 cipher 스위트와 함께 TLS 1.2+를 켜야 합니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.