Digital Certificates for Web-Based DeltaV Applications

DeltaV Distributed Control System
Digital Certificates for Web-Based
DeltaV Applications
This document provides details on how to handle digital certificates for web-based DeltaV applications.
White Paper
January 2017
Digital Certificates for Web-Based DeltaV Applications
January 2017
Table of Contents
1 Introduction.................................................................................................................................... 3
2 Hash Functions................................................................................................................................ 4
3 Web-Based DeltaV Applications....................................................................................................... 4
4 Digital Certificates Solutions for DeltaV Applications....................................................................... 6
5 Importing Digital Certificates to the DeltaV Applications................................................................. 8
6 Conclusions................................................................................................................................... 11
www.emerson.com/deltav
2
Digital Certificates for Web-Based DeltaV Applications
January 2017
1 Introduction
This whitepaper provides background information about digital certificates, how DeltaV applications utilize certificates to secure
communications, and guidelines for managing certificates to ensure the security and trust of the system are properly maintained.
A digital certificate is an electronic mechanism that uniquely identify users, services, and endpoints so that they may exchange
information securely in a network. In simpler implementations, digital certificates can be used to set the trust between two devices
involved on a data exchange.
Both cases are based on the Public Key Infrastructure (PKI), where a key-pair – a public key and a private key – is used to simply set
the trust when the Server digitally signs the information provided, or is used to encrypt the communications when both the Server
and the Client share their public keys. Encrypted communications can only be decrypted using private keys, whereas the public keys
are exchanged among the devices or applications.
Although intensively utilized over open/public networks (internet) for security reasons, digital certificates are also often used in the
Industrial Control System (ICS) environment due to the number of available web-based applications that require additional security
mechanisms. ICS also relies on digital certificates to at least allow Clients to check if the received data is coming from the trusted
Server (Client/Server model).
Root CA
2
Digital
certificate
1
4
Request for
issuing certificate
Validation
of trust
Client
Public Key
Private Key
3
Digital
certificate
Figure 1 – Client/Server communication model based on PKI.
Since digital certificates are crucial to maintain the security level and the trust relationship, it is highly recommended that proper
key management is done when managing the digital certificates. For open/public networks this is done by means of Commercial
Certification Authorities (CAs).
The CA provides the digital certificates, manage the keys and is the trusted entity within the chain of trust, hence the CA can be
referenced at any time to confirm that a certificate is still valid.
In November 2011, the Certification Authority/Browser Forum (CA/B Forum) adopted the baseline requirements for the issuance
and management of publicly-trusted certificates that took effect in July 2012 and encompasses the following basic requirements:
„„
Commercial CAs should notify applicants prior to issuance that the use of certificates for private networks has been deprecated
by the CA/B Forum.
„„
Commercial CAs should not issue certificates with an expiration date later than November 1st, 2015 for private networks.
www.emerson.com/deltav
3
Digital Certificates for Web-Based DeltaV Applications
January 2017
The CA/B Forum is a voluntary group of CAs, vendors of internet browser software, and suppliers of other applications that use
X.509 digital certificates for Secure Sockets Layer / Transport Layer Security (SSL/TLS) and code signing that chain to a trust anchor
embedded in such applications. The CA/B Forum guidelines cover certificates used for the SSL/TLS protocol and code signing, as well
as system and network security of CAs.
With the CA/B Forum in mind and understanding how their guidelines apply to ICS environments – where network segmentation
and private/dedicated networks are broadly used – alternatives are presented in this document to help you have access to the
security protections offered by digital certificates, but not necessarily giving up the chain of trust mechanism based on CAs.
There are different types of digital certificates depending on their issuance mechanism, and for simplicity in this white paper we will
refer to the following three digital certificate types:
„„
Digital certificates issued by Commercial CAs
„„
Digital certificates issued by Private CAs (or intermediate servers)
„„
Self-Signed digital certificates
2 Hash Functions
Hash functions are used to generate a compressed/fixed size data stream that can be encrypted to generate digital signatures for
large amounts of data.
There are different hash functions issued by different organizations today. The Secure Hash Algorithm (SHA) is a good example and,
along with other hash function types such as MD5 or CRC32, it is a one-way hashing formula that is used to protect the integrity
of data.
Digital signatures based on SHA are dependent on the hash value size – the larger (bit-wise) the hash value the more complex is the
encryption, hence harder to break the encryption. SHA-1 produces 160bit hash values, SHA-2 produces either 256bit (SHA-256) or
512bit (SHA-512) hash values, and so on.
In November 2013, Microsoft announced that they would not be accepting SHA-1 encryption after 2016 based on calculations
that showed how breaking SHA-1 is becoming feasible – SHA-2 is now the next available option which is widely adopted by users,
suppliers and vendors.
3 Web-Based DeltaV Applications
Certificates are used in DeltaV’s web-based applications. These applications deliver an enhanced user’s experience especially for
client PCs that are not running DeltaV software on them. Each is accessible via an internet browser (e.g. Microsoft Internet Explorer)
where the web-application Server is within a private network (DeltaV Area Control Network or L2.5 Network). For some DeltaV
applications, certificates are used at the communications level by Windows services.
The web-based DeltaV application Servers provide the web pages using the https protocol (HyperText Transfer Protocol – Secure)
which is the secure version of http and uses digital certificates to encrypt the communications between the Client and the Server.
www.emerson.com/deltav
4
Digital Certificates for Web-Based DeltaV Applications
January 2017
Below is a list of web-based DeltaV applications/services referenced in this document:
„„
DeltaV Mobile Portal (formerly Executive Portal)
„„
DeltaV Web Server
„„
DeltaV Logbooks
„„
DeltaV OPC .Net Remote
„„
DeltaV Analyze
„„
DeltaV History Analysis
„„
DeltaV Batch Analytics
„„
DeltaV History Web Service
„„
DeltaV Plant Messenger
L5
Internet
Client
Firewall
Business Network
L4
DMZ
Firewall
Plant Network
L3
Root CA
Plant-Wide History
and Data Servers
Executive Portal
(Server)
Firewall
Process DMZ Network
DMZ
Firewall
L2.5 Network
L2.5
Engineering Workstations
Operator Workstations
DeltaV Application
Stations
L2
Firewall - IPD
DeltaV Area Control Network
Controllers and I/O
L0/L1
Figure 2 – Reference architecture showing a web-based DeltaV application.
Note: Emerson is updating all web-based DeltaV applications to be installed with SHA-2 encrypted self-signed digital certificates that expire
in 90 days.
For DeltaV applications, an initial 90-day self-signed digital certificate is generated at the time of installation to provide the user
secure out-of-the-box assurance that the newly installed web-based DeltaV application is really serving its users (trusted Server).
This initial 90-day self-signed certificate is not based on a root CA and should only be used for evaluation or test of the web-based
DeltaV application. Emerson recommends you to replace the provided self-signed certificate by another alternative that can be used
for the long-term, and with proper key management to secure the communication channel between the Client browser and the
trusted Server.
www.emerson.com/deltav
5
Digital Certificates for Web-Based DeltaV Applications
January 2017
4 Digital Certificates Solutions for DeltaV Applications
Web-based DeltaV application Servers are installed on private networks within your organization, and often times do not have Fully
Qualified Domain Names (FQDN). As mentioned in the Introduction of this white paper, Commercial CAs are no longer allowed by
the CA/B Forum to issue digital certificates for private networks and therefore self-signed digital certificates issued by Root CAs, or
digital certificates issued by Private CAs can be utilized instead.
Self-signed certificates issued by the web-based application Server (without a Root CA) must not be used for the long-term as they
do not have the necessary security protections this type of solution require.
Additionally, managing self-signed certificates present some challenges as listed below:
„„
Need for technical expertise to deploy and manage the self-signed certificates.
„„
Harder to make sure the key management is secure (and not compromised).
„„
If compromised, it is not simple to revoke certificates across the private network.
„„
Cost to deploy may vary and cannot be anticipated very well.
„„
Increased risks based on misuse or mishandling.
4.1 Self-Signed Digital Certificates issued by Root CAs
If the User decides to use self-signed certificates for the web-based DeltaV applications, the first thing to consider is that a Root CA
has to be deployed. The self-signed certificate provided upon the web-based DeltaV application installation will not be re-issued,
and once expired (after 90 days) the certificate will need to be replaced. The Root CA in this case is usually a server-type machine
that is hardened and installed following security guidelines to make sure the keys involved in the certificates issuance are not
exposed – only system administrators should have access to the Root CA.
There are multiple ways to deploy Root CAs, including Microsoft’s guidelines – Root CA is one of the server roles that can be enabled
on a Microsoft Windows Server O/S. Emerson can provide support to set up the Root CA in your infrastructure, please contact your
local Emerson sales office and ask for a quote from Performance Services if you need assistance setting up a Root CA for self-signed
certificates issuance to be used with web-based DeltaV applications.
Note: It is highly recommended that the Root CA is a different server-type machine than the Professional Plus machine, or any other DeltaV
server machine – preferably the self-signed Root CA should be running independently from other applications, roles and services.
Client access to web-based
DeltaV application
Web-based DeltaV
application Server
Root CA
Private Network
Figure 3 – Self-signed Root CA architecture overview.
www.emerson.com/deltav
6
Digital Certificates for Web-Based DeltaV Applications
January 2017
4.2 Digital Certificates Issued by Private CAs
Deploying and managing Root CAs for local self-signed certificates can be complex. It requires management and server-type
machines that have specific features (e.g. Secure Boot, Trusted Platform Module, etc.). If your Organization is not equipped with
an Information Technology (IT) department that is available to support the Root CA deployment, then management overhead or
eventually misuse and mishandling become real challenges.
Certain vendors can provide an alternative solution that runs on an intermediate server which works as a dual-homed server
station connected to the public network (internet) with an FQDN, as well as to the private network where the web-based DeltaV
applications are running. This solution allows you to avoid risks, errors, and hidden costs associated with self-signed Root CA’s
deployments, and at the same time it complies with the CA/B Forum guidelines. This alternative solution is called private SSL
(Secure Sockets Layer), and is based on the deployment of a Private CA infrastructure.
The biggest advantage of using Private CAs is that all work and expertise associated to manage the keys for digital certificates is
outsourced in this case. Some companies that can provide this type of Solution as a Service (SaaS) are listed below:
„„
Symantec – http://www.symantec.com/private-ssl
„„
GlobalSign – https://www.globalsign.com/en/certificate-authority-root-signing
„„
Entrust – https://www.entrust.com/private-ssl-certificates
„„
Other companies may offer the same of similar.
The Private CA solution is not provided by Emerson at this time, but you are free to discuss solutions with vendors that provide this
type of service as indicated above.
Client access to web-based
DeltaV application
Web-based DeltaV
application Server
Private Intermediate CA
Private Root CA
Private Network
Public Network
Figure 4 – Private CA architecture overview.
Emerson recommends the use of digital certificates to enable Clients to verify if the web-based DeltaV application Server is the
trusted Server. All web-based DeltaV applications are being updated to only accept connections based on the https protocol,
therefore digital certificates are required for a fully featured user’s experience. When the self-signed certificate issued by the
web-based DeltaV applications expires, the DeltaV application will continue to work, but the Client will be presented with a
certificate error message at the top of the supported internet browser indicating there is an issue with the provided certificate (in
this case caused by the expiration date).
www.emerson.com/deltav
7
Digital Certificates for Web-Based DeltaV Applications
January 2017
Users are encouraged to define and implement the CA solution of choice and have it ready before the provided self-signed
certificates expire. Table 1 provides details of which versions of each web-based DeltaV application are considering the approach
described in this white paper.
Application
Version
DeltaV Web Server
v13.3.1 or higher
DeltaV Logbooks
v5.6.5 or higher
DeltaV Analyze
Protocol
Hash Function
Self-Signed
Certificate
Expiration
https only
SHA-256
90 days
v4.1 or higher
DeltaV History Analysis
v13.3.1 or higher
DeltaV Batch Analytics
v13.3.1 or higher
DeltaV History Web Service
v13.3.1 or higher
DeltaV Plant Messenger
v1.6 or higher
Table 1 – Web-based DeltaV applications
Note: Some web-based DeltaV applications are not listed here as they have not yet been changed to meet the requirements listed in this table. They will be added to this white paper
once they meet the requirements.
5 Importing Digital Certificates to the DeltaV Applications
Independent from which type of CA the digital certificate was issued, the process of importing it into the web-based DeltaV
applications is the same. Once the digital certificate is available, the steps provided below can be followed for any of the web-based
DeltaV applications (in this example the applications DeltaV Logbooks and History Web Services were used):
5.1 Obtain digital certificates
Once deployed, either the Root CA or the Intermediate Server provide digital certificates to allow for the proper implementation of
your PKI. You must provide a minimum set of certificates to be bound into your DeltaV infrastructure.
Private CA
Self-Signed Root CA
Description
Self-Signed Root
CA certificate
This is the root certificate that identifies the CA. It has the higher trust in
the certificate path. For Private CA this certificate is linked to the private
network via the Intermediate CA.
Intermediate
CA certificate
N/A
This certificate applies to Private CA deployments, and is the root
certificate within the private network, but it sits between the web-based
DeltaV application certificate and the Private Root CA certificate in the
certificate path.
Web-based DeltaV
application certificate
Web-based DeltaV
application certificate
This is the certificate used by the Web-Based DeltaV application to confirm
it is the trusted Server for any given Client in the private network.
Private Root
CA certificate
Table 2 – Different types of certificates applicable to a web-based DeltaV applications deployment.
www.emerson.com/deltav
8
Digital Certificates for Web-Based DeltaV Applications
January 2017
Figure 5 shows the certificate path of the web-based DeltaV application certificate whereas: ‘CorpRCA02’ is the Private Root CA
certificate, ‘CorpICA03’ is the Intermediate CA certificate, and ‘LGSYS2-LOGBOOKS’ is the web-based DeltaV application certificate.
Figure 5 – Web-based DeltaV application certificate properties showing the certificate path.
5.2 Importing Root CA certificates
The Root CA certificates are available to the web-based DeltaV application Servers and Clients in the infrastructure. This is done
using the Group Policy Management Editor on the Domain Controller of the given networks where the Servers and Clients are
connected to.
The Self-Signed Root CA certificate or the Private Root CA certificate is imported to the Trusted Root Certification Authorities folder
(Computer Configuration / Policies / Windows Settings / Security Settings / Public Key Policies).
Figure 6 – Certificate in the Trusted Root Certification Authorities folder.
www.emerson.com/deltav
9
Digital Certificates for Web-Based DeltaV Applications
January 2017
For Private CA deployments, both the Intermediate CA certificate and the Private Root CA certificate are imported to the
Intermediate Certification Authorities folder (Computer Configuration / Policies / Windows Settings / Security Settings /
Public Key Policies). After importing, the certificates need to be propagated to all workstations linked to the GPOs based on
Microsoft’s recommendations.
Figure 7 – Certificates in the Intermediate Root Certification Authorities folder.
5.3 Binding the certificates within Microsoft Internet Information Services (IIS)
Finally, the certificates are bound in the Server’s IIS where the web-based DeltaV application is running. Figures 8 and 9 show the
steps to bind them.
Figure 8 – Accessing IIS Manager to bind the certificates.
www.emerson.com/deltav
10
Digital Certificates for Web-Based DeltaV Applications
January 2017
Figure 9 – Binding certificates.
Note: If certificates are imported to any GPOs on any DeltaV workstation or server, they need to be backed up prior to any DeltaV upgrade
or migration. DeltaV System Hardening does not take into account certificates that were previously imported into a running DeltaV system
and therefore will delete the certificates as part of the DeltaV installation procedure.
The certificates can be manually exported before the upgrade/migration, and re-imported once the procedure is complete. Alternatively,
GPOs can be backed up and restored and instructions to do so are available in Emerson’s Guardian Support Portal.
6 Conclusions
Starting with Microsoft Windows 10 Anniversary Update, Microsoft Edge and Internet Explorer will no longer consider websites
protected with a SHA-1 certificate as secure. Emerson is already providing a solution for this issue by providing SHA-2 certificates
with the web-based DeltaV applications.
The provided self-signed certificates for web-based DeltaV applications are valid for 90 days, and their main purpose is to allow
you to evaluate and test the web-based DeltaV applications during Factory or Site Acceptance Tests, etc. The full long term
solution needs to be provided by either a self-signed Root CA or a Private CA, whichever better suits your security posture as well
as business decision. Please contact your local Emerson sales office in case you need support with any of the presented options in
this document.
The main purpose of using digital certificates on web-based DeltaV applications is to verify that the Server providing the web pages
can be trusted, and since it is a security protection, the certificates’ keys must be managed appropriately. Self-signed certificates
based on lower encryption hash function (e.g. SHA-1) cannot be simply deemed acceptable, and are also deprecated by the CA/B
Forum guidelines.
The following references are available as additional literature about the topics presented in this white paper:
„„
CA/B Forum website - https://cabforum.org/
„„
Windows Enforcement of SHA-1 Certificates - http://social.technet.microsoft.com/wiki/contents/articles/32288.windowsenforcement-of-sha1-certificates.aspx
„„
DeltaV Security Manual - http://www2.emersonprocess.com/siteadmincenter/pm%20deltav%20documents/manuals/
cs_deltav_security_manual-toc%20only.pdf
„„
RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile - https://tools.ietf.org/
html/rfc5280
www.emerson.com/deltav
11
Digital Certificates for Web-Based DeltaV Applications
Emerson
North America, Latin America:
+1 800 833 8314 or
+1 512 832 3774
Asia Pacific:
+65 6777 8211
Europe, Middle East:
+41 41 768 6111
www.emerson.com/deltav
January 2017
©2017, Emerson. All rights reserved.
The Emerson logo is a trademark and service mark of Emerson Electric Co. The DeltaV logo is
a mark of one of the Emerson family of companies. All other marks are the property of their
respective owners.
The contents of this publication are presented for informational purposes only, and while every
effort has been made to ensure their accuracy, they are not to be construed as warranties or
guarantees, express or implied, regarding the products or services described herein or their
use or applicability. All sales are governed by our terms and conditions, which are available on
request. We reserve the right to modify or improve the designs or specifications of our products
at any time without notice.