ホストがSSL証明書リクエストのプライベートキーをメールで送信したときにCSRを拒否する必要がありますか？
共有WebホスティングプロバイダーにCSRを要求しました。証明書を生成して、インストールするためにそれらに返信します。 （証明書自体は、私が正式に使用するための証明書を提供できる私が働いている組織によって適切に生成されます。）ホスティング会社から、CSRと秘密キーがすぐに送られてきました。彼らは他の人をCCしたり、それをGmailに入れたりしているので、Googleはおそらく広告目的でそれをすでに摂取しているのだろう。
私の控えめな意見では、これは恐ろしいことのように思えます。私はこれを拒否して彼らに返信し、CSRを更新するように求め、今度は秘密鍵を非公開にします。
自分をばかにする前に、「SSL」（TLS）証明書の秘密鍵がサーバーから出てはいけないことを確認したいのですが。
私は長年セキュリティ関連の業界で働いており、かつて暗号化プログラマーでしたので、このトピックについて少しは知っていますが、時間とともに変化することはわかっています。
私はこの関連質問を読みました： SSL証明書の秘密鍵の共有からどのような問題が発生しますか？
メタ更新：私はStack Exchangeの質の低い質問形式を書いたことに気づきました-特定の回答を受け入れるのが困難になったためです。そのための謝罪-すべての回答は、異なって等しく興味深い側面をカバーしました。最初はその目的のためにどのように言葉を使うのか疑問に思いましたが、空白を描きました。
更新：私はホストについてもこれに従いましたが、彼らは「不便をおかけして申し訳ありませんでした」し、将来の秘密鍵を「安全」に保つことを約束し、新しい別のCSRを発行しました。それが同じ公開された秘密鍵から生成されたものであるかどうかは、現時点ではわかりません。また、共有ホストであるため、サーバー全体のキーが送信されたのか、各顧客/ドメイン/仮想ホストがキーペアを取得したのかについても疑問に思います。
これは、単純な人的エラーによって、世界中のすべての暗号強度をnullおよびvoidにできるという興味深いレッスンです。ケビン・ミトニックはうなずきます。
更新2：ユーザー@Beauからの回答に応じて、次のコマンドを使用して、2番目のCSRが別の秘密秘密鍵から生成されたことを確認しました。
openssl rsa -noout -modulus -in pk1.txt | openssl md5
openssl req -noout -modulus -in csr1.txt | openssl md5
openssl req -noout -modulus -in csr2.txt | openssl md5
最初の2つのハッシュは同じですが、3番目のハッシュは異なります。いいニュースですね。
私があなたの所にいた場合、このSSL証明書の受け入れを拒否します。その理由は、誰かが秘密鍵を受け取った電子メールのいずれかに侵入した場合、その秘密鍵をダウンロードして、中間者などのクライアントに対するさまざまな攻撃でサーバーを偽装することができるためです。また、受信メールアドレスの1つが間違って書き込まれた場合、誰かがすでに秘密鍵を持っている可能性があります。また、この秘密鍵がダウンロードされ、攻撃者によって使用される可能性のあるシナリオは、さらに多くあると考えられます。
また、秘密鍵を共有しないことを会社に通知することも重要です。会社が他の場所に秘密鍵を送信しないようにするためです。秘密鍵はあなたに送信され、このメールに他のCCが送信されますが、あなたはできません。会社が秘密鍵を使って別の場所に別のメールを送信していないかどうかを確認してください。
秘密鍵を秘密鍵と呼ぶのには理由があります
これは主に私の個人的な意見であり、SSLの専門家ではないことに注意してください。
はい、CSRを完全に拒否する必要があります。さらに、彼らが何をしているか知らないように見えるので、あなたはあなたのホスティングプロバイダーを変えるべきです。
彼らがあなたに秘密鍵を電子メールで、すなわち安全でない媒体を介して送ったことはすでに十分に悪いです。しかし、彼らはそれを他の誰かにCcしましたが、これは完全な機密侵害です。
さらに、私はwhyが秘密鍵をあなたに送信したのではないかと思います-それはサーバーにインストールされているはずです。
はい、間違いなくCSRを拒否する必要があります。
ホスティングプロバイダーを再検討する必要があるかどうかは、状況によって異なります。
彼らは他の誰かをCCしました
ホスティング会社があなたの社内構造を知る必要がある理由はありますか？これを行う人は、あなたの会社に特別に割り当てられ、会社の誰が誰であるかを知る責任がある指定されたアカウントマネージャーですか？あなたの会社は、あなたの会社がどのように構造化されているか、誰が何をすることを許可されているかについてアカウントマネージャーに十分な説明を提供しましたか？そうでない場合は、キーをどのように送信する必要があるかを明確にしていないことは、部分的にあなたの（会社の）責任である可能性があります。
ほとんどのホスティングアカウントでは、事業内容に精通している指定のアカウントマネージャーがいない場合は、テクニカルサポートに、キーの送信方法、受信者、受信者の有無を技術サポートに明確に伝える必要があります。そもそも鍵を受け取りたくないかどうか。テクニカルサポート担当者があなたの会社の状況を知っていると思い込まないでください。また、指定されたアカウントマネージャーではないテクニカルサポート担当者が、以前のやり取りの出身を覚えていると決して想定しないでください。
そしてそれはGmailにあります
電子メールでCSRを送信することも、あまり安全ではないことに気づいていますか？誰か（GmailまたはAPTで作業しているインサイダー）がCSRを含むメールを傍受し、ホストが送信したCSRを独自のCSRに置き換え、ホスティング会社のCSRをホスティング会社に署名することは十分に可能です。これにより、ユーザーとユーザーおよびホスティング会社との間のMITMに対する偽造された証明書を後で使用できるようになります。
CSRは、認証されたチャネルを介して配信する必要があります（たとえば、ユーザーが制御するHTTPSサイトに証明書を送信するか、サイトで公開するGPGキーでCSRに署名する必要があります）、または少なくとも指紋認証とその両方を行う必要がありますあなたとあなたのホストは、相手を識別して認証する方法を持っている必要があります。認証されたチャネルの設定は非常に複雑なプロセスになる可能性があり、低コストのホスティングプロバイダーや高セキュリティビジネスホスティングに特化したプロバイダーで利用できるようになるものではありません。
あなたの会社がCSRの提供をどのように要求するかを指定しない場合、特にあなたがどのような種類のビジネスをしているのかを知っているはずのアカウントマネージャーによって処理されない場合、ほとんどのホスティング会社は合理的にあなたが最小限であると想定しますセキュリティ会社。最低限のセキュリティ会社で働くほとんどの人は、秘密鍵のコピーを、鍵を管理しないというセキュリティよりも高い値にすることを検討します。あなたからそうすることを彼らが仮定するのは不合理ではありません。
自分をばかにする前に、「SSL」（TLS）証明書の秘密鍵がサーバーから出てはいけないことを確認したいのですが。
場合によっては、サーバーを離れる理由がいくつかあります。たとえば、サーバーサーバーで同じ証明書を使用したり、キーの固定用にバックアップキーを使用したりできます。
しかしabsoloutelyは貴重な秘密として扱われ、信頼できるマシンにのみ保存され、システム間を移動する必要がある場合は適切に保護された方法で行われる必要があります。
私のアドバイスは、これらのピエロからすぐに離れることです。
他の場所で使用したい場合に備えて、キー/証明書のペア全体が必要になるでしょう。
秘密鍵を浮かせることは、特にそれを使用しない場合は、正当なセキュリティ上の問題です。この証明書はホスティングプロバイダー専用であることを説明し、CSRを再発行して秘密キーなしで送信するよう依頼してください。 CSRサムプリントが変更されていることを確認します。
証明書を緑の錠をセキュリティデバイスとして表示する方法として扱うように聞こえます。これはおそらく警告サインです。可能な場合や、サイトが非常に機密性の高い情報を処理する場合は、別のホスティングを検討してください。
彼らはセキュリティに関して全く能力がありません。秘密鍵は、定義により、誤って秘密です。法的にその所有者を識別するのに役立ちます。彼らは偽造と偽装を可能にしました。
あなた送信する必要がありますそれら CSRを生成した後あなた自身あなた秘密鍵/公開鍵のペア、およびtheyは、署名された証明書とその認証チェーンを送信します。他には何もありません。
彼らが秘密鍵とCSRを送信している場合、モデル全体が壊れます。
プロバイダーを変更し、お金を取り戻す少なくとも。彼らはあなたのセキュリティを危うくしているので、損失と損害に対する行動は嘘かもしれません。少なくともあなたはそれで彼らを脅すことができ、返金プロセスを容易にします。