AIA による発行者の検出 · PEM チェーンのエクスポート

SSL 証明書チェーンを完成させてください。

不足している中間証明書を見つけ、fullchain.pem をオンラインで生成します。Nginx、Apache、クラウドへの証明書アップロード向けに、順序どおりの SSL 証明書チェーンまたは CA バンドルを作成します。

SSL 証明書チェーンを構築

サーバー側でチェーンを補完するため、公開 SSL 証明書を送信します。同じファイルにある既存の中間証明書とルート証明書は再利用され、不足している発行者は自動でダウンロードされます。秘密鍵は送らないでください。

サーバー証明書を先頭に置きます。既存の中間証明書とルートはそのあとに、順不同で続けて構いません。PEM、または 1 件の DER 証明書を受け付け、上限は 1 MB です。

完了した証明書チェーンがここに表示されます

デプロイ用の fullchain.pem、または別の CA バンドルをダウンロードします。

不完全な証明書チェーン

不足している中間証明書を補います。

SSL 証明書には、クライアントが信頼するルートまでの発行者の経路が必要です。cert.pem だけを渡すと、その経路が不完全なままになることがあります。中間証明書をキャッシュしたブラウザは動いても、新しい端末やコマンドラインのクライアントは検証エラーを報告することがあります。

中間証明書が不足

ローカル発行者証明書を取得することができないか、最初の証明書のエラーを検証できない場合にCAチェーンを完了します。 エラーが主張している場合は、他の信頼の原因を確認します。

デプロイメントバンドル

リーフ証明書を先頭に、続けて中間証明書を並べた fullchain.pem を生成します。証明書チェーン専用の欄があるプラットフォーム向けに、別の CA バンドルをエクスポートします。

検証された発行者リンク

発行者名と暗号署名は、ダウンロードした証明書を追加する前にチェックされます。無関係の証明書はチェーンを完了することはできません。

FULLCHAIN.PEM を作成

証明書のチェーンを完了する方法。

秘密鍵も、ドメインへの接続も不要です。このツールは稼働中のサーバーを調べず、証明書ファイルを扱います。

  1. 01

    サーバー証明書を追加

    PEM を貼り付けるか、.pem、.crt、.cer、.der の証明書をアップロードします。部分的なチェーンがある場合は、リーフ証明書を先頭にしてください。

  2. 02

    チェーンの確認と完了

    Cloudflare の検証を完了してから証明書を送信します。サーバーは、不足している発行者を自動でダウンロードする前に、既存の中間証明書とルートを再利用します。

  3. 03

    fullchain.pem をダウンロードしてデプロイ

    既定のデプロイファイルは、サーバー証明書のあとに中間証明書が続きます。既存の秘密鍵は別に保管し、再読み込み後に稼働中のサーバーを確認してください。

チェーン結果

完了結果を理解する。

チェーンを構築しました

各発行者のつながりが検証され、チェーンは自己署名ルートに到達しています。デプロイ用バンドルをダウンロードし、対象のクライアントがそのルートを信頼するか確認してください。

発行者を取得できません

AIA がない、遮断されている、または一致する発行者を返しません。CA から中間証明書とルート証明書を用意して、再試行してください。

有効期間の警告

期限切れ、またはまだ有効でない証明書は、チェーンが完全でも使えません。デプロイする前に更新するか、有効期間の問題を解消してください。

チェーンをOpenSSLでビルドしてチェックします。

CA から中間証明書を入手し、発行者順に並べます。Nginx の ssl_certificate、または Apache 2.4.8 以降の SSLCertificateFile に fullchain.pem を設定します。秘密鍵は別の設定項目に置いてください。

サーバーを再読み込みしたあと、そのドメインで実際に提示されている証明書チェーンを確認します。ローカルのバンドルだけでは、稼働中の TLS 設定がそれを使っている証明にはなりません。

# Inspect issuer and AIA details openssl x509 -in cert.pem -noout -text # Leaf first, then ordered intermediates cat cert.pem intermediates.pem > fullchain.pem # Verify with a root you independently trust openssl verify -CAfile trusted-root.pem \ -untrusted intermediates.pem cert.pem # Inspect the live server using SNI openssl s_client -connect example.com:443 \ -servername example.com -showcerts \ -verify_return_error </dev/null

サポートされているフォーマットとダウンロード制限。

完全な PEM の CERTIFICATE ブロックを貼り付けるか、PEM バンドルまたは DER の X.509 証明書を 1 件アップロードします。AIA のダウンロードは PEM と DER の応答に対応します。P7B、PFX、P12 は、先に証明書コンバーターで変換してください。入力の上限は 1 MB です。自動リクエストにはタイムアウトとチェーンの深さの上限があります。

補完は最初の証明書から発行者を 1 本たどり、古いクライアント向けの別経路は選びません。検証、発行者のダウンロード、署名の確認は、Cloudflare の検証後にサーバーで行われます。同じ入力で、サーバー証明書のあとに既存の中間証明書とルート証明書を含めてください。

証明書チェーン補完FAQ。

SSLの証明書チェーンを完了するにはどうすればよいですか?

サーバー証明書を先頭に貼り付け、既存の中間証明書を続けます。Cloudflare の検証のあと、AutoSSL は入力にすでにある証明書を再利用し、Authority Information Access(AIA)の URL から不足している発行者をダウンロードします。各発行者は、証明書の発行者名と一致し、その署名を検証できる必要があります。チェーンが自己署名ルートに到達したら、fullchain.pem をダウンロードします。

cert.pem、chain.pem、fullchain.pem の違いは何ですか?

cert.pem には通常、サーバー証明書だけが含まれます。chain.pem または CA バンドルには、通常、中間 CA 証明書が含まれます。fullchain.pem は、サーバー証明書を先頭に、中間証明書を発行者順に結合します。ここでのデプロイ出力には自己署名ルートは含まれません。別のダウンロードにはルートが含まれます。

証明書チェーンが不完全なのはなぜですか?

サーバーがリーフ証明書だけ、または古い CA バンドルで構成されていることがあります。中間証明書をキャッシュしているクライアントは動いても、新しいクライアントは失敗します。発行者が足りないと、unable to get local issuer certificate、unable to verify the first certificate、または curl error 60 になることがあります。これらのエラーには、信頼や有効性の別の原因もあります。

なぜ自動中間証明書のダウンロードが失敗しましたか?

証明書に AIA の発行者 URL がないか、CA のエンドポイントが使えないことがあります。自動ダウンロードは、ブラウザの CORS と HTTP の制限を避けるため、対応している公開 CA リポジトリに対して同一オリジンのサービスを使います。リポジトリが未対応、または AIA がない場合は、不足している証明書を CA から入手し、同じ入力のサーバー証明書のあとに追加して再試行してください。PKCS#7 の AIA 応答は、先に証明書コンバーターで PEM に変換する必要があります。

このツールは、証明書をアップロードするか、秘密鍵が必要ですか?

はい。公開証明書または既存のチェーンは、Cloudflare の検証のあと AutoSSL に送られます。サーバーは証明書を検証し、不足している発行者を自動でダウンロードし、ルートを含む完全なチェーンを返します。秘密鍵、CSR、証明書以外の PEM ブロックは拒否されます。ダウンロードはブラウザ内で組み立てられます。

完全なチェーンは、証明書が信頼されることを意味しますか?

いいえ。 自己署名されたルートに到達すると、ブラウザやオペレーティングシステムがrootを信頼するというわけではなく、接続されているシグネチャチェーンが証明されます。 このツールは、revocation、ホスト名妥当性、CAパス制約、またはすべての証明書ポリシーをチェックしません。 期限切れの証明書はまだ更新が必要であり、プライベートCAルーツはクライアントのトラストストアにインストールが必要です。

サーバーにルート証明書を含めるべきですか?

TLS サーバーは通常、サーバー証明書と中間証明書を送ります。クライアントは信頼するルートをすでに持っています。一般的な Nginx と Apache のデプロイには fullchain.pem を使います。プラットフォームが明示的に要求するときだけ、ルートを含むチェーンをダウンロードしてください。このツールは、どちらの出力を作る前にも、最後の発行者の関係を検証するためにルートを必要とします。