在我的拙见中，这似乎是一件可怕的事情。我要写信给他们，拒绝他们，并要求续订CSR，这次保留私钥-私有。
在愚弄自己之前，我想确认一下
我已经在与安全性相关的行业工作了很多年，并且曾经是加密程序员，所以我觉得我有点了解这个主题-但我知道事情会随着时间而改变。
我已经阅读了以下相关问题：
共享SSL证书的私钥会引起什么问题？
元更新：我意识到我为Stack Exchange写的质量很差，因为现在很难接受特定的答案。对此表示歉意-所有答案都涵盖了不同且同样有趣的方面。我最初确实想知道如何为此目的写词，但留了空白。
更新：我已经与主持人一起遵循了这一做法，他们确实“对由此带来的任何不便表示歉意”，并承诺保留将来的私钥“安全”，并向我发布了新的，不同的CSR。我目前不确定它是否是从相同的公开私钥生成的。我现在还想知道，因为它是共享主机，所以他们是否已将整个服务器的密钥发送给我，还是每个客户/域/虚拟主机都获得了密钥对。
这是一个有趣的课程，如何通过一个简单的人为错误就可以使世界上所有的加密强度失效。凯文·米特尼克（Kevin Mitnik）会点头。
更新2：
为了回应用户@Beau的回答，我使用以下命令来验证第二个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
前两个哈希值相同，第三个哈希值不同。所以那就是个好消息。
#1 楼
如果我在您的位置，我将拒绝接受此SSL证书。原因是，如果有人闯入了收到私钥的任何一封电子邮件，他们便可以下载并假冒服务器对客户端的攻击方式不同，例如中间人或类似人员。
如果接收电子邮件地址之一写有误，则可能有人已经拥有私钥。可能还有更多方案可以由攻击者下载和使用此私钥。
通知公司不共享私钥也很重要，以确保公司不会无法将私钥发送到其他任何地方-私钥已发送给您，并且此电子邮件中还有其他抄送人，但是您无法知道公司是否未在其他地方发送带有私钥的单独电子邮件。
将私钥称为私钥是有原因的。
请注意，这主要是我个人的观点，我不是SSL专家。
评论
是的，关于教育他们的好点。
–密码
17年4月12日在12:54
在这一点上，切换到真正了解私钥性质的公司是否更有意义？证书发行者愉快地通过电子邮件向多个收件人发送私钥，似乎并不知道它在做什么，并且显示自己不称职，恕我直言。
– code_dredd
17年4月15日在12:18
@ray很好，如果您切换公司，则您会更安全，但是如果您要教育他们，则他们所有的客户都将是安全的。如果教育他们无济于事，那是的，换公司是明智的，但是在这一点上，显而易见
– vakus
17年4月15日在13:38
@vakus如果您想投资于教育一个应该已经了解更多的人，那取决于您。只需记住，在公司外部您会看到不良的安全实践，这暗示了您可能从未发现过的更深层次的问题（例如，您如何知道他们没有将密匙密密麻麻地指向其他地址，或更糟？），因此无法对他们进行教育。您需要确定打算“吸引”客户的风险。对他们进行教育并不意味着您必须继续作为他们的客户。离开可能会给他们更大的动力去自我修复
– code_dredd
17-4-15在13:49
#2 楼
是的，您绝对应该拒绝CSR。此外，您应该更改托管服务提供商，因为他们似乎不知道自己在做什么。已经很糟糕了，他们通过电子邮件（即通过不安全的方式）向您发送了私钥中。但是，他们也将其抄送给其他人，这完全违反了机密性。
此外，我想知道为什么他们向您发送了私钥-应该将其安装在服务器上，这是他们可以自己完成的事情。
评论
他们抄送了该帐户上的其他联系人（非技术人员）。是的，我想知道为什么呢，那真的是我的问题。仍然没有理由-只要确保我没有在这里错过备忘录即可。
–密码
17年4月12日在12:55
好的，所以这不像他们将私钥发送给您不认识的人。重点仍然成立。
–dr_
17年4月12日在12:57
@ dr01当然可以。邮件过程中想要读取的所有邮件服务器管理员，路由器管理员和防火墙管理员。
– DRF
17年4月12日在20:42
@ dr01我认为，如果您通过电子邮件发送信息，除非对其进行加密，否则您会自愿将其披露给它弹起的每台计算机，直到到达目的地为止。
–亚伦·霍尔
17年4月13日在18:27
+1告诉OP切换供应商，该供应商已经证明了其对自己领域的无知。
– code_dredd
17年4月15日在12:24
#3 楼
是的，您绝对应该拒绝CSR。关于是否应该重新考虑托管服务提供商，这取决于。
他们甚至还抄送了别人，
托管公司为什么应该知道您的内部公司结构？执行此操作的人员是否是专门分配给您公司的指定客户经理，负责了解谁是您公司的人？贵公司是否向客户经理提供了有关贵公司的组织结构以及谁有权进行操作的充分介绍？如果不是，那么可能是您（公司）未明确告知他们应如何将密钥发送给您的部分错误。
在大多数托管帐户中，如果您没有指定熟悉您业务范围的客户经理，您应该向他们的技术支持非常明确地说明如何将密钥发送给您，应该由谁接收密钥以及您是否首先希望接收密钥。不要以为技术支持人员知道您公司的情况，也不要以为不是您指定的客户经理的技术支持人员来记住您以前的互动。
，它在Gmail中
您确实意识到通过电子邮件发送CSR也不是很安全吗？某人（在Gmail或APT中工作的内部人员）很可能会截获包含CSR的电子邮件，将主机发送给您的CSR替换为自己的CSR，然后将托管公司的CSR签名给托管公司。这将允许他们以后在您和您的用户以及托管公司之间使用伪造的证书到MITM。
CSR必须通过经过身份验证的渠道交付（例如，他们将证书提交到您控制的HTTPS站点，或者他们应该使用在其站点上发布的GPG密钥对CSR进行签名），或者至少您应该进行指纹验证，并且两者您和您的房东需要有一种方法来识别和认证对方。设置经过身份验证的渠道可能是一个相当复杂的过程，在低成本托管服务提供商或不专门从事高安全性业务托管的服务提供商中将不可用。
不要指定您的公司如何要求交付CSR，特别是如果您不由客户经理来处理，而该客户经理应该知道您正在从事哪种业务，那么大多数托管公司会合理地假设您是最低安全性公司。在最低安全性公司工作的大多数人会认为，拥有私钥的副本比不控制密钥的安全性具有更高的价值，让他们从您那里承担责任并非没有道理。
评论
某人...截获包含CSR的电子邮件很有可能-您是否具有链接或更多有关此内容的信息？我正在尝试遵循这将如何工作。
– Zoredache
17年4月12日在18:42
@Zoredache超级容易。您在Google工作。您运行脚本来查找Gmail数据库中最近5分钟内发送给用户的未送达电子邮件，其中包含看似私有密钥的有效内容。您将此电子邮件临时移到暂存区域，以便不传递，然后制作备用有效负载。然后，将带有恶意有效负载的修改后的电子邮件放回数据库中，用户将在其中将其视为又一个预期的良好电子邮件。
– ErikE
17年4月12日在20:11
@ErikE当然，如果发送私钥存在问题，但是LieRyan的回答说，仅电子邮件中的CSR可能会被滥用。我没有遵循仅提供CSR的情况下如何使用MITM。除非您认为攻击者可以拦截CSR并将其设置为MITM，否则所有对该证书实际上是为其颁发的服务器的访问。
– Zoredache
17年4月12日在20:55
@Zoredache本身传输CSR（当然没有私钥）不会带来安全风险。请求者已生成一个他希望绑定到要保护的实体的私钥-公钥对（例如，与www.example.com的https网站一起使用），并请可信签名人签名并确认公钥和绑定实体之间存在这种联系。确实需要以安全的带外方式进行，而是由受信任的受保护实体控制的某人发布CSR的验证过程。
–哈根·冯·埃森（Hagen von Eitzen）
17-4-12在21:24
@Zoredache：是的，我指的是也可以设置MITM的人，例如Web主机数据中心/上游网络路径中任何系统的管理员，或者运行广泛使用的Public DNS的人。可以拦截您邮件的人至少可以修改您的电子邮件，使其包含两个CSR（真实的CSR和伪造的CSR），并告诉您一个合理的掩盖故事，例如在冗余冗余负载均衡器中安装单独的证书，而HSM不支持私钥导出。
– Lie Ryan
17年4月13日在0:34
#4 楼
在愚弄自己之前，我想确认“ SSL”（TLS）证书的私钥永远不要离开服务器吗？
它取决于，离开服务器可能有充分的理由。例如，您可能要在服务器服务器上使用相同的证书，或者可能需要备份密钥进行密钥固定。
但绝对应该将其视为有价值的秘密，仅存储在您信任和信任的计算机上。如果确实需要在系统之间移动，则应以适当的安全方式进行。
我的建议是立即远离这些小丑。
评论
好一点，我过去也自己做过。我这样做感到非常紧张，并使用SSH将其直接传输到第二台主机。
–密码
17年4月12日在22:41
#5 楼
他们可能希望您拥有整个密钥/证书对，以防您想在其他地方使用它。使私钥浮动是一个合理的安全隐患，尤其是如果您不打算使用它时。说明此证书仅适用于托管服务提供商，并请他们重新发布CSR并发送不带私钥的证书。验证CSR指纹是否已更改。
听起来像它们将证书视为使绿色锁比安全设备更像是一种方式，这可能是一个警告信号。如果可能和/或您的网站处理非常敏感的信息，请考虑使用其他托管服务。
#6 楼
他们在安全方面完全无能。根据定义，私钥是错误的。它用于合法地识别其所有者。他们使伪造和假冒成为可能。您应该从私钥/公钥对中自己生成CSR后，再将其发送给CSR，并且应该向您发送签名证书及其身份验证链。没有别的。
如果它们向您发送私钥和CSR，则它们的整个模型都将损坏。
更改提供者，并取回您的钱。至少。他们损害了您的安全，因此可能会提出损失和损坏的诉讼。至少您可以用它来威胁他们，以简化退款程序。
评论
我敢肯定，从技术上讲，它不会合法地识别其所有者。
–莫妮卡基金的诉讼
17年4月13日在18:47
我认为您在这里误解了提供程序的角色（除非我有）：他们没有颁发证书，而是将其安装到OP仅限制访问的服务器上。 OP无法生成密钥对，因为他们无权将私钥安装到Web服务器配置中。如果这样做，他们将需要将私钥传输到主机。生成密钥对并发送CSR的主机似乎绝对是正确的过程，但是他们通过共享私钥而错过了重点。
–IMSoP
17-4-13在19:54
@QPaysTaxes具有私钥的数字签名在法律上可以强制执行，因为它完全等同于合同或支票上的个人签名。
–user207421
17-4-14在0:52
@IMSoP如果有多个人拥有私钥，则它不是私钥。如果如此解释提供者的角色，那将是完全不安全的。完全发送它完全违反了PKI。
–user207421
17-4-14在0:53
@EJP是的，我明白了。但是您错过了原始问题中的要点，即应该拥有此特定私钥的人是虚拟主机。我们都同意他们通过共享来做错了，但是您关于OP应该生成自己的密钥对的建议是没有意义的，因为私钥必须最终存储在服务器配置中，只有托管公司才能访问它。
–IMSoP
17年4月14日在12:28
评论
“而且它在Gmail中，因此Google可能已经出于广告目的将其摄取了。”您知道Google运行自己的CA，并且可以将自己喜欢的任何CA证书插入Chrome吗？在这种情况下，Google可能是最不感兴趣的公司之一。是的，我不担心Google本身（我已经把生命托付给他们了！），而只是强调了我们的个人内容在如今已经到达目的地的今天所经历的额外旅程。
抱歉，我没有对此发表评论-我的代表人数不足。但是您可以使用一些openssl命令将新的CSR与原始私钥进行比较：sslshopper.com/certificate-key-matcher.html。如果每个的模数不同，那么您就可以了。不过，我不确定我是否会信任供应商的安全实践。毕竟，安全完全取决于信任。
在这一点上，转向一家真正了解私钥性质的公司可能更有意义，恕我直言。证书发行者愉快地通过电子邮件向多个收件人发送私钥，似乎并不知道它在做什么，并且表明自己不称职。使用certbot是否有问题？这就是我用于服务器的内容。
@Pharap严重高估了个人私人信息的价值。真的，没有人关心您可能拥有的秘密，Facebook暗恋，聊天记录以及存储在WhatsApp备份中的可能内容。很难承认我们并不那么有趣，而且我们大多数人只是普通的无聊。真正的价值来自海量的汇总数据，与数据集相比，您的个性化为虚无。除非您当然是普京最热衷的青少年女友或F500首席执行官，否则我们的个性化私人数据就是不值得的。