Quiz: the renewal incident

갱신 도구가 인증서 파일을 성공적으로 덮어썼는데 브라우저는 옛 인증서를 본다. 가장 그럴듯한 원인은?

• 브라우저가 옛 인증서를 캐시하고 있어서 재시작해야 한다
• 새 인증서의 SAN 이 옛것과 달라 브라우저가 옛것을 선호한다
• 갱신 도구가 파일 권한을 바꿔 서버가 읽지 못하게 됐다
• 서버가 기동 때 읽은 인증서를 메모리에서 계속 내보내고 있어 재적재가 필요하다

갱신이 실제로 반영됐는지 판정하는 근거로 가장 믿을 만한 것은?

• 갱신 도구가 남긴 성공 로그와 그 시각의 파일 갱신 기록
• openssl s_client 로 서버에서 받아 온 인증서의 serial 과 notAfter
• 디스크에 놓인 인증서 파일에서 읽은 serial 과 notAfter
• 인증서 관리 시스템의 상태 화면에 표시된 갱신 성공 여부

만료 감시 스크립트를 디스크의 인증서 파일에 -checkend 로 걸어 두었다. 이 감시의 맹점은?

• 갱신 직후 파일은 새것이라 초록불이 켜지지만 서버는 옛 인증서를 내보내고 있을 수 있다
• -checkend 는 초 단위라 날짜 단위 감시에는 쓸 수 없다
• 파일이 PEM 이 아니면 -checkend 가 동작하지 않는다
• 디스크 파일은 개인키와 함께 있어 읽을 때마다 보안 경고가 난다

같은 개인키로 갱신한 v2 인증서를 옛 v1 과 구별하는 가장 간단한 값은?

• 공개키의 sha256 해시
• 발급자(issuer)의 이름
• 일련번호(serial) 또는 지문
• SAN 의 dNSName 목록

cert-manager 가 Secret 의 인증서를 갱신했다. 그 Secret 을 볼륨으로 마운트한 앱 파드에 대해 옳은 설명은?

• Secret 이 바뀌는 순간 앱이 자동으로 새 인증서로 핸드셰이크한다
• 마운트된 파일은 얼마 뒤 바뀌지만 그 파일을 다시 읽는 것은 앱의 몫이라 재적재 로직이 없으면 파드를 재시작해야 한다
• kubelet 이 앱 프로세스에 SIGHUP 을 보내 재적재를 강제한다
• 볼륨으로 마운트한 Secret 은 갱신되지 않으므로 환경 변수로 넣어야 한다

갱신 자동화를 처음 켰을 때 운영자가 해야 할 확인으로 가장 알맞은 것은?

• 만료일까지 기다렸다가 자동으로 갱신되는지 지켜본다
• 설정 파일의 문법 검사만 통과하면 충분하다
• 유효기간을 최대한 길게 늘려 갱신이 필요 없게 만든다
• 한 번 강제로 갱신을 일으켜 서버가 새 인증서를 내보내는 것까지 s_client 로 확인한다