Назад | Перейти на главную страницу

Ошибка конфигурации JBoss Https с сертификатом CER / P7b

Мой вопрос похож на этот: Tomcat не может найти ключевую запись в хранилище ключей

У меня есть файл CER, который я импортировал в JKS с помощью следующей команды:

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

Затем у меня есть приведенная ниже строка конфигурации в standalone.xml для 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>

При этом, когда я пытаюсь запустить приложение, я вижу следующие сообщения об ошибках в файлах журнала jBoss, которые отображают ошибку такого рода.

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]

Но если я исследую содержимое хранилища ключей Java, я все равно смогу увидеть наличие соответствующего ключа.

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

Я столкнулся с аналогичной проблемой, когда пытался использовать сертификат P7B. Единственное, что до сих пор работало, это то, что сертификат создавался вручную - самоподписанный сертификат. И это явно не стратегия развития организации.

Пожалуйста, дайте мне знать, чего здесь может не хватать. Подобный пост, который я включил выше, похоже, намекает на сценарий «только сертификат, а не ключ», который я не могу связать.

Любые указатели, безусловно, помогут, поскольку я разместил это в нескольких местах, и на данный момент у меня нет никаких ответов.

Спасибо, Паван.

Нет, ваше хранилище ключей НЕ содержит закрытого ключа. Смотрите, где это говорит trustedCertEntry? Доверенный сертификат НЕ является частным ключом, это всего лишь сертификат, а сертификат не является частным ключом. Серверу SSL / TLS требуется закрытый ключ И соответствующая цепочка сертификатов; только сертификат не может использоваться для выполнения протокола, поэтому ваш сервер не может принимать какие-либо HTTPS-соединения, и, следовательно, любой браузер, который пытается подключиться по HTTPS (вероятно, после перенаправления с HTTPS), терпит неудачу. P7B также не содержит закрытого ключа, хотя может содержать несколько сертификатов, тогда как CER обычно содержит только один. (Напротив, клиент обычно требуется только «корневой» сертификат (-ы) ЦС и никакой закрытый ключ, если только не используется довольно редкая опция «аутентификации клиента».)

Ты нуждаешься в privateKeyEntry который содержит как закрытый ключ, так и цепочку сертификатов для этого ключа и желаемого имени (а) хоста. Есть два способа (с вариантом) сделать это для Java:

1: Использование keytool чтобы сгенерировать новый закрытый ключ (с фиктивным самоподписанным сертификатом) в JKS и создать для него CSR (запрос на подпись сертификата или просто Cert [ificate] Req [uest]). Отправьте CSR и другие необходимые вещи, такие как платеж в центр сертификации (CA) для получения подходящего сертификата, обычно вместе с хотя бы одним «цепным» или «промежуточным» сертификатом, который может потребоваться клиентам, чтобы доверять сертификату. Использовать keytool импортировать сертификат / цепочку в тот же JKS и запись, которая уже содержит закрытый ключ (замена фиктивного самоподписанного сертификата); при желании вы также можете импортировать цепочки сертификатов в качестве записей доверенных сертификатов.

Метод 1 является каноническим и описывается, как правило, неоднократно на веб-сайтах всех поставщиков сертификатов, на которых я когда-либо смотрел, как центров сертификации, так и торговых посредников; Не знаю, как ты их всех соскучился. Обратите внимание, что эти описания часто относятся к Tomcat, наиболее широко используемому веб-серверу на основе Java; компонент веб-сервера Jboss, ныне известный как Wildfly, на самом деле является форком Tomcat. Вот первые два, которые меня нашел Google:
* https://www.digicert.com/csr-creation-java.htm
* https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=INFO227

2A: Используйте другие инструменты (например, Windows, MacOS или OpenSSL) для создания закрытого ключа и получения подходящего сертификата, обычно с использованием CSR, от центра сертификации, включая его цепочку. Если применимо, экспортируйте / конвертируйте / объедините цепочку закрытого ключа И сертификата в файл PKCS12 (также называемый PFX в Microsoft-land) и, возможно, затем используйте keytool -importkeystore для преобразования PKCS12 в JKS. (В Java 8 во многих случаях вы действительно можете использовать PKCS12 напрямую, без преобразования его в JKS, и ожидается, что Java 9 будет способствовать этому.)

2B: Если вы уже иметь сгенерированный частный ключ и подходящий сертификат / цепочку, полученную с помощью других инструментов, просто поместите их в PKCS12 и, возможно, конвертируйте в JKS, как указано выше.

Обратите внимание, что некоторые другие графические интерфейсы, такие как Microsoft, MacOS и Firefox, сосредоточены на сертификате: они отображают доверенный сертификат как просто «сертификат», а комбинацию закрытого ключа и сертификата как «сертификат с закрытым ключом». Но разница все еще жизненно важна; сервер должен иметь закрытый ключ и пытаться использовать сертификат без privatekey 'не работает. Вместо этого Java имеет разные типы записей хранилища ключей, хотя для некоторых хранилищ ключей эти типы фактически не хранятся напрямую.