[iis] 개발을 위해 도메인 이름에 대한 자체 서명 된 인증서를 만드는 방법은 무엇입니까?

주어진 답변과 추가 리소스의 조각과 조각을 결합하여 Windows에서 자체 서명 된 인증서를 살펴보아야했습니다. 여기에 내 자신의 (그리고 희망적으로 완성 된) 연습이 있습니다. 내 자신의 고통스러운 학습 곡선의 일부를 절약 할 수 있기를 바랍니다. 또한 자신의 인증서를 만들 때 조만간 나타날 관련 주제에 대한 정보도 포함되어 있습니다.

Windows 10 이하에서 자체 서명 된 인증서 만들기

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에서 사용

이제 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는 자체 SSL 캐시를 사용하며 시프트 재로드시 제거됩니다. 따라서 로컬 웹 사이트의 인증서에 대한 변경 사항은 FF 경고에 즉시 반영되지만 다른 브라우저는 Windows SSL 캐시를 다시 시작하거나 수동으로 제거해야 할 수 있습니다.
• 또한 FF는 인증서의 유효성을 확인하기위한 몇 가지 중요한 힌트를 제공합니다. FF가 인증서 경고를 표시하면 고급을 클릭하십시오. FF는 텍스트 블록의 중앙 줄에 하나 이상의 가능한 경고가있는 짧은 텍스트 블록을 표시합니다.

자체 서명 된 인증서이므로 신뢰할 수 없습니다.

이 경고는 정확합니다! 위에서 언급했듯이 Firefox는 Windows 인증서 저장소를 사용하지 않으며 예외를 추가하는 경우에만이 인증서를 신뢰합니다. 이를 수행하는 버튼은 경고 바로 아래에 있습니다.

인증서가 이름에 유효하지 않습니다 …

이 경고는 사용자가 뭔가 잘못했음을 나타냅니다. 인증서의 (와일드 카드) 도메인이 웹 사이트의 도메인과 일치하지 않습니다. 웹 사이트의 (하위) 도메인을 변경하거나 일치하는 새 인증서를 발급하여 문제를 해결해야합니다. 사실 인증서가 일치하지 않더라도 FF에 예외를 추가 할 수 있지만 이러한 조합을 사용하면 Chrome에서 녹색 자물쇠 기호가 표시되지 않습니다.

Firefox는이 장소에서 만료 된 인증서, 오래된 서명 알고리즘이있는 인증서 등과 같이 멋지고 이해하기 쉬운 인증서 경고를 표시 할 수 있습니다. 문제를 해결하기 위해 그 정도의 피드백을 제공하는 다른 브라우저를 찾지 못했습니다.

어떤 (하위) 도메인 패턴을 개발하기 위해 선택해야합니까?

위의 New-SelfSignedCertificate 명령에서 와일드 카드 도메인을 사용했습니다 *.dev.local.

다음과 같이 생각할 수 있습니다. 왜 사용하지 *.local않습니까?

간단한 이유 : 와일드 카드 도메인으로 불법입니다.
와일드 카드 인증서 에는 최소한 두 번째 수준의 도메인 이름이 포함 되어야 합니다.

따라서 양식의 도메인은 *.localHTTP 웹 사이트를 개발하는 데 좋습니다. 하지만 HTTPS의 경우는 그다지 많지 않습니다. 시작하는 새 프로젝트마다 새 일치 인증서를 발급해야하기 때문입니다.

중요한 추가 정보 :

• 유효한 호스트 도메인은 z, 숫자, 하이픈 및 점으로 이루어진 문자 만 포함 할 수 있습니다. 밑줄은 허용되지 않습니다! 일부 브라우저는이 세부 사항에 대해 정말 까다 롭고 도메인 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 단계 도메인 부분을 사용하지 않는 것이 가장 좋습니다. 모든 변형을 세 번째 수준 부분에 넣으십시오. 이렇게하면 모든 개발 사이트에 대해 단일 인증서를 얻을 수 있습니다.

Edge의 문제점

이 자체 서명 된 인증서에 대해 정말 아니지만, 여전히 전체 프로세스에 관련된 :
위의 단계를 수행 한 다음 가장자리가 표시되지 않을 수 있는 당신이 열 때 내용 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/ 에서 찾을 수 있습니다.

---

답변