如何使其在本地networking中使用证书locking（HPKP）和自签名证书？

HPKP不会取代正常的validation。 相反，它是正常的validation。 因此，如果由于证书自签署而导致正常validation失败，HPKP将无法提供帮助。

是否为给定的本地主机名称（例如mylocalserver）发出自签名证书，并且在服务器响应中固定甚至有效？ 这甚至会工作吗？

是的，HPKP只是宣传给定的x.509证书的签名。 浏览器（或任何networking客户端）只在指定的时间内caching它，然后在进一步的访问中validation这个签名。

证书固定工作的本地主机名称（这将意味着，它只适用于域名）？

本地主机名称与其他主机名称一样。 即使它很短。 即使它有一个本地TLD。 问题是 – 客户端如何parsing它，以及它在HTTP请求的Host:头中的请求。 如果将主机foob​​arparsing为适当的IP，然后询问该Host:在HTTP请求中，并且自签名证书将CN设置为foob​​ar ，则整个scheme开始工作。

固定的证书是否必须首先有效或由CA（这意味着自签名的证书不能固定 – 除非它们被添加到客户端上的信任存储）？

不，他们不。 但是，不知何故，您的networking客户端应该有办法信任服务器证书。 要么将其放入受信任的服务器证书列表中，要么创build例外（实际上与以前相同），要么创build本地CA并使用本地CA证书签署服务器证书。 自签名服务器证书只是一种跳过本地CA创build的方法。 顺便说一下，所有官方的 CA使用自签名证书作为其公钥基础设施的根源。 这是创buildCA的合法方式。 官方的 CA只是一个证书被添加到最知名软件的信任库（如操作系统，浏览器等）的CA. 谈判增加成本的钱，这就是为什么他们大多不是免费的。

在本地有一个有效的SSL最简单的另一种方法是什么，所以我不需要configuration客户端（客户端信任存储）？

为您拥有的每项服务获取自签名证书。 如果你只有less数这样的服务，你处理自签名证书，如果你有几十个，你创build你的本地CA. 还有一种合法的免费方式来获得公认的X.509证书 – 只需使用LetsEncrypt证书颁发机构 – 它是免费的。 但是，它们不提供通配符证书 – 带有*通配证书，如果您拥有大量的服务，则这可能会成为问题。

我们可以看到证书locking作为可信任的CA的替代？ 我读的地方只是另外所以这意味着证书链需要先有效，然后你可以钉住它？

不。 当有人冒充目标CA时，证书locking是针对中间人攻击的对策。 为此，“某人”必须已经将他的根CA证书放入您的信任库，但这是另一个问题。

如果这个想法能够实现的话，我也越来越想。 因为那样我们会看到更多的使用这种技术。 每个人都可以生成自签名证书，只需将其插入即可…并且可以节省CA可信证书上的less量费用……或者我对整个概念有错误或正确的看法？

你一定是。

经过进一步的研究，因为我真的想深入到实际的规格。

所以RFC 7469说：

2.3.1。 公钥键响应头字段处理

如果UA通过安全传输接收到一个HTTP响应，该响应包含符合2.1节中规定的语法的PKP头字段， 并且没有潜在的安全传输错误或警告 。

所以现在正式明确的是，首先需要进行正确的SSL握手（包括对authentication链的validation），然后HPKP才会发生。