(이것은 인증서와 CA 뒤에 “마법”이 없다는 것을 이해하는 데 도움이되기 때문에 이전 질문에 대한 새로운 답변입니다)

@Steffen Ullrich가 제공 한 승인 된 답변의 확장으로

웹 사이트를 식별하기위한 전체 인증서는 큰 돈을 버는 사업입니다. X509 인증서는 RFC5280에 의해 정의 되며 다른 사용자는 루트 CA 또는 중간 CA 일 수 있으며, 모두 해당 엔티티에 대한 신뢰에 따라 다릅니다.

예 : Active Directory 도메인에있는 경우 기본 도메인 컨트롤러는 기본적으로 신뢰할 수있는 루트 인증 기관입니다. 한편, 다른 제 3자는 절대 관여하지 않습니다.

광범위한 인터넷에서 문제는 “회사를 신뢰할 수있는 사람”이 하나의 회사보다 훨씬 크기 때문에 식별하는 것입니다. 따라서 브라우저 공급 업체는 사용자 동의없이 다른 신뢰할 수있는 루트 CA의 사용자 지정 임의 목록을 제공합니다.

즉, Mozilla 재단과 아주 좋은 관계를 유지하고 있다면 Firefox 브라우저의 다음 릴리스에서 자체적으로 자체 서명 한 루트 CA를 해당 목록에 추가 할 수 있습니다.

또한 인증서와 관련하여 브라우저의 동작 방식에 대한 동작 및 규칙을 정의하는 RFC가 없습니다. 이는 인증서의 “CN”이 도메인 이름과 같기 때문에 일치해야한다는 암시 적 합의입니다.

이것으로 어느 정도 충분하지 않았기 때문에 브라우저 공급 업체는 모두 해당 형식의 와일드 카드 인증서가 *.domain.com모든 하위 도메인과 일치하도록 암시 적으로 노화되었습니다 . 그러나 그것은 단지 한 수준과 일치 sub.sub.domain.com합니다. 그들은 단지 그렇게 결정했기 때문입니다.

원래 질문에 대해 기본 도메인 인증서가 자신의 하위 도메인에 대한 하위 인증서를 만들 수 없도록하는 것은 브라우저가 인증서 체인을 가져 오기만하면 쉽게 확인할 수있는 프로세스입니다.

대답은 : 아무것도

(기술적으로 자신의 도메인 인증서에 “플래그”가 있어야합니다.)

이 방법이 충분히 편리하다면, 판매업자는이를 지원하기로 결정할 수 있습니다.

그러나 첫 번째 진술로 돌아가서 이것은 큰 돈 사업입니다. 따라서 브라우저 공급 업체와 계약을 맺은 소수의 루트 CA는 그 목록에 많은 돈을 소비하고 있습니다. 그리고 오늘날 각 개별 하위 도메인 인증서에 대해 비용을 지불하거나 훨씬 비싼 와일드 카드를 가져와야하므로 돈을 돌려받습니다. 그들이 당신이 당신의 자신의 서브 도메인 인증서를 만들 수 있도록 허용한다면, 이것은 그들의 이익을 엄청나게 줄입니다. 그래서 이것이 오늘날의 이유입니다.

글쎄, 당신은 여전히 ​​유효한 x509 인증서이기 때문에 여전히 할 수 있지만 어떤 브라우저도 그것을 인식하지 못합니다.

답변