验证一个签名：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 证书管理选项。证书管理选项概述对于 TIAPortal 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 固件版本相关的证书管理选项。服务 使用 TIAPortal 进行证书管理（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 (RFC5280)。因此，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 的安全设置“保护与安全 >证书管理器”区域的特性在巡视窗口中，只有该区域内才能进行全局（即，项目级）和局部（即，设备特定）证书管理器切换（选项“使用证书管理器的全局安全设置”(Useglobal security settings forcertificatemanager)）。该选项确定了您是否有权访问项目中的所有证书。•如果在全局安全设置中未使用证书管理器，则只能访问 CPU 的局部证书存储器。例如，无法访问所导入的证书或 Root证书。如果没有这些证书，则可用功能将受到限制。例如，只能生成自签名证书。•如果在全局安全设置中使用证书管理器并以管理员身份登录，则有权访问全局（项目级）证书存储器。例如，可为 CPU分配所导入的证书，也可创建由项目 CA（项目的证书颁发机构）签发与签名的证书。下图显示了在 CPU的巡视窗中激活“使用证书管理器的全局安全设置”(Use global securitysettings for thecertificate manager) 选项后，项目树中的“全局安全设置”(Global securitysettings)显示。双击项目树中全局安全设置下的“用户登录”(User login) 并进行登录时，则将显示“证书管理器”(Certificatemanager) 行。双击“证书管理器”(Certificate manager)行，则可访问项目中的所有证书。这些证书分别位于选项卡“CA”（证书颁发机构）、“设备证书”(Device certificates)和“可信证书与 Root 证书颁发机构”(Trusted certificates and root certificateauthorities) 内。生成设备证书和服务器证书（Zui终实体证书）时，STEP 7将生成私钥。私钥的加密存储的位置，取决于证书管理器中是否使用全局安全设置：•如果使用全局安全设置，则私钥将以加密形式存储在全局（项目级）证书存储器中。• 如果未使用全局安全设置，则私钥将以加密形式在局部（CPU特定的）证书存储器中。解密数据时所需的私钥将显示在全局安全设置中证书管理器中“设备证书”(Devicecertificates)选项卡的“私钥”(Private key) 列中。下载硬件配置时，同时会将设备证书、公钥和私钥下载到 CPU中。启用“使用证书管理器的全局安全设置”(Use global security settings for thecertificatemanager) 选项 - 后果“使用证书管理器的全局安全设置”(Use global securitysettings for certificate manager)选项会影响之前所用的私钥：如果创建证书时未使用证书管理器中的全局安全设置，而且更改了使用该证书管理器的选项，则将导致私钥丢失且证书ID 发生变更。系统会发出警告，提示您注意这种情况。因此，在开始组态项目时，需指定证书管理器选项。5.6.2.3证书管理示例。如前文所述，每种类型的安全通信都需要使用证书。在以下章节中，将举例说明如何通过STEP 7进行证书管理，以满足开放式用户安全通信的要求。不同通信伙伴所用的设备往往不同。为各个通信伙伴提供所需证书的相应操作步骤也各不相同。通常需使用S7‑1500 CPU 或 S7‑1500 软件控制器，固件版本 V2.0及以上版本。基本规则为：建立安全连接（“握手”）时，通信伙伴通常仅传送Zui终实体证书（设备证书）。因此，验证已传送设备证书所需的 CA证书必须位于相应通信伙伴的证书存储器中。说明在 CPU 中，需设置当前的日期/时间。使用安全通信（如，HTTPS、安全 OUC、OPCUA）时，需确保相应模块为当前时间和当前日期。否则，模块会将所用的证书评估为无效，且无法进行安全通信。两个 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 certificatemanager) 选项。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 settingsfor certificate manager)，并以 user 身份登录全局安全设置。要将通信伙伴的自签名证书添加到 CPU中，请按以下步骤操作：1. 选择 PLC_1，并导航到“保护与安全”(Protection & Security)区域中的“伙伴设备证书”(Certificates of partner devices) 表格处。2. 在“设备证书”(Devicecertificates) 表格中，单击“证书主体”(Certificate subject) 列的一个空行，添加新的证书。3.在下拉列表中选择该通信伙伴的自签名证书，并进行确认。在下一个操作步骤中，需创建用户程序进行数据交换，并加载组态和该程序。S7-1500CPU（作为 TLS 客户端）与外部设备（作为 TLS 服务器）之间的开放式用户安全通信两个设备将通过 TLS 连接或 TLS会话进行数据交换（如，配方、生产数据或质量数据）：• S7‑1500‑CPU (PLC_1) 作为 TLS 客户端；该 CPU采用开放式用户安全通信• 外部设备（如，制造执行系统 (MES)）作为 TLS 服务器。