퀴즈: 인증서의 구조

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 브라우저는 인증서의 이름을 어디에서 확인하는가?

   1. subject 의 Common Name(CN)
   2. issuer 의 Common Name
   3. subjectAltName 확장의 dNSName 목록
   4. basicConstraints 확장의 값

2. `openssl verify -CAfile ca.crt api.crt` 가 `unable to get local issuer certificate` 로 실패한다. 가장 그럴듯한 원인은?

   1. 리프와 루트 사이의 중간 CA 인증서가 없어 사슬이 끊겼다
   2. api.crt 가 만료됐다
   3. api.crt 의 SAN 에 검증하려는 이름이 없다
   4. ca.crt 의 개인키가 잘못됐다

3. OpenSSL 3.0 에서 `-addext` 로 SAN 을 넣은 CSR 을 `x509 -req` 로 서명했는데 인증서에 SAN 이 없다. 왜인가?

   1. CSR 에 SAN 을 넣으려면 설정 파일이 반드시 필요하기 때문
   2. SAN 은 CA 인증서에만 들어갈 수 있는 확장이기 때문
   3. -days 를 주면 확장이 초기화되기 때문
   4. x509 -req 는 기본으로 CSR 의 확장을 버리므로 -copy_extensions copy 를 줘야 하기 때문

4. 같은 개인키로 인증서를 갱신했다. 옛 인증서와 새 인증서에서 반드시 달라지는 것은?

   1. 공개키와 SAN
   2. 일련번호(serial)와 유효기간, 따라서 지문
   3. 발급자 이름
   4. basicConstraints 의 cA 값

5. `openssl x509 -checkend 604800` 이 종료 코드 1 로 끝났다. 뜻은?

   1. 인증서 파일이 깨져 읽을 수 없다
   2. 인증서가 이미 만료됐다는 뜻이며 앞으로의 기간은 보지 않는다
   3. 앞으로 604800초(7일) 안에 만료된다
   4. 인증서가 7일 이상 남았다

6. 중간 CA 가 발급한 리프 인증서를 서버에 물릴 때 서버가 보내야 하는 것은?

   1. 리프 + 중간 CA — 루트는 클라이언트의 신뢰 저장소에 있으므로 보내지 않아도 된다
   2. 리프 인증서 하나만 — 클라이언트가 나머지를 알아서 찾는다
   3. 루트 CA 인증서만 — 리프는 핸드셰이크에서 협상된다
   4. 리프 + 중간 CA + 루트 + CA 의 개인키