나는회사.sv도메인을 사용하고 최근에 RapidSSL 와일드카드 인증서를 구입하여 이를 설치하고 여러 브라우저(Firefox, Chromium, Chrome, IE) 및 SSL 검사 도구로 테스트했는데 Windows, Linux 및 Android 모두에서 Google Chrome을 제외한 모든 브라우저에서 제대로 작동했습니다.
Chrome을 통해 웹사이트에 접속할 때마다 접속을 시도했다는 경고 메시지가 표시됩니다.www.company.sv또는뭐든지.company.sv하지만 서버는 자신을 **.company.sv*로 식별합니다. 경고에도 불구하고 계속해서 빨간색 자물쇠를 클릭하면 네트워크 내부에서만 유효하고 외부 인증 엔터티를 통해 확인할 수 없는 서버에 연결되어 있다는 메시지가 나타납니다.
인증서 재판매업체의 지원 서비스에 문의했지만 문제가 무엇인지에 대한 직접적인 답변을 받을 수 없었습니다. TLD와 관련이 있는지 궁금합니다..sv. Chromium 소스 코드도 확인했지만 인증서가 Chromium에서 완벽하게 작동하기 때문에 다소 의미가 없는 것 같습니다.
Ubuntu 12.04 서버에서 NGINX를 사용하고 있으며 와일드카드 인증서를 구입하기 전에 Comodo의 무료 단일 도메인 인증서를 테스트했다는 점을 언급할 가치가 있을 것입니다.
답변1
웹 서버에 중간 인증서 번들을 설치하는 것을 잊은 것 같습니다. 중간 번들을 다운로드하려면 인증서 공급업체의 웹사이트를 방문하세요.
nginx의 경우 이는 인증서와 연결되어 지시문에 배치되어야 합니다 ssl_certificate. 예를 들면 다음과 같습니다.
# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt
그리고 nginx 구성에서:
ssl_certificate /etc/path/to/company.sv.chained.crt
답변2
제목 CN= 필드에 사이트 이름이 있는 것 같습니다. Chrome에서 이를 수락하려면 제목 대체 이름 필드에 있어야 합니다. 브라우저에 인증서를 표시하거나openssl x509 -in certificate-file -text
보다:
이러한 기본 요구 사항에 따라 인증 기관은 발급한 SSL 인증서에 항상 하나 이상의 주체 대체 이름을 포함해야 합니다. 이는 오늘날 응용 프로그램이 일반 이름과 주체 대체 이름을 모두 볼 필요가 없고 확인만 하면 된다는 의미입니다. 후자.
현재 대부분의 인증 기관은 일반 이름 필드에 주체 대체 이름의 첫 번째 DNS 이름도 포함하지만 이는 주로 레거시 이유로 수행되며 그리 멀지 않은 미래의 어느 시점에서는 중지될 것입니다.
인증서에는 바인딩된 도메인/IP를 표현하는 두 가지 방법이 있습니다. 하나는 구조화되지 않고 모호한 방법(commonName)이고 다른 하나는 잘 정의된 방법(subjectAltName)입니다. subjectAltNames가 없으면 Chrome은 현재 도메인을 commonName(있는 경우)과 비교합니다.
이 제안은 해당 대체 경로를 제거하는 것입니다. 실제로 subjectAltName이 필요합니다. 이상적으로는 모든 인증서(공개적으로 신뢰할 수 있는 인증서와 개인적으로 신뢰할 수 있는 인증서)에 대해 이 작업을 수행하지만 호환성 위험이 우려되는 경우 공개적으로 신뢰할 수 있는 인증서로 제한할 수 있습니다.