Cloud Computing On Demand

브라우저의 인증서 정책이 나날이 변화하고 있습니다. 
내년부터 시행될 인증서 유효기간 200일 정책을 비롯하여 
Root 인증서의 유효기간 단축 등 이벤트가 넘쳐나고 있습니다.

오늘 포스팅을 Root 인증서의 유효기간 단축으로 인해
내년부터 영향권에 들어가는 GlobalSign 인증서 처리 관련한
Cross-Signed Root 인증서 관련 이야기입니다.

사실, 이 포스팅은 제 스스로 Cross-Signed Root 인증서가
어떻게 Root 인증서의 교체를 부드럽게 넘길 수 있게 해주는 것인지
잘 이해하지 못한 부분들을 정리해보는 글이라 보셔도 무방합니다.

크로스 싸인 루트 인증서(Cross-signed Root Certificate)

신뢰할 수 있는 루트 인증서는 보통 TLS Client에 탑재되어 있습니다. 
가장 널리 사용되는 TLS Client의 하나인 웹 브라우저가 대표적이고
Java의 truststore가 아마도 그 다음 정도로 익히 들어보셨을 TLS Client 입니다.

웹 브라우저는 물론이고 자바 애플리케이션도 
truststore에 미리 저장되어 있는 신뢰 할 수 있는 루트 인증서를 바탕으로
TLS 혹은 SSL과 관련된 모든 절차를 수행합니다. 

그런데 모든 인증서는 유효 기간이 정해져 있을뿐 아니라
루트 인증서의 Private Key가 유출되는 것과 같은 사고가 발생하면
제 아무리 루트 인증서라 하더라도 폐기가 필요합니다.
여기서 폐기는 truststore 에서의 삭제 및 해당 루트 인증서로 싸이닝된
모든 인증서의 폐기를 의미합니다. 

간혹 이런 일이 발생하기도 합니다.
이럴때 부작용을 막기 위해 "크로스 싸인 루트 인증서"가 활용됩니다.
이름 그대로 "다른 루트 인증서를 이용해 싸이닝한 루트 인증서"라는 의미입니다.

이렇게 싸이닝된 "크로스 싸인 루트 인증서"를 이용하면
루트 인증서의 교체에 필요한 작업과 절차를 부드럽게 적용할 수 있다고 하는데요
과연 이 절차는 어떻게 "부드럽게" 진행되는 것인지 궁금했습니다.

사실 Let's Encrypt 에서 비슷한 일이 몇 년전 있었지만 제대로 이해하지 못하고 넘어갔었습니다.
이번엔 제대로 이해해 보고자 공부(라고 쓰고 AI와 티키타카 했다고 읽습니다)해봤습니다.

신뢰 체인(Chain of Trust)

크로스 싸인 루트 인증서의 동작을 이해하기 위해서는 
TLS Client가 신뢰 체인(Chain of Trust)를
어떻게 만들고 검증하는지  이해해야 합니다.

TLS 세계에서의 일반적인 신뢰체인은 다음과 같습니다. 
- Root 인증서 : Self Signed 로 만들어진 최상위 인증기관의 검증된 인증서 
- Intermediate 인증서 : Root 인증서와 Leaf 인증서를 연결해주는 중간 인증서 
- Leaf 인증서 : 실제 도메인(예: www.naver.com)에 대해 발급된 최종 사용자용 인증서  

TLS 인증서는 보통 3단계로 구성되어 있고
이 흐름을 신뢰체인이라고 생각하면 됩니다.
이 포스팅에서 다루는 내용은 위 그림을 기준을 봤을 때
Root Certificate의 교체가 필요한 상황을 가정하고 있습니다.
(GlobalSign의 경우도 이 경우입니다)

크로스 싸인 루트 인증서 존재 유무에 따른 신뢰체인 검증 흐름

크로스 싸인 루트 인증서는 "새로운 루트 인증서를 기존 루트 인증서로 서명한" 인증서 입니다.
이 루트 인증서를 이용해 "원래의" 루트 인증서 변경에 따른
위험을 줄이고 점진적인 마이그레이션을 추구하는 것이 크로스 싸인 루트 인증서 사용의 목적입니다.

기존 흐름)
Leaf 인증서 - Intermediate 인증서 - Legacy Root 인증서
새로운 흐름)
Leaf 인증서 - Intermediate 인증서 - Cross-Signed Root 인증서 - Legacy Root 인증서

기존 흐름의 Intermediate 인증서는 Legacy Root 인증서로 싸이닝 되어 있습니다
오래된(=truststore가 업데이트 되지 않은) 브라우저 등은
Legacy Root 인증서를 이용해서 Intermediate 인증서를 검증합니다. 

반면 새로운 흐름에서의 Intermediate 인증서는 
Cross-Signed Root 인증서를 이용해 싸이닝 되어 있고 
Cross-Signed Root 인증서는 Legacy Root 인증서를 이용해 싸이닝 되어 있습니다.

여기서 중요한 것은 Cross-Signed Root 인증서는
Legacy Root 를 개체할 새로운 Root 인증서를 지칭한다는 것입니다. 
즉, 새로운 흐름에서 Intermediate 인증서는 
기존 흐름에서의 Intermediate 인증서와 달리
새로운 Root 인증서로 싸이닝된 인증서라는 점입니다. 

차이는 뭘까요?
Legacy Root 인증서가 만료 혹은 더이상 유효하지 않은 경우를 생각합시다.
Legacy Root 인증서가 무효화되면 기존 흐름은 더이상 유효하지 않습니다.
하지만 새로운 흐름은 문제 없이 인증이 됩니다. 

왜일까요?

TLS Client 는 똑똑합니다

이러한 변화가 가능한 이유는 브라우저를 비롯한 현대적인 TLS Client의 똑똑함(?)에 기인합니다. 
새로운 truststore를 탑재한, 혹은 탑재당한 TLS Client는
"새로운 흐름"을 검증하는 과정에서 "Legacy Root 인증서"를 통한 검증 단계를 거치지 않습니다.

즉, Intermediate 인증서가 Cross-Signed Root 인증서의 내용물인
새로운 Root 인증서를 이미 truststore에 보유중이라는 것을 인지한 순간
이후의 검증 단계는 이용하지 않게 됩니다. 

정리

복잡하게 설명했지만 정리는 간단합니다.
크로스 싸인 루트 인증서가 모든 이야기의 핵심입니다. 
Legacy Root 인증서로 싸이닝된 크로스 싸인 루트 인증서는
상황에 따라 상위의 Legacy Root 인증서 검증까지 가고, 가지 않고가 핵심입니다.

이 동작을 통해 크로스 싸이닝이 루트 인증서의 이전을 안전하게 지원하고
실제 TLS Client 역할을 수행하는 주체들이
truststore를 업데이트 하는 동안 발생할 수 있는 문제를 해결해 주는 것입니다.

HTTPS 통신을 위해서는 SSL/TLS 인증서가 필요합니다. 서버측에 Private Key 와 Public key 를 설치하고, 웹 브라우저로 대표되는 User-Agent 는 Public Key 를 전달받아 통신 구간의 암호화에 사용하게 됩니다. 이러한 인증서에는 여러가지 정보들이 담겨 있는데요 가장 대표적인 것으로 도메인 정보를 담고 있는 CN (Common Name) 입니다. 

 CN 이외에도 인증서에는 인증서와 관련한 여러가지 정보를 담기 위한 필드들이 존재합니다. 위의 네이버 인증서 정보에 나오는 주/도, 소재지, 조직 등의 모든 정보들이 인증서의 Public Key 에 포함되어 사용자에게 전달되는 값 들입니다. 네, 당연히 전송되는 용량에 포함되는 값들입니다. openssl 명령으로 이 인증서를 조금 더 자세히 살펴보면...

...인증서의 발급 체계에 따라 서버 인증서, 중간 인증서, 루트 인증서의 정보를 확인할 수 있습니다. 서버 인증서에 있는 C, ST, L, O 등의 값이 브라우저에 표시되었던 정보임을 알 수 있습니다. 가장 위에 있는 루트 인증서를 보면 OU Organization Unit 라는 값이 있는데요 여기에 www.digicert.com  이라는 인증서 발급사의 도메인 정보가 들어가 있는 것을 볼 수 있습니다.

OU 를 직역하면 조직 단위 내지는 부서명 정도가 될 것 같은데 좀 엉뚱한 정보가 들어가 있는 느낌이죠? 회사에서 사용하는 LDAP 정보를 살펴봐도 보통 OU 에는 부서 혹은 조직 단위에 따른 편제 정보가 들어가 있곤 합니다. SSL/TLS 인증서 세계(?)에서는 이 필드를 원래의 목적과 다르게 사용하는 경우가 많았고, 이로 인해 불필요한 바이트의 전송이 관례적으로 있어 왔다는 것을 짐작할 수 있겠습니다 (=우리의 소중한 데이터를 소모해 왔다는 것도...)

이 필드에 대한 논란이 있어온 이래 저렴한 인증서의 대명사였던 Sectigo (과거 COMODO 였죠) 는 진작에 필드를 제거했습니다. Sectigo 쪽에서는 SSL/TLS 인증서의 제품 정보를 표현하는 것과 같은 용도로 쓰이고 있었던 것 같습니다. 역시나 제정되었던 표준, 약속과는 다른 방향이었습니다.

Digicert 는 대한민국발 인증서 사태이후 시만텍의 인증서 사업을 인수해서 운영하고 있는 가장 큰 CA 중 하나입니다. 이제 Digicert 가 OU 필드를 인증서 발급에 사용하지 않고 인증서 정보에도 포함시키지 않을 것이라고 하니, OU 필드는 퇴출이 확정된 거라 봐도 무방할 것 같습니다. 아울러 사용자들은 자신의 인터넷 회선, 모바일 플랜에서 불필요한 전송 비용을 줄일 수 있게 된 것이기도 합니다. 

[ 참고 링크들 ]

https://knowledge.digicert.com/alerts/ou-removal.html

https://www.xolphin.com/news/Change_in_use_of_OU-fields_in_Sectigo_certificates