openssl verify를 사용하여 인증서 체인 확인

openssl verify를 사용하여 인증서 체인 확인

---

다음과 같은 구성 요소로 자체 인증서 체인을 작성하고 있습니다.
Root Certificate - Intermediate Certificate - User Certificate
루트 인증서는 자체 서명 된 인증서, 중간 인증서는 루트에 의해, 사용자는 중간에 의해 서명됩니다.

이제 사용자 인증서에 루트 인증서로 앵커가 있는지 확인하고 싶습니다.

으로
openssl verify -verbose -CAfile RootCert.pem Intermediate.pem
검증 괜찮습니다. 다음 단계에서 사용자 인증서를
openssl verify -verbose -CAfile Intermediate.pem UserCert.pem
검증하고 검증은 0 심도 조회에서 오류 20을 표시합니다. 로컬 발급자 인증서를 가져올 수 없습니다

뭐가 잘못 되었 니?

---

'확인'문서에서 : "자신의 발급자 인 인증서가 발견되면 루트 CA로 간주됩니다". 다시 말해, 루트 CA는 작동 확인을 위해 자체 서명해야합니다. 이것이 두 번째 명령이 작동하지 않은 이유입니다.

대신 이것을 시도하십시오 :

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

단일 명령으로 전체 체인을 확인합니다.

---

그것은 몇 가지 합법적 인 직업 중 하나입니다 cat.

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

---

최신 정보:

Greg Smethells가 주석에서 지적한 것처럼 이 명령은 암시 적으로 Intermediate.pem을 신뢰합니다 . Greg 참조 게시물 의 첫 번째 부분을 읽는 것이 좋습니다 (두 번째 부분은 pyOpenSSL에 관한 것이며이 질문과 관련이 없습니다).

게시물이 사라지면 중요한 단락을 인용하겠습니다.

불행히도 실제로 루트 / 자체 서명 된 "중간"인증서는 위에 제공된 권장 명령을 사용할 때 신뢰할 수있는 CA로 취급됩니다 .

$ 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 : 확인

openssl은 루트 인증서가 발견되는 즉시 체인 확인을 중지하는 것으로 보입니다. 자체 서명 된 경우 Intermediate.pem 일 수도 있습니다. 이 경우 RootCert.pem은 고려되지 않습니다. 따라서 위 명령에 의존하기 전에 Intermediate.pem이 신뢰할 수있는 소스에서 제공되는지 확인하십시오.

---

문제는 그 일을 openssl -verify하지 않는 것입니다.

Priyadi가 언급 한 바와 같이 , openssl -verify종종 중간 인증서가 자체 서명 한, 따라서 당신이 정말로 체인을 확인하지, 첫 번째 자체 서명 된 인증서에서 멈 춥니 다.

생산적인 웹 서비스에 인증서 파일을 설치하기 전에 인증서 파일이 올바른지 101 % 확신한다고 가정합니다. 이 레시피는 여기서 사전 비행 점검을 정확하게 수행합니다.

주의하시기 바랍니다 베드로의 대답이 올바른지 ,의 그러나 출력은 openssl -verify모든 것을 단서없는 정말 이후 작품. 예, 문제가있을 수 있지만 전부는 아닙니다.

다음은 인증서 체인을 Apache에 설치하기 전에 인증서 체인을 확인하는 작업을 수행하는 스크립트입니다. 아마도 이것은 좀 더 신비한 OpenSSL 마술로 향상 될 수 있지만 OpenSSL 전문가가 아니며 다음과 같은 작품입니다.

#!/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

이후의 결과 EVERYTHING OK는 Apache 설정입니다. NginX또는 사용하는 사람 이나 haproxy일반적으로 이것을 완벽하게 읽고 이해할 수 있기 때문입니다 .)

이것에 대한 GitHub Gist 가 있습니다.

이 스크립트의 전제 조건 :

• /etc/ssl/certs평소 와 같이 신뢰할 수있는 CA 루트 데이터가 있습니다 (예 : Ubuntu).
• Create a directory DIR where you store 3 files:
  • DIR/certificate.crt which contains the certificate
  • DIR/certificate.key which contains the secret key for your webservice (without passphrase)
  • DIR/certificate.bundle which contains the CA-Bundle. On how to prepare the bundle, see below.
• Now run the script: ./check DIR/certificate (this assumes that the script is named check in the current directory)
• There is a very unlikely case that the script outputs CA-Bundle is not needed. This means, that you (read: /etc/ssl/certs/) already trusts the signing certificate. But this is highly unlikely in the WWW.
• For this test port 4433 must be unused on your workstation. And better only run this in a secure environment, as it opens port 4433 shortly to the public, which might see foreign connects in a hostile environment.

How to create the certificate.bundle file?

In the WWW the trust chain usually looks like this:

• trusted certificate from /etc/ssl/certs
• unknown intermediate certificate(s), possibly cross signed by another CA
• your certificate (certificate.crt)

Now, the evaluation takes place from bottom to top, this means, first, your certificate is read, then the unknown intermediate certificate is needed, then perhaps the cross-signing-certificate and then /etc/ssl/certs is consulted to find the proper trusted certificate.

The ca-bundle must be made up in excactly the right processing order, this means, the first needed certificate (the intermediate certificate which signs your certificate) comes first in the bundle. Then the cross-signing-cert is needed.

Usually your CA (the authority who signed your certificate) will provide such a proper ca-bundle-file already. If not, you need to pick all the needed intermediate certificates and cat them together into a single file (on Unix). On Windows you can just open a text editor (like notepad.exe) and paste the certificates into the file, the first needed on top and following the others.

There is another thing. The files need to be in PEM format. Some CAs issue DER (a binary) format. PEM is easy to spot: It is ASCII readable. For mor on how to convert something into PEM, see How to convert .crt to .pem and follow the yellow brick road.

Example:

You have:

• intermediate2.crt the intermediate cert which signed your certificate.crt
• intermediate1.crt another intermediate cert, which singed intermediate2.crt
• crossigned.crt which is a cross signing certificate from another CA, which signed intermediate1.crt
• crossintermediate.crt which is another intermediate from the other CA which signed crossigned.crt (you probably will never ever see such a thing)

Then the proper cat would look like this:

cat intermediate2.crt intermediate1.crt crossigned.crt crossintermediate.crt > certificate.bundle

And how can you find out which files are needed or not and in which sequence?

Well, experiment, until the check tells you everything is OK. It is like a computer puzzle game to solve the riddle. Every. Single. Time. Even for pros. But you will get better each time you need to do this. So you are definitively not alone with all that pain. It's SSL, ya' know? SSL is probably one of the worst designs I ever saw in over 30 years of professional system administration. Ever wondered why crypto has not become mainstream in the last 30 years? That's why. 'nuff said.

---

I've had to do a verification of a letsencrypt certificate and I did it like this:

1. Download the root-cert and the intermediate-cert from the letsencrypt chain of trust: https://letsencrypt.org/certificates/
2. issue this command:

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

Hope it helps you for your letsencrypt certs. Thanks for Priyadi, your solution helped me finding this command. Palease make sure to upvote his solution.

---

After breaking an entire day on the exact same issue , with no prior knowledge on SSL certificates, i downloaded the CERTivity Keystores Manager and imported my keystore to it, and got a clear-cut visualisation of the certificate chain.

Screenshot :

---

You can easily verify a certificate chain with openssl. The fullchain will include the CA cert so you should see details about the CA and the certificate itself.

openssl x509 -in fullchain.pem -text -noout

참고URL : https://stackoverflow.com/questions/25482199/verify-a-certificate-chain-using-openssl-verify