shole's questions

我有一个注册的 RHEL9 VM，最近我通过从最新的 Veeam 备份恢复克隆了它的副本。

然后我更改了 IP、网关、/etc/hosts文件并重新生成/etc/machine-id文件（也/var/lib/dbus/machine-id）

然后我在两台虚拟机上执行了subscription-manager unregister和subscription-manager clean。我还登录了 Redhat Hybrid Cloud Console 的 Web 控制台，检查没有注册相关系统。

然后我subscrption-manager register对两个虚拟机都执行了此操作，并期望 Redhat 混合云控制台上会有两个新条目。但是，我发现始终只有一个条目，并且虚拟机似乎在互相覆盖。

我已经检查过它们有两个不同的 IP、机器 ID 和订阅管理器身份，但当我尝试注册两者时，Redhat 似乎仍将它们视为同一个系统。

我的问题是这种行为的可能原因是什么以及如何正确解决它？

2025-01-06 快速更新：

按照建议的答案，我尝试更新 MAC 地址，但 Redhat 似乎仍然无法分辨它们是两个不同的虚拟机。以下是我当前对原始虚拟机和恢复的虚拟机的配置。

• 原始虚拟机：

IP 和 MAC 地址

/etc/machine-id 和 /var/lib/dbus/machine-id

订阅管理者身份

• 已还原的虚拟机：

IP 和 MAC 地址

/etc/machine-id 和 /var/lib/dbus/machine-id

订阅管理者身份

我对服务器和网络世界还很陌生，我希望问题很清楚，不要那么琐碎。我最近遇到了以下场景：

1. 有一个根证书 A，它将在几个月后到期。还有另一个新的根证书 B，旨在替代 A。A 和 B 都是自签名的。A 的 CA 受新旧浏览器/OS 信任，而 B 的 CA 仅受现代浏览器/OS 信任

2. 我们的服务器目前正在使用交叉证书 A->B（B 由 A 签名）。然而，由于 A 即将到期，我们应用了另一个交叉证书 C->B（B 由 C 签名，C 的 CA 被新旧浏览器/操作系统信任）作为替代。

3. 现在，在 UAT 环境中，我们更新证书 C->B，对于客户端，我尝试使用一些旧版浏览器进行测试，我验证了只有 A 的 CA 和 C 的 CA 是可信的，而 B 的 CA 不是。对于 PROD 环境，我们保持不变，即使用证书 A->B

4. 我使用提到的浏览器访问 UAT 站点，并首次验证使用的证书是 A->B。令人惊讶的是，对于后续访问 UAT 和 PROD 站点，使用的证书是 C->B（在客户端检查）。

我的问题是，这是正常行为吗？为什么自从第一次访问 UAT 站点以来，客户端“知道”使用 C->B？我还使用openssl s_client验证 PROD 服务器是否仍在使用 A->B。浏览器如何知道要使用哪个证书并相应地“更新”证书？

编辑于 2022-Dec-13

1. 我们的主要目的是支持非常旧的浏览器/操作系统和现代浏览器/操作系统。即即使证书A过期，所有浏览器都可以成功访问我们的站点。
2. 我认为我的主要问题或怀疑是，如果以下内容为真：

• 旧版浏览器，第一次访问UAT站点，由于某种缓存机制，显示服务器正在使用证书A->B
• 在第一次访问 UAT 站点后，服务器实际上将新证书 C->B“推送”到在服务器中配置的客户端。现在，浏览器，甚至操作系统级别都承认最新的证书是 C->B，而不是 A->B。
• 尽管 C->B 已被确认，但证书 A->B 仍保存在浏览器/操作系统中。但是浏览器以某种方式知道要使用较新的证书 C->B 进行验证。意味着我们的目的可以实现。