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は検証を機能させるために自己署名する必要があります。これが、2番目のコマンドが機能しなかった理由です。代わりにこれを試してください：

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

1つのコマンドでチェーン全体を確認します。

これは、数少ない合法的な仕事の1つですcat。

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

更新：

Greg Smethellsがコメントで指摘しているように、このコマンドは暗黙的にIntermediate.pemを信頼します。ポストGregのリファレンスの最初の部分を読むことをお勧めします（2番目の部分は特に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：OK

opensslは、ルート証明書が検出されるとすぐにチェーンの検証を停止するようです。これは、自己署名されている場合はIntermediate.pemの場合もあります。その場合、RootCert.pemは考慮されません。したがって、上記のコマンドに依存する前に、Intermediate.pemが信頼できるソースからのものであることを確認してください。

問題は、それopenssl -verifyが仕事をしないということです。

Priyadiが述べたように、openssl -verify最初の自己署名証明書で停止するため、中間証明書が自己署名されることが多いため、実際にはチェーンを検証しません。

本番のWebサービスに証明書ファイルをインストールする前に、証明書ファイルが正しいことを101％確認したいと思います。ここのレシピは、まさにこの飛行前チェックを実行します。

Peterの答えが正しいことに注意してください。ただし、の出力は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/certsUbuntuなどの通常どおり、信頼されたCAルートデータがあります。
• 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-bundle-fileをすでに提供しています。そうでない場合は、必要なすべての中間証明書とcatそれらを1つのファイルにまとめる必要があります（UNIXの場合）。Windowsでは、テキストエディター（などnotepad.exe）を開いて、証明書をファイルに貼り付けるだけです。

別のものがあります。ファイルはPEM形式である必要があります。一部のCAはDER（バイナリ）形式を発行します。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年以上にわたる専門的なシステム管理で見た中で最悪の設計の1つです。過去30年間で暗号化が主流にならない理由を知りましたか？それが理由です。'言っ途切れる。

私はletsencrypt証明書の検証を行わなければならなかったので、次のようにしました。

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証明書に関する事前の知識がまったくなく、まったく同じ問題について1日中過ごした後、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 -text -noout