들어가며

사내 시스템들의 SSL 인증서 갱신 주기가 돌아왔다.
여러 시스템들의 SSL 인증서를 갱신하다보면 어떤 시스템은 톰캣에, 또 어떤 시스템은 로드밸런서에 여러 방식으로 SSL 인증서를 갱신한다.

왜 각각 다른 방식으로 SSL 인증서를 갱신하는지, 여러 인증서 적용 및 갱신 방법을 알아보려 한다.

SSL 인증서가 각각 다른 적용 방식을 사용하는 이유는?

시스템 아키텍쳐 및 애플리케이션 범위

간략하게 두가지 시스템 아키텍쳐를 표현해보았다.

왼쪽은 다중 인스턴스에 연결되어있는 로드밸런서 즉, 중앙 집중식 지점을 제공하는 반면
오른쪽은 애플리케이션 수준의 독립적인 지점을 제공한다.

왼쪽의 경우 로드밸런서에만 SSL 을 적용하면 관리하기 더 쉽지 않을까?

장치 호환성 및 보안 요구 사항

이번에 SSL 갱신 작업을 하면서 알게된 사실인데,

Apple 의 ATS(App Transport Security) 는 SSL/TLS 사용에 대해 엄격한 규칙을 시행한다고 한다.
예를 들어 TLS 1.2 이상을 요구하며 보안 트래픽 수락을 위해 첫 번째 연결 지점(종종 로드 밸런서)에서 SSL 인증서 를 구현해야 한다.
Apple 장치는 특히 "1 Depth" 요구 사항을 적용하고 있어, 왼쪽 아키텍쳐 같은 경우 로드밸런서에 SSL 인증서 를 적용시키지 않으면 안된다.

API 만을 담당하는 시스템의 경우 독립적인 SSL 적용 을, 백/프론트 같은 화면이 있는 시스템 의 경우 로드밸런서 에 적용을 하는 것이 일반적이라고 한다.

다양한 환경에서 SSL 인증서 적용

사내에서 사용하는 적용 방식에 대해 설명해 보려한다. 추가적인 적용 방식이나 좋은 방법이 있으면 댓글로 피드백 부탁드린다.

로드밸런서에 적용

현재 사내 시스템들은 NHN 클라우드 환경에서 구동되고 관리되고 있다. (로드 밸런서 또한)
각각의 클라우드 환경마다 적용 방식이 달라 이 부분은 넘어간다.

스프링부트 프로젝트에 적용 (내장 WAS)

1. SSL 인증서 업체(Ex. 한국전자인증) 로 부터 인증서 파일을 전달 받는다.

2. 받은 키들을 이용해 PKCS12 형식으로 변환시켜준다.

2. 번까지의 작업은 인증서 업체에서 작업 후 공유해주거나 발급받은 키들을 이용해 변환하는 작업이다.
깊고 내용이 많은 부분이라 이 부분은 나중에 포스팅 하겠다.

3. 프로젝트에 변환된 파일을 넣는다.

4. .properties(또는 .yaml) 설정 파일에서 설정 및 적용한다.

톰캣/conf/ssl/ 경로에 적용 시키고 server.xml 에 적용 (외장 WAS)

1. SSL 인증서 업체(Ex. 한국전자인증) 로 부터 인증서 파일을 전달 받는다.

2. 받은 키들을 이용해 PKCS12 형식으로 변환시켜준다.

2. 번까지의 작업은 인증서 업체에서 작업 후 공유해주거나 발급받은 키들을 이용해 변환하는 작업이다.
깊고 내용이 많은 부분이라 이 부분은 나중에 포스팅 하겠다.

3. 톰캣의 ssl 인증서 경로에 넣어준다.

대부분의 경로는 톰캣경로/conf/ssl 이다.

4. server.xml 에서 인증서 정보를 수정 및 적용한다.

주석처리되어있다면 풀어주자.