나는이 subdomain.example.com내가 개발 목적으로 사용하는 것이. 내 웹 애플리케이션 솔루션에는 외부 시스템에서 호출해야하는 웹 API 등이 포함되어 있으므로 localhost를 사용하지 않습니다.
이제 SSL을 테스트하고 subdomain.example.com개발 도메인 이름에 대한 인증서가 필요합니다 .
http://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspx에 설명 된대로 자체 서명 된 인증서를 만들려고 시도 했지만이 인증서는 localhost에서만 작동합니다. 이 인증서를 내 용도로 사용할 수 있습니까? 아니면 개발 하위 도메인에 대해 자체 서명을 만들어야합니까? 개발 하위 도메인에 대해 자체 서명 된 인증을 생성해야하는 경우이를 위해 어떤 유틸리티 또는 온라인 서비스 (무료)를 사용할 수 있습니까?
답변:
IIS의 자체 서명 된 인증서 기능을 사용하면 인증서에 대한 CN (일반 이름)을 설정할 수 없으므로 선택한 하위 도메인에 바인딩 된 인증서를 만들 수 없습니다.
문제를 해결하는 한 가지 방법은 .Net 2.0 SDK와 함께 번들로 제공되는 makecert.exe를 사용하는 것입니다. 내 서버에서는 다음 위치에 있습니다.
C:\Program Files\Microsoft.Net\SDK\v2.0 64bit\Bin\makecert.exe
다음과 같이 서명 기관을 만들고 LocalMachine 인증서 저장소에 저장할 수 있습니다 (이러한 명령은 관리자 계정 또는 상승 된 명령 프롬프트에서 실행해야 함).
makecert.exe -n "CN=My Company Development Root CA,O=My Company,
OU=Development,L=Wallkill,S=NY,C=US" -pe -ss Root -sr LocalMachine
-sky exchange -m 120 -a sha1 -len 2048 -r
그런 다음 하위 도메인에 바인딩되고 새 기관에서 서명 한 인증서를 만들 수 있습니다.
(-in 매개 변수의 값은 위의 권한을 생성하는 데 사용 된 CN 값과 동일해야합니다.)
makecert.exe -n "CN=subdomain.example.com" -pe -ss My -sr LocalMachine
-sky exchange -m 120 -in "My Company Development Root CA" -is Root
-ir LocalMachine -a sha1 -eku 1.3.6.1.5.5.7.3.1
그러면 Tom Hall의 게시물에 설명 된대로 인증서가 IIS 관리자에 나타나 사이트에 바인딩됩니다.
http://www.mikeobrien.net/blog/creating-self-signed-wildcard의 훌륭한 블로그 게시물로 Mike O'Brien에게이 솔루션에 대한 모든 찬사를 보냅니다 .
sha1. 대체 -a sha512하고 -len 2048두 번째 makecert호출에 추가 하는 것을 고려하면 모두 잘 될 것입니다.
PowerShell 사용
Windows 8.1 및 Windows Server 2012 R2 (Windows PowerShell 4.0) 이상에서 새 New-SelfSignedCertificatecmdlet을 사용하여 자체 서명 된 인증서를 만들 수 있습니다 .
예 :
New-SelfSignedCertificate -DnsName www.mydomain.com -CertStoreLocation cert:\LocalMachine\My
New-SelfSignedCertificate -DnsName subdomain.mydomain.com -CertStoreLocation cert:\LocalMachine\My
New-SelfSignedCertificate -DnsName *.mydomain.com -CertStoreLocation cert:\LocalMachine\My
IIS 관리자 사용
www.domain.com또는subdomain.domain.comNew-SelfSignedCertificate -FriendlyName *.mydomain.local -DnsName *.mydomain.local, localhost -CertStoreLocation Cert:\LocalMachine\My. 개인 저장소에 인증서를 만듭니다. 그런 다음 먼저 인증서를 파일로 내 보낸 다음 IIS 관리자 (내 https 바인딩에 사용하기 위해)를 통해 IIS에 다시 가져온 다음 MMC를 통해 신뢰할 수있는 루트 CA (브라우저 경고를 피하기 위해)로 다시 가져 왔습니다.
-NotAfter옵션은 만료 날짜를 지정하는데도 유용합니다 ( 이 옵션이 없으면 기본값은 1 년임). 내가 사용한 예New-SelfSignedCertificate -DnsName *.mydomain.com -FriendlyName *.mydomain.com -NotAfter (Get-Date).AddYears(15) -CertStoreLocation cert:\LocalMachine\My
특정 도메인에 대한 새 인증서를 생성하려면 :
관리자로 Powershell ISE를 열고 다음 명령을 실행합니다.
New-SelfSignedCertificate -DnsName *.mydomain.com, localhost -CertStoreLocation cert:\LocalMachine\My
새 인증서를 신뢰하려면 :
사이트에 인증서를 바인딩하려면 :
주어진 답변과 추가 리소스의 조각과 조각을 결합하여 Windows에서 자체 서명 된 인증서를 살펴보아야했습니다. 여기에 내 자신의 (그리고 희망적으로 완성 된) 연습이 있습니다. 내 자신의 고통스러운 학습 곡선의 일부를 절약 할 수 있기를 바랍니다. 또한 자신의 인증서를 만들 때 조만간 나타날 관련 주제에 대한 정보도 포함되어 있습니다.
makecert.exe를 사용하지 마십시오. Microsoft에서 더 이상 사용하지 않습니다.
현대적인 방법은 Powershell 명령을 사용합니다.
윈도우 10:
관리자 권한으로 Powershell을 엽니 다.
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Dev Cert *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)
Windows 8, Windows Server 2012 R2 :
이러한 시스템의 Powershell에는 매개 변수 -FriendlyName 및 -NotAfter가 없습니다. 위의 명령 줄에서 제거하기 만하면됩니다.
관리자 권한으로 Powershell을 엽니 다.
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
대안은 아래의 이전 Windows 버전에 대한 방법을 사용하는 것입니다. 그러면 인증서 생성을 위해 Win 10의 모든 기능을 사용할 수 있습니다.
이전 Windows 버전 :
이전 Windows 버전에 대한 권장 사항은 Win 10 컴퓨터에서 인증서를 만들고 mmc 인스턴스 (아래의 "인증서 신뢰"참조)를 사용하여 .PFX 파일로 내 보낸 다음 대상 컴퓨터의 인증서 저장소로 가져 오는 것입니다. 오래된 Windows OS. 인증서를 가져 오려면 마우스 오른쪽 버튼으로 클릭하지 마십시오. 상황에 맞는 메뉴에 "인증서 가져 오기"항목이 있지만 Win Server 2008에서 사용하기위한 모든 시도가 실패했습니다. 대신 대상 컴퓨터에서 다른 mmc 인스턴스를 열고 "인증서 (로컬 컴퓨터) / 개인 / 인증서"로 이동하십시오. , 중간 창을 마우스 오른쪽 버튼으로 클릭하고 모든 작업 → 가져 오기를 선택합니다.
위의 두 명령 모두 도메인 localhost및 *.dev.local.
Win10 버전은 추가로 15 년의 라이브 타임과 "Dev Cert * .dev.local, dev.local, localhost"라는 읽을 수있는 표시 이름을 가지고 있습니다.
업데이트 : 매개 변수에 여러 호스트 이름 항목을 제공하면 -DnsName(위에 표시된대로) 이러한 항목 중 첫 번째 항목이 도메인의 제목 (일명 공통 이름)이됩니다. 모든 호스트 이름 항목의 전체 목록은 인증서의 SAN (주체 대체 이름) 필드에 저장됩니다. (이를 지적 해 주신 @BenSewards에게 감사드립니다.)
생성 후 IIS의 모든 HTTPS 바인딩에서 인증서를 즉시 사용할 수 있습니다 (아래 지침).
새 인증서는 신뢰 체인의 일부가 아니므로 어떤 브라우저에서도 신뢰할 수있는 것으로 간주되지 않습니다. 이를 변경하기 위해 시스템의 신뢰할 수있는 루트 CA에 대한 인증서 저장소에 인증서를 복사합니다.
mmc.exe를 열고 파일 → 스냅인 추가 / 제거 → 왼쪽 열에서 "인증서"선택 → 추가 → "컴퓨터 계정"선택 → 다음 → "로컬 컴퓨터 ..."→ 마침 → 확인
왼쪽 열에서 "인증서 (로컬 컴퓨터) / 개인 / 인증서"를 선택합니다.
새로 생성 된 인증서를 찾습니다 (Win 10에서는 "Friendly name"열이 도움이 될 수 있음).
이 인증서를 선택하고 Ctrl-C를 눌러 클립 보드에 복사합니다.
왼쪽 열에서 "인증서 (로컬 컴퓨터) / 신뢰할 수있는 루트 CA / 인증서"를 선택합니다.
Ctrl-V를 눌러 인증서를이 저장소에 붙여 넣으십시오.
인증서는 신뢰할 수있는 루트 인증 기관 목록에 나타나야하며 이제 신뢰할 수있는 것으로 간주됩니다.
이제 IIS 관리자로 이동하여 로컬 웹 사이트의 바인딩을 선택하고 → 추가 → https → 양식의 호스트 이름을 입력하고 myname.dev.local(인증서는에 대해서만 유효 함 *.dev.local) 새 인증서를 선택하고 → 확인을 선택합니다.
호스트에 추가
또한 호스트 이름을 C : \ Windows \ System32 \ drivers \ etc \ hosts에 추가합니다.
127.0.0.1 myname.dev.local
행복
이제 Chrome과 IE는 인증서를 신뢰할 수있는 것으로 취급하고 https://myname.dev.local.
Firefox는 자체 인증서 저장소를 유지합니다. 여기에 인증서를 추가하려면 FF에서 웹 사이트를 열고 FF가 인증서에 대해 경고 할 때 예외에 추가해야합니다.
Edge 브라우저의 경우 더 많은 작업이 필요할 수 있습니다 (아래쪽 참조).
인증서를 테스트하려면 Firefox가 최선의 선택입니다. (저는 Chrome 팬보이이지만이 경우에는 FF가 더 좋습니다.)
이유는 다음과 같습니다.
자체 서명 된 인증서이므로 신뢰할 수 없습니다.
이 경고는 정확합니다! 위에서 언급했듯이 Firefox는 Windows 인증서 저장소를 사용하지 않으며 예외를 추가하는 경우에만이 인증서를 신뢰합니다. 이를 수행하는 버튼은 경고 바로 아래에 있습니다.
인증서가 이름에 유효하지 않습니다 ...
이 경고는 사용자가 뭔가 잘못했음을 나타냅니다. 인증서의 (와일드 카드) 도메인이 웹 사이트의 도메인과 일치하지 않습니다. 웹 사이트의 (하위) 도메인을 변경하거나 일치하는 새 인증서를 발급하여 문제를 해결해야합니다. 사실 인증서가 일치하지 않더라도 FF에 예외를 추가 할 수 있지만 이러한 조합을 사용하면 Chrome에서 녹색 자물쇠 기호가 표시되지 않습니다.
Firefox는이 장소에서 만료 된 인증서, 오래된 서명 알고리즘이있는 인증서 등과 같이 멋지고 이해하기 쉬운 인증서 경고를 표시 할 수 있습니다. 문제를 해결하기 위해 그 정도의 피드백을 제공하는 다른 브라우저를 찾지 못했습니다.
위의 New-SelfSignedCertificate 명령에서 와일드 카드 도메인을 사용했습니다 *.dev.local.
다음과 같이 생각할 수 있습니다. 왜 사용하지 *.local않습니까?
간단한 이유 : 와일드 카드 도메인으로 불법입니다.
와일드 카드 인증서 에는 최소한 두 번째 수준의 도메인 이름이 포함 되어야 합니다.
따라서 양식의 도메인은 *.localHTTP 웹 사이트를 개발하는 데 좋습니다. 하지만 HTTPS의 경우는 그다지 많지 않습니다. 시작하는 새 프로젝트마다 새 일치 인증서를 발급해야하기 때문입니다.
중요한 추가 정보 :
motör_head.dev.local을 와일드 카드 패턴 과 일치시키는 것을 고집스럽게 거부 할 때 어려움을 줄 수 있습니다 *.dev.local. 로 전환 할 때 준수합니다 motoer-head.dev.local.*.dev.local 일치 myname.dev.local 하지만 아닙니다 other.myname.dev.local!*.*.dev.local)는 인증서에서 사용할 수 없습니다. 따라서 other.myname.dev.local형식의 와일드 카드로만 덮을 수 있습니다 *.myname.dev.local. 결과적으로 4 단계 도메인 부분을 사용하지 않는 것이 가장 좋습니다. 모든 변형을 세 번째 수준 부분에 넣으십시오. 이렇게하면 모든 개발 사이트에 대해 단일 인증서를 얻을 수 있습니다.이 자체 서명 된 인증서에 대해 정말 아니지만, 여전히 전체 프로세스에 관련된 :
위의 단계를 수행 한 다음 가장자리가 표시되지 않을 수 있는 당신이 열 때 내용 myname.dev.local.
그 이유는 "네트워크 격리"라고하는 최신 앱용 Windows 10 네트워크 관리의 특징적인 기능입니다.
이 문제를 해결하려면 관리자 권한으로 명령 프롬프트를 열고 다음 명령을 한 번 입력하십시오.
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Edge 및 네트워크 격리에 대한 자세한 정보는 https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/ 에서 찾을 수 있습니다.
appname.dev has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.말했듯이 귀하의 지시와 달리 클라이언트 예외를 추가하는 것을 허용하지 않습니다. SSL 설정, SSL 필요 및 클라이언트 인증서 옵션과 관련하여 IIS 자체 내에서 잘못된 구성입니까?
*.mydomain.com은 유효한 인증서가 될 수 me.mydomain.com있지만 me.at.mydomain.com.
IIS 8에서 호스팅되는 프로젝트에 SSL을 활성화하려고 할 때 동일한 문제가 발생했습니다. 마지막으로 사용한 도구는 OpenSSL 이었습니다. 며칠 후 makecert 명령 과 싸우고 있습니다. 인증서는 데비안에서 생성되지만 다음으로 원활하게 가져올 수 있습니다. IIS 7 및 8.
OS 및 이 구성 파일 과 호환 되는 OpenSSL을 다운로드 하십시오. 구성 파일을 OpenSSL의 기본 구성으로 설정합니다.
먼저 인증 기관 (CA)의 개인 키와 인증서를 생성합니다. 이 인증서는 인증서 요청 (CSR)에 서명하는 것입니다.
이 프로세스에 필요한 모든 필드를 완료해야합니다.
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout root-cakey.pem -out root-cacert.pem -newkey rsa:4096다음과 같은 기본 설정으로 구성 파일을 만들 수 있습니다. 이제 인증 기관에 전송되는 파일 인 인증서 요청을 생성합니다.
일반 이름은 사이트의 도메인으로 설정되어야합니다 (예 : public.organization.com) .
openssl req -new -nodes -out server-csr.pem -keyout server-key.pem -newkey rsa:4096이제 인증서 요청이 생성 된 CA 인증서로 서명됩니다.
openssl x509 -req -days 365 -CA root-cacert.pem -CAkey root-cakey.pem -CAcreateserial -in server-csr.pem -out server-cert.pem생성 된 인증서는 IIS로 가져올 수있는 .pfx 파일로 내 보내야합니다.
openssl pkcs12 -export -out server-cert.pfx -inkey server-key.pem -in server-cert.pem -certfile root-cacert.pem -name "Self Signed Server Certificate"이 단계에서는 인증서 CA를 가져옵니다.
IIS에서 가져올 인증서를 신뢰할 수 있도록 서버에서 CA 인증서를 신뢰할 수있는 루트 인증 기관으로 가져와야합니다. IIS로 가져올 인증서는 CA의 인증서로 서명되었습니다.
이 단계에서 IIS는 인증서의 신뢰성을 신뢰합니다.
마지막 단계에서 인증서를 IIS로 가져오고 바인딩 사이트를 추가합니다.
이제 IIS 관리자에서 사이트로 이동하여 바인딩을 ... 그리고 추가 새로운 바인딩을.
바인딩 유형으로 https를 선택하면 가져온 인증서를 볼 수 있습니다.
또 다른 옵션은 웹 사이트별로 도메인 이름을 지정할 수있는 자체 서명 된 인증서를 만드는 것입니다. 즉, 여러 도메인 이름에서 사용할 수 있습니다.
IIS 관리자에서
이제 IIS의 웹 사이트에서 ...
자체 서명 된 인증서를 생성하는 또 다른 쉬운 방법은 Jexus Manager를 사용하는 것입니다.
https://www.jexusmanager.com/en/latest/tutorials/self-signed.html
makecert.exe내 경로에 있으 려면 Visual Studio 2010 명령 프롬프트 를 사용해야했습니다. 인증서의 경우 더 안전하고 사용할 것이라고 생각-a SHA512 -len 8192했습니다. 생성하는 데 영원히 걸렸습니다. 그리고 내가 예상했듯이 IIS가 사용하는 암호화 수준에 영향을 미치지 않았습니다. 기본적으로 IIS는 128 비트를 사용하므로 이를 변경하려면 그룹 정책 작업 을 수행해야 합니다. 다른 독자를위한 추가 참고 사항 : 이후에 매직 넘버를 변경하지 마십시오-eku. 필수입니다.