tls-certificates

2 개의 포스트

cloudflare

인증서 투명성 모니터링이 이제 정식 출시되었습니다 (새 탭에서 열림)

Cloudflare는 Certificate Transparency(CT) 모니터링에서 자사가 발급한 정상적인 인증서 갱신까지 알림으로 보내던 문제를 해결했다. 이제 Cloudflare가 관리·발급한 인증서는 자동으로 필터링하고, 외부에서 발급된 예상치 못한 인증서만 알림을 보낸다. 이를 위해 인증서 발급 초기부터 최종 인증서까지 유지되는 공개키 기반 식별자 `spki_sha256`를 사용한다. ## CT 모니터링의 알림 과다 문제 - CT 모니터링은 고객 도메인에 새로운 TLS 인증서가 공개 CT 로그에 등장하면 이메일을 보낸다. - 이 기능은 잘못 발급된 인증서를 조기에 발견하는 데 유용하지만, Cloudflare가 고객을 대신해 발급하는 인증서도 모두 알림 대상이었다. - Universal SSL, Advanced Certificate Manager, Total TLS, Backup Certificate 등의 정상적인 발급·갱신이 반복적으로 CT 로그에 기록된다. - 기존 인증서는 최대 60일마다 갱신될 수 있으며, 2029년에는 최대 유효기간이 47일로 줄어들 예정이라 정상 갱신 알림은 더욱 늘어날 수 있다. - 결과적으로 중요한 외부 인증서 발급 알림이 정상적인 갱신 알림에 묻히거나, 사용자가 기능을 꺼버리는 문제가 발생했다. ## 인증서 관리 시스템과 CT 알림 시스템의 단절 - 인증서 발급 시스템은 내부 발급 정보를 관리하고, CT 알림 시스템은 공개 CT 로그를 읽어 알림을 생성한다. - 두 시스템은 같은 인증서를 다루지만 처리 시점과 보유 정보가 다르다. - CT 알림 시스템이 로그를 확인하는 순간에는 해당 인증서가 Cloudflare 발급인지 알려주는 발급 시스템의 정보가 없었다. - 따라서 “이 인증서가 Cloudflare가 발급한 것인가?”를 판단할 연결 고리가 필요했다. ## 사전 인증서와 최종 인증서의 처리 순서 - 하나의 인증서 발급은 일반적으로 다음 두 단계로 CT 로그에 기록된다. - CA가 사전 인증서(pre-certificate)를 생성하고 로그에 기록한다. - SCT(Signed Certificate Timestamp)를 최종 인증서에 포함한 뒤 최종 인증서를 다시 로그에 기록한다. - 하나의 발급 요청에 대해 두 개의 로그 항목이 생기므로, Cloudflare는 `stripped_fingerprint`를 사용해 중복 알림을 방지했다. - `stripped_fingerprint`는 DER로 인코딩된 TBSCertificate의 해시이며, 사전 인증서와 최종 인증서 쌍을 식별하는 데 적합하다. - 그러나 발급 시스템은 사전 인증서를 받지 않기 때문에 이 값을 발급 초기에 계산할 수 없다. - 사전 인증서가 먼저 로그에 기록되는 짧은 시간 동안에는 발급 시스템 데이터베이스에 해당 fingerprint가 없어, Cloudflare가 발급한 인증서임에도 알림이 발생할 수 있었다. ## 공개키 기반 식별자 선택 새 식별자는 다음 조건을 만족해야 했다. - CT 로그에 기록되기 전에 생성될 것 - 사전 인증서와 최종 인증서 전반에서 동일할 것 - CT 알림 시스템이 로그 정보만으로 다시 계산할 수 있을 것 - 인증서 발급 요청마다 고유할 것 이 조건을 만족하는 값으로 인증서의 공개키가 선택됐다. - 공개키는 `SubjectPublicKeyInfo(SPKI)` 구조 안에 포함된다. - 키 생성 시점부터 CSR, 사전 인증서, 최종 인증서까지 동일하게 유지된다. - Cloudflare는 발급마다 새로운 키 쌍을 생성하므로 공개키는 사실상 발급 요청마다 고유하다. - 개인키는 Cloudflare만 보유하므로, 동일한 공개키를 가진 유효한 인증서는 Cloudflare 발급 과정에서 나온 것으로 판단할 수 있다. - Cloudflare는 DER 인코딩된 SPKI를 SHA-256으로 해시한 `spki_sha256` 값을 사용한다. ## `spki_sha256`를 이용한 알림 필터링 - 인증서 발급 시스템은 CSR에서 `spki_sha256`를 계산해 키 생성 시점에 데이터베이스에 저장한다. - CT 알림 시스템은 CT 로그에서 인증서를 발견하면 공개키로 동일한 `spki_sha256`를 다시 계산한다. - 이후 발급 시스템 데이터베이스에서 해당 값을 조회한다. - 값이 있으면 Cloudflare가 발급한 인증서로 간주하고 알림을 억제한다. - 값이 없으면 외부 발급 인증서로 간주하고 기존처럼 알림을 보낸다. - 사전 인증서와 최종 인증서의 공개키가 동일하므로 어느 항목이 먼저 처리되더라도 일관되게 판단할 수 있다. ## 필터링 적용 결과 - Cloudflare가 관리하는 Universal SSL, Advanced Certificate Manager, Total TLS, Backup Certificate는 정상적으로 알림에서 제외된다. - 사전 인증서만 로그에 남고 최종 발급이 중단된 경우에도 Cloudflare 발급 기록과 일치하므로 불필요한 알림이 발생하지 않는다. - 사용자가 직접 업로드한 커스텀 인증서는 Cloudflare가 키를 생성하지 않았으므로 발급 시스템에 일치하는 키 기록이 없다. - 따라서 외부에서 관리되는 커스텀 인증서나 예상치 못한 인증서 발급은 계속 알림 대상이다. Cloudflare의 개선은 정상적인 내부 인증서 갱신을 제거하면서도 외부 발급 인증서는 놓치지 않도록 해 CT 모니터링의 신호 대 잡음비를 높인 사례다. 사용자는 알림을 끄기보다, 이제 실제로 확인할 가치가 있는 인증서 발급 이벤트를 중심으로 대응할 수 있다.

aws

AWS Certificate Manager에서 ACME 지원으로 퍼블릭 TLS 인증서 발급 자동화 | Amazon Web Services (새 탭에서 열림)

AWS Certificate Manager(ACM)가 ACMEv2를 지원하면서 Certbot, cert-manager, acme.sh 등 기존 ACME 클라이언트로 Amazon Trust Services의 공인 TLS 인증서를 자동 발급·갱신할 수 있게 됐다. 인증서 수명이 2027년 100일, 2029년 47일까지 단축될 예정인 상황에서 수동 갱신의 운영 부담을 줄이고, 조직 차원의 인증서 발급·권한·감사를 ACM에서 통합 관리할 수 있다는 것이 글의 핵심이다. ## 인증서 자동화가 필요한 이유 - TLS 인증서는 만료 시 고객의 접속 오류와 서비스 중단을 일으킬 수 있다. - CA/Browser Forum 정책에 따라 최대 인증서 유효기간이: - 2027년 3월부터 100일 - 2029년부터 47일 로 단축될 예정이다. - 수동 발급과 갱신만으로는 짧아지는 인증서 주기를 안정적으로 관리하기 어렵다. - ACME는 인증서 발급, 갱신, 폐기를 자동화하는 표준 프로토콜이며 Let’s Encrypt를 비롯한 다양한 클라이언트가 지원한다. ## ACM의 ACME 지원 - ACM이 완전 관리형 ACME 서버 엔드포인트를 제공한다. - ACMEv2 호환 클라이언트를 사용해 공인 TLS 인증서를 발급할 수 있다. - Certbot - Kubernetes cert-manager - acme.sh - 기타 ACMEv2 클라이언트 - 인증서는 Amazon Trust Services에서 발급되며, 일반적인 브라우저와 운영체제에서 기본적으로 신뢰된다. - 기존에는 외부 CA와 ACM을 함께 사용해야 해 인증서 현황과 관리가 분산됐지만, 이제 ACM에서 ACME 발급 인증서까지 검색하고 관리할 수 있다. ## 중앙 집중식 권한 및 정책 관리 - PKI 관리자는 하나 이상의 ACME 엔드포인트를 만들어 조직의 인증서 사용을 중앙 관리할 수 있다. - IAM 역할과 ACME 계정을 연결해 클라이언트별 요청 권한을 세밀하게 제어할 수 있다. - 엔드포인트 수준에서 허용 도메인과 인증서 범위를 지정할 수 있다. - 도메인별로 다음 발급 범위를 선택할 수 있다. - Exact domain: 지정한 도메인만 허용 - Subdomains: `api.example.com` 같은 하위 도메인 허용 - Wildcards: `*.example.com` 같은 와일드카드 인증서 허용 - 와일드카드 발급을 제한하는 등 조직의 보안 정책을 일관되게 적용할 수 있다. - ECDSA와 RSA 등 허용할 키 유형도 중앙에서 제한할 수 있다. ## 도메인 검증과 역할 분리 - 도메인 검증은 엔드포인트 생성 시 PKI 관리자가 한 번 수행한다. - DNS 자격 증명은 관리자에게만 유지되며, 애플리케이션 소유자에게 배포할 필요가 없다. - 애플리케이션 소유자는 EAB 자격 증명으로 ACME 계정을 등록하고, 허용된 도메인 범위 안에서만 인증서를 요청한다. - Route 53을 사용하는 경우 ACM이 DNS 검증용 CNAME 레코드를 자동 생성한다. - 외부 DNS 제공업체를 사용하면 ACM이 제공하는 CNAME 레코드를 관리자가 직접 추가해야 한다. - 이 구조는 각 ACME 클라이언트가 개별적으로 DNS 검증을 수행하는 일반적인 구성보다 DNS 키 배포 위험을 줄인다. ## ACME 엔드포인트 설정 절차 - ACM 콘솔의 ACME certificates 페이지에서 `Create ACME endpoint`를 선택한다. - 엔드포인트 유형을 Public으로 설정한다. - 인증서 유형을 Public으로 설정한다. - 인증서 키 유형을 선택한다. - 기본값: ECDSA P-256 - 선택 가능: RSA 2048, ECDSA P-384 - 발급을 허용할 도메인과 도메인 스코프를 설정한다. - Route 53 Hosted Zone을 선택하거나 DNS 제공업체에 검증용 CNAME을 직접 등록한다. - DNS 검증 상태가 `Success`로 바뀌면 엔드포인트를 사용할 수 있다. ## External Account Binding(EAB) - EAB는 ACME 클라이언트가 ACM의 ACME 서버에 계정을 등록할 때 사용하는 인증 수단이다. - 다음 두 값으로 구성된다. - Key ID - HMAC Key - ACM 콘솔의 엔드포인트 상세 화면에서 EAB 자격 증명을 생성한다. - 생성한 EAB 자격 증명은 필요한 기간만큼만 유효하도록 만료 시간을 설정하는 것이 권장된다. - ACME 클라이언트가 EAB로 초기 계정을 등록하면, 이후에는 클라이언트가 생성한 비대칭 키 쌍으로 인증서 요청을 인증한다. - EAB 값은 클라이언트 설정에 필요하므로 안전하게 보관해야 한다. ## Certbot을 이용한 인증서 발급 - ACM 콘솔은 Certbot과 acme.sh용 CLI 예제를 제공한다. - Certbot은 다음과 같은 방식으로 실행할 수 있다. ```bash certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory \ --eab-kid <EAB_KID> \ --eab-hmac-key <EAB_HMAC_KEY> \ --issuance-timeout <ISSUANCE_TIMEOUT> \ -d <DOMAIN> ``` - `--server`에는 ACM ACME 엔드포인트 URL을 지정한다. - `--eab-kid`와 `--eab-hmac-key`에는 ACM에서 생성한 EAB 값을 입력한다. - `-d`로 발급 대상 도메인을 지정한다. - 클라이언트마다 EAB 설정 방식과 명령어 문법이 다를 수 있으므로 사용 중인 ACME 클라이언트의 문서를 확인해야 한다. ## 감사, 모니터링 및 만료 알림 - AWS CloudTrail이 ACME 인증서 요청을 기록해 감사 추적을 지원한다. - Amazon CloudWatch로 운영 지표를 모니터링할 수 있다. - ACM은 인증서 만료가 임박하면 알림을 보낸다. - 콘솔, API, ACME를 통해 발급된 인증서를 ACM에서 통합 검색할 수 있다. - 별도 인증서 라이프사이클 관리 제품이나 자체 정책 시스템을 구축하지 않고도 중앙 통제와 가시성을 확보할 수 있다. ## 실용적인 결론 조직에서 여러 서비스와 Kubernetes 클러스터의 인증서를 자동 관리해야 한다면 ACM ACME 엔드포인트를 활용하는 것이 유용하다. 특히 DNS 자격 증명은 PKI 관리자에게만 보관하고, 애플리케이션별로 제한된 도메인 스코프와 짧은 만료 기간의 EAB 자격 증명을 발급해 최소 권한 원칙을 적용하는 것이 권장된다.