Во-первых, не надо мне «тыкать».
Во-вторых, надо бы мне, конечно, плюнуть и не связываться, но важно исправить заблуждение. Читайте свои же цитаты из мануалов: Server certificates, intermediate certificates, and private keys can all be put into the PEM format. Далее. Several PEM certificates, and even the private key, can be included in one file, one below the other. И далее по тексту везде. Нигде нет смешивания сертификата и закрытого ключа. Это две совершенно разные вещи. Сертификат — это подписанный публичный ключ с метадатой. Ничего другого сертификатом называться не может.
Не надо спорить в области, которая вам знакома по статьям из Википедии. Я работаю с PKI каждый день в течение последних трех лет и прекрасно знаю, что такое обмен ключами RSA, сертификаты и многое другое.
Советую остыть и все-таки попытаться понять, о чем я тут пишу уже несколько сообщений подряд.
Я вам про Фому, вы мне про Ерему. :-(
Что вы привязались к этим форматам? С вами никто по этому поводу и не спорит. Разговор о том, что сертификат не может содержать закрытого ключа. Точка. Если вы не знаете определение цифрового сертификата, то я очень советую это определение узнать.
RSA применяется для обмена сессионным ключом, остальной трафик шифруется именно сессионным ключом. Я про это и писал в первом сообщении, что закрытого ключа для расшифровки трафика недостаточно, надо знать сессионный ключ, а для этого надо мониторить процесс обмена сессионными ключами.
Все у меня верно написано, перестаньте ко мне придираться без причины.
Мне кажется, вы немного невнимательно прочитали мой комментарий. Речь шла о том, что сертификат мне содержит и не может содержать закрытого ключа. Про возможности форматов PEM и DER речи не шло.
Насчет HTTPS только на ассиметричных ключах, то такого в природе я не встречал никогда. И SSL, и TLS работают с сеансовыми симметричными ключами.
Для этого в смарт-карте должна быть логика. Это возможно только в Java или .NET картах. Обычные смарт-карты внутренней логики не имеют, они просто хранилище PKI объектов с доступом через API.
Какая же там мутная инструкция. Как будто специально хотели людей запутать, чтобы к ним за платной поддержкой обращались :-)
Меня интересует на каком месте находятся primaryIntermediate и secondaryIntermediate в цепочке сертификатов, а не в выводе keytool.
Скопируйте сюда ваш серверный сертификат в формате BASE64, я вам все скажу что и как. Сертификат — это открытый ключ, поэтому никакой конфиденциальной информации вы не потеряете.
Хе, сейчас заметил, что вы сертификаты CA добавляете с параметром -trustcacerts. Это неправильно для обычного JKS. Надо добавлять как я писал выше: keytool -import -alias cacert-file CA_cert.cer -keystore tomcat.jks
Если будете создавать truststore, тогда -trustcacerts нужен, но не путайте одно с другим.
Ну а корневой сертификат где?
primaryIntermediate выше в цепочке secondaryIntermediate или ниже?
Зачем используется параметр -destalias tomcat? Это что такое?
Вы явно не указываете keystore, поэтому могут быть разногласия при добавлении. Указывайте все явно в параметрах.
truststore.jks необходим для клиентской аутентификации по сертификату. Если у вас нет такой задачи, тогда опустите эту настройку.
Если вы все делаете правильно, а именно добавляете в tomcat.jks (из примера) сначала p12, а потом всю цепочку сертификатов от издающего до корневого, то все должно работать. И keytool -v -list -keystore tomcat.jks должен показывать Your keystore contains 4 entries… Chain length: 4.
Сервер шлет всю цепочку сертификатов клиенту, если у него есть эти данные. И клиент проверяет только корневой сертификат, а потом сверяет листы отзыва во всей цепочке.
Если промежуточные сертификаты имеют расширение AIA caIssuer, и ссылки действительные, то клиент может выкачать промежуточные сертификаты самостоятельно. Видимо не все браузеры это умеют делать.
Поэтому надо настраивать сервер так, чтобы он выдавал всю цепочку сразу.
Я правильно понял, что Апач верно отдает, а nginx старую версию подсовывает? Попробуйте удалить папку /usr/local/nginx/cache/xxxxxxxxx.kz и перезапустить nginx.
