TLS暗号は、証明書の認証を定義する部分（つまり、ECDSA、RSA ...）、鍵交換を定義する部分（ECDHE、DHE ...）、および対称暗号化の種類と関連するHMACに関する部分で構成されます、つまりRC4 + SHA1、AES128 + SHA256など.
これらの部分から、認証の部分のみが証明書のタイプに依存し、その他はすべて独立しています。つまり、RC4を拒否するなど、証明書内で特定の対称暗号化の使用を制限することはできません。これを行うには、SSL構成にそのような暗号を含めないようにクライアントまたはサーバーを構成する必要があります。
更新：この回答はTLSに適用されます1.2のみ。 2018年のTLS 1.3は、ハンドシェイクを根本的に変更し、キー交換、認証、対称（データ）暗号化/ MACareに依存せず、最後の（プラスKDF）のみが「ciphersuite」によって決定されます。また、RC4はまったく許可されなくなったため、このQ.
TLDR：限られたケースでは可、ただし不可
まず、鍵交換と認証はSSL/TLSで実際には独立していません。いくつかの選択肢が利用できる場合もありますが、合理的に選択できる多くの組み合わせは暗号スイートとして存在しません。 （SSHなど、ピースが個別にネゴシエートされ、両側が各ピースをサポートしている限り、任意の組み合わせを取得できます。）特に、（クラシックZp）Diffie-Hellman Ephemeral（DHE）キー交換は、RSAまたはDSAで認証できます。 （スペルDSS）はECDSAではなく、楕円曲線Diffie-Hellman Ephemeral（ECDHE）キー交換は、RSAまたはECDSAで認証できますが、DSAでは認証できません。また、一部のスイートは「匿名」と呼ばれる認証をまったく行いませんが、ほとんど使用されておらず、認証されていないために頻繁に禁止されています。
次に、many対称暗号とHMAC-and/or-hashを使用したauth（存在する場合）を含むkeyexchangeの組み合わせがありますが、not allです。 1つは、ECDHE ECDH(static) or ECDH_anonを使用したECCスイートでは、「エクスポート」（40ビット）暗号やシングルDESまたはSEEDを使用しないためです。これは、おそらく2006年までに（rfc4492）不要になったためです。これらの弱い暗号のために。また、ここに関連して、RC2、RC4、またはIDEAでDSA/DSS認証を使用するスイートはありません。私の推測はDSA/DSSは1980年代と1990年代にRSADSIに使用料を支払わず、当時RSA特許をかなり精力的に執行しなかった米国政府を大いに喜ばせるためのものでした。しかし、USGには、NBS-later-NISTによって「承認」された暗号のみを使用することに関するものもあり、DESは承認されましたが、RC2 RC4 IDEAは承認されませんでした。どちらもRC5ではありませんでしたが、そもそもRC5はSSL-later-TLSで使用されませんでした。
SO：サーバーが標準SSL/TLSでDSAキーと証明書を使用している場合、それはRC4をネゴシエートできないです。
しかし、欠点もあります。
Certification：これは大きな問題です。私はDSA証明書を提供するno public CA（Verisign、Comodo、Gaddaddyなど）を見てきました。 USGがDSAを使用して独自の内部PKIを実行していたことを知っていますが、それらがまだ実行されているかどうかはわかりません。たとえ実行されたとしても、おそらくそれらからの証明書を取得できず、いずれにせよそのルートはトラストストアにありません非USGシステムおよびデバイス。もちろん、自己署名のDSA証明書を簡単に作成することも、DSA証明書を発行する独自のCAを簡単に作成することもできますが、自己証明書または自己CAの信頼を確立（および維持）することは、多くの場合かなりの作業になります。そして時には実行不可能です。
DSA（パラメータ）サイズ：（クラシック）DSAとDHはRSAとほぼ同じ攻撃を受け、オープンコミュニティでは1024ビットファクタリングも1024ビットdlogも到達していませんが、技術のかなり緩やかな改善で実現可能であると広く信じられています。 Logjamの研究者 DH-1024が「[p]州レベルのリソースで閲覧可能」になると（2015年後半に）推定される。 DSA-1024にも同じロジックが適用されますが、DH（E）の場合よりもDSAパラメーターを共有することは一般的ではないため、攻撃者のモチベーションが低下する可能性があります。いずれにせよ、標準はほとんど必要です適切な安全マージンのための最小2048ビット 2014年以降、RSA DHおよびDSAに対して、実質的にNISTによって推進されています。
ただし、元のDSA標準FIPS-186（-0）では、（外部）グループを定義する素数pのサイズを512から1024ビットに64刻みで指定する必要がありました。 。しかし、NISTが186-3を確定するには、2009年までにpサイズ2048および3072を追加しました（それぞれq 224または256および256）。アプリケーションが暗号などの「コア」機能に基づいて構築され、ソフトウェアが開発、テスト、取得、および展開される方法を考えると、この1〜2年のみ DSA-2048はほとんど機能しましたが、それでもまだ遠いですユニバーサルから。一例として、Sun-now-OracleバージョンのJavaは、2014年にバージョン8でのみ186-3サイズを実装しました。OpenSSLは、拡張機能として大きなpを実装しました。はるか昔、しかし186-3qのサイズは2010年に1.0.0しかありませんでした-1.0.0はメジャーバージョンでしたが、APIが変更され、アプリケーションやシステムへの適応に数年かかりました完全に展開するまでの年数。
DHはそのような制限を公式には持っていませんでした（以下を参照）。一部の特定のパラメーターが標準化されましたが、現在は小さすぎますが、それらはいくつかのオプションの1つにすぎませんでした。 RSAには、私が知っている標準化された制限はありませんでした。初期の実装は、多くの場合1024ビットまたはそれ以下に制限されることが多かったが、これは常にコンピュータの電源が許す限り引き上げられる実装の制限として扱われ、AFAIKのすべての実装は、長年にわたって少なくとも4096をサポートしてきた。
DHEステータスとサイズ：上記のキー交換と認証の関係により、DSAキーと証明書はDHEキー交換またはSRPでのみ使用でき、実際にはSSL/TLSに誰もSRPを使用しません。かなり最近まで、多くのソフトウェアはDHEを固定またはデフォルトで、時には不適切なパラメータで実装していました。かなりの数のユーザー（ユーザー、ユーザーの代わりにブラウザーを使用するクライアント、サーバー管理者の両方）が一時的なキー交換（DHEまたはECDHE）を望み始めたのは、Snowdenの後だけでした。これはほんの数年前のことであり、InterWebの検索で見つけるほとんどの情報とブログ、「ヒント」、「トリック」は、完全に架空のものではないにしても、通常は数年から数十年古く、DHEを安全に設定するのは非常に簡単です。原則としてECDHEcouldは同様に台無しにされますが、実際には、多くは以前のSuiteBカーブP-256およびP-384に加えて、時にはP-521のみを実装しました。これは、ECDHE = goodと言うアドバイスを見つけ、ECDHEをまったく機能させることができた場合、安全であることを意味します。
Suncle Java 8より前はここでさらに悪化しました：[〜＃〜] jce [〜＃〜]DHがDSA（186-0）サイズに制限されているようですDHのDSAパラメータ生成を再利用することの副作用として、これはばかげています-SO for client 'Could not generate DH keypair'、but[〜 ＃〜] jsse [〜＃〜]サーバーは、768がkx = RSAプリマスターサイズ384の2倍であるという完全に疑わしい理由で、非エクスポートDHE 768ビットを選択しました（そしてブートするようにハードコードされています）。異なるプリマスターを持つことができます。これが、2段階の派生premaster-> master-> workingの明示的な理由です。ただし、384の強度が必要な正当な理由がある場合でも、subgroupを意味しますgroupではなく768です！）
つまり、これを行わないでください。 RC4を禁止してRC4を回避する直接、必要な方法。また、必要に応じてそれらを直接禁止することにより、エクスポートスイートとシングルDESスイートを回避します。