現在開発中の Web アプリケーションは、PCI 3.1 監査に合格する必要があります。このアプリケーションは、Debian で NGINX を実行している Amazon EC2 上にあります。
証明書についてはシマンテックと連絡を取っており、特にEV証明書とワイルドカード証明書付きのSecure Site Proに興味があります（動的なサブドメイン名を持つサーバーが1つあるため、ワイルドカード証明書を検討しています）。
何千ドルも費やして、これらが PCI 3.1 には適していないことが判明したり、NGINX と Debian の組み合わせがこれらのタイプの証明書には機能しないことが判明したりすることがないようにしたかったのです。
PCI-DSS 3.1 準拠を試みた経験があり、どの SSL 証明書を取得すべきかアドバイスをいただける方はいらっしゃいますか?
答え1
注意: 私は PCI 認証を受ける必要はありませんでした。これは、あなたの質問に対するこのトピックに関する私の調査に基づいています。
PCI3.0とPCI3.1の主な違いは、3.1ではTLS1.1以上が必要であることです。SSL3またはTLS1.0は使用できません。http://www.infosecurity-magazine.com/news/pci-dss-31-forces-move-from-ssl-to/ただし、一部の場所では TLS1.1 は許可されていないとさえ記載されています。ただし、TLS1.2 のみを使用すると、Android 4.4 未満や IE 11 未満のすべてのユーザーなど、潜在的に非常に多くの訪問者を遮断することになります。それがビジネスで許容できる場合は、そのままにしておいてください。
さらに、EV 証明書は明示的には要求されていないようです。EV 証明書はフィッシングを阻止するためのサイト認識に役立ちますが、PCI の厳格な要件ではありません。
また、ワイルドカード証明書を禁止するものも見当たりません。
信頼チェーンが訪問者のブラウザの一部である限り、任意のワイルドカード証明書を取得できます。EV 証明書である必要はなく、Symantec の証明書である必要もありません。
セットアップの重要な部分は、Nginx やその他の SSL 終端ソフトウェア/ハードウェアが正しい暗号化設定を使用していることを確認することです。Mozilla は、コンポーネントとそのバージョンを選択できる便利なページを作成し、"ベスト プラクティス" 構成を生成します。https://mozilla.github.io/server-side-tls/ssl-config-generator/そしてhttps://wiki.mozilla.org/セキュリティ/サーバーサイドTLS
答え2
要約:PCI-DSS 3.1即時発効しますが、TLS 1.0 および SSL 3 を無効にする要件は 2016 年 6 月 30 日以降に発効します。
ほとんどの場合、POODLE 脆弱性のために、3 か月以上前に SSL を無効にしているはずです。したがって、これは問題ではありません。
この要件の興味深い部分は、TLS 1.0 を使用できないことです。
公式発表は次のとおりです。
SSL および初期の TLS は強力な暗号化とはみなされず、2016 年 6 月 30 日以降はセキュリティ制御として使用できません。この日付より前に、SSL および/または初期の TLS を使用する既存の実装では、正式なリスク軽減および移行計画を実施する必要があります。ただちに、新しい実装では SSL または初期の TLS を使用できません。SSL および初期の TLS の既知のエクスプロイトの影響を受けないことが検証された POS POI 端末 (およびそれらが接続する SSL/TLS 終端ポイント) は、2016 年 6 月 30 日以降もセキュリティ制御として引き続き使用できます。
--SSL および初期の TLS からの移行、PCI-DSS 情報補足
ここで、「初期の TLS」は TLS 1.0 として定義されます。TLS 1.1 と 1.2 のみが許可され、1.2 が強く推奨されます。
販売時点管理デバイスとそのバックエンドでは TLS 1.0 と SSL 3 を引き続き使用できますが、考えられるすべての問題を軽減したことを証明できる場合は、これらも更新することを強く検討する必要があります。
余談ですが、これは Windows XP の棺に打ち込まれたもう一つの釘です...