西门子工业工控机经销总代理商通过位串，无法指定公钥的身份。欺瞒者可使用他们自己的公钥声明为其他人。如果第三方使用该公钥将其认作是指定的通信伙伴，则将导致机密信息被窃取。之后，欺瞒者再使用自己的密钥对这些本消息进行解密，虽然这些消息本不应发送给他们。Zui终，导致敏感信息泄露，落入他人之手。为了有效预防此类错误的发生，该通信伙伴必须确信与正确的通信伙伴进行数据通信。此类信任关系是通过PKI 中的数字证书建立的。5.6.1.4通过签名确保数据的真实性和完整性由能够截获服务器与客户端之间的通信并将自身伪装成客户端或服务器的程序实施的攻击称为中间人攻击。如果未能检测到这些程序的真实身份，则将造成诸如S7 程序、CPU中设定值等重要信息泄漏，进而导致设备或工厂遭受攻击。可使用数字证书避免此类攻击。在安全通信过程中，所用的数字证书符合International Telecommunication Union (ITU) 的X.509标准。该证书用于检查（认证）程序、计算机或组织机构的身份。如何通过证书建立信任关系X.509证书主要用于将带有证书的数据身份（如，电子邮件地址或计算机名称）与公钥中的身份绑定在一起。身份可以是个人、计算机，也可以是机器设备。证书由证书颁发机构（CertificateAuthority，CA）或证书主体签发。而 PKI 系统则指定了用户信任证书颁发机构及其所签发证书的规则。证书认证过程：1.要获取一份证书，需要向与证书颁发机构相关联的注册机构提交一份证书申请。2. 证书颁发机构将基于既定标准对该申请和申请人进行评估。3.如果可以清晰识别申请人的身份，则证书颁发机构将签发一份已签名的证书进行确认。申请人现成为证书主体。在下图中，对这一过程进行了简要说明。但不涉及Alice 对该数字签名的检查过程。
工控机等工业自动化的设计、技术开发、项目选型安装调试等相关服务是专业从事工业自动化控制系统、机电一体化装备和信息化软件系统
集成和硬件维护服务的综合性企业。与西门子品牌合作，只为能给中国的客户提供值得信赖的服务体系，我们
的业务范围涉及工业自动化科技产品的设计开发、技术服务、安装调试、销售及配套服务领域。建立现代化仓
储基地、积累充足的产品储备、引入万余款各式工业自动化科技产品，我们以持续的卓越与服务，取得了年销
售额10亿元的佳绩，凭高满意的服务赢得了社会各界的好评及青睐。其产品范围包括西门子S7-SMART200、S7-200CN、S7-300、S7-400、S7-1200、S7-1500、S7-ET200SP等各类工业自动化产品。西门子授权代理商、西门子一级代理商 西门子PLC模块代理商﹐西门子模块代理商供应全国范围：
与此同时，我们还提供。
西门子中国授权代理商——浔之漫智控技术（上海）有限公司，本公司坐落于松江工业区西部科技园，西边和全球zhuming芯片制造商台积电毗邻，
东边是松江大学城，向北5公里是佘山国家旅游度假区。轨道交通9号线、沪杭高速公路、同三国道、松闵路等
交通主干道将松江工业区与上海市内外连接，交通十分便利。
目前，浔之漫智控技术（上海）有限公司将产品布局于中、高端自动化科技产品领域，
PLC模块S7-200、S7-1200、S7-300、S7-400、ET200分布式I/O等
HMI触摸屏、SITOP电源、6GK网络产品、ET200分布式I/O SIEMENS驱动产品MM系列变频器、G110 G120变频器、直流调速器、电线电缆、
驱动伺服产品、数控设备SIEMENS低压配电与控制产品及软起动器等
用户也可以自己创建证书并签名，对发送给通信伙伴的消息进行加密。在上述示例中，Bob（而非Twent）可以使用私钥对自己的证书进行签名。之后，Alice 将使用 Bob 的公钥检查该签名是否与 Bob的公钥相匹配。该过程可用于简单的工厂内部数据加密通信。• 例如，根证书是一种由证书颁发机构 (CA)签署的自签名证书，其中包含证书颁发机构的公钥。自签名证书的特性自签名证书的证书主体“CN”(Common Name ofSubject) 和“Issuer”属性相同：用户已完成对证书的签名。字段“CA” (Certificate Autority)需设置为“False”；自签名证书不得用于对其它证书进行签名。自签名证书未包含在 PKI 系统中。证书内容符合 X.509 V3标准（同样用于 STEP 7 和 S7-1500 CPU）要求的证书通常包含以下元素：• 公钥•证书主体（即，密钥持有者）的详细信息。如，Common Name (CN) of Subject 。•各种属性，如序列号和有效期等等• 证书颁发机构 (CA) 的数字签名，用于证实信息的正确性。除此之外，还包含以下扩展详细：•指定公钥的使用范围(Key Usage)，如签名或密钥加密。在开放式用户安全通信中，使用 STEP 7创建一个新证书时，可从用途列表中选择相应的条目，如“TLS”。• 指定 Subject Alternative Name(SAN)，用于与 Web 服务器进行安全通信 (HTTP overTLS)，以确保 Web 浏览器地址栏中的证书同样属于该 URL所指定的 Web服务器。如何生成并验证签名非对称密钥可用于证书的验证：在“MyCert”证书示例中，介绍了具体的“签名”与“验证签名”过程。生成签名：1.“MyCert”证书的签发者使用一个特定的哈希函数（例如，SHA-1，SecureHashAlgorithm），根据证书数据生成一个哈希值。该 HASH 值是一个长度固定的位串。HASH值长度固定的优势在于，签名的时间始终相同。2. 之后，证书的签发者再使用由这种方式生成的 HASH值和私钥，生成一个数字签名。通常采用 RSA 签名机制。3. 数字签名将保存在证书中。此时，证书已签名。验证一个签名：1.“MyCert”证书的认证方将获得签发者签发的证书和公钥。2.使用签名时所用的哈希算法（例如，SHA-1），根据证书数据生成一个新的哈希值。3. Zui后，再将由证书签发者公钥确定的 HASH值与签名算法进行比较，对签名进行检查。4.如果签名通过检查，则表示证书主体的身份以及完整性（即，证书内容的可靠性和真实性）均通过验证。拥有该公钥（即，证书颁发机构的证书）的任何人均可对该签名进行检查，并确认该证书确实由该证书颁发机构签发。下图显示了Alice 如何采用 Twent（代表证书颁发机构，CA）证书中的公钥，验证 Bob的公钥签名。因此，在验证时仅需检查证书颁发机构所颁发证书的可用性。验证会在 TLS会话中自动执行。$OLFH䙊䗷7ZHQW&$ᨀⲴޜ䫕ሩ%REⲴㆮ䘋㹼傼䇱 &$7ZHQW&$%RE图5-10 使用证书颁发机构的证书公钥对证书进行验证签名消息上文中介绍的证书签名与验证机制，同样使用 TLS会话对消息进行签名和验证：如果发送方基于一条消息生成一个 HASH值并使用私钥进行加密，之后在添加到原消息中，则消息接收方即可对消息的完整性进行检查。接收方使用发送方的公钥对该 HASH值进行解密，并将其与所收到消息中的 HASH 进行比较。如果这两个值不同，则表示该消息或加密的 HASH值在传送过程中被篡改。Root证书的证书链PKI 证书通常按层级进行组织：层级顶部由根证书构成。Root 证书并非由上一级证书颁发机构签名。Root证书的证书主体与证书的签发者相同。根证书享受juedui信任。它们构成了信任“点”，因此可作为接收方的可信证书。此类证书存储在专门存储受信证书的区域。基于该PKI，Root 证书可用于对下级证书颁发机构颁发的证书（即，所谓的中间证书）进行签名。从而实现从 Root根证书到中间证书信任关系的传递。由于中间证书可对诸如 Root 证书之类的证书进行签名，因此这两种证书均称为“CA证书”这种证书签名层级可通过多个中间证书进行延伸，直至Zui底层的实体证书。Zui终实体证书即为待识别用户的证书。验证过程则反向贯穿整个层级结构：，先通过签发者的公钥确定证书签发者并对其签名进行检查，之后再沿着整条信任链确定上一级证书签发者的证书，直至到达根证书。结论：无论组态何种安全通信类型，每台设备中都必需包含一条到Root 证书的中间证书链（即证书路径），对通信伙伴的Zui低层实体证书进行验证。 
证书管理的必备知识本节介绍了根据所使用的服务（CPU 应用程序）以及 TIAPortal/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 固件版本相关的证书管理选项。服务 使用 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 中根据不同应用创建特定的证书。在 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服务器证书。 保护与安全 >证书管理器”区域的特性在巡视窗口中，只有该区域内才能进行全局（即，项目级）和局部（即，设备特定）证书管理器切换（选项“使用证书管理器的全局安全设置”(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 forcertificate manager) 选项。2. 在项目树的“全局安全设置”(Global security settings)区域中，以 user 身份进行登录。对于新项目，首次登录时的身份为“Administrator”。3.返回“保护与安全”(Protection & Security) 区域的 PLC‑1中。在“设备证书”(Devicecertificates) 表格中，单击“证书主体”(Certificate subject)列的一个空行，添加新的证书。4. 在下拉列表中，选择一个证书并单击“添加”(Add) 按钮。“创建证书”(CreateCertificate) 对话框随即打开。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 服务器