서명되지 않은 애플릿이 CA 인증 SSL 서버와 통신 할 수 있습니까?

Question

스트리밍 서버와 통신하는 서명되지 않은 애플릿이 있습니다 (HTTPS가 아닌 소켓 소켓이지만 중요한 것은 아닙니다). 보통의 TCP/IP를 사용하면 문제가 없지만 평소에 SSL을 사용하려고하면 :

SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault(); 
SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(host, port); 

// initiate the handshake (blocks) 
sslsocket.getSession(); 

핸드 셰이 킹 중에 예외가 발생합니다. 개발과 테스트를 쉽게하기 위해 애플리케이션으로 실행 중이지만 여전히 예외가 발생합니다.

키 스토어에 인증서를 추가하면이 문제를 해결할 수 있지만 수동 개입없이 수천 개의 클라이언트에 배포하려고합니다.

웹을 며칠 동안 검색했습니다 - 모든 언급은 "인증서를 키 스토어에 추가"로 끝나지만 일반적으로 자체 서명 인증서와 관련됩니다. 이 경우에는 pukka 인증서 (시험판이지만 Java의 CA 목록에 있습니다 - 구체적으로 digicert)가 있습니다. 간단히 말해, 애플릿이 인증서를 키 스토어에 추가하지 않고도 CA 서명 인증서가있는 서버에 SSL을 말할 수 있습니까?

애플릿이 포함 된 JAR 내에 인증서 또는 키 저장소를 추가하는 것이 하나의 아이디어입니다. 서명되지 않은 애플릿이 그러한 인증서/키 스토어를 읽고 설치할 수 있습니까?

덕분에,

Answer 1

I "는 CA가 인증서에 서명 한 서버에 애플릿 토크 SSL"을 배포하는 상황에서되지 않았습니다,하지만 자바 Webstart를 응용 프로그램을 배포하는 비슷한 상황에왔다 샌드 박스에서 작업을 수행 할 수 있도록 서명해야합니다 (클라이언트 시스템의 파일 쓰기 및 읽기). 우리는 수십 명의 고객에게 배포해야했습니다.

올바르게 기억하면 절차가 어렵지 않습니다 (Google을 사용하면됩니다). 자신의 인증서를 만들 수 있지만 "알 수없는 출처"에서 서명 한 인증서에 대한 경고로 짜증을받는 사람도 있습니다.

잘 알려진 CA 기관 (예 : VeriSign 또는 Thawte)을 사용하는 것이 좋습니다. CA는 같은 것을 제공하더라도 가격면에서 매우 다양합니다. 즉 인증서입니다.

Verisign은 모든 CA 중에서 가장 잘 알려져 있으며 가장 비쌉니다. 연락을하면 프로세스를 안내하고 우수한 기술 지원을 제공합니다. 예를 들어, 암호화의 적절한 강도, 애플릿, 서버 등에 설치하는 방법에 대한 정보를 제공합니다. 또한 사이트에 로고를 넣을 수 있으며 티셔츠, 멋진 달력 및 기타 케이크를 보낼 수 있습니다 매년 :

Thawte와 같은 다른 공급자는 Verisign보다 훨씬 저렴합니다 (때로는 절반 이하). 나는 그들과 함께 일하지 않았기 때문에 그들의 봉사의 질이 무엇인지 말할 수 없다.

그건 그렇고 도메인과 하위 도메인이 인증서와 일치한다는 것은 매우 중요합니다. 도메인 www.mydomain.com에 대한 인증서를 요청했고 www2.mydomain.com에서 애플릿을로드하려고 시도하면 작동하지 않습니다. Verisign 및 다른 회사는 여러 개의 또는 무제한 서브 도메인에 특별한 가격을 제공합니다.

이 정보가 도움이되기를 바랍니다. 더는 사람이 중간에 가로 채려고 - 인증서와 SSL을 사용하는 아이디어는 (이 경우 애플릿) 내가 얘기를 누가 확신 할 수 없다,

루이스

Answer 2

을주의하십시오 나를.이를 위해서는 이미 신뢰하는 사람의 인증서가 있어야하며 누가 서버의 신원을 인증하는지 다시 확인해야합니다.

이 인증서는 Java 플러그인 (또는 JRE 또는 사용자 키 저장소)의 키 저장소에 있거나, SSL 엔진에 신뢰할 수있는 키가있는 자체 키 저장소를 제공 할 수 있습니다 (예 : my project의 원본 사본).) 독일어 의견 :

public class SSLHelper 
{ 

    ... 

    /** 
    * Initialisiert die Client-SocketFactory. 
    */ 
    private void initClient() 
     throws KeyStoreException, NoSuchAlgorithmException, 
       KeyManagementException, IOException, 
       CertificateException 
    { 
     // die Namen für getInstance() sind aus diesem Dokument: 
     // http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html 
     KeyStore keystore = KeyStore.getInstance("jks"); 
     keystore.load(SSLHelper.class 
         .getResourceAsStream("client-keystore.jks"), 
         null); 
     TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX"); 
     tmf.init(keystore); 
     SSLContext kontext = SSLContext.getInstance("TLS"); 
     kontext.init(null, tmf.getTrustManagers(), null); 

     clientFactory = kontext.getSocketFactory(); 
    } 
} 

이 방법, SSL 클라이언트는 주어진 키 스토어의 인증서와 함께 전송 된 인증서를 비교할 수 있으며, 일부가 일치하는 경우, 연결이 허용됩니다.

물론 이것은 기본 문제 만 이동시킵니다. 이제 애플릿 (예 : 서버 키의 서명 된 키 스토어)을 확인해야합니다. 항아리)는 모든 사람에게 이미 올바른 인증서가 설치되어 있는지 확인하는 대신 실행중인 중간 관리자 (man-in-the-the-middle)에 의해 수정되지 않습니다. 따라서 최대 보안을 위해 HTTPS (및 HTTPS 페이지)로만 애플릿을 제공해야합니다.