A configuração do JBoss Https com o certificado CER / P7b falha

Question

A minha pergunta é semelhante a esta: O Tomcat não consegue encontrar uma entrada de chave no keystore

Eu tenho um arquivo CER, que importei em um JKS usando o comando abaixo:

keytool -importcert -file codesign_Base64.cer -keystore imported_keystore.jks -alias my_alias

Então eu tenho a linha abaixo de configuração em standalone.xml para o jBoss.

<subsystem xmlns="urn:jboss:domain:web:1.1" native="false" default-virtual-server="default-host">
            <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="8443"/>
            <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true">
                <ssl name="ssl" key-alias="my_alias " password="change_this" certificate-key-file="C:\Programs\Siemens\JBoss7.1.0\domain\configuration\imported_keystore.jks " protocol="TLSv1" verify-client="false"/>
            </connector>
            <virtual-server name="default-host" enable-welcome-root="false">
                <alias name="localhost"/>
                <alias name="example.com"/>
            </virtual-server>
        </subsystem>

Com isso, quando tento iniciar o aplicativo, vejo as seguintes mensagens de erro nos arquivos de log do jBoss, que representam um erro desse tipo.

11:46:19,692 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Error initializing endpoint: java.io.IOException: Alias name mykey does not identify a key entry
    at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:517) [jbossweb-7.0.10.Final.jar:]
    at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:452) [jbossweb-7.0.10.Final.jar:]
    at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:168) [jbossweb-7.0.10.Final.jar:]
    at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:977) [jbossweb-7.0.10.Final.jar:]
    at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:190) [jbossweb-7.0.10.Final.jar:]
    at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.0.10.Final.jar:]
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:267) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]

Mas se eu explorar o conteúdo do armazenamento de chaves java, ainda verei a presença da chave apropriada.

C:\Programs\Siemens\JBoss7.1.0\domain\configuration>keytool -list -keystore C:\Programs\Siemens\JBoss7.1.0\domain\configuration\winstore.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

my_alias, Jun 23, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 8D:64:10:8B:F6:0D:1E:17:01:52:1C:97:8A:89:75:80:2D:2F:45:6B

Eu corri para o problema semelhante quando eu tentei com um certificado P7B também. A única coisa que funcionou até agora era se o certificado foi gerado manualmente - certificado selftsigned. E esta não é a estratégia de avançar para a organização, obviamente

Por favor, deixe-me saber o que pode estar faltando aqui. O post semelhante que eu tinha incluído acima parece estar insinuando em um cenário de apenas certificado e não-chave que eu não consigo relacionar.

Todos os ponteiros certamente ajudariam, já que eu postei isso em vários lugares e não estou tendo nenhuma resposta no momento.

Obrigado Pavan.

    

Answer 1

Não, o seu armazenamento de chaves NÃO contém uma chave privada. Veja onde diz trustedCertEntry ? Um certificado confiável NÃO é uma chave privada, é apenas um certificado e um certificado não é uma chave privada. Um servidor SSL / TLS requer uma chave privada e a cadeia de certificados correspondente; um certificado sozinho não pode ser usado para executar o protocolo, portanto, seu servidor não pode aceitar nenhuma conexão HTTPS e, portanto, qualquer navegador que tente se conectar com HTTPS (provavelmente após ser redirecionado de HTTPS) falhará. Um P7B não contém uma chave privada, embora possa conter vários certificados enquanto um CER normalmente contém apenas um. (Em contraste, um cliente geralmente precisa apenas do (s) certificado (s) 'raiz' da CA e não da chave privada, a menos que a opção 'autenticação do cliente' seja usada.

Você precisa de um privateKeyEntry que contenha a chave privada E uma cadeia de certificados para essa chave e seus nomes de host desejados . Existem duas maneiras (com um variante) para fazer isso para Java:

1: Use keytool para gerar uma nova chave privada (com certificado autoassinado fictício) em um JKS e crie uma CSR (Solicitação de Assinatura de Certificado, ou apenas Solicitação de Certificado) para ela. Envie o CSR e outras coisas, conforme necessário, como o pagamento a uma Autoridade de Certificação (CA) para obter um certificado adequado, geralmente acompanhado de pelo menos um certificado 'intermediário' ou 'intermediário' que pode ser necessário para os clientes confiarem no certificado. Use keytool para importar o certificado / cadeia para o mesmo JKS e entrada que já contém a chave privada (substituindo o certificado auto-assinado fictício); opcionalmente, você também pode importar o (s) certificado (s) da cadeia como entradas de confiança.

O método 1 é canônico e é descrito, geralmente de forma repetida, no site de cada fornecedor certificado que eu já vi, tanto CAs quanto revendedores; Eu não sei como você perdeu todos eles. Observe que essas descrições geralmente se referem ao Tomcat, o servidor da Web baseado em Java mais usado; o componente do servidor web Jboss, agora marcado como Wildfly, é na verdade uma bifurcação do Tomcat. Aqui estão os dois primeiros google me encontra:
* link
* link

2A: Use outras ferramentas (como Windows ou MacOS ou OpenSSL) para gerar uma chave privada e obter um certificado adequado, geralmente usando um CSR, de uma CA e incluindo sua cadeia. Conforme aplicável, exporte / converta / combine a cadeia privada e a cadeia de certificados em um arquivo PKCS12 (também chamado de PFX no Microsoft-land) e, provavelmente, use keytool -importkeystore para converter o PKCS12 em JKS. (No Java 8, em muitos casos, é possível usar um PKCS12 diretamente, sem convertê-lo em JKS, e espera-se que o Java 9 incentive isso.)

2B: Se você já tiver um certificado / cadeia gerado por chave privada e obtido com outras ferramentas, apenas coloque-os em um PKCS12 e provavelmente converta em JKS como acima.

Observe que algumas outras GUIs, como Microsoft, MacOS e Firefox, concentram-se no certificado: elas exibem um certificado confiável como apenas 'certificado' e uma combinação de chave privada + certificado como 'certificado com chave privada'. Mas a diferença ainda é vital; um servidor deve ter a chave privada e tentar usar um 'certificado sem chave privada' falhar. Java, em vez disso, tem diferentes tipos de entradas de keystore - embora, para alguns keystores, esses tipos não sejam armazenados diretamente.