クイズ：証明書の構造

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

• subject 의 Common Name(CN)
• issuer 의 Common Name
• subjectAltName 확장의 dNSName 목록
• basicConstraints 확장의 값

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

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

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

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

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

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

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

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

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

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