글 싣는 순서
1. CTL Client 개요 및 설치
2. CTL Client 설정하기
3. 전화기를 보안모드로 설정하기
4. 외부 CA 서버에서 CUCM 인증서 받기
5. 외부 CA 서버에서 IP Phone 인증서 받기
6. 외부 CA 서버에서 CUBE 인증서 받기
7. CUCM과 CUBE간 TLS 연동
2017년 12월 재작성하였습니다. 불필요한 부분을 삭제합니다.
--------------------------------------------------------
테스트 중에 두 가지 구성의 문제가 발생하여 다시 작성하였습니다. ^^ 전에 이글을 보고 테스트하셨던 분들은 다시 시도해 보시기 바랍니다.
------------------------------------------------------------------------------
이제 3rd party 인증서가 탑재된 CUCM과 CUBE간에 TLS 및 SRTP 통신이 가능하도록 설정하겠습니다. 이 번글은 내용이 많지만 열심히 마무리 하겠습니다. 이 글에 앞서 TLS 및 SRTP에 대한 글을 "Cisco Secure IP Telephony의 이해"라는 연재에 먼저 올리는 것이 순서상 맞지만, 상황이 여의치 않아 이 글을 먼저 포스팅합니다.
이 글을 읽으시는 분들은 Cisco IOS기반의 VoIP 설정이 매우 친숙하다는 것을 가정하고 보안 설정에 관련된 부분만을 설명하겠습니다.
설정 순서
CUCM과 CUBE 간의 TLS 통신을 위해 다음과 같은 순서로 설정합니다.
- CUCM에서 CallManager 서비스의 인증서 다운로드
- CUBE에서 CallManager 서비스 인증서 주입
- CUBE에서 인증서 추출
- CUCM에서 CUBE 인증서 업로드
- CUBE 일반 설정 및 보안 설정
- CUCM에서 Trunk 설정 및 보안 설정
- 결과 확인을 위한 Debug
CUCM의 CallManager 서비스 인증서 다운로드
CUCM의 인증서(Certificate)는 아래 그림과 같이 "OS Admin >> Security >> Certificate Management"에 있습니다.
여러개의 인증서 파일이 있지만, CUCM에서 외부의 장비와 트렁크 연동을 위해 사용하는 서비스는 CallManager입니다. 아래 그림에서는 PEM 파일과 DER 파일 두가지가 있습니다만, IOS Gateway는 PEM 파일 형식만을 이용하므로 "CallManager.pem"을 클릭합니다.
아래 그림은 CallManager.pem 파일에 대한 상세 내용입니다. PEM 파일을 다운로드 하기 위해 "Download" 를 클릭합니다.
다운로드된 파일의 이름은 CallManager.pem 파일이며, PEM 파일의 내용을 복사하기 위해서는 TXT로 확장자를 변경하시면 됩니다.
CUBE에 CallManager 인증서 주입하기
CUBE는 CA 및 인증서에 관한 모든 정보는 트러스트포인트 단위로 관리합니다. 앞 장에서 RootCA 인증서를 위한 트러스트포인트와 동일한 방식으로 CCM-cert-02라는 트러스트포인트를 생성한 후에 인증서를 주입합니다.
- CUCM 인증서를 위한 트러스트포인트 생성
CUCM 인증서를 주입하기 위해 CCM-cert-02라는 트러스트포인트를 생성합니다. 항상 이름은 단순하고, 알기 쉽게 사용합니다.
VG_yohur(config)#crypto pki trustpoint CCM-cert-02
VG_yohur(ca-trustpoint)#enrollment terminal
VG_yohur(ca-trustpoint)#revocation-check none
VG_yohur(ca-trustpoint)#end - CUCM의 CallManager 서비스 인증서 주입
CCM-cert-02 트러스트포인트에 CUCM인증서를 Copy-and-Paste 합니다.
VG_yohur(config)#crypto pki authenticate CCM-cert-02
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIIEbDCCA1SgAwIBAgIDAJB6MA0GCSqGSIb3DQEBCwUAMFUxCzAJBgNVBAYTAktS
MQ0wCwYDVQQKDARLSUNBMRUwEwYDVQQLDAxBY2NyZWRpdGVkQ0ExIDAeBgNVBAMM
F1NpZ25HQVRFIERldmljZSBDQS0wMTAxMB4XDTEyMTEwODA1NTAxNVoXDTEzMTEw
(귀찮아서 중간 생략)
hazjR1HLxQiAI4za6GTejzx/lYvbOSXfnJ1MtPY8PVIdtaYkeIyqhoe0vgFvfiU4
HTlhkcJYtwIGezBggYst7B/Q+p6tULA3jjUSG46wFcw=
-----END CERTIFICATE-----
Trustpoint 'CCM-cert-02' is a subordinate CA.
but certificate is not a CA certificate.
Manual verification required
Certificate has the following attributes:
Fingerprint MD5: 7F8FF997 F31D4A50 1B0999C9 DF2E2B93
Fingerprint SHA1: 437D5782 34B7AD08 04C4E921 0DC3EAFC 25F11B57
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
VG_yohur(config)#
위에 CCM-cert-02 트러스트포인트가 Subordinate CA로 인식이 됩니다. 이미 앞장에서 rootca-01라는 트러스트포인트에 RootCA인증서를 주입하였습니다. CUCM의 인증서는 RootCA로 한 번 검증되었지만, 여전히 SubCA를 이용한 검증이 필요하다는 메세지가 표시되지만, 정상적으로 처리 되었음을 확인할 수 있습니다.
CUBE에서 기기인증서를 추출하여 CUCM에 업로드
CUCM의 CallManager 서비스 인증서를 CUBE에 주입하였으므로, CUBE의 기기인증서를 CUCM에 주입하합니다.
- CUBE의 기기 인증서 추출
앞장에서 생성한 sip-trunk-cert 트러스트포인트는 CUBE가 직접 생성한 키와 인증서를 함께 보유하고 있습니다.
VG_yohur(config)#crypto pki export sip-trunk-cert pem terminal
% CA certificate:
-----BEGIN CERTIFICATE-----
MIIEuzCCA6OgAwIBAgICJxEwDQYJKoZIhvcNAQELBQAwaDELMAkGA1UEBhMCS1Ix
DTALBgNVBAoMBEtJU0ExLjAsBgNVBAsMJUtvcmVhIENlcnRpZmljYXRpb24gQXV0
(귀차니즘으로 중간 생략 ^^)
6ZbrJiU+mkVz28cFp1iJJp+Ye7OyF9egEjmZ4hWbapmtFDnUiDm8a7Usu6nxMNv1
0y08VkcibZeIAPIptdEu
-----END CERTIFICATE-----
% General Purpose Certificate:
-----BEGIN CERTIFICATE-----
MIIEeDCCA2CgAwIBAgIDAJTsMA0GCSqGSIb3DQEBCwUAMFUxCzAJBgNVBAYTAktS
MQ0wCwYDVQQKDARLSUNBMRUwEwYDVQQLDAxBY2NyZWRpdGVkQ0ExIDAeBgNVBAMM
F1NpZ25HQVRFIERldmljZSBDQS0wMTAxMB4XDTEyMTEyMzA0MjEyOFoXDTEzMTEy
(중간 생략 ^^)
/tV4q90GuAIOjUNc43jz2xgSzmLuYBydS6yS/228q5BvwhoSuFZBKC1GW543scv+
BZihVgcs/a4AUHahQDXLLKA0QCUxmPFTKifAS1qxZO+uu/zIVNfJshjvKWo=
-----END CERTIFICATE-----
VG_yohur(config)# - 노트패드(Notepad)에 복사
CSR 생성시와는 달리 PEM 파일의 앞과 뒤 문자열이 포함되어 있으므로 그대로 복사하여 호스트네임.pem으로 저장합니다. 여기서 두 개의 인증서가 보이지만, 첫번째 "% CA certificate:"라고 되어 있는 부분을 복사합니다. - CUCM의 Certificate Management로 이동
CUCM의 Certificate Management에서 "Upload Certificate/Certificate Chain"을 클릭합니다. - CUBE의 PEM 파일 업로드
직접 생성한 CUBE의 PEM 파일을 선택한 후에 "Upload File"을 클릭합니다.
Status가 "Success"가 나오면 정상적으로 업로드 된 것입니다.
CUBE에서 TLS 설정 전의 기본 설정
VoIP 기본 설정에 대한 자세한 설명은 생략하지만, 기본 설정은 다음과 같습니다.
- VoIP를 위한 글로벌 설정
CUBE가 기본적인 VoIP 기능을 수행하기 위한 설정은 다음과 같습니다.
VG_yohur(config)#voice service voip
VG_yohur(conf-voi-serv)#ip address trusted list
VG_yohur(cfg-iptrust-list)#ipv4 10.72.86.0 255.255.255.0
VG_yohur(cfg-iptrust-list)#exit
VG_yohur(conf-voi-serv)#address-hiding
VG_yohur(conf-voi-serv)#mode border-element license capacity 225
VG_yohur(conf-voi-serv)#allow-connections sip to sip
VG_yohur(conf-voi-serv)#sip
VG_yohur(conf-serv-sip)#bind control source-interface GigabitEthernet0/0
VG_yohur(conf-serv-sip)#bind media source-interface GigabitEthernet0/0
VG_yohur(conf-serv-sip)#exit
15.0 이상 버전의 CUBE는 기본적으로 모든 VoIP 시그널링을 폐기합니다. 즉, deny all ACL이 걸려있다고 보면 됩니다. 여기서 ip address trusted list는 특정 ip address 대역이나 호스트에 대해서만 호를 처리하도록 되어 있습니다. 간혹, CUBE가 동작하지 않는다고 불평하시는 분들이 있는 데 이 명령어를 확인할 필요가 있습니다.
- Dial-peer 설정
Outbound Dial-peer를 설정합니다. CUCM으로 호를 보낼 때 사용합니다.
VG_yohur(config)#dial-peer voice 100 voip
VG_yohur(config-dial-peer)#session protocol sipv2
VG_yohur(config-dial-peer)#destination-pattern 1...
VG_yohur(config-dial-peer)#session target ipv4:10.72.86.74
VG_yohur(config-dial-peer)#no vad
VG_yohur(config-dial-peer)#dtmf-relay rtp-nte
VG_yohur(config-dial-peer)#codec g711ulaw
VG_yohur(config-dial-peer)#exit
Inbound Dial-peer를 설정합니다. CUCM으로 부터 들어오는 호를 받기 위한 것입니다. 항상 Call Leg는 Inbound와 Outbound 쌍으로 동작합니다.
VG_yohur(config)#dial-peer voice 100 voip
VG_yohur(config-dial-peer)#session protocol sipv2
VG_yohur(config-dial-peer)#incoming called .T
VG_yohur(config-dial-peer)#dtmf-relay rtp-nte
VG_yohur(config-dial-peer)#no vad
VG_yohur(config-dial-peer)#codec g711ulaw
VG_yohur(config-dial-peer)#exit
생각보다 설정은 단순합니다만, 쉽게 놓칠 수 있는 부분을 먼저 언급합니다.
- SIP는 GMT 기준 시간을 사용하지만, 라우터는 UTC 를 사용하므로 GMT로 설정
- 일반 SIP로 호를 시동하여 성공한 것을 확인하고 SRTP를 구성할 것
- SRTP를 이용할 경우 G.711과 G.729 코덱만을 지원함
- CUBE는 SRTP 호는 SRTP로 처리하고, RTP 호는 RTP로 처리하거나, SRTP만 처리하도록 설정 가능
- SRTP를 위해서는 Delay Offer를 사용할 것을 권고
CUBE에서 TLS 및 SRTP 설정을 시작합니다.
- Dial-peer에 TLS 활성화
각 CUBE와 통신하는 SIP Trunk마다 설정이 틀릴 수 있으므로 TLS 통신이 필요한 Dial-peer에 설정합니다.
VG_yohur(config)#dial-peer voice 100 voip
VG_yohur(config-dial-peer)#session transport tcp tls
VG_yohur(config-dial-peer)#session target ipv4:10.72.86.74:5061
VG_yohur(config-dial-peer)#exit
session target에서 포트 5061를 명기했습니다만, 꼭 필요한 명령어는 아닙니다.
Default 트러스트포인트(Trustpoint) 설정
CUBE로 들어오는 모든 TLS 연결에 기본적으로 사용할 트러스트포인트(Trustpoint)를 설정합니다. 아래의 sip-trunk-cert는 앞장에서 설정한 트러스트포인트이며, CUBE에서 생성한 sip-trust-key와 연동되어 있습니다. 따라서, 아래 명령어는 모든 TLS 통신에 sip-trunk-cert를 기본 트러스트포인트로 사용한다는 의미입니다.
VG_yohur(config)#sip-ua
VG_yohur(config-sip-ua)#crypto signaling default trustpoint sip-trunk-cert
VG_yohur(config-sip-ua)#end
특정 IP마다 사용할 트러스트 포인트가 틀릴 경우에는 아래와 같이 IP addres 대역이나 호스트를 지정할 수 있습니다.
crypto signaling remote-addr 10.72.86.0 255.255.255.0 trustpoint sip-trunk-cert
위의 명령어는 10.72.86.0/24 서브넷에서 들어오는 TLS 연결만 sip-trunk-cert를 이용하는 것을 의미합니다. crypto signaling 명령어에는 strict-cipher라는 옵션이 있는 데 이를 추가하면, TLS_RSA_WITH_AES_128_CBC_SHA 만을 이용한다는 것을 의미합니다.
- TLS Listener Port 설정 및 활성화
TLS를 위한 기본 TCP 포트는 5061이므로 이를 활성화합니다.
VG_yohur(config)#sip-ua
VG_yohur(config-sip-ua)#transport tcp tls
VG_yohur(config-sip-ua)#end
- SRTP 설정
CUBE에서 SRTP를 설정하는 방법은 글로벌에서 설정하는 방법과 특정 Dial-peer에서 설정하는 방법 두가지가 있으므로 둘 중에 하나만 설정해도 되고 모두해도 됩니다.
VG_yohur(config)#voice service voip
VG_yohur(conf-voi-serv)#srtp
VG_yohur(conf-voi-serv)#srtp fallback
VG_yohur(conf-voi-serv)#end
다음으로 Dial-peer에서 설정하는 방법입니다.
VG_yohur(config)#dial-peer voice 100 voip
VG_yohur(config-dial-peer)#srtp
VG_yohur(config-dial-peer)#srtp fallback
VG_yohur(config-dial-peer)#exit
특히, SRTP fallback 명령어는 TLS를 지원하지 않는 단말이 TLS Trunk를 이용하더라도 호를 중단시키지말고 진행시키라는 의미입니다. 즉, TLS는 TLS로 SIP는 SIP로 통신하도록 합니다. - SIPS 설정 (옵션 설정)
IOS기반 라우터는 TLS를 이용할 사용할 수 있습니다만, 상황에 따라 빼도 상관없습니다 .TLS를 이용하는 호는 모든 구간이 TLS를 이용하도록 활성화 되어있다고 가정할 경우 이용할 수 있습니다. 이 명령어도 글로벌 설정과 Dial-peer 설정 두가지가 있으므로 둘 다 설정해도 되고, 하나만 설정해도 됩니다.
VG_yohur(config)#voice service voip
VG_yohur(conf-voi-serv)#sip
VG_yohur(conf-serv-sip)#url sips
VG_yohur(conf-serv-sip)#end
다음으로 Dial-peer 설정입니다.
VG_yohur(config)#dial-peer voice 100 voip
VG_yohur(config-dial-peer)#voice-class sip url sips
VG_yohur(config-dial-peer)#exit
SIPS에 대한 자세한 사항은 "SIP의 이해"카테고리의 "SIP Security(상)(http://www.nexpert.net/276)"이라는 글을 참조하시기 바랍니다.
지금까지 설정한 내용을 Show run 으로 확인합니다.
!
voice service voip
ip address trusted list
ipv4 10.72.86.0 255.255.255.0
address-hiding
mode border-element license capacity 225
srtp fallback
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
bind control source-interface GigabitEthernet0/0
bind media source-interface GigabitEthernet0/0
url sips
early-offer forced
!
dial-peer voice 100 voip
destination-pattern 1...
session protocol sipv2
session target ipv4:10.72.86.74:5061
session transport tcp tls
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 200 voip
session protocol sipv2
session transport tcp tls
incoming called-number .T
dtmf-relay rtp-nte
codec g711ulaw
!
sip-ua
crypto signaling default trustpoint sip-trunk-cert
!
CUCM에서 SIP Trunk SecurityProfile 설정하기
지금부터 CUCM에서 필요로 하는 설정을 살펴보겠습니다. SIP 관련 보안 설정은 모두 Security Profile을 이용하여 진행합니다. CUCM Admin 페이지에서 System >> Security >> SIP Trunk Security Profile"로 이동 합니다.
아래 그림과 같이 CUCM은 두 개의 기본 SIP Trunk Security Profile을 보유하고 있습니다. Non Secure SIP Trunk Profile을 복사하여 새로운 프로파일을 생성하겠습니다.
아래 그림은 CUBE를 위한 Security Profile을 만드는 과정입니다. 각각의 항목들은 쉽게 값을 넣을 수 있을 것입니다만, X.509 subject Name은 단순하게 상대방 X.509 인증서의 Subject Name의 CN이름입니다. 예를 들면, 현재 구성 중인 SIP Trunk Security Profile은 CUBE와 통신을 위한 것이므로 CUBE의 인증서 (Certificate) 생성 시에 만들었던 Subject Name의 CN= 이하의 값을 넣으면 됩니다.
CUCM에서 SIP Trunk 설정하기
Trunk 설정을 위해 "Device >> Trunk"로 이동한 후에 "Add New"를 클릭하여 새로운 SIP Trunk를 생성합니다.
아래 그림은 SIP Trunk의 Device Infomation란입니다. Device Name은 빈공간(Space)없이 이름을 생성하고, "SRTP Allowed"를 선택합니다.
아래 그림은 SIP Trunk의 SIP Information 란입니다. Destination에 CUBE의 IP address를 기입하고, SIP Trunk Security Profile 파라미터에 앞에서 생성한 프로파일을 선택합니다. 그리고 "Save" 를 선택합니다.
아래 그림에서는 생성된 SIP Trunk를 확인할 수 있습니다.
CUCM에서 Route Pattern 설정하기
CUCM에서 Trunk Security Profile을 생성하여 SIP Trunk에 연동합니다. SIP Trunk는 Route Pattern에 연계해야 전화기에서 전화번호를 누르면 호가 CUBE 로 전달되는 구조입니다.
아래 그림과 같이 "Call Routing >> Rote/Hunt >> Route Pattern"으로 이동하여 "Add New"를 선택합니다.
Route Pattern과 Gateway에서 이미 설정한 SIP Trunk를 선택합니다.
인증서 및 TLS가 정상적인지를 확인
CUCM과 CUBE에서 모든 설정이 끝났습니다. CUBE에서 확인하는 명령어는 다음과 같습니다.
CCM-cert-02의 정상여부 확인
VG_yohur# show crypto pki certificates verbose CCM-cert-02
CA Certificate
Status: Available
Version: 3
Certificate Serial Number (hex): 00907A
Certificate Usage: General Purpose
Issuer:
(이하 중략)
Associated Trustpoints: CCM-cert-02
CUCM의 인증서가 정상적으로 동작하는 것을 확인할 수 있습니다.
- 실제 TLS 연결확인
몇 번 전화를 걸어서 호가 성공한 지를 확인한 후에는 다음과 같은 정보를 얻을 수 있습니다.
VG_yohur#sh sip-ua connections tcp tls detail
Total active connections : 1
No. of send failures : 0
No. of remote closures : 2
No. of conn. failures : 0
No. of inactive conn. ageouts : 0
TLS client handshake failures : 0
TLS server handshake failures : 16
---------Printing Detailed Connection Report---------
Note:
** Tuples with no matching socket entry
- Do 'clear sip <tcp[tls]/udp> conn t ipv4:<addr>:<port>'
to overcome this error condition
++ Tuples with mismatched address/port entry
- Do 'clear sip <tcp[tls]/udp> conn t ipv4:<addr>:<port> id <connid>'
to overcome this error condition
Remote-Agent:10.72.86.74, Connections-Count:1
Remote-Port Conn-Id Conn-State WriteQ-Size Local-Address
=========== ======= =========== =========== ===========
48800 3 Established 0 10.72.86.86
-------------- SIP Transport Layer Listen Sockets ---------------
Conn-Id Local-Address
=========== =============================
2 [10.72.86.86]:5061
VG_yohur#
위의 내용에서 현재 진행중인 호가 1개가 있으며, 정상적으로 Established 가 되었다는 의미입니다. 실패가 16개가 있는 것은 제가 최초에 좀 실수를 해서 표시된 것입니다.
TLS Debug로 정상 동작 확인
TLS를 위한 Debug 명령어는 다음과 같습니다.
VG_yohur#debug ssl openssl errors
TLS errors debugging is on
VG_yohur#debug ssl openssl msg
TLS msg debugging is on
VG_yohur#debug ssl openssl states
TLS state debugging is on
이제 IP Phone에서 전화를 걸어서 PSTN으로 호를 보내는 과정이지만, TLS 부분만을 확인합니다. 내용이 많은 것은 중략합니다. 실제 TLS 핸드쉐이크와 같은 자세한 사항은 "Cisco Secure IP Telephony의 이해" 연재에서 다루겠습니다.
VG_yohur#terminal monitor
*Nov 23 12:42:12.660: opssl_SetPKIInfo entry
*Nov 23 12:42:12.664: opssl_SetPKIInfo done.
*Nov 23 12:42:12.664: Handshake start: before/accept initialization
*Nov 23 12:42:12.664: SSL_accept:before/accept initialization
*Nov 23 12:42:12.664: <<< TLS 1.0 Handshake [length 0035], ClientHello
*Nov 23 12:42:12.664: 01 00 00 31 03 01 50 AF 64 1E 2F DA 13 4B B2 72
*Nov 23 12:42:12.664: 00 8D 9B 41 3B 11 35 9E 43 42 8E 4B 1D 77 01 B4
*Nov 23 12:42:12.664: FB A4 25 CC 98 D3 00 00 04 00 2F 00 FF 01 00 00
*Nov 23 12:42:12.664: 04 00 23 00 00
*Nov 23 12:42:12.664:
*Nov 23 12:42:12.664: SSL_accept:SSLv3 read client hello A
--> CUBE는 CUCM으로 부터 TLS Hello 메세지를 수신합니다.
*Nov 23 12:42:12.664: >>> TLS 1.0 Handshake [length 0051], ServerHello
*Nov 23 12:42:12.664: 02 00 00 4D 03 01 50 AF 6F 24 B5 80 06 4C E3 2A
*Nov 23 12:42:12.664: D8 3D F9 1B 8C 6E 66 BC 7E 5C 20 75 3E 98 A4 EC
*Nov 23 12:42:12.664: CB 4E 3D B1 D1 F7 20 ED D3 0A 75 43 45 04 9D 94
*Nov 23 12:42:12.664: DF FE 13 40 06 B4 AE DB EF 7C 5E D6 A3 CE DD 93
*Nov 23 12:42:12.664: 00 26 B9 97 EF 40 92 00 2F 00 00 05 FF 01 00 01
*Nov 23 12:42:12.664: 00
*Nov 23 12:42:12.664:
*Nov 23 12:42:12.664: SSL_accept:SSLv3 write server hello A
--> CUBE는 CUCM에게 TLS Hello 메세지를 송신합니다.
*Nov 23 12:42:12.664: >>> TLS 1.0 Handshake [length 0948], Certificate
*Nov 23 12:42:12.664: 0B 00 09 44 00 09 41 00 04 7C 30 82 04 78 30 82
*Nov 23 12:42:12.664: 03 60 A0 03 02 01 02 02 03 00 94 EC 30 0D 06 09
*Nov 23 12:42:12.684: 45 73 DB C7 05 A7 58 89 26 9F 98 7B B3 B2 17 D7
(중략)
*Nov 23 12:42:12.684: A0 12 39 99 E2 15 9B 6A 99 AD 14 39 D4 88 39 BC
*Nov 23 12:42:12.684: 6B B5 2C BB A9 F1 30 DB F5 D3 2D 3C 56 47 22 6D
*Nov 23 12:42:12.684: 97 88 00 F2 29 B5 D1 2E
*Nov 23 12:42:12.684:
*Nov 23 12:42:12.684: SSL_accept:SSLv3 write certificate A
--> CUBE는 CUCM에게 인증서를 전송합니다.
*Nov 23 12:42:12.684: >>> TLS 1.0 Handshake [length 000C], CertificateRequest
*Nov 23 12:42:12.684: 0D 00 00 04 01 01 00 00 0E 00 00 00
*Nov 23 12:42:12.684:
*Nov 23 12:42:12.684: SSL_accept:SSLv3 write certificate request A
*Nov 23 12:42:13.684: SSL_accept:SSLv3 flush data
--> CUBE는 CUCM에게 인증서를 요청합니다.
*Nov 23 12:42:13.688: <<< TLS 1.0 Handshake [length 0CC0], Certificate
*Nov 23 12:42:13.688: 0B 00 0C BC 00 0C B9 00 04 70 30 82 04 6C 30 82
*Nov 23 12:42:13.688: 03 54 A0 03 02 01 02 02 03 00 90 7A 30 0D 06 09
(중략)
*Nov 23 12:42:13.712: 6C 3D 0A 00 34 8E 84 21 0D 88 05 E5 4F 49 3B D0
*Nov 23 12:42:13.712: 1A AC C6 00 D0 04 1A D4 0C A3 18 ED 9C 8A 81 01
*Nov 23 12:42:13.712:
*Nov 23 12:42:13.716: SSL_accept:SSLv3 read client certificate A
--> CUBE는 CUCM으로 부터 인증서를 수신합니다.
*Nov 23 12:42:13.716: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange
*Nov 23 12:42:13.716: 10 00 00 82 00 80 A8 F8 C5 00 7E C2 3B 5F C9 41
*Nov 23 12:42:13.716: 7E 36 91 0C 4D 52 59 4F 8C BC 79 1C 36 22 FB DE
(중략)
*Nov 23 12:42:13.716: A4 E8 F1 6E B1 02 E3 0C 52 D1 9E 9E CB B8 FA C6
*Nov 23 12:42:13.716: 40 8B 65 08 A7 62
*Nov 23 12:42:13.716:
*Nov 23 12:42:13.752: SSL_accept:SSLv3 read client key exchange A
--> CUBE는 CUCM으로 부터 SRTP가 사용할 세션키를 받습니다.
*Nov 23 12:42:13.752: <<< TLS 1.0 Handshake [length 0086], CertificateVerify
*Nov 23 12:42:13.752: 0F 00 00 82 00 80 6A A9 0F D7 FA 96 4C 0D B0 96
*Nov 23 12:42:13.752: C2 FF FF 6A 88 71 A0 21 6F 73 87 D4 70 AB 0B B4
(중략)
*Nov 23 12:42:13.752: EC 1E 78 48 54 5B 20 7B B4 B7 F5 C8 62 D7 D2 DB
*Nov 23 12:42:13.752: E3 35 12 01 D4 09
*Nov 23 12:42:13.752:
*Nov 23 12:42:13.752: SSL_accept:SSLv3 read certificate verify A
--> CUBE는 CUCM으로 부터 세션키를 검증받습니다.
*Nov 23 12:42:13.752: <<< TLS 1.0 ChangeCipherSpec [length 0001]
*Nov 23 12:42:13.752: 01
*Nov 23 12:42:13.752:
--> CUCM은 암호화에 대한 방식을 변경합니다.
*Nov 23 12:42:13.756: <<< TLS 1.0 Handshake [length 0010], Finished
*Nov 23 12:42:13.756: 14 00 00 0C CB C4 77 E3 82 81 EB B5 22 FE 0F BF
*Nov 23 12:42:13.756:
*Nov 23 12:42:13.756: SSL_accept:SSLv3 read finished A
--> CUCM 은 TLS 세션을 종료합니다.
*Nov 23 12:42:13.756: >>> TLS 1.0 ChangeCipherSpec [length 0001]
*Nov 23 12:42:13.756: 01
*Nov 23 12:42:13.756:
*Nov 23 12:42:13.756: SSL_accept:SSLv3 write change cipher spec A
--> CUBE는 암호화 방식을 변경함을 통보합니다.
*Nov 23 12:42:13.756: >>> TLS 1.0 Handshake [length 0010], Finished
*Nov 23 12:42:13.756: 14 00 00 0C 82 91 18 23 5E E7 81 18 DD E3 58 D3
*Nov 23 12:42:13.756:
*Nov 23 12:42:13.756: SSL_accept:SSLv3 write finished A
*Nov 23 12:42:13.756: SSL_accept:SSLv3 flush data
--> CUBE도 TLS 세션을 종료합니다.
*Nov 23 12:42:13.756: Handshake done: SSL negotiation finished successfully
VG_yohur#
정말 긴 연재를 마무리해가고 있습니다. 요즘 Secure IPT를 설정하는 사이트가 점점 늘어나고 있습니다. 일반적으로 시스코의 Self-signed Certificate를 사용하는 것이 훨씬 편리하지만, External CA를 사용해야 할 경우에 많은 어려움이 있습니다. 이 연재가 External CA와 연결할 경우에 도움이 되길 기대합니다.
----------------- --------------------------------------------------------
라인하트 (CCIEV #18487)
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/ucwana (라인하트의 트위터 )
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스)
정리하고 보니 나도 디지털 네이티브 _____________________________________________________
