질문자 :pjohansson
로컬 호스트 CN에 대해 자체 서명된 SSL 인증서를 만들었습니다. Firefox는 예상대로 처음에 이에 대해 불평한 후 이 인증서를 수락합니다. 그러나 Chrome과 IE는 신뢰할 수 있는 루트 아래의 시스템 인증서 저장소에 인증서를 추가한 후에도 수락을 거부합니다. Chrome의 HTTPS 팝업에서 "인증서 정보 보기"를 클릭하면 인증서가 올바르게 설치된 것으로 나열되지만 여전히 인증서를 신뢰할 수 없다고 표시됩니다.
Chrome에서 인증서를 수락하고 이에 대한 불만을 표시하지 않으려면 어떻게 해야 하나요?
localhost 전용다음을 크롬에 붙여넣기만 하면 됩니다.
chrome://flags/#allow-insecure-localhost강조 표시된 텍스트가 표시되어야 합니다. localhost에서 로드된 리소스에 대해 잘못된 인증서 허용
Enable 클릭합니다.
이것은 나를 위해 일했습니다.
Chrome Settings > Show advanced settings > HTTPS/SSL > Manage Certificates 엽니다.Authorities 탭을 클릭하고 아래로 스크롤하여 인증서에 부여한 조직 이름 아래에서 인증서를 찾습니다.지금 페이지에 멋진 녹색 잠금 장치가 있어야 합니다.
편집: 새 컴퓨터에서 이것을 다시 시도했는데 빨간색의 신뢰할 수 없는 인증서 페이지에서 계속해서 인증서 관리 창에 인증서가 나타나지 않았습니다. 다음을 수행해야 했습니다.
https:// 는 빨간색으로 그어져 있음)에서 잠금 > 인증서 정보를 클릭합니다. 참고: 최신 버전의 Chrome에서는 Developer Tools > Security View certificate 선택해야 합니다.Details tab > Export 클릭합니다. 파일 형식으로 PKCS #7, single certificate 를 선택합니다.Authorities tab > Import 클릭하고 인증서를 내보낸 파일 을 선택하고 파일 형식으로 PKCS #7, single certificate 를 선택해야 합니다.openssl 명령으로 이를 수행할 수 있습니다.( 브라우저 보안 설정을 변경하지 마세요. )
다음 코드를 사용하면 (1) 자신의 CA가 되고 (2) SSL 인증서에 CA로 서명할 수 있습니다. (3) 그런 다음 CA 인증서(서버로 이동하는 SSL 인증서가 아님)를 Chrome/Chromium으로 가져옵니다. (예, 이것은 Linux에서도 작동합니다.)
주의: Windows의 경우 충돌을 피하기 위해 openssl winpty 와 함께 실행해야 한다는 보고서가 있습니다.
###################### # Become a Certificate Authority ###################### # Generate private key openssl genrsa -des3 -out myCA.key 2048 # Generate root certificate openssl req -x509 -new -nodes -key myCA.key -sha256 -days 825 -out myCA.pem ###################### # Create CA-signed certs ###################### NAME=mydomain.com # Use your own domain name # Generate a private key openssl genrsa -out $NAME.key 2048 # Create a certificate-signing request openssl req -new -key $NAME.key -out $NAME.csr # Create a config file for the extensions >$NAME.ext cat <<-EOF authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = $NAME # Be sure to include the domain name here because Common Name is not so commonly honoured by itself DNS.2 = bar.$NAME # Optionally, add additional domains (I've added a subdomain here) IP.1 = 192.168.0.13 # Optionally, add an IP address (if the connection which you have planned requires it) EOF # Create the signed certificate openssl x509 -req -in $NAME.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial \ -out $NAME.crt -days 825 -sha256 -extfile $NAME.ext요약하자면:
myCA.pem$NAME.crt 및 $NAME.key 파일 사용추가 단계(최소한 Mac의 경우):
basicConstraints=CA:FALSE 아래에 extendedKeyUsage=serverAuth,clientAuth 추가하고 설정을 요청할 때 $NAME 과 동일하게 설정했는지 확인합니다.인증서가 올바르게 빌드되었는지 확인하기 위해 작업을 확인할 수 있습니다.
openssl verify -CAfile myCA.pem -verify_hostname bar.mydomain.com mydomain.com.crt페이지의 아무 곳이나 클릭하고 BYPASS_SEQUENCE를 입력하십시오.
" thisisunsafe "는 Chrome 버전 65용 BYPASS_SEQUENCE입니다.
" badidea " 크롬 버전 62 - 64.
이전 버전의 Chrome에서 작동하는 데 사용된 " danger
입력 필드를 찾을 필요가 없습니다. 그냥 입력하십시오. 이상하게 느껴지지만 작동합니다.
Mac High Sierra에서 시도했습니다.
다시 변경했는지 다시 확인하려면 최신 크롬 소스 코드로 이동하십시오.
BYPASS_SEQUENCE를 찾으려면 현재 다음과 같습니다.
var BYPASS_SEQUENCE = window.atob('dGhpc2lzdW5zYWZl');이제 그들은 위장했지만 실제 BYPASS_SEQUENCE를 보려면 브라우저 콘솔에서 다음 행을 실행할 수 있습니다.
console.log(window.atob('dGhpc2lzdW5zYWZl'));Chrome 58+용 업데이트(2017-04-19 출시)
commonName 만 사용하여 호스트를 식별하는 기능 이 제거되었습니다 . 인증서는 이제 subjectAltName 을 사용하여 호스트를 식별해야 합니다. 여기에서 추가 토론을 참조 하고 여기에서 버그 추적기를 참조하세요 . 과거에는 subjectAltName 이 다중 호스트 인증서에만 사용되었으므로 일부 내부 CA 도구에는 인증서가 포함되지 않았습니다.
자체 서명 인증서가 과거에는 잘 작동 했지만 Chrome 58에서 갑자기 오류가 발생하기 시작했다면 이것이 이유입니다.
따라서 자체 서명된 인증서(또는 자체 서명된 CA에서 서명한 인증서)를 생성하는 데 사용하는 방법이 무엇이든 서버 인증서에 적절한 DNS 및/또는 IP 항목/항목 subjectAltName 이 포함되어 있는지 확인하십시오. 단일 호스트 .
openssl의 경우 이는 OpenSSL 구성 ( /etc/ssl/openssl.cnf )이 단일 호스트에 대해 다음과 유사해야 함을 의미합니다.
[v3_ca] # and/or [v3_req], if you are generating a CSR subjectAltName = DNS:example.com또는 여러 호스트의 경우:
[v3_ca] # and/or [v3_req], if you are generating a CSR subjectAltName = DNS:example.com, DNS:host1.example.com, DNS:*.host2.example.com, IP:10.1.2.3 Chrome의 인증서 뷰어(F12 아래의 "보안" 탭으로 이동됨)에서 Extensions Certificate Subject Alternative Name 으로 나열된 것을 볼 수 있습니다.
Mac에서 키체인 접근 유틸리티를 사용하여 자체 서명된 인증서를 시스템 키체인에 추가하면 Chrome에서 이를 수락합니다. 여기에서 단계별 지침을 찾았습니다.
Google Chrome, Mac OS X 및 자체 서명된 SSL 인증서
원래:
Mac에서는 다음을 수행하여 시스템 수준에서 Chrome 및 Safari에서 완전히 신뢰할 수 있는 인증서를 만들 수 있습니다.
# create a root authority cert ./create_root_cert_and_key.sh # create a wildcard cert for mysite.com ./create_certificate_for_domain.sh mysite.com # or create a cert for www.mysite.com, no wildcards ./create_certificate_for_domain.sh www.mysite.com www.mysite.comv3.ext 를 사용하여 주체 대체 이름 누락 오류를 방지합니다.자신의 루트 권한을 사용하여 완전히 신뢰할 수 있는 자체 서명된 새 인증서를 만들려면 이 스크립트를 사용하면 됩니다.
#!/usr/bin/env bash openssl genrsa -out rootCA.key 2048 openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem #!/usr/bin/env bash if [ -z "$1" ] then echo "Please supply a subdomain to create a certificate for"; echo "eg www.mysite.com" exit; fi if [ ! -f rootCA.pem ]; then echo 'Please run "create_root_cert_and_key.sh" first, and try again!' exit; fi if [ ! -f v3.ext ]; then echo 'Please download the "v3.ext" file and try again!' exit; fi # Create a new private key if one doesnt exist, or use the xeisting one if it does if [ -f device.key ]; then KEY_OPT="-key" else KEY_OPT="-keyout" fi DOMAIN=$1 COMMON_NAME=${2:-*.$1} SUBJECT="/C=CA/ST=None/L=NB/O=None/CN=$COMMON_NAME" NUM_OF_DAYS=825 openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT device.key -subj "$SUBJECT" -out device.csr cat v3.ext | sed s/%%DOMAIN%%/"$COMMON_NAME"/g > /tmp/__v3.ext openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days $NUM_OF_DAYS -sha256 -extfile /tmp/__v3.ext # move output files to final filenames mv device.csr "$DOMAIN.csr" cp device.crt "$DOMAIN.crt" # remove temp file rm -f device.crt; echo echo "###########################################################################" echo Done! echo "###########################################################################" echo "To use these files on your server, simply copy both $DOMAIN.csr and" echo "device.key to your webserver, and use like so (if Apache, for example)" echo echo " SSLCertificateFile /path_to_your_files/$DOMAIN.crt" echo " SSLCertificateKeyFile /path_to_your_files/device.key" authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = %%DOMAIN%%Chrome 및 Safari에서 자체 서명된 인증서를 완전히 신뢰할 수 있도록 하려면 새 인증 기관을 Mac으로 가져와야 합니다. 이렇게 하려면 다음 지침을 따르거나 mitmproxy 웹 사이트 에서 이 일반 프로세스에 대한 자세한 지침을 따르십시오.
암호를 묻는 이 명령을 사용하여 명령줄에서 두 가지 방법 중 하나를 수행할 수 있습니다.
$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain rootCA.pem Keychain Access 앱을 사용하여:
그리고 보너스로 Java 클라이언트가 인증서를 신뢰해야 하는 경우 인증서를 Java 키 저장소로 가져와서 그렇게 할 수 있습니다. 상황이 변경될 경우 업데이트해야 하므로 이미 존재하는 경우 키 저장소에서 인증서를 제거합니다. 물론 가져오는 인증서에 대해서만 이 작업을 수행합니다.
KEYSTORE="$(/usr/libexec/java_home)/jre/lib/security/cacerts"; function running_as_root() { if [ "$EUID" -ne 0 ] then echo "NO" exit fi echo "YES" } function import_certs_to_java_keystore { for crt in *.crt; do echo prepping $crt keytool -delete -storepass changeit -alias alias__${crt} -keystore $KEYSTORE; keytool -import -file $crt -storepass changeit -noprompt --alias alias__${crt} -keystore $KEYSTORE echo done } if [ "$(running_as_root)" == "YES" ] then import_certs_to_java_keystore else echo "This script needs to be run as root!" fiLinux를 사용하는 경우 다음 공식 위키 페이지를 팔로우할 수도 있습니다.
원래:
이제 다음 명령은 인증서를 추가합니다(여기서 YOUR_FILE은 내보낸 파일입니다).
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n YOUR_FILE -i YOUR_FILE모든 인증서를 나열하려면 다음 명령을 실행합니다.
certutil -d sql:$HOME/.pki/nssdb -L그래도 작동하지 않으면 다음 버그의 영향을 받을 수 있습니다. 문제 55050: Ubuntu SSL 오류 8179
PS 위의 명령을 사용하기 전에 libnss3-tools 가 있는지도 확인하십시오.
없는 경우 다음을 통해 설치하십시오.
sudo apt-get install libnss3-tools # on Ubuntu sudo yum install nss-tools # on Fedora, Red Hat, etc.보너스로 다음과 같은 편리한 스크립트를 사용할 수 있습니다.
$ cat add_cert.sh certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n $1 -i $1 $ cat list_cert.sh certutil -d sql:$HOME/.pki/nssdb -L # add '-h all' to see all built-in certs $ cat download_cert.sh echo QUIT | openssl s_client -connect $1:443 | sed -ne '/BEGIN CERT/,/END CERT/p'용법:
add_cert.sh [FILE] list_cert.sh download_cert.sh [DOMAIN] --auto-ssl-client-auth 매개변수를 사용하여 Chrome 실행
google-chrome --auto-ssl-client-auth
2017년 11월 업데이트: 이 답변은 최신 버전의 Chrome에서는 작동하지 않을 수 있습니다.
2016년 2월 업데이트: Mac 사용자를 위한 더 나은 지침은 여기 에서 찾을 수 있습니다.
추가하려는 사이트의 주소 표시줄에 있는 빨간색 자물쇠 아이콘을 마우스 오른쪽 버튼으로 클릭합니다. 
연결 탭을 클릭한 다음 인증서 정보를 클릭합니다.
세부 정보 탭을 클릭하고 파일에 복사... 버튼을 클릭합니다. 그러면 인증서 내보내기 마법사가 열리고 다음 을 클릭하여 내보내기 파일 형식 화면으로 이동합니다.
DER로 인코딩된 바이너리 X.509(.CER)를 선택 하고 다음을 클릭합니다.
찾아보기...를 클릭하고 파일을 컴퓨터에 저장합니다. 설명이 포함된 이름을 지정합니다. 다음 을 클릭한 후 마침 을 클릭합니다.
Chrome 설정을 열고 맨 아래로 스크롤한 다음 고급 설정 표시...를 클릭합니다.
HTTPS/SSL 에서 인증서 관리...를 클릭합니다.
신뢰할 수 있는 루트 인증 기관 탭을 클릭한 다음 가져오기... 버튼을 클릭합니다. 인증서 가져오기 마법사가 열립니다. 다음 을 클릭하여 가져올 파일 화면으로 이동합니다.
찾아보기를 클릭하고 이전에 저장 한 인증서 파일을 선택하고 다음을 클릭합니다.
다음 저장소에 모든 인증서 저장을 선택 합니다. 선택한 저장소는 신뢰할 수 있는 루트 인증 기관 이어야 합니다. 그렇지 않은 경우 찾아보기...를 클릭하고 선택합니다. 다음을 클릭하고 마침
보안 경고에서 예 를 클릭합니다.
크롬을 다시 시작합니다.
2020년 4월 23일 업데이트됨
보안 오류에도 불구하고 Chrome을 계속 진행하기 위해 오류 페이지에 입력할 수 있는 비밀 우회 문구가 있습니다. thisisunsafe (이전 버전의 Chrome에서는 badidea 를 입력하고 더 이전 버전에서는 위험을 입력 ). 왜 필요한지 정확히 이해 하지 못하면 이것을 사용하지 마십시오!
원천:
https://chromium.googlesource.com/chromium/src/+/d8fc089b62cd4f8d907acff6fb3f5ff58f168697%5E%21/
( window.atob('dGhpc2lzdW5zYWZl') thisisunsafe 해석됩니다.)
소스의 최신 버전은 @ https://chromium.googlesource.com/chromium/src/+/refs/heads/master/components/security_interstitials/core/browser/resources/interstitial_large.js 이고 window.atob 함수는 JS 콘솔에서 실행됩니다.
Chrome 팀이 우회 문구를 처음으로 변경한 이유에 대한 배경 정보:
https://bugs.chromium.org/p/chromium/issues/detail?id=581189
"어쨌든 진행" 옵션을 사용할 수 없거나 우회 문구가 작동하지 않는 경우 빠른 일회성으로 이 해킹이 잘 작동합니다.
localhost 인증서 오류를 허용합니다(플래그 값을 변경한 후 Chrome을 다시 시작해야 함).
chrome://flags/#allow-insecure-localhost
(및 투표 답변 https://stackoverflow.com/a/31900210/430128 @Chris)
연결하려는 사이트가 localhost 이면 작업이 완료된 것입니다. 그렇지 않으면 로컬로 포트 8090에서 수신 대기하도록 TCP 터널을 설정하고 포트 443에서 broken-remote-site.com socat 설치되어 있는지 확인하고 터미널 창에서 다음과 같이 실행합니다.
socat tcp-listen:8090,reuseaddr,fork tcp:broken-remote-site.com:443
브라우저에서 https://localhost:8090 으로 이동합니다.
"다른 모든 것이 실패하면(해결 방법 #1)"과 유사하게 여기에서 ngrok 을 사용하여 로컬 서비스에 대한 프록시를 구성합니다. TLS(이 경우 유효한 인증서가 있는 ngrok에 의해 종료됨) 또는 비 TLS 끝점을 통해 ngrok http 터널에 액세스할 수 있기 때문에 브라우저는 잘못된 인증서에 대해 불평하지 않습니다.
ngrok을 다운로드하여 설치한 다음 ngrok.io 를 통해 노출합니다.
ngrok http https://localhostngrok이 시작되고 연결할 수 있는 호스트 이름을 제공하고 모든 요청이 로컬 시스템으로 다시 터널링됩니다.
Mac을 사용 중이고 내보내기 탭이 표시되지 않거나 인증서를 얻는 방법이 저에게 효과적이었습니다.
"인증서 정보"를 클릭하십시오.
이제 다음이 표시되어야 합니다. 
작은 인증서 아이콘을 바탕 화면(또는 아무 곳)으로 드래그하십시오.
다운로드한 .cer 파일을 두 번 클릭하면 키체인으로 가져와야 하며 인증서 목록에 대한 키체인 액세스가 열립니다.
어떤 경우에는 이것으로 충분하며 이제 페이지를 새로 고칠 수 있습니다.
그렇지 않으면:
이제 문제의 페이지를 새로고침하면 문제가 해결됩니다! 도움이 되었기를 바랍니다.
이것을 조금 더 쉽게 하기 위해 다음 스크립트( source )를 사용할 수 있습니다:
다음 스크립트 를 whitelist_ssl_certificate.ssh 로 저장합니다.
#!/usr/bin/env bash -e SERVERNAME=$(echo "$1" | sed -E -e 's/https?:\/\///' -e 's/\/.*//') echo "$SERVERNAME" if [[ "$SERVERNAME" =~ .*\..* ]]; then echo "Adding certificate for $SERVERNAME" echo -n | openssl s_client -connect $SERVERNAME:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | tee /tmp/$SERVERNAME.cert sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" /tmp/$SERVERNAME.cert else echo "Usage: $0 www.site.name" echo "http:// and such will be stripped automatically" fi스크립트를 실행 가능하게 만들기(셸에서):
chmod +x whitelist_ssl_certificate.ssh원하는 도메인에 대한 스크립트를 실행합니다(전체 URL을 복사/붙여넣기만 하면 됩니다).
./whitelist_ssl_certificate.ssh https://your_website/whatever테스트 환경의 경우
--ignore-certificate-errors 를 명령줄 매개변수로 사용할 수 있습니다(Ubuntu의 버전 28.0.1500.52에서 작업).
이렇게 하면 오류를 무시하고 경고 없이 연결됩니다. 이미 실행 중인 chrome 버전이 있는 경우 명령줄에서 다시 실행하기 전에 이 버전을 닫아야 합니다. 그렇지 않으면 새 창이 열리지만 매개변수는 무시됩니다.
테스트 서버에는 유효한 인증서가 없기 때문에 디버깅을 할 때 이런 방식으로 chrome을 실행하도록 Intellij를 구성합니다.
인증서 확인은 중요한 보안 기능이기 때문에 이와 같은 일반적인 검색은 권장하지 않지만 일부 사용자에게는 도움이 될 수 있습니다.
WINDOWS 2017년 6월 Windows Server 2012
@Brad Parks 답변을 따랐습니다. Windows에서는 신뢰할 수 있는 루트 인증 기관 저장소에서 rootCA.pem을 가져와야 합니다.
다음 단계를 수행했습니다.
openssl genrsa -out rootCA.key 4096 openssl req -x509 -new -nodes -key rootCA.key -newkey rsa:4096 -sha256 -days 1024 -out rootCA.pem openssl req -new -newkey rsa:4096 -sha256 -nodes -keyout device.key -out device.csr openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 2000 -sha256 -extfile v3.ext여기서 v3.ext는 다음과 같습니다.
authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = localhost IP.1 = 192.168.0.2 IP.2 = 127.0.0.1그런 다음 내 경우에는 자체 호스팅 웹 앱이 있으므로 IP 주소와 포트로 인증서를 바인딩해야 하며 인증서는 개인 키 정보와 함께 내 저장소에 있어야 하므로 pfx 형식으로 내보냈습니다.
openssl pkcs12 -export -out device.pfx -inkey device.key -in device.crtmmc 콘솔(파일/스냅인 추가/제거/인증서/추가/컴퓨터 계정/로컬 컴퓨터/확인)을 사용하여 개인 저장소에서 pfx 파일을 가져왔습니다.
나중에 이 명령을 사용하여 인증서를 바인딩했습니다(HttpConfig 도구를 사용할 수도 있음).
netsh http add sslcert ipport=0.0.0.0:12345 certhash=b02de34cfe609bf14efd5c2b9be72a6cb6d6fe54 appid={BAD76723-BF4D-497F-A8FE-F0E28D3052F4}certash=인증서 지문
appid=GUID(선택 사항)
먼저 신뢰할 수 있는 루트 인증 기관에서 인증서 "device.crt"를 가져오려고 했지만 여전히 동일한 오류가 발생합니다.
그러나 도메인에 대한 인증서가 아닌 루트 기관의 인증서를 가져와야한다는 것을 깨달았습니다. 그래서 mmc 콘솔(파일/스냅인 추가/제거/인증서/추가/컴퓨터 계정/로컬컴퓨터/확인)을 사용하여 신뢰할 수 있는 루트 인증 기관 저장소에서 rootCA.pem을 가져왔습니다.
Chrome을 다시 시작하면 작동합니다.
로컬 호스트 사용:
또는 IP 주소:
내가 달성할 수 없었던 유일한 것은 구식 암호(그림의 빨간색 사각형)가 있다는 것입니다. 이 점에 대해 도움을 주시면 감사하겠습니다.
makecert를 사용하면 SAN 정보를 추가할 수 없습니다. New-SelfSignedCertificate(Powershell)를 사용하면 SAN 정보를 추가할 수 있으며 작동합니다.
누군가가 지적했듯이 브라우저 창뿐만 아니라 모든 Chrome을 다시 시작해야 합니다. 이 작업을 수행하는 가장 빠른 방법은 탭을 여는 것입니다.
chrome://restart
신뢰할 수 있는 루트 CA 저장소에 CA 인증서를 추가합니다.
크롬으로 이동하여 이 플래그를 활성화하십시오!
chrome://flags/#allow-insecure-localhost
마지막으로 *.me 도메인 또는 *.com 및 *.net과 같은 유효한 도메인을 사용하고 호스트 파일에서 유지하기만 하면 됩니다. 로컬 개발자의 경우 다음과 같이 유지 관리되는 호스트 파일과 함께 *.me 또는 *.com을 사용합니다.
호스트에 추가합니다. C:/windows/system32/drivers/etc/hosts
127.0.0.1 nextwebapp.me
참고: 이 작업을 수행할 때 브라우저가 이미 열려 있으면 오류가 계속 표시됩니다. 따라서 브라우저를 닫고 다시 시작하십시오. 더 나은 방법은 시크릿 모드로 전환하거나 즉각적인 효과를 위해 새 세션을 시작하는 것입니다.
사이트가 제공되는 주소가 인증서와 동일하다고 확신합니까? Chrome 및 자체 서명 인증서에 동일한 문제가 있었지만 결국 인증서의 도메인 이름 유효성 검사에 대해 매우 까다롭다는 것을 알았습니다.
Chrome에는 자체 인증서 저장소가 없으며 Windows 자체를 사용합니다. 그러나 Chrome은 인증서를 저장소로 가져올 수 있는 방법을 제공하지 않으므로 대신 IE를 통해 인증서를 추가해야 합니다.
또한 자체 서명된 인증서를 만드는 몇 가지 다른 접근 방식에 대해 살펴보십시오(언급하지 않은 것처럼 IIS를 사용하고 있다고 가정합니다).
필리포 Valsorda는 크로스 플랫폼 도구 썼다 mkcert 이 작업을 수행하기 위해, 많은 신뢰 매장을. 나는 그가 이 질문에 대한 답이 너무 많은 것과 같은 이유로 그것을 썼다고 가정합니다. 신뢰할 수 있는 루트 CA가 서명한 SubjectAltName
mkcert 는 Windows, macOS 및 여러 Linux 버전을 위한 주요 패키지 관리 시스템에 포함되어 있습니다. 강력한 기능 테스트 4단계의 Chromium 문서에도 언급되어 있습니다.
mkcert
mkcert는 로컬에서 신뢰할 수 있는 개발 인증서를 만들기 위한 간단한 도구입니다. 구성이 필요하지 않습니다.$ mkcert -install Created a new local CA at "/Users/filippo/Library/Application Support/mkcert" The local CA is now installed in the system trust store! The local CA is now installed in the Firefox trust store (requires browser restart)! $ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1 Using the local CA at "/Users/filippo/Library/Application Support/mkcert" Created a new certificate valid for the following names - "example.com" - "*.example.com" - "example.test" - "localhost" - "127.0.0.1" - "::1" The certificate is at "./example.com+5.pem" and the key at "./example.com+5-key.pem"
bjnord가 제안한 Google Chrome, Mac OS X 및 자체 서명된 SSL 인증서 를 사용하는 과정을 살펴보았습니다.
블로그에 표시된 내용이 작동하지 않았습니다.
그러나 블로그에 대한 댓글 중 하나는 금이었습니다.
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain site.crt
인증서 파일을 얻는 방법에 대한 블로그를 따라가야 합니다. 그런 다음 위의 명령을 사용할 수 있으며 잘 진행해야 합니다.
Linux의 Chromium에서 SSL 인증서를 관리하기 위한 GUI가 제대로 작동하지 않았습니다. 그러나 그들의 문서는 올바른 답을 제시했습니다. 트릭은 자체 서명된 SSL 인증서를 가져오는 아래 명령을 실행하는 것입니다. <certificate-nickname> 및 certificate-filename.cer 의 이름을 업데이트한 다음 chromium/chrome을 다시 시작하세요.
문서에서:
Linux에서 Chromium은 NSS 공유 DB를 사용합니다. 기본 제공 관리자가 작동하지 않으면 NSS 명령줄 도구를 사용하여 인증서를 구성할 수 있습니다.
도구 가져오기
데비안/우분투:
sudo apt-get install libnss3-tools페도라:
su -c "yum install nss-tools"젠투:
su -c "echo 'dev-libs/nss utils' >> /etc/portage/package.use && emerge dev-libs/nss"(예를 들어nsscertutilnss접두사를 사용하여 아래의 모든 명령을 실행해야 합니다. ) Opensuse:sudo zypper install mozilla-nss-tools자체 서명된 서버 인증서를 신뢰하려면 다음을 사용해야 합니다.
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n <certificate-nickname> -i certificate-filename.cer모든 인증서 나열
certutil -d sql:$HOME/.pki/nssdb -LTRUSTARGS는 쉼표로 구분된 0개 이상의 알파벳 문자로 구성된 세 개의 문자열입니다. SSL, 이메일 및 개체 서명에 대해 인증서를 신뢰하는 방법을 정의하고 신뢰 플래그에 대한 certutil 문서 또는 Meena의 블로그 게시물에 설명되어 있습니다.
SSL 클라이언트 인증을 위한 개인 인증서 및 개인 키 추가 다음 명령을 사용하십시오.
pk12util -d sql:$HOME/.pki/nssdb -i PKCS12_file.p12PKCS #12 파일에 저장된 개인 인증서 및 개인 키를 가져옵니다. 개인 인증서의 TRUSTARGS는 "u,u,u"로 설정됩니다.
인증서 삭제
certutil -d sql:$HOME/.pki/nssdb -D -n <certificate nickname>
발췌 출처: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux_cert_management.md
이 방법을 통해 안전하지 않은 로컬 호스트가 제대로 작동하도록 허용합니다. chrome://flags/#allow-insecure-localhost
xxx.localhost에 대한 개발 호스트 이름을 만들어야 합니다.
이것은 나를 위해 일했습니다. 참조: http://www.robpeck.com/2010/10/google-chrome-mac-os-x-and-self-signed-ssl-certificates/#.Vcy8_ZNVhBc
주소 표시줄에서 X가 있는 작은 자물쇠를 클릭합니다. 그러면 작은 정보 화면이 나타납니다. "인증서 정보"라고 표시된 버튼을 클릭합니다.
이미지를 클릭하고 바탕 화면으로 드래그합니다. 작은 인증서처럼 보입니다.
더블 클릭합니다. 그러면 키체인 접근 유틸리티가 나타납니다. 잠금을 해제하려면 비밀번호를 입력하세요.
로그인 키체인이 아닌 시스템 키체인에 인증서를 추가해야 합니다. 아무 일도 하지 않는 것 같더라도 "항상 신뢰"를 클릭합니다.
추가한 후 더블 클릭합니다. 다시 인증해야 할 수 있습니다.
"신뢰"섹션을 확장하십시오.
"이 인증서를 사용할 때"를 "항상 신뢰"로 설정합니다.
Chrome v58 이상이 신뢰할 수 있는 Windows에서 자체 서명된 인증서를 만들려면 상승된 권한으로 Powershell을 시작하고 다음을 입력합니다.
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "fruity.local" -DnsName "fruity.local", "*.fruity.local" -FriendlyName "FruityCert" -NotAfter (Get-Date).AddYears(10) #notes: # -subject "*.fruity.local" = Sets the string subject name to the wildcard *.fruity.local # -DnsName "fruity.local", "*.fruity.local" # ^ Sets the subject alternative name to fruity.local, *.fruity.local. (Required by Chrome v58 and later) # -NotAfter (Get-Date).AddYears(10) = make the certificate last 10 years. Note: only works from Windows Server 2016 / Windows 10 onwards!!이렇게 하면 인증서가 Personal\Certificates 저장소 아래의 로컬 컴퓨터 인증서에 저장됩니다.
이 인증서를 신뢰할 수 있는 루트 인증 기관\인증서 저장소에 복사하려고 합니다.
이를 수행하는 한 가지 방법은 Windows 시작 버튼을 클릭하고 certlm.msc 입력하는 것입니다. 그런 다음 아래 스크린샷에 따라 새로 생성된 인증서를 신뢰할 수 있는 루트 인증 기관\인증서 저장소로 끌어다 놓습니다. 
2020년 3월부터 Chrome 81을 사용하는 MacOS Catalina에서 위에 설명된 대로 openssl을 사용하여 유효한 인증서를 생성하면 이 내용이 변경되었습니다.
먼저 Safari를 사용하여 내 사이트를 탐색하고 사이트에 액세스할 수 있는 경고 페이지 하단의 링크를 클릭했습니다. 이것은 내 Mac 키체인(예: Keychain.app)에 인증서를 추가했습니다. 그러면 Safari에서 페이지를 볼 수 있습니다. Chrome은 인증서가 신뢰할 수 있음을 보여 주었지만 페이지를 볼 수는 없습니다. CERTIFICATE_INVALID 오류가 계속 발생했습니다.
키체인의 왼쪽 하단 창에서 모든 항목을 선택합니다. 그런 다음 localhost DNS 이름(예: myhost.example.com)을 검색합니다.
인증서를 두 번 클릭합니다. 인증서에 대한 편집 대화 상자가 열립니다.
"이 인증서를 사용할 때"를 "항상 신뢰"로 변경
이것은 SSL이 이미 항상 신뢰로 설정되어 있었기 때문에 완전히 반직관적이었습니다. 아마도 인증서가 추가되었을 때 Safari에서였을 것입니다. Chrome은 전역적으로 항상 신뢰로 변경한 후에만 작동하기 시작했습니다. 다시 바꾸니 작동이 안되네요.
URL 옆에 줄이 그어진 작은 자물쇠 아이콘을 클릭하면 다음과 같은 상자가 나타납니다.
인증서 정보 링크를 클릭하면 다음 대화 상자가 표시됩니다.
어떤 인증서 저장소가 올바른지 알려줍니다. 신뢰할 수 있는 루트 인증 기관 저장소입니다.
다른 답변에 설명된 방법 중 하나를 사용하여 해당 저장소에 인증서를 추가하거나 다음을 사용할 수 있습니다.
certutil -addstore -user "ROOT" cert.pemROOT 는 앞에서 언급한 인증서 저장소의 내부 이름입니다.cert.pem 은 자체 서명된 인증서의 이름입니다.Windows에서 Chrome을 수정합니다.
먼저 인증서를 내보내야 합니다.
가져오기
Chrome 58+부터 SAN 누락으로 인해 macOS 에서 인증서 오류가 발생하기 시작했습니다. 주소 표시줄에 녹색 잠금을 다시 설정하는 방법은 다음과 같습니다.
다음 명령을 사용하여 새 인증서를 생성합니다.
openssl req \ -newkey rsa:2048 \ -x509 \ -nodes \ -keyout server.key \ -new \ -out server.crt \ -subj /CN=*.domain.dev \ -reqexts SAN \ -extensions SAN \ -config <(cat /System/Library/OpenSSL/openssl.cnf \ <(printf '[SAN]\nsubjectAltName=DNS:*.domain.dev')) \ -sha256 \ -days 720 server.crt 를 KeyChain으로 가져온 다음 인증서를 두 번 클릭하고 Trust 를 확장하고 Always Trust를 선택합니다.
Chrome에서 https://domain.dev 페이지를 새로 고치면 녹색 잠금 장치가 다시 나타납니다.
MacOS용 Chrome의 경우 인증서를 준비한 경우:
나는 모든 것을 시도했고 무엇이 작동했는지: 가져올 때 올바른 범주, 즉 신뢰할 수 있는 루트 인증 기관을 선택하십시오.
(독일어라서 죄송하지만 이미지를 따르세요)
mkdir CA openssl genrsa -aes256 -out CA/rootCA.key 4096 openssl req -x509 -new -nodes -key CA/rootCA.key -sha256 -days 1024 -out CA/rootCA.crt openssl req -new -nodes -keyout example.com.key -out domain.csr -days 3650 -subj "/C=US/L=Some/O=Acme, Inc./CN=example.com" openssl x509 -req -days 3650 -sha256 -in domain.csr -CA CA/rootCA.crt -CAkey CA/rootCA.key -CAcreateserial -out example.com.crt -extensions v3_ca -extfile <( cat <<-EOF [ v3_ca ] subjectAltName = DNS:example.com EOF )이 게시물은 이미 응답으로 가득 차 있지만 Chrome에서 유효한 자체 서명 TLS 인증서를 더 쉽게 생성할 수 있도록 다른 답변 중 일부를 기반으로 bash 스크립트 Chrome 65.x 에서 테스트됨). 다른 사람들에게 유용하기를 바랍니다.
인증서를 설치( 및 신뢰 chrome://restart )을 다시 시작하는 것을 잊지 마십시오.
체크 아웃할 가치가 있는 또 다른 도구는 CloudFlare의 cfssl 도구 키트입니다.
출처 : http:www.stackoverflow.com/questions/7580508/getting-chrome-to-accept-self-signed-localhost-certificate
| Python이 이 JSON 데이터를 구문 분석할 수 없는 이유는 무엇입니까? (0) | 2022.02.24 |
|---|---|
| Java에서 두 개의 배열을 어떻게 연결할 수 있습니까? (0) | 2022.02.24 |
| C#에서 클래스 대신 구조체를 사용해야 하는 경우는 언제인가요? (0) | 2022.02.24 |
| Node.js를 완전히 제거하고 처음부터 다시 설치하는 방법(Mac OS X) (0) | 2022.02.24 |
| 대문자와 숫자를 사용한 무작위 문자열 생성 (0) | 2022.02.24 |