高级 SSL：中级证书颁发机构和部署嵌入式盒子
好的，高级 SSL 女孩们和伙计们 - 在两天的时间后我将为此添加赏金，因为我认为这是一个复杂的主题，值得为任何认真回答的人提供奖励。
这里的一些假设很简单：假设，或者更准确地说是充满希望的猜测。将此视为一个脑筋急转弯，简单地说“这是不可能的”就没有抓住重点。
如果您做过“类似”的事情，欢迎使用替代和部分解决方案，个人经验。即使我的整个计划有缺陷，我也想从中学到一些东西。
场景如下：
我正在嵌入式 Linux 系统上进行开发，并希望其 Web 服务器能够提供开箱即用、无障碍的 SSL。以下是我的设计标准：
必须具备：
- 我不能让用户将我自己开发的 CA 证书添加到他们的浏览器中
- 我不能让用户添加静态生成的证书（在制造时） ）自签名证书到他们的浏览器
- 我无法让用户将动态生成的（在启动时）自签名证书添加到他们的浏览器。
- 我无法默认使用 HTTP 并具有启用/禁用 SSL 的切换功能。它必须是 SSL。
- 嵌入式盒子和网络浏览器客户端可能有也可能没有互联网接入，因此必须假定在没有互联网接入的情况下也能正常工作。我们唯一可以依赖的根 CA 是操作系统或浏览器附带的根 CA。让我们假设该列表在浏览器和操作系统中“基本上”相同 - 即，如果我们依赖它们，我们将获得约 90% 的成功率。
- 我不能使用不可靠的操作，即“快速埃迪的 SSL 证书交换所 - 价格这么低，我们的服务器必须被黑客攻击！”
富人有福：
- 我不希望用户收到证书主机名与浏览器中的主机名不匹配的警告。我认为这是一个很好的选择，因为它可能是不可能的。
不想：
- 我不想为每个盒子提供相同的静态密钥集。有点像“不能”清单所暗示的，但我知道风险。
是的，我知道..
- 我可以并且确实为用户提供了一种上传自己的证书/密钥的机制，但我认为这种“高级模式”超出了这个问题的范围。如果用户足够先进，可以拥有自己的内部 CA 或购买密钥，那么他们就很棒，我喜欢他们。
思考时间
我在 SSL 方面的经验是生成由“真实”root 签名的证书/密钥，以及通过制作自己的内部 CA、在内部分发“自我”来加强我的游戏-签署的证书。我知道您可以链接证书，但我不确定操作顺序是什么。即浏览器“向上”链是否会看到有效的根 CA 并将其视为有效证书 - 或者您是否需要在每个级别进行验证？
我遇到了中间证书颁发机构的描述，这让我思考了潜在的解决方案。我可能已经从“简单的解决方案”变成了“噩梦模式”，但是有可能：
疯狂的想法#1
- 获得由“真正的”CA 签名的中间证书颁发机构证书。 (ICA-1)
- ROOT_CA -> ICA-1
- 该证书将在制造时用于为每个盒子生成唯一的无密码子中间证书颁发机构对。
- ICA-1-> ICA-2
- 使用 ICA-2 生成唯一的服务器证书/密钥。这里需要注意的是，您能否为 IP（而不是 DNS 名称？）生成密钥/对？即，一个潜在的用例是用户最初通过 http 连接到盒子，然后使用重定向 URL 中的 IP 将客户端重定向到 SSL 服务（这样浏览器就不会抱怨不匹配）。这张牌可能会导致房子垮掉。由于必须在发生任何重定向之前建立 SSL 连接，因此我发现这也是一个问题。但是，如果这一切都神奇地起作用，那么
- 我可以在盒子更改 IP 时使用 ICA-2 生成新的证书/密钥对，这样当 Web 服务器恢复时它总是有一个“有效”密钥链。
- ICA-2-> SP-1
好吧，你真聪明
我的复杂解决方案很可能行不通 - 但如果行的话那就太好了。你有遇到过类似的问题吗？你做了什么？权衡是什么？
Ok Advanced SSL gals and guys - I'll be adding a bounty to this after the two-day period as I think it's a complex subject that deserves a reward for anyone who thoughtfully answers.
Some of the assumptions here are simply that: assumptions, or more precisely hopeful guesses. Consider this a brain-teaser, simply saying 'This isn't possible' is missing the point.
Alternative and partial solutions are welcome, personal experience if you've done something 'similar'. I want to learn something from this even if my entire plan is flawed.
Here's the scenario:
I'm developing on an embedded Linux system and want its web server to be able to serve out-of-the-box, no-hassle SSL. Here's the design criteria I'm aiming for:
Must Haves:
- I can't have the user add my homegrown CA certificate to their browser
- I can't have the user add a statically generated (at mfg time) self-signed certificate to their browser
- I can't have the user add a dynamically generated (at boot time) self-signed certificate to their browser.
- I can't default to HTTP and have an enable/disable toggle for SSL. It must be SSL.
- Both the embedded box and the web browser client may or may not have internet access so must be assumed to function correctly without internet access. The only root CAs we can rely on are the ones shipped with operating system or the browser. Lets pretend that that list is 'basically' the same across browsers and operating systems - i.e. we'll have a ~90% success rate if we rely on them.
- I cannot use a fly-by-night operation i.e. 'Fast Eddie's SSL Certificate Clearing House -- with prices this low our servers MUST be hacked!'
Nice to Haves:
- I don't want the user warned that the certificate's hostname doesn't match the hostname in the browser. I consider this a nice-to-have because it may be impossible.
Do not want:
- I don't want to ship the same set of static keys for each box. Kind of implied by the 'can't' list, but I know the risk.
Yes Yes, I know..
- I can and do provide a mechanism for the user to upload their own cert/key but I consider this 'advanced mode' and out of scope of this question. If the user is advanced enough to have their own internal CA or purchase keys then they're awesome and I love them.
Thinking Cap Time
My experience with SSL has been generating cert/keys to be signed by 'real' root, as well as stepping up my game a little bit with making my own internal CA, distributing internally 'self-signed' certs. I know you can chain certificates, but I'm not sure what the order of operations is. i.e. Does the browser 'walk up' the chain see a valid root CA and see that as a valid certificate - or do you need to have verification at every level?
I ran across the description of intermediate certificate authority which got me thinking about potential solutions. I may have gone from 'the simple solution' to 'nightmare mode', but would it be possible to:
Crazy Idea #1
- Get an intermediate certificate authority cert signed by a 'real' CA. ( ICA-1 )
- ROOT_CA -> ICA-1
- This certificate would be used at manufacturing time to generate a unique passwordless sub-intermediate certificate authority pair per box.
- ICA-1 -> ICA-2
- Use ICA-2 to generate a unique server cert/key. The caveat here is, can you generate a key/pair for an IP (and not a DNS name?)? i.e. A potential use-case for this would be the user connects to the box initially via http, and then redirects the client to the SSL service using the IP in the redirect URL (so that the browser won't complain about mismatches). This could be the card that brings the house down. Since the SSL connection has to be established before any redirects can happen, I can see that also being a problem. But, if that all worked magically
- Could I then use the ICA-2 to generate new cert/key pairs any time the box changes IP so that when the web server comes back up it's always got a 'valid' key chain.
- ICA-2 -> SP-1
Ok, You're So Smart
Most likely, my convoluted solution won't work - but it'd be great if it did. Have you had a similar problem? What'd you do? What were the trade offs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
基本上，不，你不能按照你希望的方式做到这一点。
您不是中级 SSL 权威机构，而且您也没有能力成为其中级权威机构。即使你是，你也根本不可能被允许向消费者分发为任何域创建新的有效证书所需的一切，默认情况下在所有浏览器中都受信任。如果这是可能的，整个系统就会崩溃（并不是说它没有问题）。
通常，您无法让公共机构签署颁发给 IP 地址的证书，尽管技术上没有任何办法可以阻止。
请记住，如果您确实将私钥分发到除防篡改安全加密模块之外的任何内容中，那么您的设备并没有真正受到 SSL 的保护。拥有其中一台设备的任何人都可以提取私钥（尤其是无密码的情况下）并对您的所有设备进行有效的、签名的 MITM 攻击。你不鼓励随意窃听，但仅此而已。
您最好的选择可能是获取并签署有效互联网子域的证书，然后让设备回答该子域。如果它是传出路径中的网络设备，您可能可以执行一些路由魔法以使其响应域，类似于许多围墙花园系统的工作方式。您可以为每个系统设置类似“system432397652.example.com”的内容，然后为与该子域对应的每个框生成一个密钥。将直接 IP 访问重定向到域，或者让盒子拦截请求，或者在互联网上进行一些 DNS 欺骗，以便域解析为每个客户端的正确内部 IP。为此，请使用单一用途的主机域，不要与其他企业网站共享。
为证书支付更多费用并不会真正使它们更加合法或不合法。当一家公司成为根 CA 时，它就不再是不可靠的操作了。您应该检查 StartSSL 是否适合您的需求，因为它们不会对每个证书收费基础。
Basically, no, you can't do this the way you hope to.
You aren't an intermediate SSL authority, and you can't afford to become one. Even if you were, there's no way in hell you'd be allowed to distribute to consumers everything necessary to create new valid certificates for any domain, trusted by default in all browsers. If this were possible, the entire system would come tumbling down (not that it doesn't already have problems).
You can't generally get the public authorities to sign certificates issued to IP addresses, though there's nothing technically preventing it.
Keep in mind that if you're really distributing the private keys in anything but tamper-proof secured crypto modules, your devices aren't really secured by SSL. Anyone who has one of the devices can pull the private key (especially if it's passwordless) and do valid, signed, MITM attacks on all your devices. You discourage casual eavesdropping, but that's about it.
Your best option is probably to get and sign certificates for a valid internet subdomain, and then get the device to answer for that subdomain. If it's a network device in the outgoing path, you can probably do some routing magic to make it answer for the domain, similarly to how many walled-garden systems work. You could have something like "system432397652.example.com" for each system, and then generate a key for each box that corresponds to that subdomain. Have direct IP access redirect to the domain, and either have the box intercept the request, or do some DNS trickery on the internet so that the domain resolves to the correct internal IP for each client. Use a single-purpose host domain for that, don't share with your other business websites.
Paying more for certificates doesn't really make them any more or less legit. By the time a company has become a root CA, it's far from a fly-by-night operation. You should check and see if StartSSL is right for your needs, since they don't charge on a per-certificate basis.