Comment créer un certificate ssl à usage interne avec une autorité de certificateion interne qui ne se lit pas comme auto-signée?

Je tente finalement d'get un client PHP CAS (server zend 8 avec apache) pour faire confiance à un server CAS (tomcat 7) et, à cette fin, je suis allé jusqu'à générer ma propre infrastructure key privée, ici vu avec le mot de passe remplacé par des fesses:

PKI GEN

#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 

Maintenant, les files CAchain.pem, server.crt et server.key peuvent être utilisés dans Apache HTTP Server, par exemple, pour activer HTTPS. Le certificate rootCA.crt doit être importé aux autorités de confiance dans le browser ou le client de messagerie.

Certes, le certificate rootCA.crt doit être importé aux autorités de confiance dans le browser ou le client de messagerie. C'est aussi un voyage étrange:

import racine

 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 

Certes, je ne sais pas où même mettre les files CERT CAchain & server, mais plus particulièrement s_client se plaint que le cert est encore auto-signé d'une manière ou d'une autre, plutôt que de simplement suspendre comme vérification. Juger du sujet et des lignes de l'émetteur

 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 

les certs include le DN de la boîte sur laquelle ils ont été forgés. Pourrais-je m'enfuir avec ceci si j'ai fait mes CA sur une autre boîte, puis l'ai-la et l'ai-je utilisé pour signer mes certs de server / client? Notamment, les deux servers fonctionnent sur la même boîte, car tout ce désordre est toujours soumis à une évaluation exploratoire.

Pour vérifier votre string, vous devez append l'ancre de confiance à la list OpenSSL. Cela consiste à placer votre certificate CA racine dans un location connu et à exécuter la command update-ca-trust .

Sur mon système Fedora, le directory est /etc/pki/ca-trust/source/anchors . L'exécution de la update-ca-trust ajoute le certificate à /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt . Différentes dissortingbutions utilisent des paths différents, donc certaines searchs peuvent être nécessaires ici.

Pour vérifier le path parcouru:

 $ openssl verify -CApath /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt -untrusted intermediateCA.crt server.crt server.crt: OK 

Encore une fois, le path d'access à -CApath peut être différent sur votre machine.


openssl s_client vérifie les certificates en tant que client SSL / TLS. Par conséquent, vous le signalez à l'URL du server distant. Avant cela, vous devez installer à la fois le certificate CA subordonné et le certificate de l'entité finale (server) et la key privée sur cette machine distante. Ce process, bien sûr, dépend de l'application que vous utilisez pour votre server distant. Par exemple, avec apache vous placez les files dans un location raisonnable et vous indiquent dans la configuration de votre site avec:

 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 

(Notez que SSLCertificateChainFile est obsolète à partir de la version 2.4.8)

La sortie que vous avez semble suggérer que les certificates actuellement installés sur cette machine distante sont les auto-signés générés au moment de l'installation.

Welp, 's'avère que la réponse est "Oui, mais pas besoin". La plupart de cette génération de PKI est très bien, mais tous ces files ne sont pas utilisés – les files CAchain ne sont pas vraiment nécessaires, sauf pour la vérification car openssl verify ne prend que deux arguments, les files clients ne sont pas nécessaires et le Les files srl sont des sous-produits. En ce qui concerne le CN délivrant correspondant au CN requérant, les clients vérifient certs par domaine.

Afin de faire en sorte que Tomcat présente le certificate PKI et non le cert auto-signé, beaucoup de guides recommandnt de faire fonctionner HTTPS, il y a deux étapes supplémentaires:

convertir en 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 

puis importez sur la banque de keys de TomKSKK

… en vous assurant que la nouvelle input correspond à la configuration de Tomcat et à changer l'alias de l'original d'abord

 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 

Le storepass et le keypass doivent correspondre pour que cela fonctionne.

s_client est toujours écrasé sur le rootCA étant auto-signé, et le rootCA doit être installé par le client (je ne peux pas les reprocher de ne pas avoir confiance en "World Domination"), mais le SSO de redirection de CAS fonctionne maintenant de façon transparente.