В конечном итоге я пытаюсь заставить клиент PHP CAS (zend server 8 с apache) доверять серверу CAS (tomcat 7), и с этой целью я зашел так далеко, что создал мою собственную инфраструктуру закрытого ключа, здесь видно с паролем заменены ягодицами:
#root key
openssl genrsa -out rootCA.key -aes256 -passout pass:butts 4096
openssl req -x509 -new -key rootCA.key -out rootCA.crt -subj '/C=US/O=World Domination/CN=WorldDom Root CA' -days 3650 -sha256 -passin pass:butts
#intermdiate key
openssl genrsa -out intermediateCA.key -aes256 -passout pass:butts 4096
openssl req -new -key intermediateCA.key -out intermediateCA.csr -subj '/C=US/O=<orgname>/CN=<orgname> Intermediate CA' -passin pass:butts
#X509V3 extension config file
cat <<EOF > v3_ca.ext
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints=CA:true
EOF
#sign intermediate with root key & X509V3 extensions
openssl x509 -req -in intermediateCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -CAserial rootCA.srl -extfile v3_ca.ext -out intermediateCA.crt -days 365 -sha256 -passin pass:butts
#works at this stage
openssl verify -CAfile rootCA.crt intermediateCA.crt
openssl x509 -in intermediateCA.crt -text
#server
openssl genrsa -out server.key -aes256 -passout pass:butts 4096
openssl req -new -key server.key -out server.csr -subj '/C=US/O=<orgDiv>/CN=CASsrv' -passin pass:butts
openssl x509 -req -in server.csr -CA intermediateCA.crt -CAkey intermediateCA.key -CAcreateserial -CAserial intermediateCA.srl -out server.crt -days 365 -sha256 -passin pass:butts
#decrypt for web server use
mv server.key server.key.secure
openssl rsa -in server.key.secure -out server.key -passin pass:butts
#client
openssl genrsa -out client.key -aes256 -passout pass:butts 4096
openssl req -new -key client.key -out client.csr -subj '/C=US/O=<orgSubDiv>/CN=ZServer/emailAddress=test@example.com' -passin pass:butts
openssl x509 -req -in client.csr -CA intermediateCA.crt -CAkey intermediateCA.key -CAcreateserial -CAserial intermediateCA.srl -out client.crt -days 365 -sha256 -passin pass:butts
cat intermediateCA.crt rootCA.crt > CAchain.pem
openssl pkcs12 -export -passout pass:butts -in client.crt -inkey client.key -certfile CAchain.pem -out client.p12 -passin pass:butts
#works here too
openssl verify -CAfile CAchain.pem server.crt (or client.crt)
openssl x509 -in server.crt -text
Теперь файлы CAchain.pem, server.crt и server.key можно использовать в HTTP-сервере Apache, например, для включения HTTPS. Сертификат rootCA.crt должен быть импортирован в доверенные центры в браузере или почтовом клиенте.
Якобы сертификат rootCA.crt должен быть импортирован в доверенные центры в браузере или почтовом клиенте. Это тоже странное путешествие:
sudo cp rootCA.crt /etc/ssl/certs/worldDomCA.crt
#symlink named after its hash.4, hash result is same after rename so I used the local version rather than the renamed etc/ssl version
sudo ln -s /etc/ssl/certs/worldDomCA.crt /etc/ssl/certs/'openssl x509 -hash -noout -in rootCA.crt'.4
#this just hangs, disturbingly
openssl verify -CApath /etc/ssl/certs/worldDomCA.crt
По общему признанию, я не уверен, куда даже поместить файлы сертификатов CAchain и сервера, но, в частности, s_client жалуется, что сертификат все еще самоподписан, а не просто висит, как проверка. Судя по теме и эмитенту
subject=/C=US/ST=test/L=test/O=test/OU=test/CN=servername.domain.int
issuer=/C=US/ST=test/L=test/O=test/OU=test/CN=servername.domain.int
сертификаты включают DN коробки, на которой они были подделаны. Могу ли я уйти от этого, если я создал свои центры сертификации на другом компьютере, а затем принес его и использовал для подписания сертификатов сервера / клиента? Примечательно, что оба сервера работают на одном компьютере, поскольку весь этот беспорядок все еще находится на стадии исследовательской оценки.
Чтобы проверить свою цепочку, вам нужно добавить якорь доверия в список OpenSSL. Это состоит из размещения вашего корневого сертификата CA в известном месте и запуска update-ca-trust команда.
В моей системе Fedora каталог /etc/pki/ca-trust/source/anchors. Бег update-ca-trust добавляет сертификат к /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt. Различные дистрибутивы используют разные пути, поэтому здесь могут потребоваться некоторые исследования.
Чтобы проверить путь, выполните:
$ openssl verify -CApath /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt -untrusted intermediateCA.crt server.crt
server.crt: OK
Опять же, путь к -CApath может отличаться на вашей машине.
openssl s_client проверяет сертификаты как клиент SSL / TLS. Поэтому вы указываете его на URL-адрес удаленного сервера. Перед этим вам необходимо установить и подчиненный сертификат CA, и сертификат конечного объекта (сервера) и закрытый ключ на этом удаленном компьютере. Этот процесс, конечно, зависит от того, какое приложение вы используете для своего удаленного сервера. Например, с apache вы размещаете файлы в удобном месте и указываете на них в конфигурации своего сайта с помощью:
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key
SSLCertificateChainFile /etc/pki/tls/certs/world-domination.ca-bundle
(Обратите внимание, что SSLCertificateChainFile устарело, начиная с версии 2.4.8)
Вывод, который у вас есть, предполагает, что сертификаты, установленные в настоящее время на этом удаленном компьютере, являются самозаверяющими, созданными во время установки.
Welp, оказывается, ответ - «Да, но в этом нет необходимости». Большая часть этого поколения PKI просто прекрасна, хотя не все эти файлы на самом деле используются - файлы CAchain действительно не нужны, за исключением проверки, поскольку openssl verify принимает только два аргумента, клиентские файлы не нужны, а srl являются побочными продуктами. Проблема заключается в том, что выдающий CN соответствует запрашивающему CN, поскольку клиенты проверяют сертификаты по домену.
Чтобы заставить Tomcat представить сертификат PKI, а не самозаверяющий сертификат, многие руководства рекомендуют запустить и запустить HTTPS, есть два дополнительных шага:
openssl pkcs12 -export -chain -passout pass:butts -in server.crt -inkey server.key -out server.p12 -name alias -CAfile (intermediateCA.crt or CAchain.crt) -caname steeve
... убедитесь, что новая запись соответствует тому, что ищет конфигурация tomcat, и сначала измените псевдоним оригинала
keytool -changealias -alias tomcat -destalias derpcat -storepass changeit
keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore server.keystore -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass butts -alias tomcat
storepass и keypass должны совпадать, чтобы это работало.
s_client все еще бормочет о том, что rootCA самоподписан, а rootCA должен быть установлен клиентом (я не могу винить их за то, что они не доверяют «World Domination»), но SSO перенаправления CAS теперь работает без проблем.