IIS - appcmd.exe를 이용해 특정 페이지에 클라이언트 측 인증서를 제출하도록 설정하는 방법
제 홈페이지의 경우, 특정 페이지를 방문했을 때 클라이언트 측 인증서를 제출하도록 했습니다.
IIS 7에서 클라이언트 측 인증서 사용 시 주의점
; https://www.sysnet.pe.kr/2/0/418
위의 글에서처럼, IIS 관리자에서는 "SSL Settings"를 통해 손쉽게 설정할 수 있습니다. 문제는, 이것이 Azure에 배포되는 PaaS 형식의 웹 사이트인 경우 바람직하지 않다는 점입니다. 즉, Azure로 웹 사이트를 배포하는 시점에 자동으로 "SSL Settings"를 할 수 있는 방법이 있어야 합니다.
이를 위해 이전에 설명했던 ServiceDefinition.csdef 파일의 Task 설정을 사용할 수 있습니다.
Azure Cloud Service 배포시 사용자 정의 작업을 추가하는 방법
; https://www.sysnet.pe.kr/2/0/11022
Azure - 네트워크 포트 여는 방법
; https://www.sysnet.pe.kr/2/0/1319
이제 수행할 명령어가 필요한데요, 이는 다음의 문서에 나와 있습니다.
Specify Whether to Use Client Certificates (IIS 7)
; https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753983(v=ws.10)
위의 문서에 따라 가령 test.aspx를 방문할 때 클라이언트 인증서를 요구하고 싶다면 다음과 같이 실행하면 됩니다.
%windir%\System32\inetsrv\appcmd set config "https://localhost/test.aspx" /section:access /sslFlags:SslNegotiateCert /commit:APPHOST
그런데, 실제로 이런 식으로 명령을 내리면 경우에 따라 다음과 같은 오류가 발생합니다.
D:\>%windir%\System32\inetsrv\appcmd set config "http://localhost/test.aspx" /section:access /sslFlags:SslNegotiateCert /commit:APPHOST
ERROR ( message:Cannot find SITE object with identifier "localhost/test.aspx". )
왜냐하면, Azure의 웹 사이트는 사이트 바인딩 설정에 IP 주소가 설정되어 있기 때문입니다.
위와 같이 바인딩이 명시되어 버리면 appcmd set config http://.... 와 같은 형식의 대상 지정은 오류가 발생합니다. 대신, 이런 경우 사이트 이름을 지정하는 방식으로 바꿔야 합니다. 이렇게!
%windir%\System32\inetsrv\appcmd set config "Default Web Site/test.aspx" /section:access /sslFlags:SslNegotiateCert /commit:APPHOST
사이트 이름은 IIS 관리자에서도 확인할 수 있지만 appcmd.exe로도 확인이 가능합니다.
D:\>%windir%\System32\inetsrv\appcmd list site
SITE "Default Web Site" (id:1,bindings:http/192.168.0.88:80:,https/192.168.0.88:443:,state:Started)
이 방식대로 실행해주면, 정상적으로 반영되었다는 메시지를 다음과 같이 확인할 수 있습니다.
D:\>%windir%\System32\inetsrv\appcmd set config "Default Web Site/test.aspx" /section:access /sslFlags:SslNegotiateCert /commit:APPHOST
Applied configuration changes to section "system.webServer/security/access" for "MACHINE/WEBROOT/APPHOST/Default Web Site/test.aspx" at configuration commit path "MACHINE/WEBROOT/APPHOST"
그리고 이 결과는 "%windir%\System32\inetsrv\config\applicationHost.config" 파일에 다음의 내용을 포함하는 것으로 반영됩니다.
<location path="Default Web Site/test.aspx">
<system.webServer>
<security>
<access sslFlags="SslNegotiateCert" />
</security>
</system.webServer>
</location>
(참고로, 저 설정은 web.config에도 넣을 수는 있지만 적용이 안 됩니다.)
그런데, 문제가 여기서 끝이 아닙니다. 위의 작업을 Azure의 Task에 명시된 Startup.cmd에 다음과 같이 추가할 수 있을 텐데요.
%windir%\System32\inetsrv\appcmd set config "...[사이트이름].../test.aspx" /section:access /sslFlags:SslNegotiateCert /commit:APPHOST
웬일인지, 이렇게 추가하고 배포해도 여전히 test.aspx에 대한 설정이 applicationHost.config 파일에 적용되지 않습니다. 예측하기로는, 아마도 Startup.cmd가 실행되는 시점이 너무 이른 것이 아닌가 하는 건데요. 이런 경우 Task 작업을 다소 지연시키기 위해 별도의 실행 파일을 만들어서 taskType을 "background"로 설정할 수 있습니다.
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="SysnetWebApp9.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
<WebRole name="SysnetWebApp9" vmsize="Small">
<Startup>
<Task commandLine="Startup.cmd" executionContext="elevated" taskType="simple" />
<Task commandLine="SslSettings.exe" executionContext="elevated" taskType="background">
</Task>
</Startup>
...[생략]...
</WebRole>
</ServiceDefinition>
위와 같이 해주면, Azure는 배포 시 SslSettings.exe를 실행하고 그 결과를 기다리지 않은 체 배포 작업을 진행하게 됩니다. 따라서, SslSettings.exe에서는 내부에 단순히 Thread.Sleep과 같은 일정 시간 지연을 한 다음 Process.Start를 이용해 appcmd.exe 작업을 처리해 줄 수 있습니다.
일단, 5초 지연을 주고 appcmd.exe를 실행하니 정상적으로 applicationHost.config에 반영되는 것을 확인했습니다. ^^
휴~~~ 환경이 바뀌니 이렇게 부가 작업이 많아지는군요.
엎어진 김에 쉬어간다고... ^^ 이참에 Azure에 구성하는 VM의 종류를 기존 Windows Server 2012 R2에서 Windows Server 2016으로 변경했습니다. 방법은, 단순히 ServiceConfiguration.Cloud.cscfg 파일의 osFamily를 5로 지정하면 됩니다.
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="..." xmlns="..." osFamily="5" osVersion="*" schemaVersion="2015-04.2.6">
<Role name="SysnetWebApp9">
<Instances count="1" />
...[생략]...
</Role>
</ServiceConfiguration>
그런데, 웬일인지 배포가 실패하고 다음과 같은 오류 메시지가 나왔습니다.
The OS family 5 you are trying to deploy is not supported by the SDK package. The SDK package supported OS families:3,4,1,2,98. Please try to deploy to a different operating system. To do this specify a different osFamily and/or osVersion in your .cscfg file.
원인은, Visual Studio에서 사용 중인 Azure SDK를 업데이트하지 않아서 그런 것입니다. "Tools" / "Extensions and Updates"에 가면 신규 버전의 Azure SDK가 있다는 알림이 있을 텐데 그것을 설치하신 후 다시 배포를 하시면 됩니다.
그러고 보니... 예전에 썼던 글이 하나 생각납니다.
Azure 구독 후 PaaS 서비스 만들어 보기
; https://www.sysnet.pe.kr/2/0/11023
위의 글에서, 다음과 같은 이야기를 했었는데요.
Azure Cloud Service로 배포되는 WebRole은 현재 지원되는 .NET 버전이 4.0/4.5입니다. 만약 4.6이 포함된 웹 프로젝트를 배포하는 경우 다음과 같은 식의 빌드 경고가 발생합니다.
2>------ Rebuild All started: Project: AzureCloudService1, Configuration: Debug Any CPU ------
2>..\WebApplication1\WebApplication1.csproj(0,0): warning WAT210: Microsoft Azure Cloud Service projects only support roles that run on .NET Framework versions 4.0 and 4.5. Please set the Target Framework property in the project settings for project 'WebApplication1' to .NET Framework 4.0, or .NET Framework 4.5.
2>WebApplication1(0,0): warning WAT190: The project 'WebApplication1' targets .NET Framework 4.6. To make sure that the role starts, this version of the .NET Framework must be installed on the virtual machine for this role. You can use a startup task to install the required version, if it is not already installed as part of the Microsoft Azure guest OS. For more details, see http://go.microsoft.com/fwlink/?LinkId=309796.
osFamily를 5로 설정해 Windows Server 2016을 사용하게 되면, WebRole 프로젝트도 4.6을 지정할 수 있게 됩니다. 이러한 호환 정보는 다음의 문서로 정리되어 있으니 참고하세요.
Azure Guest OS releases and SDK compatibility matrix
; https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-guestos-update-matrix
아래는 Windows Server 2016과 2012 R2의 닷넷 프레임워크 지원 정보를 나타냅니다.
그러니까, "
Azure 구독 후 PaaS 서비스 만들어 보기" 글을 쓸 당시에 지정한 osFamily가 4이므로 Windows Server 2012 R2가 지정된 것이고, .NET 4.6을 사용할 수는 없었던 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]