10-7. SSL 보안 웹서버 구현

앞에서 잠깐 언급을 한 바는 있지만, 웹사이트의 등록정보에서 ‘디렉터리 보안’탭의 ‘익명 액세스 및 인증제어’에서 다루는 ‘인증’이라는 것은 클라이언트가 웹서버에 접근할 때 어떠한 인증을 지원하는지에 관련된 내용이었다. Windows 통합인증의 경우는 사용자가 서버로 제시하는 사용자 계정과 암호정보를 Kerberos, NTLM 등의 보안 인증 프로토콜을 통하여 처리하기 때문에 상대적으로 안전하다고 할 수 있지만, 그것은 어디까지나 인증에 한정된 개념일 뿐이다. 일단 인증이 이루어지고 나면 그때부터 서버와 클라이언트간의 데이터는 암호화되지 않은 트래픽으로 네트워크로 전송된다. 제3자에 대해 도청의 위험에 노출된다는 것을 의미한다.

 

또한 인터넷쇼핑몰이나 여러 커뮤니티 사이트등은 웹사이트에 접근하는 사용자들이 ‘로그인’을 해서 자신의 메일을 확인한다거나, 개인정보를 변경하는 등의 작업을 할 수 있도록 하고 있는데, 그렇다면 과연 이러한 로그인 정보를 제3자가 도청했다면 어떻게 할까? 또 만일 로그인 정보뿐만이 아니라, 인터넷 쇼핑몰에서 상품을 주문하고 자신의 신용카드 정보를 입력하여 결제를 하고 있는 상황이라면 웹서버로 전송되는 개인의 중요한 데이터가 안전하게 보내지고 있다고 믿을수 있을 것인가?

 

이름만 들으면 누구나 알 수 있을 만한 유명한 웹사이트들에서도 사용자들의 로그인 정보에 암호화를 지원하기 시작한 것은 그리 오랜일이 아니다. 늦었지만 바람직한 일이다. 아직 이러한 기본적인 ‘고객정보보호’에 대해서 무관심한 사이트가 너무도 많다. 또 우습게도 인터넷 쇼핑몰을 운영하고 있는 회사에서 고객들의 신용카드 번호와 같은 민감한 트래픽을 암호화조차 없이 인터넷을 통해서 데이터를 전송받고 있는 경우도 어렵지 않게 찾아볼 수 있다.

 

웹브라우저로부터 웹서버로 보내는 데이터, 그것은 로그인 정보일 수도 있고, 신용카드 번호, 유효기간, 게시판에 포스팅하는 글 등일수 있다. 이렇게 송신측에서 보내는 모든 데이터를 안전하게 전송하고자 할 때 ‘암호화(Encryption)’를 사용한다고 이야기한 바 있다. 3장.PKI 단원을 건너뛰었다면 잠시 책을 앞으로 돌려 3장의 내용을 먼저 이해하고 넘어오길 바란다.

 

이번 예제에서는 웹서버가 인증기관(CA)으로부터 발급받은 ‘인증서(Certificate)’를 이용해서 SSL서버를 구성하여 클라이언트가 https 프로토콜을 이용해서 안전한 통신을 할 수 있도록 네트워크 채널에 대한 보안의 기반을 마련하고자 하는 작업을 해 보도록 한다.

 

SSL서버 설치는 다음과 같은 순서로 진행된다.

(1)   CSR (Certficate Signing Request) 생성 (2)   서버 인증서 발급 요청 및 인증서 설치 (3)   SSL 서버 구성

 

10-7-1. CSR(Certficate Signing Request) 생성

 

SSL서버구성을 위해서 첫번째로 해야 할 일은 인증서를 발급받는 작업인데, 인증서를 발급받기 위해서는 SSL서버로 구성하고자 하는 웹서버에서 CSR (Certificate Signing Request; 인증요청서)을 생성하는 것이 선행되어야 한다. 이 과정은 어떠한 인증기관(CA)을 이용하든지 동일한 방법이다. 인증기관과는 무관하게 웹서버에서 이루어지는 작업이기 때문이다. 먼저 CSR을 생성해 보자. 이 CSR을 가지고 인증서를 발급해줄 CA에 접근하여 인증서를 발급받을 수 있다.

<그림10-57. CSR(인증 요청서) 생성 1 >	웹서버에서 SSL을 적용하고자 하는 웹사이트의 등록정보를 연다.
<그림10-58. CSR(인증 요청서) 생성 2 >	등록정보의 ‘디렉터리 보안’탭을 확인한다. [인증서 보기]가 비활성화되어 있음을 기억하자. [서버인증서]를 클릭한다.
<그림10-59. CSR(인증 요청서) 생성 3 >	웹 서버 인증서 마법사가 실행된다. [다음]을 누른다.
<그림10-60. CSR(인증 요청서) 생성 4 >	서버 인증서 화면에서는 ‘새 인증서를 만듭니다.’를 선택한다.
<그림10-61. CSR(인증 요청서) 생성 5 >	‘요청을 지금 준비하지만 나중에 보냅니다.’를 선택한다. 이 옵션이 CSR을 생성하게 해 준다.
<그림10-62. CSR(인증 요청서) 생성 6 >	인증서 이름을 입력하고, 인증서 요청에 포함시킬 공개키의 길이를 결정한다. 필자는 1024비트를 선택했다. [다음]으로 진행한다.
<그림10-63. CSR(인증 요청서) 생성 7 >	인증서에 들어갈 조직, 조직구성단위 등을 입력한다. 나중에 이 웹서버에 연결하는 클라이언트들이 인증서를 통해서 확인하게 될 정보이므로 명확하게 입력할 필요가 있다.
<그림10-64. CSR(인증 요청서) 생성 8>	사이트 일반 이름 화면이 열리는데, 아주 중요한 옵션이다. 예제에서는 ssl.windowsnetwork.msft 을 입력했는데 클라이언트는 https://ssl.windowsnetwork.msft  URL을 이용해서 접근하게 될 것이다. 이 이름이 잘못되면 웹서버로 접근하는 클라이언트측에서는 인증서의 이름이 웹사이트의 이름과 맞지 않는다는 에러 메시지를 보여주게 된다.
실제로 웹서비스를 할 웹사이트의 이름을 정확히 입력해 준다. 예를 들어서 쇼핑몰을 운영하는 www.mscs.co.kr 웹사이트가 있다고 가정하자. 클라이언트가 이 쇼핑몰에 처음 접근할 때는 http://www.mscs.co.kr URL을 이용해서 접근할 것이다. 이러한 경우는 암호화된 통신이 이루어지지 않는다. 사용자 계정과 암호를 넣고 로그인을 하는 트래픽도 마찬가지로 대부분의 경우 암호화를 하지 않고 있다. 앞으로 관리자들의 의식이 바뀌어 가고 고쳐가야 할 부분이다.   하지만 사용자가 쇼핑을 하면서 구입하고자 하는 아이템을 장바구니에 담고 최종적으로 결제하고자 할때는 [결제하기]버튼을 누르면 그때는 https 프로토콜을 이용해서 SSL통신을 하게 되는데(모든 쇼핑몰 사이트가 그렇다는 것은 아니다. 안타깝게도 사용자의 신용카드 정보와 유효기간 등을 요구하는 결제페이지가 암호화를 지원하지 않는 사이트도 보았다), 만일 이 회사의 결제 페이지의 이름이 payment.mscs.co.kr 이었다면 그때 클라이언트가 접근하게 되는 URL은 https://payment.mscs.co.kr 이 될 것이다. 그렇다면 인증서에도 발급대상의 이름란에는 payment.mscs.co.kr 가 들어있어야 한다. 이렇게 인증서의 발급대상 주소와 인증서가 실제 사용되는 웹사이트의 주소가 정확하게 일치하지 않으면 이 서버에 접근하는 사용자는 인증서 관련한 에러를 만나게 될 것이고 뭔가 믿음이 가지 않는 꺼름직한 기분을 느끼게 될 것이다.
<그림10-65. CSR(인증 요청서) 생성 9>	‘지역정보’란에 회사의 위치에 해당하는 국가명, 시/도, 구/군/시 등의 정보를 입력하고 [다음]으로 진행한다.
<그림10-66. CSR(인증 요청서) 생성 10 >	인증서 요청 (CSR) 파일을 저장할 위치를 지정하고 요청파일의 이름을 잘 기억해 둔다. 기본적으로 파일이름은 certreq.txt 로 저장된다.
<그림10-67. CSR(인증 요청서) 생성 11 >	이제 거의 마쳤다. ‘요청 파일 요약’정보를 잘 확인하고 [다음]을 누른다. 잘못 되어서 인증서 재발급을 받아야 한다면 인증서 발급 기관 (CA)에 추가비용을 지불해야 할 것이다. [다음]을 눌러서 마법사를 마친다.
<그림10-68. CSR(인증 요청서) 생성 12>	위에서 지정한 위치로 이동하여 certreq.txt 파일을 열어보았더니 알 수 없는 글자가 잔뜩 쓰여진 것을 알 수 있다. ‘------ BEGIN NEW CERTIFICATE REQUEST ------‘로 시작하고, ‘------ END NEW CERTIFICATE REQUEST ------‘ 로 끝나는 메시지를 담고 있다.

 

10-7-2. 서버 인증서 발급 요청

 

앞에서 생성한 CSR을 이용해서 인증기관(CA)에 인증서 발급요청을 해야 한다. 예제에서는 Windows 2000 독립실행형 루트CA로 구성된 www.windowsnetwork.msft 에게 인증서 발급요청을 하고 있다.

<그림10-69. 인증서 발급요청 1 >	인증서 발급 요청을 위해 웹브라우저를 실행하고 http://www.windowsnetwork.msft/certsrv URL을 이용하여 접근하였다. WindowsNetwork CA 가 응답하고 있는 화면이다. ‘인증서 요청’을 선택하고 [다음]을 눌렀다.
<그림10-70. 인증서 발급요청 2>	요청 유형을 결정하는 화면이 나온다. ‘고급인증서요청’을 선택했다.
<그림10-71. 인증서 발급요청 3 >	‘고급 인증서 요청’ 화면에서 두번째 메뉴인 ‘Base 64 인코딩 CMC 또는 PKCS #10파일을 사용하여…’을 선택하고 [다음]을 누른다.
<그림10-72. 인증서 발급요청 4 >	‘인증서 또는 갱신 요청 제출’화면에서 ‘저장된 요청’상자에 CSR이 생성된 certreq.txt 파일의 내용을<그림10-68> “------ BEGIN NEW CERTIFICATE REQUEST ------‘부터 ‘------ END NEW CERTIFICATE REQUEST ------‘까지 포함하여 복사하여 웹브라우저의 창으로 붙여넣기 하고 [제출]을 누른다.
<그림10-73. 인증서 발급요청 5 >	‘인증서 대기중’화면이 보인다. 인증기관으로 인증요청은 전송되었고 인증기관이 보류중이라는 상태를 보여준다. 이 화면은 인증기관의 정책에 따라 달라질 수 있다. Windows Server 2003 독립실행형 CA의 경우는 기본설정이 인증서 발급요청에 대해 대기중으로 처리된다.

 

<참고> 윈도우 서버 인증기관(CA)의 인증서 발급과정   웹서버에서 SSL서버를 사용하고자 인증기관으로 인증요청을 보냈을 때 인증기관에서는 어떻게 처리되는지 확인해 보자. 인증기관 서비스가 동작하고 있는 서버에서 ‘관리도구à인증기관’을 실행했다. <그림10-74. 보류중인 인증서 발급 요청>   예제의 화면에서는 WindowsNetwork CA 의 인증서 관리콘솔을 보여주는데, 보류중인 요청을 보니 오른쪽 패널에 하나의 인증서 발급 요청이 올라와 있는 것을 확인할 수 있다. 마우스 오른쪽 클릭하여 ‘모든 작업à발급’을 선택했다. <그림10-75. 발급된 인증서 확인>   이제 발급된 인증서 항목에서 인증서를 확인할 수 있게 되었다.

 

<그림10-76. 인증서 발급요청 6 >	인증서 발급이 되었는지 확인하기 위하여 다시 웹브라우저를 이용하여 http://www.windowsnetwork.msft/certsrv 로 접근했다. 이번에는 보류중인 인증요청을 확인하려는 것이니 마지막 메뉴인 ‘대기중인 인증서 요청의 상태표시’를 선택하고 [다음]을 누른다.
<그림10-77. 인증서 발급요청 7 >	현재 보류중인 요청을 보여준다. 링크를 클릭한다.
<그림10-78. 인증서 발급요청 8 >	인증서가 발급되었다. 인증서를 다운로드 할 수 있다. ‘인증서 다운로드’를 선택한다.
<그림10-79. 인증서 발급요청 9>	인증서를 다운로드 한다는 메시지가 팝업되었다. [저장]을 누른다.
<그림10-80. 인증서 발급요청 10 >	저장할 위치를 결정한다. 접근의 편의를 위해서 바탕화면에 저장하였다. 이제 인증서를 발급받는 작업을 마쳤다.

 

10-7-3. SSL서버 구성

 

지금까지 인증서를 발급받는 작업을 마쳤다. 이제 이 인증서를 이용해서 SSL서버를 구성해 보도록 하자. 다시 인터넷 서비스 관리자(ISM)를 이용해서 접근한다.

<그림10-81. SSL 서버 구성 1 >	SSL서버를 구성하고자 하는 웹사이트의 등록정보를 열고 ‘보안통신’항목을 연 다음, [서버 인증서]를 클릭한다.
<그림10-82. SSL 서버 구성 2 >	웹서버 인증서 마법사가 열렸다.
<그림10-83. SSL 서버 구성 3 >	처음 CSR을 생성하기 위해 접근했을때와는 다른 화면을 보여준다. 웹서버에서 기존에 CSR을 생성하고 인증서를 설치하기 위해 보류중이기 때문에 다른 화면이 보이는 것이다. ‘보류 중인 요청을 처리한 다음 인증서를 설치합니다.’를 선택하고 [다음]을 누른다.
<그림10-84. SSL 서버 구성 4 >	인증서의 위치를 묻는 화면이 나온다.
<그림10-85. SSL 서버 구성 5 >	바탕화면에 저장해 둔 certnew.cer 파일을 지정해 준 다음 [다음]을 누른다.
<그림10-86. SSL 서버 구성 6 >	SSL통신에 사용할 포트번호를 묻고 있다. 기본포트인 443 포트를 사용하고자 한다.
<그림10-87. SSL 서버 구성 7>	인증서 요약 정보를 보여준다. 잘 확인해 본 후 [다음]을 누른다. 이제 웹 서버 인증서 마법사를 완료하였다.

 

<참고> 웹서버에서 ‘신뢰된 루트 인증기관’ 확인   웹서버가 발급받은 인증서를 발급해준 인증기관(CA)이 ‘신뢰된 인증기관’의 목록에 있는지 확인해 보도록 하자. 베리사인 등의 상업용 외부CA로부터 인증서를 발급받았거나, 도메인환경에서 웹서버와 인증기관 모두가 같은 도메인에 있을 때 인증서를 발급받은 것이라면 신뢰된 인증기관의 목록에서 인증기관의 이름을 찾을 수 있을 것이다. 이 경우는 바로 SSL서버구성을 시작해도 좋다.   그렇지만 테스트환경에서 웹서버와 인증기관은 아무런 관계가 없다. 또한 테스트에서 사용한 인증기관은 자체적인 내부CA로 구성된 인증기관이므로 이대로 사용하면 웹서버에서 SSL서버 구성하는 작업을 진행하기 전에 먼저 웹서버에서 자신이 발급받은 인증서를 발급해준 인증기관을 ‘신뢰된 인증기관’의 목록에 추가시키는 작업을 해 줘야 한다. 상업용 CA로부터 받았더라도 아래의 인터페이스를 통해서 확인해 보도록 하자. <그림10-88. 신뢰된 인증기관 구성1> ‘제어판à인터넷 옵션à내용à인증서’를 클릭한다. <그림10-89. 신뢰된 인증기관 구성2> 신뢰된 루트 인증기관의 목록을 확인하였다. 당신의 인증서를 발급해준 인증기관의 이름을 찾을 수 있는가? 찾을 수 없다면 [가져오기]를 클릭한다. <그림10-90. 신뢰된 인증기관 구성3> 인증서 가져오기 마법사가 시작된다. <그림10-91. 신뢰된 인증기관 구성4> 인증기관으로부터 발급받은 인증서의 위치를 찾는다. 바탕화면에 certnew.cer 로 저장했음을 기억하자. 인증서에는 발급대상의 정보도 있지만 더불어 발급해준 인증기관의 전자서명도 들어있다. 웹서버에서 사용할 인증서를 인증기관이 전자서명을 통해서 ‘신뢰성’을 부여하는 것이다. 가져올 파일의 위치를 잘 확인한 다음 [다음]을 누른다. <그림10-92. 신뢰된 인증기관 구성6> 인증서 저장소의 위치를 묻는다. ‘모든 인증서를 다음 저장소에 저장’을 선택하고 ‘신뢰된 루트 인증기관’을 선택하였다. <그림10-93. 신뢰된 인증기관 구성8> 인증서를 저장소에 추가하겠다는 메시지가 나왔다. 잘 읽어보자. [예]를 선택하면 인증서 가져오기가 완료된다. 이제 ‘신뢰된 루트 인증기관’목록에서 Secure.pe.kr CA의 이름을 찾을 수 있다. 이상으로 신뢰된 루트 인증기관 구성을 마쳤다.

 

계속해서 웹서버에 SSL통신을 하도록 구성을 해 보자.
<그림10-94. SSL 서버 구성 1 >	이제 서버에 인증서가 설치되었으니 이 인증서를 이용해서 SSL통신을 하도록 구성을 하면 되는데, 이것은 웹사이트, 가상 디렉터리, 특별한 파일 하나, 어떠한 부분에서라도 할 수 있다. 웹사이트 전체에서 구현하려면 웹사이트에서 등록정보로 접근하고, 특정 가상디렉터리에만 적용하려면 가상디렉터리에서, 특정 파일만 SSL통신을 하도록 하려면 해당 파일을 클릭하고 등록정보로 접근한다.   예를 들어서 웹서버에 사용자 로그인 처리할때는 SSL통신을 통해서 사용자 정보를 보호하겠다고 생각했다면 로그인을 처리하는 asp파일에만 SSL인증을 구현할 수도 있다.   예제에서는 웹사이트 등록정보를 열고 ‘디렉터리 보안’탭을 열었다. 이제 보안통신 항목에 [인증서 보기]가 활성화된 것을 확인할 수 있다. 인증서를 확인하기 위해서 [인증서 보기]를 눌렀다.
<그림10-95. SSL 서버 구성 2>	인증서를 확인해 보니, 용도는 ‘원격 컴퓨터의 신분을 확인합니다.’로 되어 있고, 발급대상은 ‘ssl.windowsnetwork.msft’, 발급자는 ‘WindowsNetwork CA’이다. 이상없는 인증서이다. 추가로 자세히탭과 인증경로탭도 확인해 보라. 여러가지 정보를 확인할 수 있을 것이다.   다시 ‘디렉터리 보안’탭으로 돌아와서 ‘보안통신’항목의 [편집]버튼을 클릭했다.
<그림10-96. SSL 서버 구성 3 >	보안통신 화면에서 ‘보안 채널 필요(SSL)’항목을 체크했다. 이제 이 서버는 https 프로토콜을 통해서 접근하는 클라이언의 요청만 받아들일 것이다.

 

10-7-4. SSL서버 연결 테스트

 

늘 그렇듯이 빠트릴 수 없는 것. 무엇인가 설정을 했으면 잘 동작하는지 테스트를 해 보는 것은 필수적인 과정이다. SSL서버에 연결이 제대로 되는지 테스트를 해 보자.

<그림10-97. SSL 서버 연결 테스트1>	웹브라우저를 열고 http://ssl.windowsnetwork.msft사이트에 접근했다. ‘보안채널을 통해서 보아야 한다’는 메시지를 출력한다. 웹서버에서 <그림10-96>과 같이 ‘보안 채널 필요’를 선택한 결과이다.
<그림10-98. SSL 서버 연결 테스트2>	다시 https 로 바꿔서 접근해 보았다. https:// ssl.windowsnetwork.msft 를 이용해서 접근했더니 이번에는 그림처럼 ‘보안경고’ 창이 팝업된다. 클라이언트는 https 프로토콜로 접근하고 있고 SSL서버로부터 서버인증서를 확인하였는데, 인증서에 문제가 있음을 알려주는 경고창이다. 3가지 항목중 맨 위의 항목인 ‘신뢰여부를 결정한 적이 없는 회사가 발행한 인증서’라는 경고메시지가 보일 것이다.   클라이언트쪽에는 이미 ‘신뢰된 인증기관’의 목록이 있는데 이 목록에서 ssl.windowsnetwork.msft 사이트에서 가지고 있는 인증서를 발행한 인증기관의 이름을 찾을 수 없었기에 이러한 경고메시지를 내 보내는 것이다.   하지만 경고메시지의 맨 위에있는 내용은 ‘이 사이트와 교환한 정보는 다른 사람이 보거나 변경할 수 없습니다.’라는 내용을 보여준다. 암호화를 통한 SSL통신에는 문제가 없다는 것을 나타낸다.
<그림10-99. SSL 서버 연결 테스트3>	웹서버의 인증서를 확인하기 위해 [인증서 보기]를 눌렀다. ssl.windowsnetwork.msft 사이트에서 내부CA로부터 발급받은 인증서를 사용했기 때문에 생기는 에러메시지이다. 한가지 사실을 알게 되었다. 내부CA를 사용하더라도 SSL 통신에는 문제가 없다. 다만 가장 중요한 문제는 ‘신뢰성’의 여부에 달려 있는 것이다.
<그림10-100. 신뢰할 수 있는 인증기관1>	이대로는 뭔가 찜찜한 기분이 남아있다. 어떻게 해결할 것인가? Active Directory 도메인 환경에서는 그룹정책을 이용하여 사용자들의 PC에 인증기관의 인증서를 ‘신뢰할 수 있는 인증기관’에 추가시키는 작업이 가능하다. 그러면 깔끔해지겠지만, 도메인 환경이 아니라면 약간의 작업을 해 줄 필요가 있다. 서버에서 그랬던 것처럼 클라이언트도 동일하게 웹브라우저를 열고 http://www.windowsnetwork.msft/certsrv 인증서 서비스 웹페이지에 접근한 다음 ‘CA인증서, 인증서 체인 또는 CRL다운로드’를 선택한다.
<그림10-101. 신뢰할 수 있는 인증기관2>	<그림10-101>화면에서 ‘이 CA 인증서 체인을 설치하십시오’ 링크를 클릭한다.
<그림10-102. 신뢰할 수 있는 인증기관3>	인증서를 추가하도록 [예]를 선택하여 신뢰할 수 있는 루트인증기관에 WindowsNetwork CA를 추가하고자 한다.
<그림10-103. 신뢰할 수 있는 인증기관4>	설치를 마쳤다.
<그림10-104. SSL 서버 연결 테스트1>	다시 https://ssl.windowsnetwork.msft 로 접근해 보았다. 아무런 에러 메시지가 없이 SSL웹사이트가 잘 열리는 것을 확인할 수 있다. 웹브라우저 아래의 상태표시줄에 노란 자물쇠를 더블클릭하여 인증서를 확인할 수 있다.