☰

如何使用内部 CA 创建不能读取自​​签名的内部使用 SSL 证书？

tag-icon • tag-icon ssl openssl cas
如何使用内部 CA 创建不能读取自​​签名的内部使用 SSL 证书？

我最终尝试让 PHP CAS 客户端（带有 apache 的 zend server 8）信任 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/[email protected]' -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 文件可以在 Apache HTTP Server 中使用，例如，启用 HTTPS。rootCA.crt 证书应导入到浏览器或邮件客户端中受信任的机构。

表面上看，rootCA.crt证书应该导入到浏览器或邮件客户端的受信任的机构。这也是一次奇怪的旅程：

rootCA 导入

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 抱怨证书仍然是自签名的，而不是像 verify 那样挂起。从主题和颁发者行判断

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。如果我在另一台机器上创建 CA，然后将其带进来并用它来签署我的服务器/客户端证书，我能逃脱惩罚吗？值得注意的是，两台服务器都在同一台机器上运行，因为整个混乱局面仍在探索性评估中。

答案1

要验证您的链，您需要将信任锚添加到 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 版本开始已弃用）

您的输出似乎表明该远程计算机上当前安装的证书是安装时生成的自签名证书。

答案2

好吧，答案是“是的，但不需要”。大多数 PKI 生成都很好，尽管并非所有这些文件都得到实际使用——CAchain 文件除了用于验证外并不是真正需要的，因为 openssl verify 只接受两个参数，客户端文件不需要，srl 文件是副产品。问题在于颁发 CN 是否与请求 CN 匹配，因为客户端按域检查证书。

为了让 Tomcat 出示 PKI 证书而不是自签名证书，许多指南建议启动并运行 HTTPS，还有两个额外的步骤：

转换为 pkcs12

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的JKS密钥库

...确保新条目与 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”），但 CAS 重定向 SSO 现在已经无缝运行。

相关内容