CNAME 레코드를 사용할 때 SSL 인증서 서명 요청에 사용할 FQDN 호스트 이름은 무엇입니까?


10

다른 호스트 이름 (CNAME 레코드에 정의 된)의 별칭 인 하위 도메인 ( https://portal.company.com )이 있습니다.

이 동적 DNS 호스트 이름 ( https://portal.dlinkddns.com )은 사무실의 공개 (동적) IP 주소로 확인됩니다. 사무실에서 라우터는 직원이 집에서 액세스 할 수있는 (Spiceworks) 웹 포털을 실행하는 서버로 포트 443을 전달하도록 구성되어 있습니다. 사무실의 공용 IP 주소가 변경 되더라도 하위 도메인은 여전히 ​​직원을 웹 포털로 안내합니다. (예상 한) SSL 인증서 오류 담당자가 사이트에 처음 연결할 때 확인하는 것과는 별도로 모든 것이 작동합니다.

방금 SSL 인증서를 구입했으며 이제 서버에서 인증서 서명 요청을 완료하는 중입니다.

내 질문으로 연결됩니다 ...

" 공통 이름 (예 : 서버 FQDN 또는 사용자 이름) "에 대한 인증서 서명 요청을 완료 할 때 무엇을 입력해야합니까?

정식 이름 ( https://portal.dlinkddns.com ) 또는 별칭 ( https://portal.company.com )을 입력해야합니까 ? 서버 자체의 FQDN은 "servername.companyname.local"이므로 사용할 수 없습니다.

어떤 제안이나 아이디어라도 대단히 감사하겠습니다!

답변:


12

서비스에 액세스 한 이름을 사용합니다. 따라서 포털 클라이언트가 https://portal.dlinkddns.com을 방문 하는 경우 portal.dlinkddns.com을 사용 하십시오 . https://portal.company.com 을 방문 하면 portal.company.com을 사용 하십시오 .

클라이언트가 둘 다에 액세스하는 경우 이름 중 하나는 DN으로, 다른 하나는 subjectAltName으로 인증서를 확보하여 두 가지 모두에 사용할 수 있습니다.

질문 줄 사이에서 올바르게 읽으면 브라우저에서 액세스 할 수있는 모든 것이 https://portal.company.com 이므로 귀하의 경우에는 해당 이름의 인증서를 받으십시오.


"portal.company.com"을 사용했는데 지금까지 모든 것이 좋아 보입니다. CSR 프로세스가 완료되었으며 GoDaddy에서 SSL 인증서를 발급했습니다. 인증서를 Spiceworks로 가져온 후 세부 정보로 업데이트하겠습니다.
Austin ''Danger ''Powers

SSL 인증서를 가져 왔으며 모든 것이 잘 작동합니다. 브라우저 경고가 없습니다. 건배
오스틴 '위험'힘 9

7

도메인 company.com (예 :)이 있고 인증서의 일반 이름이 "그냥 작동"하도록하려면 다음과 같이 와일드 카드 기반 일반 이름을 사용하는 것이 좋습니다. *.company.com

그러면 SSL 인증서가 https://company.comhttps://www.company.com 및 사용하기로 선택한 모든 하위 도메인에 대해 작동해야 합니다.

참고 : openssl 명령으로 만든 자체 서명 된 인증서에서만 사용했지만 "실제"인증서에서도 작동 할 수 있습니다. 나는 그들이 왜 그런지 알 수 없습니다. (하지만 와일드 카드 인증서는 구입할 때 비 와일드 카드 인증서보다 비쌀 수 있습니다.)

openssl 명령이 공통 이름을 요청할 때이 정보를 힌트로 제공하지 않는 것은 부끄러운 일입니다. 테스트 서버에 대한 SSL 인증서를 자체 서명 할 때는 "* .company.com"형식의 일반 이름을 사용합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.