47-Day TLS Certificates
공개 TLS 인증서의 최대 유효기간이 현재 398일에서 2029년까지 47일로 대폭 단축된다. 이로 인해 도메인 제어 검증(DCV) 재사용 기간도 10일로 줄어들어 모든 인증서 갱신 시마다 새로운 검증이 필요해진다. 이러한 변화는 인증서 자동화 없이는 서비스 중단과 보안 위험을 초래할 수 있으며, 플랫폼 팀은 인증서 재고 관리, 자동화, DCV 자가복구, 외부 모니터링 등 준비가 필수적이다. 특히 2027년 3월 100일 제한 도입 전에 미리 테스트하는 것이 권장된다.

https://www.tidelock.dev/blog/47-day-tls-certificates

#tls #certificate #automation #security #dcv

The 47-day TLS certificate is coming. Your renewal strategy probably won't survive. | Tidelock

TLS certificate lifetimes are dropping from 398 days to 47 over the next three years. Here's what changes, why it's happening, and the eight things every platform team should fix before the first cliff in 2027.

Tidelock

A new draft of "Domain Control Validation using DNS" has been published -- see https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-11

This includes a Threat Model, as suggested by @paulehoffman and others. There aren't many precedent examples for a Threat Model as a sub-portion of a draft (although there are standalone Threat Model RFCs). I took a STAMP-like approach to writing this one, along with cross-references back to it elsewhere in the draft. After having gone through the process of writing this, I'm quite glad that I did. I'm now convinced that any IETF draft trying to solve a security problem should (SHOULD?) include a Threat Model to make it clear what problem it is trying to solve.

#STAMP #security #IETF #DNS #ThreatModel #DCV

Domain Control Validation using DNS

Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems.

IETF Datatracker

Et vous, ? elle commence comment votre journée ? #DCV #PKI

https://github.com/cabforum/servercert/blob/main/docs/BR.md#32242-email-fax-sms-or-postal-mail-to-domain-contact

> Confirming the Applicant's control over the FQDN by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.

Les cartes postales, ça compte ?

servercert/docs/BR.md at main · cabforum/servercert

Repository for the CA/Browser Forum Server Certificate Chartered Working Group - cabforum/servercert

GitHub