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

다음 구성 요소로 자체 인증서 체인을 작성 중입니다.

Root Certificate - Intermediate Certificate - User Certificate

루트 인증서는 자체 서명 된 인증서이며, 중간 인증서는 루트에 의해, 사용자는 중간에 의해 서명됩니다.

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

와

openssl verify -verbose -CAfile RootCert.pem Intermediate.pem

확인은 괜찮습니다. 다음 단계에서는 사용자 인증서를

openssl verify -verbose -CAfile Intermediate.pem UserCert.pem

그리고 검증 쇼

error 20 at 0 depth lookup:unable to get local issuer certificate

뭐가 잘못 되었 니?

에서 verify문서 :

자체 발급자 인 인증서가 발견되면 루트 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을 신뢰합니다 . 나는 그레그 참조 게시물 의 첫 부분을 읽는 것이 좋습니다 (두 번째 부분은 특히 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사용하는 사람들 때문에 아파치 설정이며, NginX또는 haproxy일반적으로 읽고, 너무 완벽이 이해할 수 있습니다)

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

이 스크립트의 전제 조건 :

• /etc/ssl/certs평소 와 같이 신뢰할 수있는 CA 루트 데이터가 있습니다 (예 : Ubuntu).
• DIR3 개의 파일을 저장 하는 디렉토리를 작성하십시오 .
  • DIR/certificate.crt 인증서가 들어있는
  • DIR/certificate.key 여기에는 웹 서비스의 비밀 키가 포함되어 있습니다 (암호 없음)
  • DIR/certificate.bundle여기에는 CA 번들이 포함됩니다. 번들을 준비하는 방법은 아래를 참조하십시오.
• 이제 스크립트를 실행하십시오 : ./check DIR/certificate(스크립트의 이름 check이 현재 디렉토리에 있다고 가정합니다 )
• 스크립트가 출력되는 경우는 거의 없습니다 CA-Bundle is not needed. 이는 귀하 (읽기 /etc/ssl/certs/:)가 이미 서명 인증서를 신뢰 함을 의미 합니다. 그러나 이것은 WWW에는 거의 없을 것입니다.
• 이 테스트 포트 4433은 워크 스테이션에서 사용하지 않아야합니다. 그리고 포트 4433이 대중에게 곧 열리기 때문에 안전한 환경에서만 실행하는 것이 좋습니다. 이로 인해 적대적인 환경에서 외부 연결이 발생할 수 있습니다.

certificate.bundle파일 을 만드는 방법 ?

WWW에서 트러스트 체인은 일반적으로 다음과 같습니다.

• 의 신뢰할 수있는 인증서 /etc/ssl/certs
• 알 수없는 중간 인증서, 다른 CA에서 서명 한 크로스 인증서
• 당신의 증명서 ( certificate.crt)

이제 평가는 아래에서 위로 진행됩니다. 즉, 먼저 인증서를 읽은 다음 알 수없는 중간 인증서가 필요하고 교차 서명 인증서가 필요한 /etc/ssl/certs경우 적절한 신뢰할 수있는 인증서를 찾기 위해 문의합니다.

ca 번들은 올바른 처리 순서로 정확하게 구성해야합니다. 즉, 첫 번째로 필요한 인증서 (인증서에 서명하는 중간 인증서)가 번들에서 먼저 나옵니다. 그런 다음 교차 서명 인증서가 필요합니다.

일반적으로 CA (인증서에 서명 한 기관)는 해당 ca 번들 파일을 이미 제공합니다. 그렇지 않은 경우 필요한 모든 중간 인증서와 cat단일 파일 (UNIX의 경우)을 함께 선택해야합니다 . Windows에서는 (와 같은 notepad.exe) 텍스트 편집기를 열고 인증서를 파일에 붙여 넣을 수 있습니다.

또 다른 것이 있습니다. 파일은 PEM 형식이어야합니다. 일부 CA는 DER (2 진) 형식을 발행합니다. PEM은 쉽게 알아볼 수 있습니다. ASCII로 읽을 수 있습니다. 무언가를 PEM으로 변환하는 방법에 대한 내용은 .crt를 .pem으로 변환 하고 노란색 벽돌 길을 따르는 방법을 참조하십시오 .

예:

당신은 :

• intermediate2.crt 귀하의 서명 한 중간 증명서 certificate.crt
• intermediate1.crt 노래 한 또 다른 중간 증명서 intermediate2.crt
• crossigned.crt 다른 CA의 서명 인증서 인 서명 한 intermediate1.crt
• crossintermediate.crt서명 한 다른 CA와 다른 중간체입니다 crossigned.crt(아마도 그런 것을 보지 못할 것입니다)

그런 다음 적절한 내용 cat은 다음과 같습니다.

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

어떤 파일이 필요한지 어떤 순서로 알 수 있습니까?

실험이 끝날 때까지 check모든 것이 정상임을 알 수 있습니다. 수수께끼를 해결하는 컴퓨터 퍼즐 게임과 같습니다. 마다. 단일. 시각. 전문가조차도. 그러나 이렇게 할 때마다 더 나아질 것입니다. 따라서 당신은 모든 고통을 겪고있는 것이 확실하게 혼자가 아닙니다. SSL이야, 알아? SSL은 아마도 30 년 이상의 전문 시스템 관리에서 본 최악의 디자인 중 하나 일 것입니다. 지난 30 년 동안 암호 화폐가 왜 주류가되지 않았는지 궁금한 적이 있습니까? 그 이유입니다. '그런가 말했다.

letencrypt 인증서를 확인해야했고 다음과 같이했습니다.

1. 에서 루트 인증서와 중간 인증서를 다운로드하십시오. letsencrypt 신뢰 체인 .

2. 이 명령을 발행하십시오.

   $ 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
   

SSL 인증서에 대한 사전 지식없이 하루 종일 똑같은 문제를 겪은 후 CERTivity Keystores Manager를 다운로드했습니다. 키 저장소를 가져와 인증서 체인을 명확하게 시각화했습니다.

스크린 샷 :

당신이 해당 확인하려면 발행자 의 UserCert.pem 실제로있다 Intermediate.pem (예를 들어 용도 : 다음을 수행하십시오 OpenSSL 1.1.1) :

openssl verify -no-CAfile -no-CApath -partial_chain -trusted Intermediate.pem UserCert.pem

그리고 당신은 얻을 것이다 :

UserCert.pem: OK

또는

UserCert.pem: verification failed

openssl을 사용하여 인증서 체인을 쉽게 확인할 수 있습니다. 전체 체인에는 CA 인증서가 포함되므로 CA 및 인증서 자체에 대한 세부 정보를 볼 수 있습니다.

openssl x509 -in fullchain.pem-텍스트 -noout