Communications services
3.6 Secure Communication
Communication
60
Function Manual, 05/2021, A5E03735815-AJ
The figure does not show the measures taken at Alice's end (browser) to verify the certificate
sent by the Web server. Whether Alice can trust the Web server certificate received and
therefore the identity of the Web server, and can accept the exchange of data, depends on
positive verification.
The steps for verifying the authenticity of the Web server:
1.
Alice must know the public keys of all relevant certificate authorities, which means she
requires the complete certificate chain to verify the Web server certificate (i.e. the end-entity
certificate of the Web server):
Alice will generally have the required root certificate in her certificate memory. When a
Web browser is installed, a range of trusted root certificates is also installed. If she does
not have the root certificate, she must download it from the certificate authority and
install it in the certificate authority of the browser. The certificate authority can also be the
device on which the Web server is located.
You have the following options for obtaining the intermediate certificates:
–
The server itself sends the required intermediate certificates to Alice along with its end-
entity certificate – in the form of a signed message so that Alice can verify the integrity
of the certificate chain.
–
The certificates often contain the URLs of the certificate issuer. Alice can load the
required intermediate certificates from these URLs.
When you work with certificates in STEP 7 it is always assumed that you have imported
the intermediate certificates and the root certificate into the project and assigned them to
the module.
2.
Alice validates the signatures in the certificate chain with the public keys of the certificates.
3.
The symmetric key must be generated and transferred to the Web server.
4.
If the Web server is addressed by its domain name, Alice also verifies the identity of the Web
server in accordance with the Internet PKI rules defined in RFC 2818. She is able to do this
because the URL of the Web server, in this case the "Fully Qualified Domain Name" (FQDN),
is saved in the end-entity certificate of the Web server. If the certificate entry in the "Subject
Alternative Name" field corresponds to the entry in the address bar of the browser,
everything is fine.
The process continues with the exchange of data with the symmetric key, as shown in the
figure above.
Summary of Contents for SIMATIC ET 200AL
Page 2: ......
Page 143: ......
Page 218: ......
Page 250: ......
Page 296: ......
Page 337: ......
Page 365: ......
Page 392: ......
Page 419: ......
Page 451: ......
Page 483: ......
Page 597: ......
Page 648: ......
Page 702: ......
Page 739: ......
Page 781: ......
Page 804: ......
Page 828: ......
Page 853: ......
Page 880: ......
Page 906: ......
Page 996: ...Diagnostics ...
Page 1121: ......
Page 1565: ......