SIEMENS西门子 软起动器 3RW40746BB44

       验证一个签名：1. “MyCert”证书的认证方将获得签发者签发的证书和公钥。2. 使用签名时所用的哈希算法（例如，SHA-1），根据证书数据生成一个新的哈希值。3. Zui后，再将由证书签发者公钥确定的 HASH 值与签名算法进行比较，对签名进行检查。4. 如果签名通过检查，则表示证书主体的身份以及完整性（即，证书内容的可靠性和真实性）均通过验证。拥有该公钥（即，证书颁发机构的证书）的任何人均可对该签名进行检查，并确认该证书确实由该证书颁发机构签发。下图显示了 Alice 如何采用 Twent（代表证书颁发机构，CA）证书中的公钥，验证 Bob 的公钥签名。因此，在验证时仅需检查证书颁发机构所颁发证书的可用性。验证会在 TLS 会话中自动执行。签名消息上文中介绍的证书签名与验证机制，同样使用 TLS 会话对消息进行签名和验证：如果发送方基于一条消息生成一个 HASH 值并使用私钥进行加密，之后在添加到原消息中，则消息接收方即可对消息的完整性进行检查。接收方使用发送方的公钥对该 HASH 值进行解密，并将其与所收到消息中的 HASH 进行比较。如果这两个值不同，则表示该消息或加密的 HASH值在传送过程中被篡改。Root 证书的证书链PKI 证书通常按层级进行组织：层级顶部由根证书构成。Root 证书并非由上一级证书颁发机构签名。Root 证书的证书主体与证书的签发者相同。根证书享受juedui信任。它们构成了信任“点”，因此可作为接收方的可信证书。此类证书存储在专门存储受信证书的区域。基于该 PKI，Root 证书可用于对下级证书颁发机构颁发的证书（即，所谓的中间证书）进行签名。从而实现从 Root 根证书到中间证书信任关系的传递。由于中间证书可对诸如 Root 证书之类的证书进行签名，因此这两种证书均称为“CA 证书”这种证书签名层级可通过多个中间证书进行延伸，直至Zui底层的实体证书。Zui终实体证书即为待识别用户的证书。验证过程则反向贯穿整个层级结构：，先通过签发者的公钥确定证书签发者并对其签名进行检查，之后再沿着整条信任链确定上一级证书签发者的证书，直至到达根证书。结论：无论组态何种安全通信类型，每台设备中都必需包含一条到 Root 证书的中间证书链（即证书路径），对通信伙伴的Zui低层实体证书进行验证。证书管理的必备知识本节介绍了根据所使用的服务（CPU 应用程序）以及 TIA Portal/CPU 固件的版本提供的相应S7-1500 CPU 证书管理选项。证书管理选项概述对于 TIA Portal V14 和 CPU 固件版本 V2.0 及更高版本，可以在 TIA Portal 中管理 S7-1500CPU 的不同服务之间实现安全通信的证书并将其下载到 CPU 中。对于 TIA Portal V17 以及 S7-1500 CPU 固件版本 V2.9 及更高版本，支持另一种证书管理方式：使用 GDS 推送方法，可以在 CPU 运行期间传输或更新证书，而无需重新下载 CPU。采用同一方式，自 TIA Portal V18 起，还可以传输 S7-1500 CPU（自固件 V3.0 起）的 Web 服务器证书。下表概述了与所使用的服务以及 TIA Portal 固件版本或 CPU 固件版本相关的证书管理选项。服务 使用 TIA Portal 进行证书管理（TIA Portal 版本/S7-1500 CPU 固件版本）使用 OPC UA GDS 推送方法进行证书管理（TIA Portal 版本/S7-1500 CPU 固件版本）Web 服务器 自 V14 起/自 V2.0 起 自 V18 起/自 V3.0 起安全 OUC 通信 自 V14 起/自 V2.0 起 -OPC UA 服务器 自 V14 起/自 V2.0 起 自 V17 起/自 V2.9 起OPC UA 客户端 自 V15.1 起/自 V2.6 起 -安全 PG/HMI 通信 自 V17 起/自 V2.9 起 -更多信息单击此处了解使用 GDS 推送方法进行证书管理的说明：通过全球发现服务器 (GDS) 实现证书管理 (页 166)5.6.2.2 使用 TIA Portal 进行证书管理STEP 7 V14 及更高版本与 S7‑1500-CPU 固件版本 V2.0 及更高版本一同使用时，支持 InternetPKI (RFC 5280)。因此，S7‑1500 CPU 可与同样支持 Internet PKI 的设备进行数据通信。如，可使用 X.509 证书验证上文中所介绍的证书。STEP 7 V14 及更高版本采用的 PKI 与 Internet PKI 类似。例如，证书吊销列表 (CRL) 不受支持。在 TIA Portal 中创建或分配证书对于具有安全特性的设备（如，S7-1500 CPU 固件版本 V2.0 及以上版本），可在 STEP 7 中根据不同应用创建特定的证书。53通信服务5.6 安全通信通信功能手册, 11/2023, A5E03735819-AL在 CPU 巡视窗口的以下区域内，可创建新的证书或选择现有的证书：• “Web 服务器 > 安全”(Web server > Security) - 用于生成和分配 Web 服务器证书。• “保护和安全 > 连接机制”(Protection & Security > Connection mechanisms) - 用于生成或分配 PLC 通信证书（TIA Portal V17 及以上版本的 PG/HMI 间安全通信）。• “保护和安全 > 证书管理器”(Protection & Security > Certificate manager)- 用于生成和分配所有类型的证书。生成证书时，将预设开放式用户安全通信的 TLS 证书。• “OPC UA > 服务器 > 安全”(OPC UA > Server > Security) - 用于生成或分配 OPC UA 服务器证书。图 5-11  STEP 7 中 S7‑1500 CPU 的安全设置“保护与安全 > 证书管理器”区域的特性在巡视窗口中，只有该区域内才能进行全局（即，项目级）和局部（即，设备特定）证书管理器切换（选项“使用证书管理器的全局安全设置”(Use global security settings for certificatemanager)）。该选项确定了您是否有权访问项目中的所有证书。• 如果在全局安全设置中未使用证书管理器，则只能访问 CPU 的局部证书存储器。例如，无法访问所导入的证书或 Root 证书。如果没有这些证书，则可用功能将受到限制。例如，只能生成自签名证书。• 如果在全局安全设置中使用证书管理器并以管理员身份登录，则有权访问全局（项目级）证书存储器。例如，可为 CPU 分配所导入的证书，也可创建由项目 CA（项目的证书颁发机构）签发与签名的证书。下图显示了在 CPU 的巡视窗中激活“使用证书管理器的全局安全设置”(Use global securitysettings for the certificate manager) 选项后，项目树中的“全局安全设置”(Global securitysettings) 显示。双击项目树中全局安全设置下的“用户登录”(User login) 并进行登录时，则将显示“证书管理器”(Certificate manager) 行。双击“证书管理器”(Certificate manager) 行，则可访问项目中的所有证书。这些证书分别位于选项卡“CA”（证书颁发机构）、“设备证书”(Device certificates) 和“可信证书与 Root 证书颁发机构”(Trusted certificates and root certificate authorities) 内。生成设备证书和服务器证书（Zui终实体证书）时，STEP 7 将生成私钥。私钥的加密存储的位置，取决于证书管理器中是否使用全局安全设置：• 如果使用全局安全设置，则私钥将以加密形式存储在全局（项目级）证书存储器中。• 如果未使用全局安全设置，则私钥将以加密形式在局部（CPU 特定的）证书存储器中。解密数据时所需的私钥将显示在全局安全设置中证书管理器中“设备证书”(Device certificates)选项卡的“私钥”(Private key) 列中。下载硬件配置时，同时会将设备证书、公钥和私钥下载到 CPU 中。启用“使用证书管理器的全局安全设置”(Use global security settings for the certificatemanager) 选项 - 后果“使用证书管理器的全局安全设置”(Use global security settings for certificate manager) 选项会影响之前所用的私钥：如果创建证书时未使用证书管理器中的全局安全设置，而且更改了使用该证书管理器的选项，则将导致私钥丢失且证书 ID 发生变更。系统会发出警告，提示您注意这种情况。因此，在开始组态项目时，需指定证书管理器选项。5.6.2.3 证书管理示例。如前文所述，每种类型的安全通信都需要使用证书。在以下章节中，将举例说明如何通过STEP 7 进行证书管理，以满足开放式用户安全通信的要求。不同通信伙伴所用的设备往往不同。为各个通信伙伴提供所需证书的相应操作步骤也各不相同。通常需使用 S7‑1500 CPU 或 S7‑1500 软件控制器，固件版本 V2.0 及以上版本。基本规则为：建立安全连接（“握手”）时，通信伙伴通常仅传送Zui终实体证书（设备证书）。因此，验证已传送设备证书所需的 CA 证书必须位于相应通信伙伴的证书存储器中。说明在 CPU 中，需设置当前的日期/时间。使用安全通信（如，HTTPS、安全 OUC、OPC UA）时，需确保相应模块为当前时间和当前日期。否则，模块会将所用的证书评估为无效，且无法进行安全通信。两个 S7-1500 CPU 之间的开放式用户安全通信两个 S7-1500 CPU（PLC_1 和 PLC_2）之间通过开放式用户安全通信进行数据交换。使用 STEP 7 生成所需的设备证书，然后将其分配给 CPU，如下所述。STEP 7 项目证书颁发机构（项目的 CA）用于对设备证书进行签名。在用户程序中根据证书 ID 对证书进行引用（TCON 通信指令组合相关的系统数据类型，例如TCON_IPV4_SEC）。在生成或创建证书时，STEP 7 将自动分配证书 ID。

      操作步骤STEP 7 自动将所需的 CA 证书与硬件配置一同加载到通信伙伴的 CPU 中，确保两个 CPU 中满足证书验证需求。因此，用户只需生成相应 CPU 的设备证书，其余操作将由 STEP 7 完成。1. 在“保护和安全”(Protection & Security) 区域中，标记 PLC_1 并激活“使用证书管理器的全局安全设置”(Use global security settings for certificate manager) 选项。2. 在项目树的“全局安全设置”(Global security settings) 区域中，以 user 身份进行登录。对于新项目，首次登录时的身份为“Administrator”。3. 返回“保护与安全”(Protection & Security) 区域的 PLC‑1 中。在“设备证书”(Devicecertificates) 表格中，单击“证书主体”(Certificate subject) 列的一个空行，添加新的证书。4. 在下拉列表中，选择一个证书并单击“添加”(Add) 按钮。“创建证书”(Create Certificate) 对话框随即打开。5. 保留该对话框中的默认设置。这些设置专用于开放式用户安全通信（用途：TLS）。提示：补充证书主体的默认名称（此时，为 CPU 名称。为了便于区分，需管理大量设备证书时，建议保留系统默认的 CPU 名称。示例：PLC_1/TLS 变为 PLC_1-SecOUC-Chassis17FactoryState。6. 编译组态。设备证书和 CA 证书是组态的一部分。7. 对于 PLC_2，重复以上操作步骤。在下一个操作步骤中，需创建用户程序进行数据交换，并加载组态和该程序。使用自签名证书而非 CA 证书创建设备证书时，可选择“自签名”(Self-signed) 选项。即使在未登录，也可创建自签名证书进行全局安全设置。但不建议执行该操作。这是因为，采用这种方式创建的证书不会保存在全局证书存储器中，也无法直接分配给伙伴 CPU。如上文所述，选择证书的主体名称时需小心谨慎，以确保为设备指定的证书正确无误。对于自签名证书，无法通过 STEP 7 项目的 CA 证书进行验证。要确保自签名证书可通过验证，需要将通信伙伴的自签名证书加入每个 CPU 的可信伙伴设备列表中。为此，必须激活选项“使用证书管理器的全局安全设置”(Use global security settings for certificate manager)，并以 user 身份登录全局安全设置。要将通信伙伴的自签名证书添加到 CPU 中，请按以下步骤操作：1. 选择 PLC_1，并导航到“保护与安全”(Protection & Security) 区域中的“伙伴设备证书”(Certificates of partner devices) 表格处。2. 在“设备证书”(Device certificates) 表格中，单击“证书主体”(Certificate subject) 列的一个空行，添加新的证书。3. 在下拉列表中选择该通信伙伴的自签名证书，并进行确认。在下一个操作步骤中，需创建用户程序进行数据交换，并加载组态和该程序。S7-1500 CPU（作为 TLS 客户端）与外部设备（作为 TLS 服务器）之间的开放式用户安全通信两个设备将通过 TLS 连接或 TLS 会话进行数据交换（如，配方、生产数据或质量数据）：• S7‑1500‑CPU (PLC_1) 作为 TLS 客户端；该 CPU 采用开放式用户安全通信• 外部设备（如，制造执行系统 (MES)）作为 TLS 服务器。