https://www.ibm.com/support/knowledgecenter/ko/SSZH4A_6.2.0/com.ibm.worklight.installconfig.doc/admin/c_ssl_config.html
알려진 공공 인증 기관(CA)에서 서명하지 않은 인증서로 Worklight® 서버와 클라이언트 간의 SSL 작업을 작성할 경우 문제가 발생할 수 있습니다. 각 모바일 플랫폼에는 고유의 특징이 있으며 상황에 따라 TLS(Transport Layer Security) 표준의 상이한 부분에 중점을 두고 실행합니다.
다음 권장사항은 주로 iOS와 Android 환경에 중점을 둡니다. X.509 인증서에 대한 지원은 IBM® Worklight Foundation가 아닌 개별 플랫폼에서 제공됩니다. X.509 인증서의 특정 요구사항에 대한 자세한 정보는 각 모바일 플랫폼의 문서를 참조하십시오.
사용 중인 애플리케이션에서 SSL 관련 문제 때문에 Worklight Server에 액세스하기 어려운 경우 잘못된 서버 인증서가 원인일 수 있습니다. 다른 원인으로는 클라이언트가 서버를 신뢰하도록 제대로 구성되지 않았을 수 있습니다. SSL 핸드쉐이크가 실패하는 기타 다양한 이유가 있을 수 있지만 여기서 다 다루지는 않았습니다. 경우에 따라서는 지나칠 수 있는 가장 기본적인 문제점을 해결할 수 있도록 일부 힌트와 팁이 제공되어 있습니다. 이러한 문제점은 모바일 월드와 X.509 인증서를 처리하는 경우에 중요합니다.
기본 개념
- 인증 기관(CA)
- 인증서를 발행하는 엔티티입니다. CA는 기타 인증서 또는 기타 CA 인증서(중개 CA 인증서)를 발행(서명)할 수 있습니다.
PKI(공개 키 인프라)에서는 계층 구조 신뢰 체인을 통해 인증서를 검증합니다. 이 트리의 최상위 인증서는 루트 CA 인증서입니다.
공용 인터넷 CA로부터 인증서를 구매할 수 있으며, 자체 소유의 개인용(로컬) CA를 운용하여 사용자 및 애플리케이션에 대한 개인용 인증서를 발행할 수 있습니다. CA는 클라이언트가 충분히 신뢰하는 기관을 의미합니다. 대부분의 상용 CA는 대부분의 웹 브라우저 및 모바일 플랫폼에서 자동으로 신뢰하는 인증서를 발행합니다. 개인용 CA를 사용함은 루트 CA가 서명한 인증서를 클라이언트가 신뢰함을 보장할 수 있도록 특정 조치를 취해야 함을 의미합니다.
인증서는 모바일 플랫폼, 개인용 CA에 의해 또는 자체적으로 알려진 다수의 공용 CA 중 하나로 서명(발행)될 수 있습니다.
- 자체 서명 인증서
- 자체적으로 서명되며 유효성을 검증해주는 CA가 없는 인증서입니다.
대부분의 모바일 플랫폼에서 자체 서명된 인증서의 사용을 지원하지 않으므로 이를 사용하지 않도록 권장합니다.
- 자체 서명 CA
- 자체 서명된 CA입니다. 이는 인증서인 동시에 CA입니다. 트리의 최상위 인증서이므로 이를 루트 CA라고도 합니다.
사설 CA가 서명한 인증서는 보안상 외부 Internet-facing 서버의 프로덕션 용도로는 권장되지 않습니다. 그러나 비용이 저렴하므로 개발 및 테스트 환경에서 선호할 수 있습니다. 또한 배치가 쉽고 빠르므로 내부(인트라넷) 서버용으로 적합합니다.
다른 모바일 플랫폼에서 지원하는 인증서 유형
| 플랫폼 | 자체 서명된 인증서 | 자체 서명된 CA 인증서 | 개인용 CA에서 서명한 인증서 | 공용 CA에서 서명한 인증서 |
|---|---|---|---|---|
| iOS | - | ✔ | ✔ | ✔ |
| Android | - | ✔ | ✔ | ✔ |
| Windows Phone | - | ✔ | ✔ | ✔ |
| Blackberry | - | ✔ | ✔ | ✔ |
자체 서명된 인증서 대 자체 서명된 CA
모바일 플랫폼(예: Android 및 iOS)에서는 디바이스의 신뢰 저장소에 해당 유형의 인증서 설치를 허용하지 않으므로 모바일 고객과 거래 중인 경우에는 자체 서명된 인증서를 사용하지 않도록 권장합니다. 이 제한사항으로 인해 클라이언트는 서버의 인증서를 신뢰할 수 없습니다. 자체 서명된 인증서가 종종 개발 및 테스트 용도로 권장됨에도 불구하고, 이는 클라이언트가 모바일 디바이스인 경우에는 작동되지 않습니다.
이에 대한 대안은 자체 서명된 인증서 대신에 자체 서명된 CA 인증서를 사용하는 것입니다. 자체 서명된 CA 인증서는 가져오기도 쉬우며 비용 효과적인 솔루션이기도 합니다.
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out cerficate.crt -reqexts v3_req -extensions v3_ca
openssl x509 -in certificate.crt -text -noout
클라이언트에 신뢰 확립
모바일 브라우저에서 웹 페이지를 열거나 HTTPS 포트에서 Worklight Server에 직접 연결하는 경우에는 클라이언트가 SSL 핸드쉐이크의 서버 인증서를 수신합니다. 그리고 클라이언트는 알려진 신뢰 CA의 자체 목록에 대해 서버 인증서를 평가하여 신뢰를 구축합니다. 각각의 모바일 플랫폼에는 SSL 인증서의 발행에 대해 신뢰할 수 있다고 여겨지는 신뢰 CA의 세트가 포함됩니다. 신뢰는 디바이스에서 이미 신뢰하는 CA가 사용자의 서버 인증서에 서명한 경우에 구축됩니다. 신뢰가 구축된 후에는 SSL 핸드쉐이크에 성공하며 브라우저에서 웹 페이지를 열거나 서버에 직접 연결할 수 있습니다.
그러나 서버에서 클라이언트에 알려지지 않은 CA가 서명한 인증서를 사용하면 신뢰를 구축할 수 없으며 SSL 핸드쉐이크에 실패합니다. 클라이언트 디바이스가 서버의 인증서를 신뢰하도록 보장하려면, 클라이언트 디바이스에 신뢰 앵커 인증서(루트 CA)를 설치해야 합니다.
iOS의 경우에는 iOS에 루트 CA 설치를 참조하십시오.
Android의 경우에는 Android에 루트 CA 설치를 참조하십시오.
Windows Phone의 경우에는 Windows Phone에 루트 CA 설치를 참조하십시오.
Android 구성
android:debuggable="true"
프로덕션 환경에서는 이 플래그를 사용하지 않는 것이 좋습니다. 이는 클라이언트 디바이스가 신뢰하는 CA에서 서명한 인증서로 서버를 올바르게 구성한 경우에는 필요하지 않습니다.
인증서 체인 처리
자체적으로 서명하지 않은 서버 인증서를 사용 중인 경우에는 서버가 전체 인증서 체인을 클라이언트에 전송하는지 확인해야 합니다.
클라이언트에서 인증서 경로를 유효성 검증하려면 전체 인증서 체인에 대한 액세스 권한이 필요합니다. 클라이언트에 중개 인증서를 포함하여 전체 인증서 체인에 대한 액세스 권한이 있는지 확인하려면 체인의 모든 인증서가 서버측 키 저장소 파일에 있는지 확인하십시오.
WebSphere® Application Server Liberty 프로파일의 경우에는 인증서 체인을 사용하도록 키 저장소 및 Liberty 프로파일 구성 업데이트를 참조하십시오.
인증서 확장기능 처리
RFC 5280(및 이전)은 인증서에 대한 추가 정보를 제공하는 다수의 인증서 확장기능을 정의합니다. 인증서 확장기능은 원래 X.509 인증서 정보 표준을 확장하는 수단을 제공합니다.
확장기능이 X.509 인증서에 지정되어 있는 경우, 확장기능은 해당 기능이 중요한 또는 사소한 확장기능인지 여부를 지정해야 합니다. 클라이언트가 처리할 수 없거나 클라이언트가 인식하지 않는 중요한 확장기능이 있는 인증서를 처리 중인 클라이언트는 해당 인증서를 거부해야 합니다. 인식되지 않는 경우, 사소한 확장기능은 무시될 수 있습니다.
모든 모바일 플랫폼이 동일한 방식으로 특정 인증서 확장기능을 인식하거나 처리하지는 않습니다. 이러한 이유 때문에 사용자는 가급적 최대한으로 RFC를 따라야 합니다. 모든 대상 모바일 플랫폼이 예상한 대로 처리하는지 알지 못하는 경우에는 인증서 확장기능을 사용하지 마십시오.
CRL 지원
사용 중인 인증서에서 인증서 폐기 목록(CRL)을 지원하면 CRL URL이 올바르고 액세스 가능한지 확인하십시오. 그렇지 않으면 인증서 체인 유효성 검증에 실패합니다.
서버 인증서 검증 도구
인증서 경로 유효성 검증 문제점을 디버그하려면 openssl s_client 명령행 도구를 사용하십시오. 이 도구는 SSL 문제 해결에 필요한 적합한 진단 정보를 생성합니다.
openssl s_client -CApath $HOME/CAdir -connect hostname:port
openssl x509 -in certificate.crt -text -noout
신뢰할 수 있는 인증 기관이 서명하지 않은 서버 인증서의 문제점 해결
| 문제점 | 수행할 조치 |
|---|---|
iOS에서 루트 CA를 설치할 수 없습니다. 인증서는 설치되지만 설치 이후에 iOS에서 해당 인증서를 신뢰할 수 없음을 표시합니다. | 인증서가 인증 기관으로서 식별되지 않습니다. 인증서가 특정 확장기능을 지정하는지 확인하십시오.
자세한 정보는 자체 서명된 인증서 대 자체 서명된 CA을 참조하십시오. 인증서가 PEM 형식인지 확인하십시오. 인증서에 .crt 파일 확장자가 있는지 확인하십시오. |
Android에서 루트 CA를 설치할 수 없습니다. 설치 이후에 인증서가 시스템의 신뢰할 수 있는 신임 정보에 표시되지 않습니다. | 인증서가 X.509 버전 1 인증서이거나 다음의 인증서 확장기능이 없습니다.
자세한 정보는 자체 서명된 인증서 대 자체 서명된 CA을 참조하십시오. 인증서가 PEM 또는 DER 형식인지 확인하십시오. 인증서에 .crt 파일 확장자가 있는지 확인하십시오. |
| "errorCode":"UNRESPONSIVE_HOST","errorMsg":"서비스를 현재 사용할 수 없습니다." | 이 오류는 일반적으로 SSL 핸드쉐이크 장애를 표시합니다. 클라이언트가 서버 인증서의 신뢰를 구축할 수 없습니다.
서버 인증서가 올바르지 않습니다.
|
SSL이 Android에서는 작동하지만 iOS에서는 작동하지 않습니다. | Android가 debuggable 모드인 경우, Cordova는 대부분의 SSL 오류를 무시합니다. 이 동작은 작업이 진행 중이라는 느낌을 줍니다. APK가 서명되지 않았거나 명시적으로 Manifest의 모드로 설정된 경우에 Android는 debuggable 모드에 있습니다. Android Manifest 파일에서 debuggable 플래그가 false로 설정되어 있는지(debuggable:false) 확인하거나 APK에 서명하십시오. 이를 debuggable 모드로 설정하는 Manifest의 명시적 선언이 없는지 확인하십시오. Android 구성에 대한 자세한 정보는 Android 구성의 내용을 참조하십시오. |
| 설치 이후에 인증서가 시스템의 신뢰 신임 정보 또는 신뢰 저장소에 나타나지 않습니다. | 브라우저에서 직접 보호된 자원에 액세스하여 서버 인증서가 설치되지 않았는지 확인하십시오. 이 조치는 브라우저 공간으로만 인증서를 가져오며 디바이스 시스템 신뢰 저장소로는 가져오지 않습니다. 유일한 요구사항은 루트 CA의 설치입니다. 디바이스에 루트 CA를 올바르게 설치하는 방법에 대한 자세한 정보는 다음 주제를 참조하십시오. iOS의 경우에는 iOS에 루트 CA 설치를 참조하십시오. Android의 경우에는 Android에 루트 CA 설치를 참조하십시오. |