인터넷

HTTPS와 SSL 인증서

HTTPS VS HTTP

HTTP는 Hypertext Transfer Protocol의 약자다. 즉 Hypertext 인 HTML을 전송하기 위한 통신규약을 의미한다. HTTPS에서 마지막의 S는 Over Secure Socket Layer의 약자로 Secure라는 말을 통해서 알 수 있듯이 보안이 강화된 HTTP라는 것을 짐작할 수 있다. HTTP는 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트가 주고 받는 메시지를 감청하는 것이 매우 쉽다. 예를들어 로그인을 위해서 서버로 비밀번호를 전송하거나, 또는 중요한 기밀 문서를 열람하는 과정에서 악의적인 감청이나 데이터의 변조등이 일어날 수 있다는 것이다. 이를 보안한 것이 HTTPS다.

HTTPS와 SSL

HTTPS와 SSL를 같은 의미로 이해하고 있는 경우가 많다. 이것은 맞기도 틀리기도 하다. 그것은 마치 인터넷과 웹을 같은 의미로 이해하는 것과 같다. 결론적으로 말하면 웹이 인터넷 위에서 돌아가는 서비스 중의 하나인 것처럼 HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜이다.

SSL과 TLS

같은 말이다. 네스케이프에 의해서 SSL이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었다. TLS 1.0은 SSL 3.0을 계승한다. 하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용되고 있다.

SSL 디지털 인증서

SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서다. 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달한다. 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 다음 절차를 수행하게 된다. SSL과 SSL 디지털 인증서를 이용했을 때의 이점은 아래와 같다.

  • 통신 내용이 공격자에게 노출되는 것을 막을 수 있다. 
  • 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단할 수 있다.
  • 통신 내용의 악의적인 변경을 방지할 수 있다. 

SSL에서 사용하는 암호화의 종류

이 수업의 목적은 서버에 SSL 인증서를 설치해서 서버로 접속하는 클라이언트가 안전하게 통신할 수 있도록 하는 것이다. SSL의 동작방법은 이를 수행하기 위해서 꼭 필요한 내용은 아니지만, 이를 모르면 인증서를 사용하는 과정에서 많은 의문점이 생길 것이다. 자연스럽게 보안상의 허점이 생길 확률도 높아질 것이다. 필자의 경험에 따르면 SSL 인증서의 사용은 SSL의 동작방법에 상당히 많이 의지하기 때문에 SSL의 메커니즘을 이해하는 것이 차라리 빠른 길이었다.
필자가 이 분야의 전문가는 아니기 때문에 틀린 내용이나 부족한 내용이 있을 수 있습니다. 조언해주시면 성실하게 반영하겠습니다. 

SSL의 핵심은 암호화다. SSL은 보안과 성능상의 이유로 두가지 암호화 기법을 혼용해서 사용하고 있는데 SSL 동작방법을 이해하기 위해서는 이 암호화 기법들에 대한 이해가 필요하다. 이 방법을 모르면 SSL의 동작방법이 추상적으로 느껴질 것이다. SSL에 대한 구체적인 이해를 할 수 있도록 SSL에서 사용하는 암호화 기법들을 소개하겠다. 이것은 비단 SSL의 이해 뿐 아니라 IT 담당자의 기본 소양에 해당하기 때문에 도전해보자.

대칭키

암호를 만드는 행위인 암호화를 할 때 사용하는 일종의 비밀번호를 키(key)라고 한다. 이 키에 따라서 암호화된 결과가 달라지기 때문에 키를 모르면 암호를 푸는 행위인 복호화를 할 수 없다. 대칭키는 동일한 키로 암호화와 복호화를 같이 할 수 있는 방식의 암호화 기법을 의미한다. 즉 암호화를 할 때 1234라는 값을 사용했다면 복호화를 할 때 1234라는 값을 입력해야 한다는 것이다. 이해를 돕기 위해서 openssl을 이용해서 대칭키 방식으로 암호화하는 방법을 살펴보자. 아래 명령을 실행하면 plaintext.txt 파일이 생성된다. 그리고 비밀번호를 요구 받을 것이다. 이 때 입력한 비밀번호가 대칭키가 되는 것이다. 

필자는 리눅스 배포판 중의 하나인 ubuntu 서버 버전에서 실습을 진행할 것이다.
echo 'this is the plain text' > plaintext.txt;
openssl enc -e -des3 -salt -in plaintext.txt -out ciphertext.bin;

위 명령의 의미는 아래와 같다.

  • enc -e -des3 : des3 방식으로 암호화 함
  • -in plaintext.txt -out ciphertext.bin : plaintext.txt 파일을 암호화 한 결과를 ciphertext.bin 파일에 저장함
openssl enc -d -des3 -in ciphertext.bin -out plaintext2.txt;

위의 명령은 enc -d 옵션으로 인해서 ciphertext.bin 파일을 plaintext2.txt 파일로 복호화하겠다는 의미다.

 

 

공개키

대칭키 방식은 단점이 있다. 암호를 주고 받는 사람들 사이에 대칭키를 전달하는 것이 어렵다는 점이다. 대칭키가 유출되면 키를 획득한 공격자는 암호의 내용을 복호화 할 수 있기 때문에 암호가 무용지물이 되기 때문이다. 이런 배경에서 나온 암호화 방식이 공개키방식이다.

공개키 방식은 두개의 키를 갖게 되는데 A키로 암호화를 하면 B키로 복호화 할 수 있고, B키로 암호화하면 A키로 복호화 할 수 있는 방식이다. 이 방식에 착안해서 두개의 키 중 하나를 비공개키(private key, 개인키, 비밀키라고도 부른다)로하고, 나머지를 공개키(public key)로 지정한다. 비공개키는 자신만이 가지고 있고, 공개키를 타인에게 제공한다. 공개키를 제공 받은 타인은 공개키를 이용해서 정보를 암호화한다. 암호화한 정보를 비공개키를 가지고 있는 사람에게 전송한다. 비공개키의 소유자는 이 키를 이용해서 암호화된 정보를 복호화 한다. 이 과정에서 공개키가 유출된다고해도 비공개키를 모르면 정보를 복호화 할 수 없기 때문에 안전하다. 공개키로는 암호화는 할 수 있지만 복호화는 할 수 없기 때문이다.

이 방식은 이렇게 응용할 수도 있다. 비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송한다. 정보와 공개키를 획득한 사람은 공개키를 이용해서 암호화된 정보를 복호화 한다. 이 과정에서 공개키가 유출된다면 의도하지 않은 공격자에 의해서 데이터가 복호화 될 위험이 있다. 이런 위험에도 불구하고 비공개키를 이용해서 암호화를 하는 이유는 무엇일까? 그것은 이것이 데이터를 보호하는 것이 목적이 아니기 때문이다. 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미한다. 즉 공개키가 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다. 이러한 것을 전자 서명이라고 부른다.

그럼 이해를 돕기 위해서 공개키를 이용해서 RSA라는 방식의 공개키를 사용해보자. 아래 명령은 private.pem이라는 이름의 키를 생성한다. 이 키는 1024bit 길이을 갖는다. 이 숫자가 높을수록 안전하다.

openssl genrsa -out private.pem 1024;

다음 명령은 private.pem이라는 이름의 비공개키에 대한 public.pem이라는 이름의 공개키를 생성한다. 이 공개키를 자신에게 정보를 제공할 사람에게 전송하면 된다.

openssl rsa -in private.pem -out public.pem -outform PEM -pubout;

공개키를 가진 사람이 어떤 정보를 비공개키를 가지고 있는 사람에게 전송하는 상황을 상정해보자. 아래는 coding everybody라는 이름의 문자를 담고 있는 file.txt를 만든다. 이 데이터를 비공개키 소유자에게 전송하기 위해서는 암호화가 필요하다.

echo 'coding everybody' > file.txt

file.txt를 암호화 해보자. 아래의 예제는 file.txt의 내용을 RSA방식으로 암호화한 file.ssl이라는 이름의 파일을 생성한다. 이 때 사용된 공개키가 public.pem이다. 이제 안심하고 file.txt를 암호화한 결과인 file.ssl을 비공개키의 소유자에게 전송할 수 있다.

openssl rsautl -encrypt -inkey public.pem -pubin -in file.txt -out file.ssl;

그럼 file.ssl을 수신받은 비공개키 소유자가 어떻게 이 정보를 복호화 할 수 있는지 알아보자. 아래 예제는 file.ssl을 복호화한 결과를 decrypted.txt로 만들어내는 방법을 보여준다. 이 과정에서 비공개키인 private.pem을 사용했다.

openssl rsautl -decrypt -inkey private.pem -in file.ssl -out decrypted.txt

SSL 인증서

SSL 인증서의 역할은 다소 복잡하기 때문에 인증서의 메커니즘을 이해하기 위한 몇가지 지식들을 알고 있어야 한다. 인증서의 기능은 크게 두가지다. 이 두가지를 이해하는 것이 인증서를 이해하는 핵심이다.

  1. 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장한다.
  2. SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
우선 단편적인 지식들을 하나씩 파악하면서 뒤에서 전체적인 메커니즘을 이해하자. SSL에 대한 전체적인 이해에는 상당히 많은 개념들이 유기적으로 상호작용하기 때문에 한번에 이해하기 난해하다. 여러번 읽어가면서 그 관계들을 파악해야 한다.

CA

인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 한다. 이 역할을 하는 민간기업들이 있는데 이런 기업들을 CA(Certificate authority) 혹은 Root Certificate 라고 부른다. CA는 아무 기업이나 할 수 있는 것이 아니고 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다. 그 중에 대표적인 기업들은 아래와 같다. 수치는 현시점의 시장점유율이다. (위키피디아 참조)

  •  Symantec (VeriSign, Thawte, Geotrust) with 42.9% market share
  • Comodo with 26%
  • GoDaddy with 14%
  • GlobalSign with 7.7%

SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야 한다. CA는 서비스의 신뢰성을 다양한 방법으로 평가하게 된다.

사설 인증기관

개발이나 사적인 목적을 위해서 SSL의 암호화 기능을 이용하려한다면 자신이 직접 CA의 역할을 할 수도 있다. 물론 이것은 공인된 인증서가 아니기 때문에 이러한 사설 CA의 인증서를 이용하는 경우 브라우저는 아래와 같은 경고를 출력한다.

공인된 CA가 제공하는 인증서를 사용한다면 브라우저의 주소창이 아래와 비슷한 모양을 보여줄 것이다.

SSL 인증서의 내용

SSL 인증서에는 다음과 같은 정보가 포함되어 있다.

  1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등등)
  2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

인증서의 내용은 위와 같이 크게 2가지로 구분할 수 있다. 1번은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지에 대한 내용을 담고 있고, 2번은 서버와 통신을 할 때 사용할 공개키와 그 공개키의 암호화 방법들의 정보를 담고 있다. 서비스의 도메인, 공개키와 같은 정보는 서비스가 CA로부터 인증서를 구입할 때 제출해야 한다.

위와 같은 내용은 CA에 의해서 암호화 된다. 이 때 사용하는 암호화 기법이 공개키 방식이다. CA는 자신의 CA 비공개키를 이용해서 서버가 제출한 인증서를 암호화하는 것이다. CA의 비공개키는 절대로 유출되어서는 안된다. 이것이 노출되는 바람에 디지노타라는 회사는 파산된 사례도 있다.

CA를 브라우저는 알고 있다

인증서를 이해하는데 꼭 알고 있어야 하는 것이 CA의 리스트다. 브라우저는 내부적으로 CA의 리스트를 미리 파악하고 있다. 이 말은 브라우저의 소스코드 안에 CA의 리스트가 들어있다는 것이다. 브라우저가 미리 파악하고 있는 CA의 리스트에 포함되어야만 공인된 CA가 될 수 있는 것이다. CA의 리스트와 함께 각 CA의 공개키를 브라우저는 이미 알고 있다.

SSL 인증서가 서비스를 보증하는 방법

이번 절을 시작할 때 인증서의 첫번째 목적을 아래와 같이 언급했다. 어떤 메커니즘으로 인증서가 서버의 신뢰성을 보장하는지 알아보자.

클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장

웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공한다. 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지를 확인한다. 확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화 한다. CA의 공개키를 이용해서 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미한다. 해당 CA의 비공개 키를 가지고 있는 CA는 해당 CA 밖에는 없기 때문에 서버가 제공한 인증서가 CA에 의해서 발급된 것이라는 것을 의미한다. CA에 의해서 발급된 인증서라는 것은 접속한 사이트가 CA에 의해서 검토되었다는 것을 의미하게 된다. CA의 검토를 통과했다는 것은 해당 서비스가 신뢰 할 수 있다는 것을 의미한다. 이것이 CA와 브라우저가 특정 서버를 인증하는 과정이다. 이 과정이 잘 이해가 되지 않는다면 전자서명 부분을 다시 읽어보자. 또한 이 과정은 뒤에서 다시 한번 살펴볼 것이다.

이렇게해서 인증서가 서버의 신뢰성을 제공하는 방법을 알아봤다. 그런데 의문점이 남는다. 인증서에 포함된 서버의 공개키는 어떤 용도에 사용될까? 이제부터 이것에 대해서 알아보자.

SSL의 동작방법

결론부터 말하면 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용한다. 즉 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다. 이 설명만으로는 이해하기 어려울 것이다. 아래의 관계만 일단 머리속에 기억해두고 좀 더 구체적인 설명으로 넘어가자.

  • 실제 데이터 : 대칭키
  • 대칭키의 키 : 공개키

컴퓨터와 컴퓨터가 네트워크를 이용해서 통신을 할 때는 내부적으로 3가지 단계가 있다. 아래와 같다.

악수 -> 전송 -> 세션종료

이것은 은밀하게 일어나기 때문에 사용자에게 노출되지 않는다. 이 과정에서 SSL가 어떻게 데이터를 암호화해서 전달하는지 살펴보자.

1. 악수 (handshake)

사람과 사람이 소통을 할 때를 생각해보자. 우선 인사를 한다. 인사를 통해서 상대의 기분과 상황을 상호탐색을 하는 것이다. 이 과정이 잘되야 소통이 원활해진다. 클라이언트와 서버 사이도 마찬가지다. 실제 데이터를 주고 받기 전에 클라이언트와 서버는 일종의 인사인 Handshake(진짜로 사용하는 기술용어다)를 한다. 이 과정을 통해서 서로 상대방이 존재하는지, 또 상대방과 데이터를 주고 받기 위해서는 어떤 방법을 사용해야하는지를 파악한다.

SSL 방식을 이용해서 통신을 하는 브라우저와 서버 역시 핸드쉐이크를 하는데, 이 때 SSL 인증서를 주고 받는다. 이 과정은 앞에서 설명한 바 있다. 인증서에 포함된 서버 측 공개키의 역할은 무엇일까를 이제 알아보자.

공개키는 이상적인 통신 방법이다. 암호화와 복호화를 할 때 사용하는 키가 서로 다르기 때문에 메시지를 전송하는 쪽이 공개키로 데이터를 암호화하고, 수신 받는 쪽이 비공개키로 데이터를 복호화하면 되기 때문이다. 그런데 SSL에서는 이 방식을 사용하지 않는다. 왜냐하면 공개키 방식의 암호화는 매우 많은 컴퓨터 자원을 사용하기 때문이다. 반면에 암호화와 복호화에 사용되는 키가 동일한 대칭키 방식은 적은 컴퓨터 자원으로 암호화를 수행할 수 있기 때문에 효율적이지만 수신측과 송신측이 동일한 키를 공유해야 하기 때문에 보안의 문제가 발생한다. 그래서 SSL은 공개키와 대칭키의 장점을 혼합한 방법을 사용한다. 그 핸드쉐이크 단계에서 클라이언트와 서버가 통신하는 과정을 순서대로 살펴보자.

  1. 클라이언트가 서버에 접속한다. 이 단계를 Client Hello라고 한다. 이 단계에서 주고 받는 정보는 아래와 같다.
    • 클라이언트 측에서 생성한 랜덤 데이터 : 아래 3번 과정 참조
    • 클라이언트가 지원하는 암호화 방식들 : 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 한다. 이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송한다.
    • 세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송한다.
       
  2. 서버는 Client Hello에 대한 응답으로 Server Hello를 하게 된다. 이 단계에서 주고 받는 정보는 아래와 같다.
    • 서버 측에서 생성한 랜덤 데이터 : 아래 3번 과정 참조
    • 서버가 선택한 클라이언트의 암호화 방식 : 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 이로써 암호화 방식에 대한 협상이 종료되고 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 된다.
    • 인증서
       
  3. 클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA 리스트를 확인한다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력한다. 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다. 인증서를 전송한 서버를 믿을 수 있게 된 것이다.

    클라이언트는 상기 2번을 통해서 받은 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 pre master secret라는 키를 생성한다. 이 키는 뒤에서 살펴볼 세션 단계에서 데이터를 주고 받을 때 암호화하기 위해서 사용될 것이다. 이 때 사용할 암호화 기법은 대칭키이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안된다.

    그럼 문제는 이 pre master secret 값을 어떻게 서버에게 전달할 것인가이다. 이 때 사용하는 방법이 바로 공개키 방식이다. 서버의 공개키로 pre master secret 값을 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 안전하게 복호화 할 수 있다. 그럼 서버의 공개키는 어떻게 구할 수 있을까? 서버로부터 받은 인증서 안에 들어있다. 이 서버의 공개키를 이용해서 pre master secret 값을 암호화한 후에 서버로 전송하면 안전하게 전송할 수 있다.
     
  4. 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다. 이로서 서버와 클라이언트가 모두 pre master secret 값을 공유하게 되었다. 그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다. master secret는 session key를 생성하는데 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다. 이렇게해서 세션키를 클라이언트와 서버가 모두 공유하게 되었다는 점을 기억하자.
     
  5. 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.

2. 세션

세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다. 이 단계에서 핵심은 정보를 상대방에게 전송하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화 한다는 점이다. 암호화된 정보는 상대방에게 전송될 것이고, 상대방도 세션키 값을 알고 있기 때문에 암호를 복호화 할 수 있다.

그냥 공개키를 사용하면 될 것을 대칭키와 공개키를 조합해서 사용하는 이유는 무엇을까? 그것은 공개키 방식이 많은 컴퓨터 파워를 사용하기 때문이다. 만약 공개키를 그대로 사용하면 많은 접속이 몰리는 서버는 매우 큰 비용을 지불해야 할 것이다. 반대로 대칭키는 암호를 푸는 열쇠인 대칭키를 상대에게 전송해야 하는데, 암호화가 되지 않은 인터넷을 통해서 키를 전송하는 것은 위험하기 때문이다. 그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.

3. 세션종료

데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이 때 통신에서 사용한 대칭키인 세션키를 폐기한다.

CA를 통해서 인증서 생성

수업에서 필자의 착오로 startssl을 starssl이라고 언급하고 있다. startssl이 맞는 브랜드 이름이다. 
2009년 이전의 XP나 비스타와 같은 운영체제에서는 startssl이 공인된 인증서로 등록 되어 있지 않을 수 있다. 물론 사용자가 업데이트를 충실히 했다면 그런 문제는 발생하지 않는다.  

지금부터는 CA를 통해서 인증서를 구입해서 사용하는 방법을 알아보자. 앞서 언급한 것처럼 CA는 인증서를 발급해주는 기관이다. 이 기관들을 통해서 인증서를 구입함으로서 사용자들에게 좀 더 안전한 서비스를 제공할 수 있다. 인증서를 구입하는 것부터 설치하는 방법까지 알아보자.

CA는 기업이다. 따라서 어떤 기업을 선택할 것인지를 각자가 충분히 숙고해서 판단해야 한다. 위키피디아에는 주요한 CA들의 인증서를 비교할 수 있는 자료가 있다. 이를 참고한다. http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers 또 국내의 웹호스팅 업체들이 CA를 대행해서 인증서를 판매하고 있기 때문에 영어나 행정절차가 부담된다면 이들 업체를 이용하면 된다.

인증서 구입

필자가 선택한 CA는 이스라엘 기업인 StarCom이다. 이 회사는 1년간 무료로 사용할 수 있는 인증서를 제공한다. 인증서 구입에 부담이 있는 개인이나 작은 사업자라면 만족할만한 보안을 제공하는 것으로 알려져있다. 이 회사에서 제공하는 무료 인증서는 아래와 같은 기능을 제공한다.

  • 웹서버 인증서 (SSL/TLS)
  • Client 와 mail 인증서 (S/MIME)
  • 128/256-bit 암호화
  • US $ 10,000 보상금
  • 1년간 유효함

1. 로그인 페이지로 이동한다.

2. Express Lane 옵션을 선택한다.

StartSSL은 클라이언트 측 인증서를 요구한다. 아직 인증서를 발급받지 않은 상태라면 인증서 오류가 발생할 것이기 때문에 Express Lane 옵션을 빠르게 선택해서 이동한다.

3. 요구하는 정보를 '사실대로' 입력한다. 만약 허위 정보가 입력되면 가입 승인이 거부된다.

4. 이메일로 인증코드가 반송된다. 이메일을 확인한다.

5. 필자는 이런 내용의 이메일을 받았다.

This electronic mail message was created by StartCom's Administration Personnel:
Thank you for registering with StartSSL. It seems that you provided the address details of an organization. However our terms and conditions require from our subscribers to disclose the private address of residence. Please reply to this message and send us the details of your personal residence.

6. 한국어로 번역하면 아래와 같다.

내용은 당신이 보낸 메일이 진짜 자신의 메일인지 증명하기 위해서 아까 입력한 내용을 메일로 회신해주세요.

이것은 인증의 단계로 회원가입 시에 입력한 주소를 다시 적어서 메일로 회신하면 Startssl 측에서 아래와 같이 물어볼 것이다.

It's your company address or it's a personal residence? (이것이 회사 주소인가요? 집 주소인가요?)

7. 아래와 같이 답변한다.

My Personal residence. (집주소 입니다)

8. 그럼 인증에 성공했다는 메시지가 도착할 것이다. 내용은 아래와 비슷할 것이다.

Your request for an account at StartSSL™ (www.startssl.com) has been approved and is available during the next 24 hours at the following location:

https://www.startssl.com/?app=12&action=release

The verification code in order to continue the process is ***

Thank you!

9. 위의 주소로 ***로 표시한 부분이 자신의 인증코드다. 인증코드를 복사한 후에 링크를 클릭해보자. 아래와 같은 메시지가 출력될 것이다. 인증코드를 붙여넣기 한다.

10. 비공개키의 암호화 방식을 지정한다. 2048을 사용하자.

11.  install 버튼을 누른다.

12. 축하 메시지가 출력되면 인스톨에 성공한 것이다. 

이 때 크롬의 경우 브라우저 상단에 클라이언트 인증서가 설치되었다는 메시지가 보일 것이다. 앞으로 startssl의 관리자에 접속할 때는 이 인증서를 이용할 것이기 때문에 등록한 이메일에 해당하는 startssl 계정의 관리자로 접속할 때는 꼭 이 인증서가 설치된 브라우저로 접속해야 한다. Continue를 누른다.

13. 도메인 주소를 입력한다.

14. 인증 메일을 선택한다.

자신의 도메인임을 증명하기 위해서 도메인과 연관된 이메일 주소 중의 하나를 선택한다. 꼭 사용할 수 있는 이메일 주소를 선택해야 한다. 만약 사용할 수 있는 이메일 주소가 없다면 네임서버의 설정을 변경해야 한다.

15. 수신 받은 이메일을 확인한다. 메시지는 아래와 유사할 것이다.

This mail is intended for the person who requested verification of domain control at StartSSL™ (http://www.startssl.com).

Your verification code is ***
Copy and paste this code now into the form at your open browser window.

16. *** 표시된 텍스트를 복사해서 Vertification Code 필드에 입력한다.

17. 아래와 같은 화면이 출력된다면 인증에 성공한 것이다. 30일 안에 인증서를 발급받아야 한다는 내용이다.

 18. 비공개키를 발급 받는다. 비공개키는 직접 생성할수도 있지만 startssl이 제공하는 키를 사용하면 편리하다.

Key Password는 비공개키가 유출 되었을 때 비공개키를 보호해주는 수단이다. 비공개키가 있다고해도 이 비밀번호가 없다면 데이터를 복호화 할 수 없다. 이 값을 설정하면 보안의 레벨은 상승 하지만 서버를 재부팅 할 때마다 Apache와 같은 웹서버에 비밀번호를 입력해줘야 하는 불편함이 있다. 이 비밀번호는 꼭 기억해야 한다. keysize는 2048, Secure Hash Algorithm은 sha1을 선택한다.

19. 비공개키를 복사한다.

비공개키는 매우 중요한 정보다. 비공개키가 유출되면 ssl을 통해서 서버로 전달되는 정보가 해독될 수 있기 때문에 절대로 노출되서는 안된다. 이 정보는 별도의 파일로 복사해서 저장한다. 파일명으로 필자는 ssl.key를 사용했다.

20. 도메인 추가

만약 opentutorials.org의 서브 도메인인 www.opentutorials.org로 ssl로 보호하고 싶다면 아래 화면에서 www를 입력한다.
아래와 같이 입력하면 StartSSL은 opentutorials.org와 www.opentutorials.org에 대해서만 보호 기능을 제공한다. 만약 dev.opentutorials.org에 대해서 SSL 서비스를 하고 싶다면 인증서를 하나 더 만들어야 한다. www나 dev와 같은 부분을 호스트 네임이라고 하는데 모든 호스트 네임에 대해서 보호되는 인증서를 사용하고 싶다면 와일드 카드 인증서를 구입해야 한다. 인증서를 비교한 차트에서 와일드 카드 항목을 참고하면 된다.http://www.startssl.com/?app=40

21. 인증서 발급을 위한 모든 정보의 입력이 끝났다. Continue를 누른다.

 22. 인증서가 발급되었다.  이 내용을 복사해서 ssl.crt 파일에 저장한다. 화면 하단에 Save also the intermediate and root CA certificates for the installation at your server(Save AS...)라고 되어 있는 부분의 내용을 클릭해서 파일로 저장한다.

인증서 발급이 끝났다. 이제 StartSSL을 통해서 발급 받은 인증서를 이용해서 서버쪽 셋팅을 하면 SSL을 사용할 수 있다.

정리

이상의 절차를 통해서 얻은 정보는 크게 4가지다. 이 정보들을 이용해서 SSL을 제공하는 방법을 알아보자.

  • ssl.key : 서버쪽 비공개키
  • ssl.crt : 디지털 인증서
  • ca.pem : ROOT CA 인증서
  • sub.class1.server.ca.pem : 중계자 인증서

웹서버 셋팅

SSL을 서비스하는 마지막 단계는 웹서버에 인증서를 설치하는 것이다. SSL 통신을 할 때 사용할 인증서를 웹서버에게 알려주면 웹서버는 정해진 절차에 따라서 SSL 통신을 하게 된다.

인증서를 웹서버에 설치하는 방법은 웹서버 별로 다르다. 이번 시간에는 가장 표준적인 웹서버인 Apache에 인증서를 설치하는 방법을 살펴볼 것이다. 다른 웹서버에 인증서를 설치하는 방법은 인증기관에서 메뉴얼을 제공하기 때문에 그것을 참고하면 된다. StartSSL은 아래 URL을 통해서 메뉴얼을 제공하고 있다.

http://www.startssl.com/?app=20

1. apache 설치

sudo apt-get install apache2;

2. 아파치의 SSL 모듈을 활성화 한다.

sudo a2enmod ssl

3. 아피치를 재시작 한다.

sudo service apache2 restart

4. SSL 인증서 관련된 파일을 위치시킬 디렉토리를 만든다.

sudo mkdir /etc/apache2/ssl 

5. /etc/apache2/ssl 디렉토리에 인증서 파일들을 위치시킨다. 파일들의 경로는 아래와 같다.

  • /etc/apache2/ssl/ca.pem
  • /etc/apache2/ssl/ssl.crt
  • /etc/apache2/ssl/ssl.key
  • /etc/apache2/ssl/sub.class1.server.ca.pem

6. 보안을 위해서 디렉토리와 파일의 권한을 조정한다.

디렉토리와 파일의 소유자는 root로 지정한다.

sudo chown -R root:root /etc/apache2/ssl;

파일의 권한을 600(소유자만 읽기, 쓰기 허용)

sudo chmod 600 /etc/apache2/ssl/*.*

디렉토리의 권한을 700(소유자만 읽기, 쓰기, 실행 허용)

sudo chmod 700 /etc/apache2/ssl;

팔자의 경우 아래와 같은 상태가 되었다. 

7. virtualhost를 설정한다. 하나의 웹서버(apache)에서 여러개의 서비스를 도메인 별로 운영할 수 있도록 돕는 apache의 기능이다. 기본 설정 파일인 /etc/apache2/sites-available/default-ssl을 수정한다. 아래에서는 편집기로 nano를 사용하고 있다. nano에 대한 사용법은 nano 수업을 참고한다.

sudo nano /etc/apache2/sites-available/default-ssl

8. 파일의 내용에서 지시자의 값을 아래와 같이 변경한다.  예제 파일은 http://www.startssl.com/?app=21를 참고한다.

SSLCertificateFile    /etc/apache2/ssl/ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/ssl.key
SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem
SSLCACertificateFile /etc/apache2/ssl/ca.pem

9. 버추얼 호스트 default-ssl을 활성화된 서비스로 등록한다.

sudo a2ensite default-ssl

10. apache를 재시작한다. 재시작 할 때 비밀번호를 물어보는 경우가 있다. 이것은 비공개키를 생성하는 단계에서 입력한 비밀번호를 입력하면 된다.

11. https 프로토콜로 접속한다. (구글 크롬 기준) 아래와 같이 녹색 자물쇠가 도메인 앞에 표시되고, 인증서와 관련된 팝업이 표시된다면 SSL 서비스를 성공적으로 제공하기 시작한 것이다.

참고

댓글

댓글 본문
작성자
비밀번호
  1. 장인정신
    훌륭한 강의 정말 감사드립니다.
  2. 멋찌십니다!!
    지금까지 완벽히 이해하지 못하고 이리저리 언저리로 쪼금쪼금 보다말다하니 금방 까먹었는데
    이번엔 많이 도움이 되어 그래도 오래 기억할 것 같아요!
    엄지 척입니다!!!
    감사합니다.
  3. codebasik
    강의 감사합니다.

    현업(java)에서 https 통신시 handshake alert: unrecognized_name exception이 발생하여 강의를 통해 힌트를 얻으려 했는데, 여의치 않아 질문을 드리게 됐습니다.

    handshake alert 발생시에 대한 솔루션 관련하여 자료를 찾아보니 jdk 버전 업( ~ ->7) 되면서 ssl 인증 강화(?) 가 된 것으로 알고 있는데요
    이를 무시(?) 하는 방법으로 systemProperties에 SNIExtension 을 false 설정하는 것이 많이 공유 되어 있더라구요

    문제는 2 ( A / B )개 API를 https 통신하는데
    위 옵션을 추가한 경우 A (정상) / B(handshake 실페)
    옵션을 제거한 경우A (handshake 실페) / B(정상)
    이 된다는 것입니다.

    자료를 조금 더 찾아보니 가상서버인 경우 SNI 확장 필드를 true 해야 한다는 내용이 있었습니다.
    A 경우, 외부 업체라 가상서버의 여부는 알지 못한 상황이고
    B 경우는 가상서버 입니다.

    혹시 위와 관련하여 조언을 좀 구할 수 있을까요?
  4. 특명이
    둘을 조합하여 세션키를 만드는 겁니다.

    어떤 식으로 조합하여 어떤 세션키가 나올지 크래커가 알 수는 없지요.
    대화보기
    • 김타조
      만화를 보다가 보니 계속 보게되네요.. 하핫..
    • ironhee
      감사합니다!! 쉽게 잘 설명되어있어서 도움 많이 받아갑니다! :D
    • JustStudy
      고맙습니다.
    • rongzel
      많은 도움 되었습니다. 이고잉님의 노력에 많은 감사를 드립니다.
    • lchyun1202@gmail.com
      정말 잘 읽었습니다 이고잉님!! SSL 개념이 헷갈려서 힘들어하고 있었는데, 이 강의를 보고 가닥을 잡을 수 있었습니다.

      본문에서 딱! 1가지 내용이 잘 이해가 안되서 질문 드립니다.

      SSL 핸드쉐이킹 과정에서 "client hello" 할 때 클라이언트가 생성한 랜덤 데이터를 서버에게 보내고, "server hello"할 때 서버가 생성한 랜덤 데이터를 클라이언트에게 보낸다고 했습니다. 클라이언트는 이 둘을 조합해서 pre-master secret을 만들고 서버의 공개키로 암호화해서 서버에게 보낸다고 하셨지요.

      이 부분이 좀 이해가 막힙니다. 제 생각에 "client hello"와 "server hello"는 암호화되기 전 통신이기 때문에 중간에 packet sniffing 을 하면 빼갈 수 있는 정보라고 생각합니다. 그러므로 도청을 시도하는 제 3자가 클라이언트가 생성한 랜덤 데이터와 서버가 생성한 랜덤 데이터를 모두 알 수 있으므로 pre-master secret도 알게되는 것이 아닌가 싶네요.

      클라이언트가 혼자 랜덤 데이터를 생성해서 서버의 공개키로 암호화해서 서버에게 보내주면, 문제가 해결될 것 같은데.... 어떻게 생각하시는지요?
    • 어렵네요.
      어렵네요. 비대칭 암호화 알고리즘이 뭔가 궁금해서 찾아보니 수학공식이 많더라구요.
      이 사이트 전체 통털어서 가장 어려운 부분인 듯. 그동안 은행 사이트 같은데 가면
      액티브x로 별도의 yessign 같은 인증서 프로그램 까는건줄 알았는데 웹브라우저에서도 저런게 되나 보네요.
    • 파이어볼
      발급시 https://www.securesign.kr/ 여기도 참고해 보시면 어떨까 합니다~
    • 최영국
      자료 잘 참조 했습니다. 감사합니다.
      좀 다른 질문인데요.
      *
      첫째,
      웹서버 상이 아닌, 일반적인 클라이언트-서버 프로그래밍에서 SSL method (예를 들어 SOAP 의 soap_ssl_client_context) 를 이용해서 클라이언트가 서버가 발행한 인증서를 이용해서 등록된 클라이언트라는 증명을 하면서 통신을 하게될때에도 같은 방식의 SSL 작동이 일어나야 하는것인지, 아니면 취사 선택해서 사용하는것인지 궁금하고요.

      두번째,

      인터넷상에 보니 SSL 에서 이용하는 알고리즘을 과거 주로 사용하던 SHA-1 에서 SHA-2 계열 (SHA 256, SHA 518 등) 으로 바꾸어야 한다고 강력하게 권장하는것 같은데, 그때 그 변경/업그레이드 대상은 주로 웹서버입니까?

      아니면 모든 기기에서 (서버든 클라이언트든) SHA-2 계열로 바꾸는 작업을 해야 한다는 의미 인가요?
      제가 짐작하기로는 서버에서만 일어나는 일이고 특히 웹서버에서 주의해야 할 사항이며, 클라이언트 입장에서는 해당 기기 의 소프트웨어 (브라우져와 SSL) 버젼만 SHA-2 계열 이용이 가능한 해당 상위 버젼으로 업그레이드 하면 되는것 같은데, 맞습니까?

      너무 구체적인 질문들이라 좀 죄송한데, 강의 올리신 선생님이나 아시는 분 답변 부탁드립니다.
    • 저도 적용이 끝나지는 않았습니다만 CA인증서는 https://www.startssl.com/root 여기 있는거같습니다.

      그리고 체인파일을 얻으시려면 먼저 로그인하신 다음에

      1. tool box -> certificate list -> action 칼럼에 있는 retrieve 버튼을 클릭하여 압축파일을 다운로드 받습니다.

      2. 압축을 풀고 폴더에 들어가면 서버 종류별로 압축파일이 또 있는데 거기서 apacheserver.zip을 풀어줍니다.

      여기서 1_root_bundle.crt이 체인파일입니다,
      대화보기
      • lionel.j
        ca.pem : ROOT CA 인증서
        sub.class1.server.ca.pem : 중계자 인증서

        는 언제 어떤 경로로 다운받게 된것인지 설명이 없네요. 궁금합니다.
      • 홈페이지 리뉴얼이 되서.. 따라하기가 힘드네요..ㅠㅠ
      • 코드나비
        혹시 아파치 서버 재부팅없이 SSL인증서를 반영하는 방법이 있나요?
        .htaccess 파일로는 URL리다이렉트만 되는데 혹시 다른방법이 있을까요
      • 갑기
        startcom 홈페이지 리뉴얼로 인하여 안내해주신 과정과는 달라졌지만.. 전체적인 개념을 잡을 수 있어서 좋았습니다. 덕분에 어렵지 않게 적용까지 가능하게 되었습니다. 감사합니다.
      • 에어기어
        egoing님 답변갑사합니다. 또 긍금한게 인증서보면 유효기간이 있던데 이것도 도메인처럼 암호화 통신하는데 실제 관련이 없는건가요?
      • egoing
        https로 접근하시면 항상 암호화 됩니다. 다만 인증서는 그 도메인이 위조된 것인지와 같은 여부를 확인해주는 기능이 추가적으로 포함된 것이라고 생각하시면 될 것 같습니다. (저도 공부한지 오래되서 100% 확신은 아닙니다만 ^^;)
        대화보기
        • 에어기어
          발급받은 ssl 인증서 도메인정보와 접속하는 도메인이 달라도 브라우저 경고창과 상관없이 실제 암호화통신은 되는건지 궁금합니다. 예를 들어 a.xxx.com으로 인증서를 셋팅했는데 b.xxx.com으로 접속했을때 실제 암호화통신여부입니다 암호화할때 도메인정보 일치여부가 필수인지..
        • Let's Encrypt
          잘 이해가 됩니다.
          이번에 Let's encrypt의 등록이 시작되었는데 이것에 대한 이야기도 적어주시면 어떨까요?
        • Dean
          좋습니다.. 아주 좋아요!
        • 코난도일
          아, 찾아보니 혹시 이건가요?
          http://jne-sw.tistory.com/320
          맞다면 링크 대체하는 것이 좋을 듯 합니다.
        • 코난도일
          SSL이란 무엇인가 링크가 깨졌습니다.ㅜㅜ
        • sereno
          와 깔끔한 설명, 정리 감사합니다~
        • 유기농브래드
          네~ 강좌 너무 잘 봤습니다.
          그간 애매했었는데, 시원하게 뚫어주셨네요. 감사합니다!!
        • Inseop Kim
          참고의 두번째 SSL이란 무엇인가에 해당된 미닉스의 작은 이야기들 블로그는 현재 운영안하며 링크에 해당되는 글이 삭제되었습니다. 링크 취소선으로 바꿔주세요.
        • 내용이 쉽고 잘이해되네요~
        • RSA 암호화의 원리를 이용해서 변조되지 않음을 인증하는 방법을 설명한 걸로 보입니다.
          암호화했다는 게 아니구요. 어찌되었던 SHA1withRSA라는 방식도 RSA에 나오는 키 쌍을 이용해서 상대방의 것을 인증할 수 있다라고 본인도 말하고 있자나요?
          대화보기
          • HyunHo Lim
            위 방식으로 ssl 적용을 완료 하였습니다. 한가지 궁금한게 생겼는데요 지금 인증서1개에 1개의 사이트가 연결이 되어있는데 만약에 새로운 홈페이지가 하나 더생겨서 그 홈페이지도 ssl을 추가 하고 싶으면 어떻게 해야 하나요??? 다시 ssl사이트에서 ssl파일을 만들어서 위 방식대로 해야 하나요??
          • 토론토당근
            강의 감사합니다.
            브라우저의 CA 리스트에 존재하지 않는 CA인증된 인증서인 경우,
            어떻게 디코딩될 수 있나요? (CA public키를 어떻게 얻게 되나요?)
          • 유령전사
            잘들었습니다. SSL 인증서 관련하여서 몰랐는데... 기초가 부족한데 많은 도움이 되었습니다. ^^
          • 명강
            잘 들었습니다. 좋은 강의 감사합니다. ^^
          • 코카콜라
            STARTSSL 관리패널 로그인용 "클라이언트 인증서"의 만료기간이 거의 다 되어가고 있는데요.
            이걸 연장하려면 어디서 해야할까요?
          • newagro
            이쪽 분야가 전무한 상태에서 현재 이 사이트를 알게 되어 매우 감사하게 공부중입니다.

            이 전 강의에서 iptime공유기를 통한 ddns서버 개설을 보고 따라 했습니다. 그리고 ssl인증기관의 적용을 받고 싶어 수업처럼 startssl에 접속하여 인증키를 받으려 했었는데요.

            그런데 수업도중 발생하신 현상처럼 저도 도메인을 입력할 시 .iptime.org가 최상의 도메인이 아닌 subdomain이란 오류가 뜨면서 문제가 발생되었습니다.

            이런경우 해결방법이 있나 해서 질문드립니다.

            찼다가 개인이 apache서버를 이용해서 개인 인증 ssl인증서와 개인키를 만들어 설치하는 방법까지는 적용했지만 인증기관을 적용하는 것과는 차이가 크기 때문입니다.
          • greenyant
            지금 startssl에서 해보니 Generate Private Key 할 때 비밀번호 없인 진행이 안됩니다. ㅠㅠ
          • 신입사원
            정말~너무 이해가 잘돼요. 단어는 많이 들어봤는데, 실제로 어떤건지는 확실히 몰랐는데, 강의듣고나니 이해가 됐어요. 더 많은 강의가 있었으면 좋겠어요~~! 감사합니다 ^^
          • 식장산
            명강의 입니다.
          • 삼실청년
            너무나 잘 설명해주셨습니다.감사합니다.
          • hotshotseo
            중간쯤 보고 있는데, 내용이 너무 훌륭합니다. 명쾌하고 깔끔하네요.
          • 배우
            정말로 좋은 강의 감사합니다!!
            머리에 쏙쏙 들어오네요
          • ruapapa
            좋은 자료 감사하니다. ^
          • 배움배움
            a2enmod는 centos에서 어떻게 해야 하나요????
          • 규만
            이해하기 쉽게 잘 정리된 내용 감사 합니다. ^^
          • wolfkang
            위키피디아에서 http://en.wikipedia.org......ers 페이지가 삭제됐네요.
          • charlie
            좋은 강의 감사합니다.
          • martus
            아.. 정말 잘 정리된 내용입니다!
            좋은 자료네요~ 감사합니다 ^^
          • tmpId
            정말 유익한 정보 감사 드립니다.~
          • starmark
            정말 잘 정리하셨네요. 큰 도움이 되었습니다. 감사합니다 !
          • 그게바로펄풱 인생의 진리지
            서명부분 설명이 조금 이상하네요?
            인증기관에서 공개키+회사정보에 대해서 전자서명을 하여 인증서를 발급하는 것은 암호화가 아닙니다.
            공개키와 회사정보가 인증서에 그대로 나타나는데 어디를 암호화 한 걸까요?
            암호화와 서명은 다릅니다.
            서명은 이 데이터는 변조가 되지 않았음이라는 것을 보증해주는 것이지요.
            그 때 사용하는 알고리즘이 뭐..SHA1withRSA정도 되려나요? SHA1withRSA로 인증서에 담을 내용의 해쉬값을 만들지요. 그 때 인증기간의 프라이빗키를 파라미터로 넘겨서 만듭니다. 그러면 160bit의 시그니쳐가 나오구요. 인증서를 받은 클라이언트는 SHA1 withRSA에 퍼블릭키를 파라미터로 넘겨서 시그니처가 같은지 보고 이게 신뢰할수 있는 인증서라는 것을 확인할 수 있습니다. 음냐..
          버전 관리
          egoing
          현재 버전
          선택 버전
          graphittie 자세히 보기