Le problème est que openssl -verifycela ne fait pas le travail.
Comme Priyadi l'a mentionné , openssl -verifys'arrête au premier certificat auto-signé, donc vous ne vérifiez pas vraiment la chaîne, car souvent le certificat intermédiaire est auto-signé.
Je suppose que vous voulez être sûr à 101% que les fichiers de certificat sont corrects avant d'essayer de les installer dans le service Web productif. Cette recette effectue ici exactement cette vérification avant vol.
Veuillez noter que la réponse de Peter est correcte , mais la sortie de openssl -verifyne donne aucun indice que tout fonctionne vraiment après. Oui, il peut y avoir des problèmes, mais pas tous.
Voici un script qui vérifie une chaîne de certificats avant de l'installer dans Apache. Peut-être que cela peut être amélioré avec certaines des magies les plus mystiques d'OpenSSL, mais je ne suis pas un gourou d'OpenSSL et les œuvres suivantes:
#!/bin/bash
# This Works is placed under the terms of the Copyright Less License,
# see file COPYRIGHT.CLL. USE AT OWN RISK, ABSOLUTELY NO WARRANTY.
#
# COPYRIGHT.CLL can be found at http://permalink.de/tino/cll
# (CLL is CC0 as long as not covered by any Copyright)
OOPS() { echo "OOPS: $*" >&2; exit 23; }
PID=
kick() { [ -n "$PID" ] && kill "$PID" && sleep .2; PID=; }
trap 'kick' 0
serve()
{
kick
PID=
openssl s_server -key "$KEY" -cert "$CRT" "$@" -www &
PID=$!
sleep .5 # give it time to startup
}
check()
{
while read -r line
do
case "$line" in
'Verify return code: 0 (ok)') return 0;;
'Verify return code: '*) return 1;;
# *) echo "::: $line :::";;
esac
done < <(echo | openssl s_client -verify 8 -CApath /etc/ssl/certs/)
OOPS "Something failed, verification output not found!"
return 2
}
ARG="${1%.}"
KEY="$ARG.key"
CRT="$ARG.crt"
BND="$ARG.bundle"
for a in "$KEY" "$CRT" "$BND"
do
[ -s "$a" ] || OOPS "missing $a"
done
serve
check && echo "!!! =========> CA-Bundle is not needed! <========"
echo
serve -CAfile "$BND"
check
ret=$?
kick
echo
case $ret in
0) echo "EVERYTHING OK"
echo "SSLCertificateKeyFile $KEY"
echo "SSLCertificateFile $CRT"
echo "SSLCACertificateFile $BND"
;;
*) echo "!!! =========> something is wrong, verification failed! <======== ($ret)";;
esac
exit $ret
Notez que la sortie après EVERYTHING OKest le paramètre Apache, car les personnes utilisant NginXou haproxygénéralement peuvent parfaitement lire et comprendre cela aussi;)
Il y a un GitHub Gist de ceci qui pourrait avoir des mises à jour
Prérequis de ce script:
- Vous avez les données racine de l'autorité de certification de confiance
/etc/ssl/certscomme d'habitude, par exemple sur Ubuntu
- Créez un répertoire dans
DIRlequel vous stockez 3 fichiers:
DIR/certificate.crt qui contient le certificatDIR/certificate.key qui contient la clé secrète de votre webservice (sans mot de passe)DIR/certificate.bundlequi contient le CA-Bundle. Pour savoir comment préparer le bundle, voir ci-dessous.
- Maintenant, exécutez le script:
./check DIR/certificate(cela suppose que le script est nommé checkdans le répertoire courant)
- Il existe un cas très improbable que le script génère
CA-Bundle is not needed. Cela signifie que vous (lisez /etc/ssl/certs/:) fait déjà confiance au certificat de signature. Mais c'est très improbable sur le WWW.
- Pour ce test, le port 4433 doit être inutilisé sur votre poste de travail. Et mieux vaut ne l'exécuter que dans un environnement sécurisé, car il ouvre prochainement le port 4433 au public, ce qui pourrait voir des connexions étrangères dans un environnement hostile.
Comment créer le certificate.bundlefichier?
Sur le WWW, la chaîne de confiance ressemble généralement à ceci:
- certificat de confiance de
/etc/ssl/certs
- certificat (s) intermédiaire (s) inconnu (s), éventuellement signé (s) croisé (s) par une autre autorité de certification
- votre certificat (
certificate.crt)
Maintenant, l'évaluation se déroule de bas en haut, cela signifie d'abord que votre certificat est lu, puis le certificat intermédiaire inconnu est nécessaire, puis peut-être le certificat de signature croisée, puis il /etc/ssl/certsest consulté pour trouver le certificat de confiance approprié.
Le ca-bundle doit être constitué exactement dans le bon ordre de traitement, cela signifie que le premier certificat nécessaire (le certificat intermédiaire qui signe votre certificat) vient en premier dans le bundle. Ensuite, le certificat de signature croisée est nécessaire.
Habituellement, votre autorité de certification (l'autorité qui a signé votre certificat) fournira déjà un tel fichier ca-bundle approprié. Sinon, vous devez sélectionner tous les certificats intermédiaires nécessaires et catles rassembler dans un seul fichier (sous Unix). Sous Windows, vous pouvez simplement ouvrir un éditeur de texte (comme notepad.exe) et coller les certificats dans le fichier, le premier nécessaire en haut et en suivant les autres.
Il y a autre chose. Les fichiers doivent être au format PEM. Certaines autorités de certification émettent le format DER (un binaire). PEM est facile à repérer: il est lisible en ASCII. Pour en savoir plus sur la façon de convertir quelque chose en PEM, voir Comment convertir .crt en .pem et suivez la route de briques jaunes.
Exemple:
Tu as:
intermediate2.crt le certificat intermédiaire qui a signé votre certificate.crtintermediate1.crt un autre cert intermédiaire, qui a chanté intermediate2.crtcrossigned.crt qui est un certificat de signature croisée d'une autre autorité de certification, qui a signé intermediate1.crtcrossintermediate.crtqui est un autre intermédiaire de l'autre CA qui a signé crossigned.crt(vous ne verrez probablement jamais une telle chose)
Alors le bon catressemblerait à ceci:
cat intermediate2.crt intermediate1.crt crossigned.crt crossintermediate.crt > certificate.bundle
Et comment savoir quels fichiers sont nécessaires ou non et dans quel ordre?
Eh bien, expérimentez, jusqu'à ce que checkvous disiez que tout va bien. C'est comme un jeu de puzzle informatique pour résoudre l'énigme. Chaque. Célibataire. Temps. Même pour les pros. Mais vous vous améliorerez à chaque fois que vous en aurez besoin. Vous n'êtes donc définitivement pas seul avec toute cette douleur. C'est SSL, tu sais? SSL est probablement l'une des pires conceptions que j'ai jamais vues en plus de 30 ans d'administration système professionnelle. Vous êtes-vous déjà demandé pourquoi la cryptographie n'était pas devenue courante au cours des 30 dernières années? C'est pourquoi. dit Nuff.
man verify, j'ai trouvé que le-untrustedparamètre est le bon à utiliser lors de la spécification du certificat intermédiaire.