CSRが生成したS / MIME証明書を取得/購入する場所
広告のような具体的なサービスプロバイダーを求めているので、このボードに適格かどうかはわかりませんが、技術的な問題もあるので試してみます。
私の具体的なシナリオは次のとおりです。
電子メールの暗号化にS/MIMEを使用したい。デフォルトのメールクライアントはすべてS/MIMEをサポートしていますが、追加のプラグインなしのPGPはサポートしていないため、私の決定はS/MIMEに関して行われました。また、自己署名した証明書ではなく、信頼できる証明書を取得したいと考えています。これは、連絡するすべての人を念頭に置いて使用するほうが簡単だからです。
今問題に：私は私の電子メールのアーカイブで将来安全でありたいです。私が調査した限りでは、ほとんどのCAはS/MIME証明書をhtml <keygen>タグで作成します。これにより、ブラウザーは新しい秘密公開鍵ペアを作成できます。今のところ問題ありません。ただし、証明書の有効期間は通常1〜3年です。証明書を更新したい場合は、ブラウザーから新しい秘密鍵と公開鍵のペアを作成する必要があります。電子メールのアーカイブに関しては、これにより、大量のキーが生成されます。これらのキーは、アーカイブされた電子メールを読みたい場合に、保存/バックアップして再利用する必要があります。さらに、どのキーが復号化に適したものであるかを試す必要があるか、具体的なデータと、どのキーペアがいつ使用されたかのリストが必要です。
私が理解している限り、これは、CSRリクエストから受け取った証明書に問題がないはずです。証明書の有効期限が切れるたびにCSRを再利用し、すべてのメールで同じキーを何年も保持できます。
さて、質問へ：クライアントのCSRによって生成されたS/MIME証明書を提供するCAを知っていますか？
S/MIMEにデフォルトのサーバー証明書を使用することもできますか？ （別の電子メールでは、webmaster、root、... @ mydomain.comですが、theo @ mydomain.comのようなもので、クラス1ドメインで検証されたサーバー証明書を取得するためのデフォルトの電子メールアドレスではありません）
それとも、ごちゃごちゃしたキーなしで長期間の耐久性を得る方法は他にありますか？
理論としては、古いキーを保持している限り、メールソフトウェアは受信したメールを復号化できます。証明書の有効期限が切れているということは、他の人々が古い暗号化されたメールを送信するために古い公開鍵を使用することを受け入れないことを意味しますが、あなたの側であなたのメールボックスを読むことはあなたの使用を必要としません公開鍵または証明書、秘密鍵のみ。つまり、certificatesは期限切れになりますが、秘密鍵は期限切れになりません。通常の電子メールソフトウェアは、証明書によってキーにインデックスを付けます（証明書があり、証明書には対応する秘密キーへのリンクがあります）。そのため、有効期限が切れた場合でも、証明書を保持しておくことをお勧めします。
この理論では、蓄積された秘密鍵のストレージスペースを除いて、新しい証明書が必要なときにいつでも新しい鍵ペアを生成しても問題はありません。 1つのRSA秘密鍵は2 kB未満で済むため、3年ごとに鍵を1回入力しても、すぐにディスクがいっぱいになることはありません。ただし、秘密キーをスマートカードに保存している場合、これは問題になる可能性があります。スマートカードは永遠ではなく、バックアップも簡単ではないため、キーの損失（したがってデータの損失）のリスクを意味します。新しい証明書を生成するのではなく、新しい証明書に同じキーペアを再利用しても、とにかく役に立ちません。
プロフェッショナルCAは、Certification Practice Statementに従うことになっています。これは、証明書の更新に新しいキーが必要になることが多いものです。この要件はさまざまな理由で存在する可能性がありますが、必ずしも適切なものではありません。たとえば、1つの議論はこうなります。主要なクラッキングアルゴリズムには時間がかかります。長期間有効なキー（長年にわたるキーの有効期間と証明書の更新）を使用することにより、攻撃者がキーを解読するためにより多くの時間を与えることになります。古いキーを壊すことは攻撃者にとってすでに興味深い（古い電子メールへのアクセスを許可する）ため、これはあまり良い議論ではありませんが、それでもなお広く見られる議論です。新しいキーペアを強制することも、長いキーを定期的に強制する簡単な方法です。したがって、多くのCAは既成のCSRを簡単には受け入れません。
もちろん、潜在的にブラウザのコードを変更して（それがオープンソースであると仮定すると）、新しいキーを生成するためにふりをすることができます、しかし、実際には前のものを再利用します。 CAは、新しいキーが以前のキーと異なることを明示的にチェックしない限り、それを実際に防ぐことはできません。
この問題のもう1つの側面は、暗号化キーをエスクロー（つまり、どこかにバックアップ）する必要があることです。実際、秘密鍵を失うことは、その鍵で暗号化された古いメールへのアクセスを使用することを意味します。したがって、秘密鍵のストレージポリシーは、必要以上にすでに複雑になっています。 1つではなく1ダースのキーをカバーできるようにそのポリシーを拡大することは、それほど多くの問題とは思えない。
概要：これは正確な質問に答えるものではありませんが、証明書の更新後も同じ秘密鍵を保持することを強くお勧めします。新しいキーペアの生成は問題ないはずであり、キーを変更することは「良いこと」であると少なくとも議論の余地があります。 3年ごと、または1年ごとに1つの新しい証明書は、あなた自身の終焉の前に "混乱"することはありません（できるだけ遠くにあることを願っています）。
主要なライフサイクル管理は難しい問題です。シンプルさは、他のすべての条件が同じであっても良いことですが、シンプルすぎると使いやすさやセキュリティが低下し始める点があります。
（「すべてを統治する1つのリング」は、当時は良いアイデアのように見えました。）
信頼できる証明書を発行するために認証局が従う必要がある特定のルールがあります（これらの1つは、証明書が3年以上有効でないことです）
アーカイブの場合、古い証明書のコピーを保持できます（有効期限後にメールを送信しようとすると、期限切れとして表示されます）が、古いメールを引き続き表示できます。
証明書はコンピュータのレジストリの深い場所に保存されます-Webブラウザはこれへのショートカットを保持します（SSLの目的で必要になります）
証明書を注文すると、注文したコンピューターに秘密鍵が作成されます。注文すると、CSR（証明書署名要求）が発行者に送信され、秘密鍵と一致するものを作成します
これらの証明書が作成されると修正されます（そのため、誰もがそれらに依存します）。したがって、「再発行」または「更新」すると、基本的に古い証明書が無関係な新しい証明書に置き換えられます（アカウントで時間が一致するように編集されます）
私はこの機能を提供するCAを見たことがありませんが、StartComフォーラムで質問するCAに参加すると、将来的にサポートを追加することを検討する可能性が高くなります。議論は https://forum.startcom.org/viewtopic.php?f=15&t=168 にあります