OS X Server에 StartSSL class 1 certificate 설치

왜 SSL을 쓰는가?

암호화되지 않은 통신으로 로그인 정보를 전송하는 것은 내 아이디와 비밀번호를 책상에 포스트잇으로 붙여두었다. 굳이 악의를 가지지 않은 사람도 지나가다가 내 비밀번호를 볼 수 있게된다. 누군가 당신의 웹서비스의 계정 정보를 알게 하고 싶지는 않을 것이다.

그렇다면 SSL이라고 100% 안전한가? 당연히 아니다. 애초에 https 자체가 서버와 브라우저가 공유키를 교환하는 과정에서만 공개키 알고리즘이 사용되고, 그 다음 부터는 공유키를 가지고 데이터를 암호화한다. 이론적으로는 공유키를 추정(?)할 수 도 있지만, 그 길이가 길기 때문에 현실적으로는 이런 도전은 큰 의미가 없는 것 같다. https를 사용하면 서버 로드가 증가한다. 그래서 대부분의 웹서비스는 http를 기반으로 서비스를 하고, 개인 정보와 같은 민감한 정보를 전달할 때만 https를 사용한다.

내 서버에서도 mod_rewrite를 통해 특정 URI만 https로 돌려서 보호할 수 도 있지만, 난 그냥 전체 사이트를 https로 돌리기로 하였다. 방문자가 있을지도 모르는 개인 블로그 하나 돌리는데 CPU load가 얼마나 되겠는가… 내가 인증서 하나 설치했다고 내 서버와의 완벽하게 보호되지는 않지만, 누구나 볼 수 있는 형태로 내 웹서비스로 내 로그인 정보를 전달할 수 는 없지 않은가?

StartCOM Certificate Authority

StartCOM의 전자인증 서비스인 StartSSL은 class 1 무료 인증서를 발급해주는 것으로 유명하다. 유료 인증서 서비스도 Verisign과 같은 더 잘 알려진 root CA들 대비 훨씬 저렴한 가격에 제공을 하고 있다. 무료 인증서를 발급 받는 절차는 간단하다.

가입 – 개인 메일 인증

이메일 주소와 간단한 정보를 입력하면 입력한 이메일로 인증 키가 담긴 메일이 발송된다. 메일의 인증코드를 복사하여 붙여넣으면 가입이 완료된다. 바로 로그인이 가능한 것은 아니고 입력된 정보가 정확한지 확인 후 통보해준다는 안내가 보여진다. 한 시간 안에 완료 메일이 올 것이다. 인증이 완료되면 가입된 이메일에 대한 S/MIME 인증서가 발급된다. 개인키와 인증서를 잘 저장해둔다. 이후 이 인증서와 개인키를 사용해서 서비스에 로그인할 수 있다. 이 인증서는 1년간 유효하므로 1년 뒤에는 동일한 인증 절차를 반복해야 한다.

도메인 인증

로그인 후 Validations Wizard 에서 domain을 선택한 후 보유한 도메인을 입력하면, 도메인 소유자로 등록된 이메일 주소를 포함해서 해당 도메인의 몇 가지 이메일 주소 중 하나를 선택하여 인증 메일을 수신해야 한다. 수신된 메일의 인증코드를 입력하면 도메인 소유자로 인증이 된 상태이다. 인증받은 도메인은 30일간 유효하므로 1개월 이후 인증서를 갱신하려고 할 경우 다시 도메인 인증을 받아야 한다.

인증서 발급

Certificates Wizard 메뉴에서 Web Server SSL/TLS Certificate을 선택한다. CSR이 있을 경우 Skip을 선택하여 진행하면 된다. 개인키도 새로 만들 경우 개인키의 암호를 입력한 후 계속을 선택하면 생성된 개인키가 PEM 형식으로 보여진다. ssl.key와 같은 이름의 텍스트 파일을 만들어서 내용을 잘 복사해둔다. 도메인 목록에서 인증서를 생성할 도메인을 선택 후 호스트 이름을 입력한다. www을 입력했다면 발급되는 인증서의 subject의 CN은 “www.mydomain.com” 이지만 altName의 DN은 “www.mydomain.com”과 “mydomain.com”이라는 2개의 DN 필드를 가지게 된다. 인증서가 pem 형식으로 표시되는데 잘 저장해둔다. 아파치에 바로 사용하려면 생성된 키와 인증서만으로 가능하지만, OS X Server에서 사용하기 위해서는 다음 몇 단계의 절차가 더 필요하다. 처음 이 서비스를 사용할 때만 해도 동일한 호스트(“www.mydomain.com”)에 대해서 여러번 반복해서 인증서를 받을 수 있었는데 언제 버그가 수정된 것인지 이제는 revoke가 되지 않은 경우 동일 호스트에 대해서 인증서를 중복으로 받을 수 없게 되었다.

P12 포멧으로 변경

Tool box의 Create PKCS#12 (PFX) File을 선택한다. 아까 생성된 개인키와 인증서를 붙여넣고 개인키의 암호를 입력한 후 계속을 누른 후 생성된 파일을 저장한다. PKCS#12로 변경할 때 OS X에서 OpenSSL을 사용했었는데, 어째서인지 Keychain access 도구에서 가져오기 중 오류가 발생했다. StartSSL의 Tool Box를 사용해서 생성하는 .p12 파일은 가져오기가 잘 되더라.. 왜지;;

OS X Server

분명 Lion Server에서는 Server app에 인증서 가져오기 메뉴가 있었다. 이를 통해서 별다른 고민 없이 StartSSL에서 발급받은 인증서를 설치할 수 있었는데, OS X Server에서는 CSR을 만든 다음 가져오도록 변경되었다. 이미 인증서를 발급 받았기 때문에 인증서를 설치하고 SSL 설정이 되지 않아 한참을 애먹었다. (아.. 속상해.. 그래도 devmgrd가 수시로 CPU 100%를 사용하거나 하는 문제는 OS X Server에서는 발생하지 않는게 다행이다)

생성된 인증서를 시스템 인증서로 가져오기

Keychain access를 실행 한 다음 왼쪽에서 System 항목을 선택한 다음 위에서 생성된 xxx.p12 파일을 떨군다. (또는 Finder에서 xxxx.p12를 열기 시도하면 Keychain access가 실행되는데 System으로 가져오기를 하면 된다. 인증서 암호를 입력하면 가져오기가 완료된다.

개인키 접근 권한 수정

실제로 인증서를 가져온 상태에서 /etc/certificate (=/private/etc/certificate)을 확인해보면 새로 생성된 파일이 3개인 것을 확인할 수 있다. ~.pem.key 파일이 누락되었고, ~.concat.pem 파일을 열어보면 개인키가 누락된 상태이다. ~.concat.pem 파일은 jabberd (Messages 서비스)를 SSL/TLS로 제공할 때 필요하다.

원인은 개인키의 접근제한 때문에 서버의 인증서 관련 툴이 개인키를 읽지 못했기 때문이다. 정확히 어떤 프로그램이 그 일을 하는지 못찾아서, 그냥 개인키의 액세스를 풀어버렸다. 이 즈음에서 보안은 산으로 가버리신다. (어떤 프로그램이 인증서를 관리하는지 아신다면 좀 공유 부탁드린다..) 아무튼 Kechain access에서 System을 선택 후 아래쪽에서 Key 항목을 보면 여러개의 개인키가 보일 것이다. 번거롭지만 하나씩 열어서 위에서 생성한 인증서와 연결된 개인키를 찾는다. 관리를 편하게 하려면 개인키의 이름을 적절하게 변경해두는 편이 좋다. 개인키를 찾았다면 개인키의 속성을 열어서 Access control 탭을 선택한 다음 모든 프로그램의 접근을 허용하는 옵션을 선택한다. 속성창을 닫고 시스템을 재시작한다.

이제 /etc/certificates 폴더를 보면 ~.pem.key 파일도 재대로 생성되어있고, ~.concat.pem 파일에도 개인키가 포함된 것을 알 수 있을 것다.

keychain_tool_key

 

이제 모든 서비스들을 SSL/TLS로 보호 할 준비가 되었다!