Vérifier une chaîne de certificats en utilisant openssl vérifier

à Partir de 'vérifier' documentation: "Si un certificat est constaté, qui est son propre émetteur, il est supposé être l'autorité de certification racine". En d'autres termes, l'AC racine doit s'auto-signer pour que verify fonctionne. C'est pourquoi votre deuxième commande n'a pas fonctionné.

essayez plutôt ceci:

openssl verify -CAfile RootCert.pem -untrusted Intermediate.pem UserCert.pem

il vérifiera toute votre chaîne en une seule commande.

C'est l'un des rares emplois légitimes pour cat :

openssl verify -verbose -CAfile <(cat Intermediate.pem RootCert.pem) UserCert.pem

---

mise à Jour:

comme Greg Smethells le souligne dans les commentaires, cette commande fait implicitement confiance à Intermediate.pem . Je recommande la lecture de la première partie de les références post Greg (la deuxième partie concerne spécifiquement pyOpenSSL et n'est pas pertinente à cette question).

Au cas où le post disparaîtrait, je citerai les paragraphes importants:

malheureusement, un certificat "intermédiaire" qui est en fait une racine / auto-signée sera traité comme un CA de confiance lors de l'utilisation de la commande recommandée ci-dessus:

$ openssl verify-CAfile <(cat geotrust_global_ca.pem rogue_ca.pem) fake_sometechcompany_from_rogue_ca.com.pem fake_sometechcompany_from_rogue_ca.com.pem: OK

il semble que openssl cessera de vérifier la chaîne dès qu'un certificat racine est rencontré, qui peut aussi être Intermédiaire.pem si elle est auto-signé. Dans ce cas, RootCert.pem n'est pas considérée. Donc, assurez-vous que les Intermédiaires.pem vient d'une source fiable avant de s'appuyer sur la commande ci-dessus.

le problème est que openssl -verify ne fait pas le travail.

comme Priyadi a mentionné , openssl -verify s'arrête au premier certificat auto-signé, donc vous ne Vérifiez pas vraiment la chaîne, comme 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 voici effectue exactement cette pré-vol-vérification.

s'il vous Plaît noter que la réponse de Pierre est correct , cependant la sortie de openssl -verify est aucune idée de ce que tout vraiment oeuvres par la suite. Oui, il peut en trouver certains problèmes, mais pas tous.

voici un script qui fait le travail de vérifier une chaîne de certificats avant de l'installer dans Apache. Peut-être que cela peut être amélioré avec certains de la magie plus mystique OpenSSL, mais je ne suis pas un gourou 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 OK est le paramètre Apache, parce que les personnes utilisant NginX ou haproxy peuvent généralement lire et comprendre cela parfaitement, aussi;)

il y a un Github Gist de ce qui pourrait avoir quelques mises à jour

conditions préalables de ce script:

• vous avez les données de confiance de la racine CA dans /etc/ssl/certs comme d'habitude par exemple sur Ubuntu
• créer un répertoire DIR où vous stockez 3 fichiers:
  • DIR/certificate.crt qui contient le certificat
  • DIR/certificate.key qui contient la clé secrète pour votre service Web (sans phrase de passe)
  • DIR/certificate.bundle qui contient le faisceau de CA. Comment pour préparer le paquet, voir ci-dessous.
• exécutez maintenant le script: ./check DIR/certificate (cela suppose que le script est nommé check dans le répertoire courant)
• il est très improbable que le script sorte CA-Bundle is not needed . Cela signifie que vous (lisez: /etc/ssl/certs/ ) faites déjà confiance au certificat de signature. Mais cela est très peu probable dans le WWW.
• pour ce test, le port 4433 ne doit pas être utilisé. sur votre poste de travail. Et mieux ne le faire que dans un environnement sécurisé, car il ouvre le port 4433 sous peu au public, qui pourrait voir des connexions étrangères dans un environnement hostile.

comment créer le fichier certificate.bundle ?

Dans le WWW de la chaîne de confiance ressemble généralement à ceci:

• certificat de confiance de /etc/ssl/certs
• intermédiaire inconnu certificat (s), éventuellement contresigné (s) par un autre CA
• votre certificat ( certificate.crt )

maintenant, l'évaluation a lieu de bas en haut, ce qui signifie, d'abord, votre certificat est lu, puis le certificat intermédiaire inconnu est nécessaire, puis peut-être le certificat de signature croisée et puis /etc/ssl/certs est consulté pour trouver le bon certificat de confiance.

Le ca-bundle doivent être réalisés dans exactement le bon ordre de traitement, c'est-à-dire le premier certificat requis (le certificat intermédiaire qui signe votre certificat) vient en premier dans le paquet. Ensuite, la croix-signature-cert est nécessaire.

habituellement, votre AC (l'autorité qui a signé votre certificat) fournira déjà un tel fichier ca-bundle. Si non, vous devez choisir les certificats intermédiaires et cat ensemble dans un seul fichier (sur Unix). Sur les fenêtres, vous pouvez simplement ouvrir un rédacteur de texte (comme notepad.exe ) et coller les certificats dans le fichier, le premier nécessaire sur le dessus et en suivant les autres.

Il y a autre chose. Les fichiers doivent être au format PEM. Certains CAs édition DER (un format binaire). PEM est facile à repérer: il est lisible en ASCII. Pour plus sur la façon de convertir quelque chose en PEM, voir comment convertir .crt .pem et suivre la route de briques jaunes.

exemple:

Vous avez:

• intermediate2.crt le certificat intermédiaire qui a signé votre certificate.crt
• intermediate1.crt un autre cert intermédiaire, qui singed intermediate2.crt
• crossigned.crt qui est un certificat de signature croisée d'une autre AC, qui a signé intermediate1.crt
• crossintermediate.crt qui est un autre intermédiaire de L'autre CA qui a signé crossigned.crt (vous jamais vu une telle chose)

alors le bon cat ressemblerait à 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 le check vous dise que tout va bien. C'est comme un jeu de puzzle informatique pour résoudre l'énigme. Chacun. Seul. Temps. Même pour les pros. Mais tu iras mieux à chaque fois que tu auras besoin de faire ça. Vous n'êtes donc pas seul avec toute cette douleur. C'est SSL, tu sais? SSL est probablement l'un des plus mauvais designs que j'ai jamais vu en plus de 30 ans d'administration de système professionnelle. Vous êtes-vous déjà demandé pourquoi la cryptographie n'est pas devenue courante au cours des 30 dernières années? C'est pourquoi. 'nuff said.

après avoir cassé une journée entière sur la même question, sans connaissance préalable sur les certificats SSL, j'ai téléchargé le CERTivity Keystores Manager et y ai importé mon keystore, et obtenu une visualisation claire de la chaîne de certificat.

Capture d'écran :

j'ai dû faire une vérification d'un certificat letsencrypt et je l'ai fait comme ceci:

1. télécharger le cert racine et le cert intermédiaire de la chaîne de confiance letsencrypt: https://letsencrypt.org/certificates /
2. cette commande:

openssl verify -CAfile letsencrypt-root-cert/isrgrootx1.pem.txt -untrusted letsencrypt-intermediate-cert/letsencryptauthorityx3.pem.txt /etc/letsencrypt/live/sitename.tld/cert.pem /etc/letsencrypt/live/sitename.tld/cert.pem: OK

J'espère que cela vous aidera pour vos certs letsencrypt. Merci pour Priyadi, votre solution m'a aidé à trouver cette commande. Palease s'assurer d'augmenter sa solution.

vous pouvez facilement vérifier une chaîne de certificats avec openssl. Le fullchain inclura le cert CA, vous devriez donc voir les détails au sujet de L'AC et du certificat lui-même.

openssl x509-in fullchain.pem-text-noout