도메인 및 하위 도메인에 대한 자체 서명 된 인증서 만들기-NET :: ERR_CERT_COMMON_NAME_INVALID

도메인 및 하위 도메인에 대한 자체 서명 된 인증서 만들기-NET :: ERR_CERT_COMMON_NAME_INVALID

---

개발 목적으로 Windows에서 서명 된 SSL 인증서를 생성하기 위해이 자습서를 따랐으며 내 도메인 중 하나에서 훌륭하게 작동했습니다 (DNS를 시뮬레이션하기 위해 호스트 파일을 사용하고 있습니다). 그런 다음 하위 도메인이 많고 각 하위 도메인에 대한 인증서를 만드는 것이 당장 고통 스러울 것이라고 생각했습니다. 그래서 Commonserverfault의 일부 답변에서 제안한 것처럼 필드 에서 와일드 카드를 사용하여 인증서를 만들려고 했습니다. 이렇게 :

Common Name: *.myserver.net/CN=myserver.net

그러나이 인증서를 신뢰할 수있는 루트 인증 기관으로 가져온 후 NET::ERR_CERT_COMMON_NAME_INVALIDChrome, 기본 도메인 및 모든 하위 도메인에 오류 가 발생합니다 (예 : https://sub1.myserver.netand https://myserver.net.

이 서버는 myserver.net임을 증명할 수 없습니다. 보안 인증서는 * .myserver.net / CN = myserver.net에서 가져옵니다.

이는 구성이 잘못되었거나 공격자가 연결을 가로 채서 발생할 수 있습니다.

이 오류를 일으키는 일반 이름 필드에 문제가 있습니까?

---

Rahul이 말했듯이 일반적인 Chrome 및 OSX 버그입니다. 나는 과거에 비슷한 문제를 겪고있었습니다. 사실 나는 마침내 작업을 위해 로컬 사이트를 테스트 할 때 2 번의 추가 클릭을 만드는 데 지쳤습니다.

[Windows 사용]이 문제에 대한 가능한 해결 방법으로 사용 가능한 많은 자체 서명 인증서 유틸리티 중 하나를 사용 합니다 .

권장 단계 :

1. 자체 서명 된 인증서 만들기
2. Windows 인증서 관리자로 인증서 가져 오기
3. 크롬 인증서 관리자에서 인증서 가져 오기
   참고 : 3 단계 경험이 문제가 해결됩니다 일단 가까운 미래에는 ETA가되지 않은 부실의 시간을 고려 ... 구글 주소 버그를 **.
   
   만큼 I가 크롬을 사용하는 것을 선호로 최근 Firefox Developer Edition 에서 저를 발견했습니다 . 이 문제가 없습니다.
   
   도움이 되었기를 바랍니다 :)

---

Chrome 58은 주체 대체 이름이없는 인증서에 대한 지원을 중단했습니다 .

앞으로이 오류가 발생하는 또 다른 이유가 될 수 있습니다.

---

해결 방법은 "subjectAltName"(X509v3 주체 대체 이름)으로 사용하는 도메인 이름을 추가하는 것입니다. 이는 OpenSSL 구성 ( /etc/ssl/openssl.cnfLinux)을 변경하고 v3_req섹션을 다음과 같이 수정하여 수행 할 수 있습니다 .

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net

이를 통해 -extensions v3_req새 인증서를 생성 할 때 스위치 를 사용하는 것을 잊지 마십시오 . ( OpenSSL을 사용하여 SubjectAltName으로 자체 서명 된 인증서를 생성하려면 어떻게해야합니까? 참조 )

---

openssl.conf파일 생성 :

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O  = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net

이 명령을 실행하십시오.

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt  -config openssl.conf

파일을 출력 app.crt하고 app.key나를 위해 일하십시오.

---

와일드 카드는 *.example.com않습니다 하지 루트 도메인을 포함 example.com하지만, 어떠한 변형 다룰 것입니다 보조 등 -domain www.example.com또는test.example.com

The preferred method is to establish Subject Alternative Names like in Fabian's Answer but keep in mind that Chrome currently requires the Common Name to be listed additionally as one of the Subject Alternative Names (as it is correctly demonstrated in his answer). I recently discovered this problem because I had the Common Name example.com with SANs www.example.com and test.example.com, but got the NET::ERR_CERT_COMMON_NAME_INVALID warning from Chrome. I had to generate a new Certificate Signing Request with example.com as both the Common Name and one of the SANs. Then Chrome fully trusted the certificate. And don't forget to import the root certificate into Chrome as a trusted authority for identifying websites.

---

I think it may be a bug in chrome. There was a similar issue long back: See this.

Try in a different browser. I think it should work fine.

---

For everyone who is encountering this and wants to accept the risk to test it, there is a solution: go to Incognito mode in Chrome and you'll be able to open "Advanced" and click "Proceed to some.url".

This can be helpful if you need to check some website which you are maintaining yourself and just testing as a developer (and when you don't yet have proper development certificate configured).

Of course this is NOT FOR PEOPLE using a website in production where this error indicates that there is a problem with website security.

---

If you're tired of this error. You can make Chrome not act out like this. I'm not saying it's the best way just saying it's a way.

As a workaround, a Windows registry key can be created to allow Google Chrome to use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates.

Data type: Boolean [Windows:REG_DWORD] Windows registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome Windows/Mac/Linux/Android preference name: EnableCommonNameFallbackForLocalAnchors Value: 0x00000001 (Windows), true(Linux), true (Android), (Mac) To create a Windows registry key, simply follow these steps:

Open Notepad Copy and paste the following content into notepad Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:00000001 Go to File > Save as Filename: any_filename.reg Save as type: All Files

Select a preferred location for the file

Click on Save

Double click on the saved file to run

Click on Yes on the Registry Editor warning

Found this information on Symantec support page: https://support.symantec.com/en_US/article.TECH240507.html

참고URL : https://stackoverflow.com/questions/27294589/creating-self-signed-certificate-for-domain-and-subdomains-neterr-cert-commo