[웹 기반기술 42] DNS - 인증서 발급과 갱신

인증서가 무엇을 보증하는지 이해했다면, 다음은 그 인증서를 실제로 손에 넣는 과정이다. 인증서 발급은 한때 번거롭고 비용이 드는 일이었지만, 지금은 자동화된 절차를 통해 무료로 짧은 시간에 받을 수 있게 되었다. 이 변화는 웹 전체가 보안 연결로 옮겨 가는 데 결정적인 역할을 했다. 발급이 쉬워졌다는 것은, 이제 보안 연결을 갖추지 않을 이유가 사라졌다는 뜻이기도 하다.

이번 편은 인증서를 발급받고 갱신하는 과정을 다룬다. 발급의 전제가 되는 도메인 소유 검증이 어떻게 이루어지는지, 그 발급을 자동화하는 약속은 무엇인지, 수명이 짧아지면서 갱신이 왜 리듬이 되었는지, 갱신을 지켜보는 안전장치는 어떻게 두는지, 그리고 발급 과정에서 흔히 겪는 함정은 무엇인지를 차례로 짚는다. 발급과 갱신을 자동화된 흐름으로 만들어 두면, 인증서는 더는 주기적으로 신경 써야 할 골칫거리가 아니게 된다.

도메인 소유를 증명하는 검증

인증서 발급의 핵심은 요청자가 정말 그 도메인의 주인인지를 확인하는 검증이다. 아무나 임의의 도메인에 대한 인증서를 받을 수 있다면 사칭이 만연할 것이므로, 발급 기관은 발급 전에 요청자가 그 도메인을 통제하고 있음을 증명하도록 요구한다. 이 증명이 통과해야 비로소 인증서가 발급된다. 검증은 인증서 신뢰의 첫 단추다.

가장 널리 쓰이는 검증 방식은 지정된 값을 도메인에 배치하게 하는 것이다. 발급 기관이 임의의 문자열을 주고, 요청자가 그것을 자신의 웹 경로나 이름 레코드에 올려 두면, 기관이 그 값을 조회해 확인한다. 그 값을 배치할 수 있다는 것은 곧 그 도메인을 통제하고 있다는 증거다. 도메인의 관리 권한을 가진 사람만이 할 수 있는 일을 신뢰의 근거로 삼는 것이다.

웹 경로에 값을 두는 방식과 이름 레코드에 값을 두는 방식은 쓰임이 조금 다르다. 웹 경로 방식은 간단하지만 그 도메인이 이미 웹으로 접근 가능해야 하고, 이름 레코드 방식은 웹이 아직 없어도 되고 여러 이름을 포괄하는 인증서에도 쓸 수 있다. 특히 상위 도메인 아래 모든 서브도메인을 포괄하는 인증서는 이름 레코드 방식으로만 검증할 수 있는 경우가 많다. 상황에 맞는 방식을 고르는 것이 첫 판단이다.

검증은 발급 시점의 통제를 확인할 뿐, 그 통제가 영원히 지속됨을 보증하지는 않는다. 그래서 인증서에 유효 기간이 있고 갱신 때마다 검증을 다시 거친다. 도메인의 소유가 바뀌면 새 소유자가 검증을 통과하게 되고, 옛 소유자의 인증서는 갱신되지 못해 자연히 사라진다. 검증을 반복하는 구조가 소유의 변화를 인증서에 반영하는 장치인 셈이다.

발급을 자동화하는 약속

발급 과정을 사람이 매번 손으로 하면 번거롭고 실수가 잦다. 이 과정을 기계끼리 주고받을 수 있도록 정형화한 약속이 자리 잡으면서, 발급과 갱신이 자동으로 이루어질 수 있게 되었다. 서버에 설치된 도구가 발급 기관과 정해진 절차대로 대화하며, 검증 값을 배치하고 인증서를 받아 설치하는 일련의 과정을 사람 개입 없이 수행한다.

이 자동화의 핵심은 검증과 발급, 설치가 하나의 흐름으로 이어진다는 데 있다. 도구는 발급을 요청하고, 기관이 준 검증 값을 자동으로 배치하고, 검증이 통과하면 인증서를 받아 서버에 설치한다. 이 흐름이 한번 갖추어지면 이후의 갱신도 같은 절차를 반복하므로, 사람은 처음 설정만 하면 된다. 자동화는 반복되는 작업에서 사람을 완전히 빼내는 것을 목표로 한다.

이 자동화된 발급이 무료로 제공되면서 보안 연결의 문턱이 크게 낮아졌다. 비용과 수고가 사라지자 작은 개인 사이트조차 보안 연결을 갖추게 되었고, 보안 연결이 예외가 아니라 기본이 되었다. 이 변화의 밑바탕에는 발급을 자동화한 약속과 그것을 무료로 뒷받침한 기관들이 있다. 기술의 정형화가 웹 전체의 안전 수준을 끌어올린 사례다.

자동화 도구는 여러 종류가 있지만 동작의 원리는 같다. 어떤 도구를 쓰든 발급 기관과 정해진 약속대로 대화하고, 검증을 거쳐 인증서를 받아 온다. 그래서 특정 도구의 사용법보다 그 아래에서 벌어지는 검증과 발급의 원리를 이해하는 편이 오래간다. 도구는 바뀌어도 발급의 원리는 그대로이기 때문이다.

자동화를 도입할 때는 그 도구가 어떤 권한으로 동작하는지를 살펴야 한다. 검증 값을 이름 레코드에 배치하는 방식을 쓰려면 도구가 그 레코드를 편집할 권한을 가져야 하는데, 이 권한을 지나치게 넓게 주면 도구가 침해되었을 때 도메인 전체가 위험해진다. 자동화의 편리함을 취하되 그 도구에 주는 권한은 필요한 범위로 좁히는 것이 원칙이다.

짧아지는 수명과 갱신의 리듬

인증서의 유효 기간은 점점 짧아지는 추세다. 수명이 짧으면 유출된 열쇠나 잘못 발급된 인증서가 통용될 수 있는 창이 좁아지고, 불완전한 무효화 장치에 덜 의존하게 된다. 대신 짧은 수명은 갱신을 자주 해야 한다는 부담을 낳는다. 이 부담은 갱신을 자동화함으로써만 감당할 수 있으며, 그래서 짧은 수명과 자동 갱신은 한 쌍으로 움직인다.

갱신은 만료 직전에 몰아서 하는 것이 아니라 여유를 두고 미리 하는 것이 정석이다. 유효 기간의 절반쯤 지난 시점에 갱신을 시도하도록 설정해 두면, 한 번 실패하더라도 만료 전에 여러 번 다시 시도할 여유가 생긴다. 만료에 임박해서야 갱신하면 그 시도가 실패했을 때 대응할 시간이 없다. 갱신의 리듬은 만료보다 충분히 앞서 있어야 한다.

자동 갱신이 설정되어 있으면 인증서는 사람의 손을 떠나 스스로 순환한다. 도구가 주기적으로 남은 수명을 확인하고, 갱신이 필요하면 검증과 발급을 다시 거쳐 새 인증서를 설치한다. 이 순환이 매끄럽게 돌면 인증서의 존재를 잊고 지내도 서비스가 끊기지 않는다. 잘 설계된 자동 갱신은 인증서를 의식의 뒤편으로 밀어낸다.

다만 자동 갱신이 돌고 있다는 사실만 믿고 방치하는 것은 위험하다. 갱신은 여러 이유로 조용히 실패할 수 있고, 실패가 쌓이면 어느 날 인증서가 만료되어 사이트가 멈춘다. 자동 갱신은 갱신의 수고를 없애 주지만, 그 갱신이 실제로 성공하고 있는지를 지켜보는 눈까지 없애 주지는 않는다. 자동화와 감시는 함께 가야 한다.

갱신을 지켜보는 안전장치

갱신을 감시하는 가장 기본적인 장치는 만료 시점을 미리 알리는 통지다. 인증서의 남은 수명을 주기적으로 확인해 만료가 가까워지면 담당자에게 알리도록 해 두면, 자동 갱신이 실패했더라도 만료 전에 사람이 개입할 수 있다. 이 통지는 자동 갱신이 정상일 때는 울리지 않고, 무언가 어긋났을 때만 울리는 마지막 안전망이다.

감시는 인증서를 설치한 서버 안쪽이 아니라 바깥에서 실제 연결을 통해 확인하는 것이 더 믿을 만하다. 서버 내부의 파일만 보면 갱신은 되었는데 서버가 새 인증서를 다시 읽어 들이지 않아 옛 인증서를 계속 제시하는 상황을 놓친다. 바깥에서 실제로 연결해 서버가 제시하는 인증서의 만료일을 확인하면, 사용자가 실제로 마주하는 상태를 그대로 점검할 수 있다.

갱신 뒤에는 서버가 새 인증서를 반영하는 단계까지 확인해야 한다. 인증서 파일이 갱신되어도 서버가 그것을 다시 읽어 들이지 않으면 옛 인증서가 계속 쓰인다. 그래서 자동 갱신 흐름에는 인증서 교체 후 서버를 다시 읽어들이게 하는 단계가 포함되어야 한다. 발급과 설치, 반영까지가 하나의 완결된 흐름이 되어야 갱신이 진짜로 끝난 것이다.

여러 서버나 여러 도메인의 인증서를 다룬다면 만료 현황을 한곳에서 볼 수 있게 모아 두는 편이 낫다. 인증서가 흩어져 있으면 그중 하나의 갱신 실패를 놓치기 쉽다. 모든 인증서의 만료일을 한눈에 확인할 수 있는 현황판을 두면, 어느 하나가 위험 구간에 들어섰을 때 바로 알아챌 수 있다. 감시는 개별 인증서가 아니라 전체를 조망하는 관점에서 이루어져야 한다.

발급에서 겪는 함정

가장 흔한 함정은 검증에 쓰는 경로나 레코드가 갱신 시점에 사라져 있는 것이다. 처음 발급 때는 검증 값을 잘 배치했는데, 이후 설정이 바뀌면서 그 경로가 막히거나 레코드가 지워지면 갱신 검증이 실패한다. 검증 방식이 의존하는 경로는 갱신 때도 열려 있어야 하므로, 그 통로를 함부로 막지 않도록 관리해야 한다.

발급 요청 횟수에 제한이 있다는 점도 자주 부딪히는 함정이다. 설정을 시험하며 짧은 시간에 발급을 여러 번 시도하면 제한에 걸려 한동안 발급이 막힌다. 그래서 실제 발급 전에는 시험용 환경에서 절차를 검증한 뒤, 확신이 섰을 때 실제 발급을 한 번에 진행하는 것이 안전하다. 무턱대고 반복 시도하는 것은 스스로 발급의 문을 닫는 일이 된다.

포괄 인증서의 검증 방식을 잘못 고르는 것도 함정이다. 상위 도메인 아래 모든 서브도메인을 포괄하는 인증서는 웹 경로 방식으로는 검증되지 않고 이름 레코드 방식을 요구하는데, 이를 모르고 웹 경로 방식을 시도하다 실패하는 경우가 있다. 어떤 인증서가 어떤 검증 방식을 요구하는지를 미리 확인하고 그에 맞는 자동화를 준비해야 한다.

마지막 함정은 발급은 성공했으나 사슬을 온전히 설치하지 않는 것이다. 서버 인증서만 두고 중간 인증서를 함께 설치하지 않으면 일부 브라우저에서 신뢰가 끊긴다. 발급 도구가 대개 사슬까지 챙겨 주지만, 수동으로 설치할 때는 이 부분을 놓치기 쉽다. 발급 뒤에는 여러 환경에서 실제로 신뢰가 성립하는지 확인해야 발급이 온전히 끝난 것이다.

발급을 통제하는 정책

인증서 발급이 쉬워졌다는 것은 동시에 누군가 내 도메인에 대한 인증서를 몰래 발급받으려 시도할 수 있다는 뜻이기도 하다. 도메인 검증만 통과하면 발급이 이루어지므로, 검증 절차가 어딘가에서 뚫리면 공격자가 유효한 인증서를 손에 넣어 사칭에 쓸 수 있다. 그래서 어떤 기관이 내 도메인의 인증서를 발급할 수 있는지를 도메인 소유자가 미리 제한하는 장치가 필요해졌다.

이 제한은 이름 레코드로 표현된다. 도메인에 특정 발급 기관만 인증서를 발급할 수 있다는 정책을 레코드로 명시해 두면, 발급 기관은 발급 전에 이 레코드를 조회해 자신이 허용되었는지를 확인한다. 허용되지 않은 기관은 발급을 거부해야 하며, 이를 통해 소유자가 지정하지 않은 경로로 인증서가 발급되는 것을 막는다. 발급의 권한을 도메인 소유자가 이름 레코드로 통제하는 것이다.

이 정책은 완벽한 방어는 아니지만 공격의 표면을 좁힌다. 발급을 허용받은 기관의 수를 줄이면, 그 기관들만 신뢰하면 되므로 감시할 대상이 줄어든다. 어느 기관을 통해서든 발급이 가능한 상태보다, 지정한 몇몇 기관으로 발급을 한정한 상태가 훨씬 다루기 쉽다. 정책은 발급이라는 문에 자물쇠를 하나 더 다는 셈이다.

발급 내역을 사후에 감시하는 방법도 있다. 발급된 인증서들은 공개 기록에 남으므로, 내 도메인에 대해 발급된 인증서 목록을 주기적으로 살피면 지정하지 않은 인증서가 발급되었는지를 뒤늦게라도 알아챌 수 있다. 발급을 막는 정책이 발급 전에 문을 걸어 두는 사전 방어라면, 발급 내역을 살피는 감시는 이미 벌어진 일을 뒤늦게 잡아내는 사후 탐지다. 이 둘을 함께 두면 인증서 발급이라는 민감한 통로를 앞뒤로 지킬 수 있다. 이렇게 소유 검증, 발급 자동화, 갱신의 리듬, 감시의 안전장치, 발급의 함정, 그리고 발급을 통제하는 정책까지 이해하면 인증서는 스스로 순환하면서도 통제된 배경 장치가 된다. 다음 편은 이렇게 확보한 이름과 인증서 위에서 여러 입구를 하나로 모으는 리다이렉트를 다룬다.