오늘 기준으로 certbot으로는 IP 주소 인증서를 받을 수 없었음
대신 lego를 사용했는데, 정확한 명령어를 찾는 데 꽤 시간이 걸렸음
어제 성공한 명령은 다음과 같음 lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived
혹시 Caddy에서도 이 기능이 지원되는지 궁금했음
아직 진행 중인 듯함 (GitHub 이슈)
IP 주소 인증서는 iOS 사용자가 직접 DoH 서버를 운영할 때 특히 흥미로운 주제임
iOS에서는 FQDN과 IP 모두에 올바른 인증서가 있어야 작동했음
그래서 dns4eu나 nextdns 같은 대형 서비스의 프로필은 잘 작동하지만, 개인이 만든 DoH 서버는 실패했음
OpenSSL이 TLS 연결 시 인증서의 SAN 필드에 IP 주소가 포함되어야 한다고 엄격히 요구함
아마 iOS 엔지니어가 명시적으로 추가한 게 아니라, 사용하는 암호화 라이브러리의 부작용일 가능성이 있음
나는 개인 도메인을 리버스 프록시 뒤에서 DoH로 매일 사용 중인데 아무 문제 없음
왜 6일짜리 인증서인지 궁금했음
8일이면 주 단위로 갱신하기 좋고, 8은 2의 거듭제곱이자 행운의 숫자라 생각했음
하지만 6은 그냥 마음에 들지 않음
6일 주기로 하면 장기적으로 부하가 주중에 균등하게 분산됨
8일이면 특정 요일에 트래픽이 몰릴 수 있음
실제로는 6일이 아니라 약 160시간(6.6일) 임
160은 첫 11개의 소수의 합이자, 첫 세 소수의 세제곱 합이기도 함
6일은 신이 6일 일하고 7일째 쉬었다는 상징도 있음
6은 가장 작은 완전수(perfect number) 라서 완벽함의 상징임
다음으로는 .onion 주소용 인증서 발급에 집중하길 바람
.onion은 이미 키 쌍을 가지고 있어서 소유 증명이 DNS보다 더 신뢰할 수 있음
Hacker News 의견들
오늘 기준으로 certbot으로는 IP 주소 인증서를 받을 수 없었음
대신 lego를 사용했는데, 정확한 명령어를 찾는 데 꽤 시간이 걸렸음
어제 성공한 명령은 다음과 같음
lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived아직 진행 중인 듯함 (GitHub 이슈)
IP 주소 인증서는 iOS 사용자가 직접 DoH 서버를 운영할 때 특히 흥미로운 주제임
iOS에서는 FQDN과 IP 모두에 올바른 인증서가 있어야 작동했음
그래서 dns4eu나 nextdns 같은 대형 서비스의 프로필은 잘 작동하지만, 개인이 만든 DoH 서버는 실패했음
아마 iOS 엔지니어가 명시적으로 추가한 게 아니라, 사용하는 암호화 라이브러리의 부작용일 가능성이 있음
왜 6일짜리 인증서인지 궁금했음
8일이면 주 단위로 갱신하기 좋고, 8은 2의 거듭제곱이자 행운의 숫자라 생각했음
하지만 6은 그냥 마음에 들지 않음
8일이면 특정 요일에 트래픽이 몰릴 수 있음
160은 첫 11개의 소수의 합이자, 첫 세 소수의 세제곱 합이기도 함
다음으로는 .onion 주소용 인증서 발급에 집중하길 바람
.onion은 이미 키 쌍을 가지고 있어서 소유 증명이 DNS보다 더 신뢰할 수 있음
IP 인증서를 원한다면 certbot은 아직 지원하지 않음
관련 PR이 열려 있음 (#10495)
대신 acme.sh는 이미 지원하는 듯함
certbot도 곧 지원될 것으로 기대함
나는 2주 갱신 주기로 테스트 중이었는데, 이제 인증서가 6일짜리로 나와서 당황했음
파이프라인이 실패하면 디버깅할 시간이 너무 짧음
IP가 도메인보다 더 변동성이 크다는 이유는 납득하기 어려움
VPS의 고정 IP는 그렇게 자주 바뀌지 않음
만약 45일짜리 인증서를 발급받고 바로 IP를 반납하면, 다른 사용자가 그 IP를 쓰게 됨
그럼 남의 IP에 대한 유효한 인증서를 갖게 되는 셈이라 위험함
이런 정책은 현장의 실무를 잘 모르는 접근 같음
대부분의 서비스 운영자는 IP 자체를 직접 통제하지 않으므로, CA의 리스크를 줄이기 위한 조치임
악용은 어렵지만, 여전히 보안상 고려할 부분임
IP 주소 인증서가 생기면 IPsec 전송 모드가 다시 주목받을 수 있을지 궁금했음
내가 작성한 RFC 5660도 관련 있음
IPsec 터널에 인증서를 쓰게 하는 것도 여전히 번거로움
일부 방화벽 장비는 인증서 체인이 길면 인증 실패를 일으키는 이상한 버그도 있음
IP 인증서는 인터넷에서 접근 가능한 주소만 가능하므로, LAN 기기용 TLS는 여전히 어려움
엣지에서 DNAT로 트래픽을 받아 인증서 갱신용 VM으로 전달하고, 내부 기기로 분배하면 됨
*.home.example.com)를 사용 중임TXT 레코드를 API로 설정할 수 있는 공개 DNS가 필요하지만, lego의 DNS 플러그인이 여러 제공자를 지원함
이번 발표가 정말 반가움
IP 인증서는 self-hosted 소프트웨어의 초기 부트스트랩 문제를 해결해줌
예를 들어 TakingNames의 instant subdomains 기능을 더 이상 필요로 하지 않을 수도 있음
IP 주소 인증서는 짧게 존재하는 서비스(ephemeral service) 가 TLS 통신을 할 때 유용함
DNS 레코드를 따로 만들 필요가 없어서 수백 개의 임시 인스턴스를 띄울 때 편리함
평문으로 노출되는 SNI 대신 IP 인증서를 사용하면, 외부에서 실제 호스트명을 볼 수 없음
대형 클라우드가 아닌 소규모 사이트도 프록시 없이 ECH를 쓸 수 있게 됨
더 익명성이 높아짐