CNAME은 옮겼다. 예전 사업자에게 열쇠가 남았다.

Summary

• HTTP 작업반의 서버 추가 인증서 초안 03판은 2026년 11월 2일 갱신된 Internet-Draft다. TLS 연결이 성립한 뒤 HTTP/2 또는 HTTP/3 서버가 다른 사이트 인증서의 개인키를 갖고 있음을 SERVER_CERTIFICATE 프레임으로 증명하도록 제안한다.
• 양쪽이 먼저 지원을 표시해야 한다. RFC 9261의 내보낸 인증자는 추가 키의 증명을 기존 TLS 세션에 묶는다. 클라이언트는 그 인증서와 서버가 두 번째 사이트에 적합한지도 판단한다.
• 7.3절은 사업자 교체의 빈틈을 지적한다. CNAME을 바꾸면 새 연결은 새 사업자로 가지만, 예전 사업자는 다른 사이트를 위한 연결에서 떠난 사이트의 추가 인증서를 계속 보일 수 있다. 남은 서비스 권한을 정리하는 일은 사업자와 고객의 몫이다.

출판사가 호스팅 사업자를 바꾼다고 하자. CNAME 변경 뒤 새 연결은 후임 사업자에 도착한다. 하지만 한 독자의 브라우저에는 기존 사업자가 운영하는 다른 사이트와의 HTTP/2 연결이 남아 있다. 그 사업자는 출판사 사이트의 인증서를 여전히 갖고 있고 열린 연결에서 키 증명을 보낸다. 클라이언트가 이것만으로 권한을 인정하면, 이동한 사이트의 다음 요청이 옛 경로로 돌아갈 수 있다. 초안에 적힌 위험을 검증하기 위한 가상 상황이다.

기술적 이익은 뚜렷하다. HTTP/2와 HTTP/3는 서버가 각 출처를 서비스할 권한이 있을 때 연결을 재사용할 수 있다. TLS 핸드셰이크 인증서 한 장에 여러 이름을 넣을 수 있지만, 호스팅 사업자는 고객별 인증서를 따로 갱신하고 폐기하고 싶을 수 있다. 초안은 인증서를 나눠 관리하면서 전송 연결을 공유한다. 절약한 연결 뒤에는 두 번째 사이트의 현재 권한을 누가 확인하느냐는 문제가 남는다.

하나의 연결이 두 번째 신분을 얻는다

먼저 양쪽이 명시적으로 합의한다. 클라이언트와 서버 모두 SETTINGS_HTTP_SERVER_CERT_AUTH 값을 1로 보내야 한다. 둘 중 하나라도 빠지면 추가 인증서 기능을 사용할 수 없다. 이후 서버는 언제든 SERVER_CERTIFICATE 프레임을 보낼 수 있다. HTTP/2에서는 스트림 0, HTTP/3에서는 제어 스트림에 둔다. 프레임의 내보낸 인증자는 추가 인증서에 해당하는 개인키의 보유 사실을 이 TLS 세션에 묶어 증명한다. 인증서 파일을 복사해 보내는 것만으로는 그 증명이 되지 않는다.

클라이언트는 인증자를 검증한 뒤 요청 대상 사이트에 인증서가 적합한지 살핀다. 실패에도 종류가 있다. 인증자가 잘못되면 연결 오류다. 만료되거나 폐기되었거나 요청에 맞지 않는 인증서는 그 출처의 자격을 거부하는 문제다. 초안은 이 경우 권한 있는 서버와 새 연결을 시도하라고 권한다. 공유 연결 자체는 정상인데 두 번째 사이트만 거절될 수 있다. 연결 성공률 하나로는 이 갈림길을 볼 수 없다.

보안 절에는 더 날카로운 상황이 있다. 추가 인증서와 키를 탈취한 악성 서버는 클라이언트를 자신이 운영하는 아무 HTTPS 사이트로 끌어들이기만 하면, 그 연결에서 다른 사이트의 훔친 자격을 내밀 수 있다. 초안은 첫 TLS 핸드셰이크에서 DNS를 확인했을 이름이라면 추가 인증서에서도 DNS를 확인하라고 권한다. DNS를 생략한다면 ORIGIN 프레임 같은 다른 권한 근거가 판단을 보강할 수 있다. 키를 가진 사실과 오늘의 접속 경로는 다른 증거다.

DNS는 떠나고 연결은 남는다

7.3절의 일반적인 사업자 교체에는 키 탈취가 필요 없다. 소유자가 CNAME을 바꾸면 새 연결은 후임 사업자에게 간다. 기존 사업자는 다른 고객의 연결을 계속 받으며, 떠난 사이트의 추가 인증서 설정을 남겨 둘 수 있다. 그러면 공유 연결에서 그 사이트를 계속 대표할 수 있다. 초안은 이 동작이 기존 사업자의 설정과 맞지만 소유자의 의도와는 어긋날 수 있다고 설명한다. 제안된 프로토콜에는 잔존 상태를 자동으로 끄는 장치가 없으며, 사업자에게 고객 사전 설명을 권한다.

따라서 퇴장에는 여러 장의 영수증이 필요하다. 개인키는 누가 보관하는가? 어떤 서버가 아직 추가 인증서를 보내는가? 설정 삭제와 인증서 폐기는 언제 이뤄지는가? 클라이언트가 두 번째 사이트의 권한을 다시 확인하는가? 새 DNS 응답은 새 연결의 방향만 알려 준다. 기존 공유 연결의 요청은 보이지 않는다. 열린 연결 목록만 봐도 각 요청의 도착지는 알 수 없다. 둘을 대조해야 한다.

초안은 TLS 세션을 재개했을 때 이전에 확인한 추가 인증서를 그대로 유효한 것으로 취급하는 것도 금지한다. 서버는 다시 제시할 수 있고, 클라이언트는 새로 판단해야 한다. 연결 안에서 요청을 처리하는 동안에도 받아들인 인증서 집합이 변할 수 있어 권한 상태를 다시 평가해야 한다. 연결을 줄인 대신 움직이는 신뢰 상태를 관리할 책임이 생긴다.

공식 자료에는 보급 규모나 실제 사업자 교체 사고의 측정치가 없다. DNS, 열린 연결, 인증서 프레임, 요청 도착지를 함께 기록한 통제된 이전 시험이 결과를 밝힐 것이다. 당장 실행할 일은 분명하다. DNS 별칭을 바꾸는 만큼 철저하게 추가 인증서 경로도 닫아야 한다. 거리의 안내판을 바꿔도 옛 건물의 열쇠는 저절로 사라지지 않는다.

HTTP 초안 · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336