☰

X.509 証明書は Chrome でエラーが発生しますが、Firefox では動作します。

tag-icon • tag-icon debian chrome
X.509 証明書は Chrome でエラーが発生しますが、Firefox では動作します。

RedHat 6.2 VMApache 2.2を実行しているサイト/仮想ホストでMulticertによって発行されたパブリックX.509証明書を更新しました。そう呼ぶhttps://www.multicert.com。サイトにアクセスするためにChromeを使用しているクライアントコンピュータが実行されていますDebian 9。

驚くべきことに、証明書はFirefox Quantum 60.2.0esr（64ビット）とSafariの両方で承認/緑を提供しましたが、Chrome 69.0.3497.92ではサイトが安全ではないと不平を言います（以前は以前の証明書を使用したときは問題ありませんでした）。 。

Apacheの設定を確認しましたが、すべてが大丈夫だと思います。また、X.509証明書チェーンとルートを3回調べましたが、すべてが問題ないようです。

同様に設定されたサイトに対して同時に別の公開証明書が発行されましたが、発行されたが発行されておらず、ComodoこのMulticertサイトではChromeが証明書とうまく機能しました。これを呼び出します。https://www.digicert.com

以前の証明書に戻ると、Chromeは再び機能しますが、明日は終了し、数日後に期限切れになる可能性があるため、ただ維持することはできません。

Comodo証明書を含むウェブサイトで私たちが見つけた唯一の変更は、Chromeで証明書をクリックしたときにlock->Certificate-details「拡張」の下に識別子を持つ新しいフィールドがあることです。OID.1.3.6.1.4.1.1.11129.2.4.2

ビデオ

ここで何が起こっているのでしょうか？

ベストアンサー1

OIDが与えられたら、.1.3.6.1.4.1.1.11129.2.4.2関連するLet's Encrypt記事を見つけました。エンジニアリングディープディスカッション：証明書のSCTエンコーディング

Let's Encryptは最近、証明書にSCTを含む機能を導入しました。この機能を使用すると、ブラウザで証明書が証明書の透明性ログに送信されたことを確認できます。

私はこのトピックについて調査を開始し、最終的にGoogleが2018年5月1日からすべての種類のX.509証明書に対してChromeで証明書の透明性を実施していることに気づきました。

~からGoogle Chrome の証明書の透明性の実施

この通知は、共通のCAデータベース[1]で知られているすべてのCAオペレータに送信され、Chromeが現在または将来実行される可能性があるプラットフォーム（Mozilla NSS、Microsoft Windows、Apple iOS / macOS、Google ChromeOS、およびAndroid）に適用されます。 。

Chromeが2018年4月に証明書透明性（CT）施行を実施する予定であることをもう一度申し上げたいと思います。 CA / Bフォーラム[2]で最初に発表されたように、その後mozilla.dev.security.policyフォーラム[3]で発表され、後で参照されるct-policyフォーラム[4]で更新され、Chromeが起動します。 2018年4月以降に発行されたすべてのTLS証明書は、信頼できるChromium CTポリシー[5]に準拠するように施行されました。

2015年1月から、ChromeではEVステータスを取得するためにCT要件を満たすために拡張検証（EV）証明書が必要です。 2018年4月に、この要件は新しく発行されたすべてのパブリック信頼証明書（DV、OV、EV）に拡大され、Chrome評価時にこのポリシーに準拠していない証明書は信頼できるとは見なされません。信頼できるローカルCA、またはユーザーまたは管理者によって追加されたエンタープライズCAによって発行された証明書には、この要件は適用されません。

いつ、何が起こったのですか？

Chromeでは、Chromium CTポリシーに準拠するために、2018年4月30日以降に発行されたすべてのTLSサーバー証明書が必要です。この日以降にChromeがChromium CTポリシーに準拠していない公的に信頼できる証明書を提供するウェブサイトに接続すると、ユーザーはその接続がCTに準拠していないことを示す全ページのフロント広告を表示します。 CTに準拠していないhttps接続を介して提供されるサブリソースはロードされず、Chrome DevToolsにエラーが表示されます。 CAは3月末までに顧客と協力して、TLS証明書がRFC 6962セクション3.3 [6]で指定されている3つの方法のうちの1つで、Chromium CTポリシーに準拠する準備ができていることを確認して発生するすべての問題を特定することをお勧めします。展開中の CT サポートは、実行の締め切り前に解決されます。これらの変更は、macOS、Windows、Linux、ChromeOSなどのデスクトッププラットフォームに最初にリリースされます。

一部の企業固有の要件を解決するために、Chromeポリシーでは、管理対象デバイスと個人用デバイスからChromeにログインしている管理ユーザーに対するCTの実施を禁止しています。 URL[7]を介してCT施行を無効にする既存の機能に加えて、Chromeは組織が証明書のみを発行するCAに対してCTが施行を無効にすることを許可するポリシーを追加します。

~からChromeでは、2018年4月以降のCTが必要です。

Chromeでは、Chromium CTポリシーに準拠するために、2018年4月30日以降に発行されたすべてのTLSサーバー証明書が必要です。 「これは、SSL / TLS証明書が次のいずれかの条件を満たしてCT資格を持つ必要があることを意味します。

  • 検査時に資格のあるログの署名付き証明書タイムスタンプ（SCT）、TLS拡張を介して提供またはステープルされたOCSPレスポンスに含まれ、検査中に資格のあるGoogleログのSCTが1つ以上、非認証ログのSCTが1つ以上含まれます。 - GoogleログのSCTがスキャンに合格しました。

  • Googleログに含まれる少なくとも1つのSCT、Google以外のログに含まれる少なくとも1つのSCT、および含まれているSCTの最小数を含む、スキャン時に適格なログに含まれるSCTを提供します。

だから証明書の透明性の紹介

署名証明書タイムスタンプ

証明書は通常、証明書を発行したCAによってCTログに送信されますが、サイト所有者は自分の証明書をログに送信することもできます。 SCTは、証明書の送信時に証明書ログの応答として、デフォルトで指定された期間内にログに証明書を追加することを約束します。お客様が当社のウェブサイトへのTLS接続を確立するとき、当社はこのSCTをお客様に提供する必要があり、これを行う方法は3つあります。

x.509v3拡張

サイト運営者にSCTを提供する基本的な方法は、X.509v3拡張を使用することです。つまり、CA が証明書に署名して発行する前に SCT を証明書に含めるため、ユーザー側で作業や設定がまったく必要ありません。 CA は、最終段階に署名する前に証明書を作成し、事前証明書として CT ログに送信します。ログは事前認証されたSCTで応答し、CAは証明書に組み込み、署名してユーザーに発行する準備をします。

TLS拡張

SCTはTLS拡張を介してホストから接続クライアントに渡すこともできます。これは、signed_certificate_timestampという拡張を使用してTLSハンドシェイク中に実行されますが、ホストがサーバーを更新してSCTを転送するように構成する必要があります。ここでの利点は、CAの場合、証明書の発行方法を変更する必要はありませんが、SCT TLS拡張の信頼性の高いサーバー実装を待つことはサイト運営者にとっては悪いことです。

OCSPバインディング

私は通常、証明書に関する失効情報を渡すために使用されますが、CAがサイト運営者にSCTを渡すためにも使用できるOCSPステープルのファンです。これは、発行プロセスを変更することなく、通常どおり証明書に署名して発行し、OCSPを介してSCTを提供できるという点でCAのもう1つの利点です。ただし、サーバーが確実にOCSPステープルを実行し、ハンドシェイク中にクライアントにSCTを含めることができる必要があるため、これは私たちにとっても問題になります。

その結果、私の2つのウェブサイトがありました。www.digicert.com) は SCT X.509 拡張を証明書に直接含め、サーバー側で設定を変更する必要はありません。

他のサイト（multicert.comなど）では、CAオペレータがX.509ステープル留めを使用することを選択したため、Apache Webサーバーに設定変更が必要でした。

Digicertに関する記事も見つけました。Apache用のOCSPバインディング

したがって、サイトがOSCPステープル留めで機能するようにするには、次のものが必要です。

  • Apacheのバージョンは2.3.3以降です。

  • CA OCSP サーバと通信する VM

  • 仮想ホストに追加：

    <virtualhost...> ディレクティブの外部

     SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    <virtualhost...>ディレクティブ内で

     SSLUseStapling on

    そしてApacheを再起動してください。

Multicertによって発行されたX.509証明書を使用するサイトを変更した後、Chromeはその証明書が両方のサイトで有効であることを示します。

また、見ることができますChrome LinuxにX.509拡張機能、SCTは表示されません。

より技術的な詳細

また、2018年5月1日の時間基準がどのように設定され、既存の証明書がどのようになるかについて質問もありました。オンラインでより明確な詳細が不足しているので、以下からChromiumソースコードをダウンロードしました。https://chromium.googlesource.com/chromium/src/使用コマンド：

git clone https://chromium.googlesource.com/chromium/src

証明書の透明性機能に興味がある人にとっては、もっと興味深いディレクトリが components/certificate_transparency/最も興味深い文書ファイルであるようです。net/docs/certificate-transparency.md

興味深い抜粋net/docs/certificate-transparency.md

概要

証明書透明性（CT）は、SSL / TLS証明書エコシステムのさまざまな構造上の欠陥を修正するように設計されたプロトコルです。で説明されている RFC 6962、記録できる公開追加専用データ構造を提供します。認証機関 （カリフォルニア）。証明書のロギングにより、公衆は特定のCAからどの証明書が発行されたかを確認できます。これにより、サイト運営者は自分のドメインの証明書が発行された時期を検出し、不正な発行を確認できます。さらに、ブラウザとルートリポジトリ、さらに広いコミュニティがCAによって発行された証明書を確認し、CAが予想または公開されている慣行に準拠していることを確認できます。

基本的な

証明書に付属のCT情報が複数のCTログに書き込まれたことを示す場合、証明書は証明書の透明性をサポートすると言われます。このCT情報は、以下に従う必要があります。Chromeの証明書の透明性 ポリシー。時々、CTを「有効にする」サイトを「CT適格」または「CT公開」証明書を使用することと呼びます。

Chromeポリシー

ここ数年、Chromeはますます一般的に信頼できる証明書に証明書の透明性を求めてきました。

  • 2015年1月1日より、Chromeでは、証明書の透明性を介してすべての拡張検証証明書を公開する必要があります。正しく公開されていない証明書は電気自動車の地位を奪うただし、規制に準拠していないサイト訪問者には警告は表示されません。

  • 2016年6月1日より、Chromeは、Symantecが所有するルート証明書セットから発行されたすべての新しい証明書が証明書の透明性によって公開されることを要求します。公開されていないかRFC 6962と一致する方法で公開されていない証明書は、信頼できないものとして拒否されます。

  • 2018年4月30日以降に発行されたすべての新規証明書の場合、Chrome では、証明書の透明性を通じて証明書を公開する必要があります。。この日以降に証明書が発行され、証明書またはサイトがCTをサポートしていない場合、その証明書は信頼できないものとして拒否され、接続がブロックされます。ホームページがロードされると、ユーザーはエラーコードを含むフルページ証明書警告ページを表示しますnet::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED。このエラーが発生した場合、CAは証明書がCTをサポートしているかどうかを確認するための措置を講じていないため、CAの販売チームまたはサポートチームに連絡して有効な代替証明書を入手できることを確認する必要があります。

ドメインプライバシー

CT ログに証明書を公開して CT をサポートするということは、証明書の内容全体が公にアクセスされて表示されることを意味します。具体的には、証明書が属するドメインと証明書が属する組織がドメイン検証より高いレベルの検証を持っている場合、または組織固有のCAによって発行された場合は、証明書の透明性ログに含まれることを意味します。

注: 興味深いことに、RFC 6292~として定義された実験的

2018年5月1日の一時開始日に関連して、Chromiumコード（Chromeと共通）には、移行Chrome / Chromiumコードに表示される期限を定義するハードコードされた特定のインスタンスがあります。これは、2018年5月1日より前に発行された証明書のさまざまな動作を説明しています。

services/network/network_context.ccから：

1525         // For old certificates (issued before 2018-05-01),
1526         // CheckCTRequirements() may return CT_NOT_REQUIRED, so we check the
1527         // compliance status here.
1528         // TODO(https://crbug.com/851778): Remove this condition once we require
1529         // signing certificates to have CanSignHttpExchanges extension, because
1530         // such certificates should be naturally after 2018-05-01.
1531         if (ct_verify_result.policy_compliance ==
1532                 net::ct::CTPolicyCompliance::CT_POLICY_COMPLIES_VIA_SCTS ||
1533             ct_verify_result.policy_compliance ==
1534                 net::ct::CTPolicyCompliance::CT_POLICY_BUILD_NOT_TIMELY) {
1535           ct_verify_result.policy_compliance_required = true;
1536           break;
1537         }

コンポーネント/certificate_transparency/chrome_ct_policy_enforcer.ccから：

217   // ... AND there is at least one embedded SCT from a Google Log once or
218   //   currently qualified;
219   // AND there is at least one embedded SCT from a non-Google Log once or
220   //   currently qualified;
221   // ...
222   //
223   // Note: This policy language is only enforced after the below issuance
224   // date, as that's when the diversity policy first came into effect for
225   // SCTs embedded in certificates.
226   // The date when diverse SCTs requirement is effective from.
227   // 2015-07-01 00:00:00 UTC.
228   const base::Time kDiverseSCTRequirementStartDate =
229       base::Time::UnixEpoch() + base::TimeDelta::FromSeconds(1435708800);
230   if (issuance_date >= kDiverseSCTRequirementStartDate &&
231       !(has_embedded_google_sct && has_embedded_nongoogle_sct)) {
232     // Note: This also covers the case for non-embedded SCTs, as it's only
233     // possible to reach here if both sets are not diverse enough.
234     return CTPolicyCompliance::CT_POLICY_NOT_DIVERSE_SCTS;
235   }

付録：私が調査した後に見つけたもののいくつかに基づいて、詳細は次のとおりです。Chrome LinuxにX.509拡張機能、SCTは表示されません。

SCT拡張https://www.digicert.com

デジタル証明書

OCSPの定義https://www.multicert.com

複数の証明書

おすすめ記事