FUJITSU Software ServerView Suite
Managing SSL certificates in the
ServerView Suite
Secure server management using SSL and PKI
The User Documentation Department would like to know your opinion of this manual. Your feedback helps us optimize our documentation to suit your individual needs.
Feel free to send us your comments by e-mail to [email protected].
Certified documentation according to DIN EN ISO
9001:2008
To ensure a consistently high quality standard and user-friendliness, this documentation was created to meet the regulations of a quality
management system which complies with the requirements of the standard DIN EN ISO 9001:2008.
cognitas. Gesellschaft für Technik-Dokumentation mbH www.cognitas.de
Copyright and trademarks
Copyright © 1998 - 2015 Fujitsu Technology Solutions. All rights reserved.
Delivery subject to availability; right of technical modifications reserved. All hardware and software names used are trademarks of their respective manufacturers.
1 Introduction 7
1.1 Target groups and objectives of this manual 7
1.2 ServerView Suite link collection 8
1.3 Documentation for the ServerView Suite 9
1.4 Typographic conventions 10
2 Communication security: SSL, PKI and certificates 11
2.1 Communication security on the Internet 12
2.2 Fundamentals of cryptography 13
2.2.1 Encryption methods 13
2.2.1.1 Symmetric key encryption 13
2.2.1.2 Asymmetric key encryption (public key encryption) 15
2.2.1.3 Hybrid encryption methods 17
2.2.2 Cryptographic hash functions 17
2.2.3 Message Authentication Code (MAC) 18
2.2.4 Digital signatures 18
2.3 SSL (overview) 21
2.3.1 SSL in the TCP/IP protocol stack 21
2.3.2 SSL handshake 23
2.3.3 Cipher suites 27
2.4 Digital certificates and Certification Authorities (CA) 28
2.5 Public key infrastructure (PKI) 28
3 Managing digital certificates using PKI 31
3.1 Security recommendations 31
3.2 Certification Authorities (CA) 32
3.2.1 Certificates can be issued by different types of CA 32 3.2.2 Hierarchical trust structure: Root CA and subordinate (intermediate)
CAs 33
3.2.3 Creating your own CA 35
3.3 X.509 certificates 37
3.3.1 Certificate types 37
3.3.1.2 Certificate types relating to the issuing instance 38 3.3.2 Certificate Revocation Lists (CRL) and OCSP 38
3.3.3 Structure of an X.509 certificate 39
3.3.4 Applying for and creating X.509 certificates 40 3.3.5 X.509 file formats (extensions) for certificates and keys 41 3.4 Software tools for managing certificates and keys 43
3.5 Creating X.509 certificates 44
3.5.1 Creating a CA certificate 44
3.5.2 Creating a self-signed certificate 45
3.5.2.1 Creating the self-signed certificate in one go 45 3.5.2.2 Creating the self-signed certificate based on a private key 45
3.6 Key store and trust store 46
4 SSL communication in the ServerView Suite 49 4.1 Managing SSL certificates for server management with ServerView
Operations Manager and ServerView Agents 51
4.1.1 Managing SSL certificates on the CMS 52
4.1.1.1 Self-signed certificate 52
4.1.1.2 Replacing the certificate on the CMS 54
4.1.2 Managing certificates for SSO and RBAC on the managed node 54 4.1.3 Installing the CMS certificate on the managed node(s) via
ServerView Update Manager 55
4.1.3.1 Overview 55
4.1.3.2 Installing the CMS certificate on the managed node(s) 59 4.1.3.3 Uninstalling the CMS certificate from the managed node(s) 60 4.1.4 Trust state column in the ServerView server list on the CMS 61
4.2 Managing SSL certificates on the iRMC S4 62
4.2.1 Pre-installed default certificates 62
4.2.2 Uploading SSL certificates and Root CA certificate onto the iRMC S4 63 4.2.2.1 Uploading a Root CA certificate into the trust store of the iRMC S4 64 4.2.2.2 Uploading an SSL certificate into the key store of the iRMC S4 64
4.2.3 Generating a self-signed SSL certificate 66
4.2.4 No ServerView Update Management support 67
4.3 Secure SSL communication with the ServerView RAID Manager 68 4.4 Secure SSL communication with the SSM Web Interface 70
4.4.1 Requirements and overview 70 4.4.1.1 Requirements for using a secure HTTPS connection 70 4.4.1.2 Steps needed to establish a secure HTTPS connection via strategy
2 71
4.4.2 Creating your own CA 72
4.4.3 Importing the Root CA certificate into the browsers of the
communication end devices 73
4.4.4 Preparing the managed server for secure HTTPS communication
with the end devices 74
4.4.4.1 Creating a server certificate for the managed node 74 4.4.4.2 Creating the ServerView Connector Service certificate 77 4.4.4.3 Configuring the ServerView Connector Service 77
1
Introduction
All Internet data traffic to, from and between the individual components of the ServerView Suite are secured using SSL/TLS. Both the SSL (Secure Sockets Layer) protocol and its enhanced successor, the TLS (Transport Layer Security) protocol, enable mutual authentication of two communication endpoints and, beyond that, ensure confidentiality, integrity, and non-repudiation of the data origin. Client/server systems can therefore communicate via SSL/TLS without falling victim to security threats such as address spoofing, tampering and capture reply. The use of SSL is transparent for the protocols and applications involved. Although SSL was initially developed for the HTTP protocol, SSL and TLS can now secure every protocol that is located above the Transport Layer (TCP) in the TCP/IP protocol stack. In the following, SSL/TLS is referred to as SSL for short. SSL is a hybrid encryption protocol allowing two communication endpoints to use asymmetric encryption (public key encryption) for securely transferring or exchanging their common symmetric session key. This key is then employed to encrypt/decrypt the payload data.
A public key infrastructure (PKI) provides the infrastructure for distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party. The latter is achieved by using digital certificates.
1.1
Target groups and objectives of this manual
This manual is aimed at system administrators, network administrators, and service staff who have a sound knowledge of hardware and software.
It provides an overview of how to manage SSL certificates in the context of the FUJITSU Software ServerView Suite.
Once you have read this manual, you should be able to:
l Create your own certification authority (CA). l Create a CA Certifcate.
l Use certificates within the ServerView Suite.
o To ensure secure communication between the individual components of the ServerView Suite.
o To ensure secure Web-based communication with the individual components of the ServerView Suite.
o To avoid browser security warnings when accessing a ServerView component via a Web browser from a communication end device.
1.2
ServerView Suite link collection
Via the ServerView Suite link collection, Fujitsu provides you with numerous downloads and further information on the ServerView Suite and PRIMERGY servers.
For ServerView Suite, links are offered on the following topics:
l Forum l Service Desk l Manuals l Product information l Security information l Software downloads l Training
The downloads include the following:
o Current software statuses for the ServerView Suite as well as additional Readme files.
o Information files and update sets for system software components (BIOS, firmware, drivers, ServerView Agents and ServerView Update Agents) for updating the PRIMERGY servers via ServerView Update Manager or for locally updating individual servers via ServerView Update Manager Express.
o The current versions of all documentation on the ServerView Suite. You can retrieve the downloads free of charge from the Fujitsu Web server.
For PRIMERGY servers, links are offered on the following topics:
l Service Desk l Manuals
l Product information l Spare parts catalogue
Access to the ServerView Suite link collection
You can reach the link collection of the ServerView Suite in various ways: 1. Via ServerView Operations Manager.
l Select Help – Links on the start page or on the menu bar.
This opens the start page of the ServerView Suite link collection.
2. Via the start page of the online documentation for the ServerView Suite on the Fujitsu manual server.
You access the start page of the online documentation via the following link:
http://manuals.ts.fujitsu.com
l In the selection list on the left, select x86 Servers.
l On the right, click PRIMERGY ServerView Links under Selected
documents.
This opens the start page of the ServerView Suite link collection. 3. Via the ServerView Suite DVD 2.
l In the start window of the ServerView Suite DVD 2, select the option
ServerView Software Products.
l On the menu bar select Links.
This opens the start page of the ServerView Suite link collection.
1.3
Documentation for the ServerView Suite
The documentation can be downloaded free of charge from the Internet. You will find the online documentation athttp://manuals.ts.fujitsu.comunder the link x86 Servers.
For an overview of the documentation to be found under ServerView Suite as well as the filing structure, see the ServerView Suite sitemap (ServerView Suite – Site Overview).
1.4
Typographic conventions
The following typographic conventions are used: Convention Explanation
Indicates various types of risk, namely health risks, risk of data loss and risk of damage to devices.
Indicates additional relevant information and tips. bold Indicates references to names of interface elements.
monospace Indicates system output and system elements, e.g., file names
and paths.
monospace
semibold Indicates statements that are to be entered using the keyboard.
<abc> Indicates variables which must be replaced with real values. [abc] Indicates options that can be specified (syntax).
[key] Indicates a key on your keyboard. If you need to enter text in uppercase, the Shift key is specified, for example,[SHIFT] + [A] for A. If you need to press two keys at the same time, this is indicated by a plus sign between the two key symbols.
Screenshots
Some of the screenshots are system-dependent, so some of the details shown may differ from your system. There may also be system-specific differences in menu options and commands.
certificates
To communicate via the Internet (e.g. with Web browsers), the individual ServerView components use secure connections based on a public key infrastructure (PKI) with secure SSL connections.
This chapter provides information on the follwing topics:
l Communication security on the Internet l Fundamentals of cryptography
l SSL
l X.509 certificates
l Public key infrastructure (PKI)
SSL (Secure Sockets Layer) and its enhanced successor, the Transport Layer Security Protocol (TLS), are currently the most sophisticated security protocol in the Internet. Originally developed by the company Netscape Communications to permit secure data transfer using the HTTP protocol, SSL/TLS can now secure every protocol that is located above the Transport Layer (TCP) in the TCP/IP protocol stack. SSL supports mutual authentication of two communication endpoints and, in addition, guarantees confidentiality, integrity, and authenticity of the application data exchanged.
SSL and TLS
The Transport Layer Security Protocol (TLS) is an enhancement of the SSL V3.0 protocol which was standardized by the Internet Engineering Task Force (IETF) in RFC 2246. Therefore, SSL and TLS are often mentioned in the same breath. When no distinction is necessary, SSL/TLS are referred to in the following as SSL for short.
2.1
Communication security on the Internet
Communication security comprises the following aspects:
l Authentication of the data origin
Authentication of the data origin indicates that the specified data origin is the actual sender. This is required to ward off active attacks in which the attacker places themselves between the two communication partners (“man in the middle”) and pretends to each partner to be the other communication partner.
l Data confidentiality
Data confidentiality prevents data from being read by unauthorized persons.
l Data integrity
Data integrity guarantees that transferred data has not been modified.
l Anti-replay
Anti-replay prevents data from being intercepted and read in again by an intruder.
l Confidentiality of the traffic flow
Confidentiality of the traffic flow prevents unauthorized persons from obtaining information through unauthorized analysis of the message traffic.
l Non-repudiation
Non-repudiation ensures that the communication partners cannot deny that they sent the transferred data.
SSL enables the first four of these aims to be implemented and counters the threats to communication security with the aid of cryptographic methods. In the process, SSL offers a high degree of flexibility in selecting the cryptographic methods used, at the same time relieving the user of the need to have detailed cryptographic knowledge.
2.2
Fundamentals of cryptography
Cryptography implements the aims of communication security such as data confidentiality, data integrity and so on with the aid of the following cryptographic methods:
l Encryption methods ensure data confidentiality.
l Cryptographic hash functions and Message Authentication Codes (MACs). l Digital signatures ensure non-repudiation.
Most cryptographic methods require strong random numbers.
2.2.1
Encryption methods
There are two classes of encryption methods which, because of their specific advantages and disadvantages, are tailored to different application areas:
l Symmetric key encryption methods.
Symmetric key encryption methods are used for encrypting the payload (confidentiality).
l Asymmetric (public) key encryption methods.
Asymmetric key encryption methods are used: o In key exchange protocols.
o To create digital signatures (non-repudiation).
l Hybrid encryption.
Hybrid encryption combines symmetric and asymmetric encryption, thereby benefiting from the specific advantages of each.
Common to both classes is that security is based on the key(s) remaining
confidential, while the method and the specific algorithm used for encryption are generally known.
2.2.1.1 Symmetric key encryption
With symmetric key encryption, the cryptographic algorithms for encrypting the data at the sender and decrypting it at the receiver use the same key.
If, before it is used, the key is to be exchanged over the same medium as that over which the encrypted payload is transported, you must counter the danger of compromising the key. For this purpose it is practical to use asymmetric
encryption methods such as RSA or Diffie Hellmann (DH) (see"Asymmetric key encryption (public key encryption)" on page 15).
The following figure outlines the principles of symmetric key encryption:
Figure 1: Symmetric key encryption
The best-known symmetric key encryption methods are:
l AES (Advanced Encryption Standard)
Candidates for AES, the successor standard to DES, were sought in a competition, the winner being a method named Rijndael.
l 3-DES (“Triple DES”)
3-DES comprises consecutive three-fold DES encryption.
l DES (Digital Encryption Standard)
Formerly the best-tried symmetric method, DES is no longer recommended due to insufficient security.
Advantage of symmetric key encryption
The symmetric methods are fast compared with the asymmetric methods. The security of symmetric key encryption is dependent on the key length. To ensure secure encryption, the key should be at least 160 bits long.
Disadvantage of symmetric key encryption
As each pair of communication partners requires a separate key, key
management involves a considerable effort because the number of keys needed is proportional to the square of the number of group members.
2.2.1.2 Asymmetric key encryption (public key encryption)
With asymmetric key encryption, which is often also referred to as public key encryption, each communication partner has two different keys between which a mathematical relationship exists:
l Public key
The public key is known to all communication partners and is used to encrypt messages.
l Private key
The private key must only be known to the owner and is used to decrypt messages encrypted with the associated public key. Private keys must be kept secure to prevent unauthorized persons from compromising it thus allowing them to intercept confidential communication.
Besides being applied for encryption purposes, private keys may also be used for digital signatures and key exchange.
When asymmetric key encryption is used, message exchange between two communication partners A and B proceeds as follows:
1. Before A sends a message to B, A must know B’s public key. 2. A encrypts his/her message using B’s public key.
3. A sends the encrypted message to B. (The encrypted message can now be decrypted only with the aid of B’s private key.)
The following figure outlines the principles of public key encryption:
Figure 2: Public key encryption
The best-known asymmetric key encryption methods are:
l RSA
RSA stands for the inventors Rivest, Shamir and Adleman.
l DH
DH stands for the inventors Whitfield Diffie and Martin Hellman. Unlike RSA, DH cannot be used for digital signatures, which ensure the authenticity of the partners involved in the key exchange. DSS (Digital Signature Standard), for example, is available for this purpose. DSS is also known under the name of DSA (Digital Signature Algorithm).
l ECC (Elliptic Curve Cryptography)
This method class is still relatively young. As the demands on hardware performance are relatively low, these methods are particularly suitable for smart cards.
With asymmetric key encryption methods, only the owner of the private key can perform operations with this key. Signature methods can be created on this basis ("electronic signature").
The security of asymmetric key encryption is dependent on the key length. To ensure secure encryption, the currently (since 2013) recommended key size is 2048 bits for RSA and DH.
Advantage of asymmetric key encryption
As one of the two keys can be known publicly, only one key pair is required per receiver. Consequently the total number of keys required is considerably lower than with symmetric methods.
Disadvantage of asymmetric key encryption
Asymmetric methods are considerably slower than symmetric methods and are primarily used for key exchange, i.e. for encrypting and exchanging a secret (symmetric) session key between two communication partners. Asymmetric encryption is not used for encrypting the user data (payload data) even if the amount of data to be encrypted is very small.
2.2.1.3 Hybrid encryption methods
Hybrid encryption methods combine the specific advantages of symmetric and asymmetric encryption while at the same time bypassing the weaknesses.
l Due to its high efficiency in encrypting/decrypting huge amounts of data,
symmetric encryption is employed for encrypting the payload data, i.e. the message itself. For this purpose, a (pseudo)randomly generated session key is used. The session key is usually generated when communication is initiated.
l Due to its ease of managing keys, asymmetric encryption is employed for
key exchange and digital signatures.
2.2.2
Cryptographic hash functions
A hash function is a mathematical function which maps a character string of any given length onto a character string of fixed length. In this way hash functions can be used to create a characteristic identifier for an extensive plain text. This identifier is referred to as a checksum, fingerprint,message digest, or simply digest.
A hash algorithm suitable for cryptographic purposes must satisfy a number of requirements:
l For identical input, a hash algorithm must return the same output.
l Minimal changes to the input must result in a significantly changed message
digest.
l Under no circumstances should it be possible to reconstruct the input from
the message digest.
l It should be virtually impossible to find two different plain texts for which
the hash algorithm returns the same message digest.
Hash functions with these characteristics are known as cryptographic hash functions. Cryptographic hash functions are very suitable for securing data integrity.
Two very frequently used hash algorithms are MD5 and SHA-1. The digest length is 128 bits for MD5 and 160 bits for SHA-1.
2.2.3
Message Authentication Code (MAC)
Message Authentication Codes (MACs) are cryptographic hash functions which also use a secret key to generate the message digest. MACs secure integrity and authenticity of the data traffic between two communication partners who share one secret key.
The most commonly used MAC is HMAC. HMAC can be used with every
cryptographic hash algorithm and is currently the only MAC supported in SSL and OpenSSL.
2.2.4
Digital signatures
In addition to ensuring data integrity, cryptographic hash functions are used to create digital signatures. A digital signature attached to a document or message allows the receiver to verify data integrity and data origin:
l Data integrity
Data integrity means that the document has not been changed since the time the signature was created.
A digital signature ensures that the sender of the document is actually the person they claim to be.
Digital signatures are based on public key encryption. Creating a digitally signed message
Figure 3: Creating a digitally signed message
A digitally signed message is created as follows: 1. The author writes a plain text message.
2. A cryptographic hash function is applied to complete the message. The output string of the hash function (message digest) is much shorter than the source text.
3. The digital signature is obtained by encrypting (signing) the message digest with the author's private key.
4. The plain text message is digitally signed by attaching the related digital signature to the plain text.
5. The digitally signed message can now be sent.
Be aware that hashing, encryption etc., which are automatically executed by the PKI service, are completely transparent to the user. For details on PKI see section"Public key infrastructure (PKI)" on page 28.
Verifying a digitally signed message
Figure 4: Verifying a digitally signed message
To verify the digital signature, the receiver of the signed data proceeds as follows:
1. A message has been received.
2. The signature is decrypted with the sender's public key. The output is the message digest that was previously signed (encrypted) by the sender with their private key.
3. A cryptographic hash function is applied to the message plain text, thus producing another message digest.
4. The message digest derived from the signature is compared with the message digest computed ("hashed") from the message text. If both message digests match, the integrity of the received message is proven.
As the message digest also passed the signing process (it was signed by the sender and decrypted by the receiver), the identity of both message digests also proves the authenticity of the sender.
Be aware that hashing, decryption etc., which are automatically executed by the PKI service, are completely transparent to the user. For details on PKI see section"Public key infrastructure (PKI)" on page 28.
2.3
SSL (overview)
In conjunction with SSL (X.509) certificates, the SSL (Secure Socket Layer) protocol permits mutual authentication of two communicating applications and, in addition, guarantees confidentiality, integrity, and authenticity of the
application data exchanged. Client/server systems can thus communicate via SSL without running the risk of exchanged data being intercepted or forged. The use of SSL is transparent for the protocols and applications involved.
SSL and TLS
The Transport Layer Security protocol (TLS) is an enhancement of the SSL V3.0 protocol which was standardized by the Internet Engineering Task Force (IETF) in RFC 2246. Therefore, SSL and TLS are often mentioned in the same breath. When no distinction is necessary, SSL/TLS are referred to in the following as SSL for short.
To prevent attacks (e.g. "BEAST" and "POODLE" ), the ServerView components normally support only the SSL/TLS protocols SSLv2Hello, TLSv1.1, and TLSv1.2.
In some components of the ServerView Suite, you have the option to also enable SSLv3 support.
2.3.1
SSL in the TCP/IP protocol stack
The SSL protocol is included in the TCP/IP protocol stack above the TCP protocol and below the Application Layer. SSL uses a hybrid encryption and comprises two subordinate protocols:
l SSL Record Protocol
The SSL Record Protocol is based directly on the TCP protocol and is
responsible for transferring the payload data (i.e. the message itself) over a secure SSL connection which is based on symmetric key encryption. The payload data is encrypted/decrypted with the symmetric session key previously exchanged between the communication partners via the SSL Handshake Protocol.
l SSL Handshake Protocol
The SSL Handshake Protocol operates on the basis of the SSL Record Protocol. It enables the SSL client and SSL server to authenticate themselves to each other and to exchange encryption algorithms together with the cryptographic key before an Application Layer protocol transfers the first data.
The following figure outlines the position of SSL/TLS in the TCP/IP protocol stack.
Figure 5: SSL Handshake and Record protocol in the TCP/IP protocol stack
Using SSL with a higher layer protocol (e.g. HTTP) simply layers the initial protocol (e.g. HTTP) on top of the SSL protocol. This results in the corresponding secure protocol variant (HTTPS in the case of HTTP) thus adding the security capabilities of SSL to standard communication (e.g. HTTP communication).
2.3.2
SSL handshake
SSL communication between client and server always begins with a so-called handshake. This handshake permits authentication of the server and agreement to be reached on the encryption method and key that are to be used. With every handshake the server must authenticate itself to the client by means of public key encryption. The server can also request the client to authenticate itself (also by means of public key encryption). However, this is only done in special cases.
The following diagram outlines the steps required for an SSL handshake:
The steps shown in the diagram are explained in more detailed below: 1. Client Hello
The client sends the server the list of supported SSL protocol versions, a list of the supported encryption methods (cipher suites), a randomly generated 32 octet number, and a session ID.
The cipher suite used by client and server for the first steps (including ChangeCipherSpec (Client) message) of the SSL handshake isTLS_ NULL_WITH_NULL_NULL(null cipher suite). The related messages are
therefore sent without encryption. 2. Server Hello
The server selects from these lists its preferred SSL protocol version, cipher suites etc. and returns these to the client.
3. Server authentication
1. The server sends the client the server’s X.509 certificate containing the server’s public key which the client needs for encrypting messages it sends to the server.
2. The client authenticates the server by checking whether the server certificate has already been signed by a CA whose certificate is present on the client and which the client thus trusts implicitly. The client also checks whether the certificate was issued for the server to which it wants to set up the connection.
4. Request for client authentication (optional)
The server may request client authentication (e.g. if the client wants to access a server resource requiring client authentication).
5. Server Done
The Server Done message signals to the client that the server's part of the dialog is finished for the time being.
6. Client authentication (optional)
If the server has requested client authentication the following occurs: 1. The client sends the server the client’s X.509 certificate containing the
client’s public key.
2. The server authenticates the client by checking whether the client certificate has already been signed by a CA whose certificate is present
on the server and which the server thus trusts implicitly. The server also checks whether the certificate was issued for the client to which it wants to set up the connection.
7. ClientKeyExchange
The client generates the so-called pre-master secret, a 46-byte random number used to create the symmetric key (for payload data encryption) and also to create the MAC key.
Using the server’s public key (obtained from the server certificate), the client encrypts the pre-master secret and sends this to the server.
From the pre-master secret and the random numbers exchanged in the preceding steps, the client and server then calculate the master secret from which are derived all keys required for the various encryption and MAC algorithms.
8. ChangeCipherSpec (Client)
The client sends a message notifying the server that all subsequent communication will be encrypted using the cipher suite negotiated in the ClientHello and ServerHello steps (instead of using the Null cypher suite applied so far).
9. Finished (Client)
The clients sends an encrypted message which informs the sender that the client's part of the handshake is finished. This message comprises all messages exchanged during the SSL handshake (except the Finished (Client) message itself).
10. ChangeCipherSpec (Server)
The server sends a message notifying the client that all subsequent communication will be encrypted using the cipher suite negotiated in the ClientHello and ServerHello steps (instead of using the null cypher suite applied so far).
11. Finished (Server)
The server sends an encrypted message which informs the client that the server's part of the handshake is finished. This message comprises all messages exchanged during the SSL handshake (except the Finished (Server) message itself).
The Finished Server step completes the SSL-handshake. All subsequently exchanged payload data traffic between the client and the server is encrypted using the payload data encryption of the negotiated cipher suite and each payload message contains the negotiated MAC.
2.3.3
Cipher suites
Not all conceivable combinations of the various cryptographic methods can be used with SSL. On the contrary, in the SSL standard a number of permissible combinations of authentication methods (RSA, DSS), key exchange methods (RSA, DH), symmetric key encryption methods (DES, 3DES, AES, RC4 etc.) and message digests have been defined. These combinations are referred to as cipher suites.
A typical example of an SSLv3 cipher suite is as follows:
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
In detail, the individual string components have the following meanings.
l RSAis the key exchange algorithm.
l WITH_3DES_EDE_CBCspecifies the symmetric cipher for encrypting the
payload data traffic (here: Triple DES with Cyclic Block Chaining).
l SHAspecifies the cryptographic hash function for generating the Message
Authentication Code (MAC)- in this case SHA1. More recent cipher suites support stronger MACs such as SHA256/SHA512.
To avoid BEAST attacks, you should only use the following cipher suites:
l RSA_WITH_3DES_EDE_CBC_SHA
2.4
Digital certificates and Certification Authorities
(CA)
Public key encryption allows everyone to securely send a message to a partner by using their (publicly available) public key. However, a public key does not ensure on its own that it actually belongs to the designated sender or recipient. This is done by using digital certificates, also known as public key certificates or simply certificates. A digital certificate correlates a public key to its owner. Digital certificates used in conjunction with SSL conform to the X.509 standard (X.509 certificates). X.509 certificates work with a hierarchical trust structure, at the top of which the Certificate Authorities are legally liable for ensuring the proven identity of the certificate owners.
Certification Authorities (CA)
As part of a public key infrastructure (PKI), CAs are responsible for issuing digital certificates. Initially, the CA checks the identity of the person or organization specified in the certificate. After successful evaluation, the CA signs the certificate with the CA's private key. The signature is included in the certificate and disclosed at the time of connection setup, thus allowing the communication partner to verify the trustworthiness of the certificate.
Certificate Revocation List (CRL)
Certificates which are signed by a CA can be declared invalid in a Certificate Revocation List (CRL).
2.5
Public key infrastructure (PKI)
A public key infrastructure (PKI) provides a security framework based on the concepts of public key cryptography. The techniques and policies made available by the PKI ensure secure communication between the individual communication endpoints.
Three fundamental services are provided by a PKI: authentication, data integrity, and confidentiality. Beyond these services, a variety of additional security services as well as security components can be used by employing a PKI.
The following components and services are part of a PKI:
l Digital certificates
l Support for non-repudiation l Certification Authority l Registration Authority l Certificate repository l Certificate revocation l Key backup and recovery l Automatic key update l Key history management l Cross-certification l Time-stamping
l Certificate policies (CP) and Certification Practice Statements (CPS) l Appropriate client software
Registration Authority
A Registration Authority (RA) cooperates closely with the CA. The RA is responsible for verifying certificate requests (i.e. user requests for a digital certificate) and prompting the CA to issue the certificate. The functions of both the CA and the RA are often performed by the same authority, no matter whether it is called a CA or RA.
Certificate repository
The certificate repository comprises an LDAP database and an LDAP directory service based on it. The database stores information on all unexpired certificates as well as revocation information.
Key backup and recovery
The only keys requiring backup are users’ decryption keys. As long as a trusted agent (e.g. the CA) securely backs up users’ decryption keys, security is not compromised and the user’s data can always be recovered. However, signing keys have different requirements from decryption keys. In fact, as the next section describes, backing up signing keys destroys a basic requirement of a PKI.
3
Managing digital certificates using PKI
Managing digital certificates using a public key infrastructure (PKI) comprises the management of public keys in conjunction with SSL.
This chapter provides information on the following topics:
l Security recommendations l Certification Authorities (CA) l X.509 certificates
l Software tools to manage certificates and keys l Creating X.509 certificates
l Key store and trust store
3.1
Security recommendations
When using certificates, you are strongly advised to keep the following recommendations in mind:
l It is highly recommended to use the SSL option for the Web interface of any
component of the ServerView Suite, and to replace the predefined certificate with a CA certificate as soon as possible.
l It is recommended to use certificates that are signed by a trusted
Certification Authority (CA certificate).
l Establish your own CA if you do not want to buy certificates signed by
(commercial) CAs already trusted by the browser. Then import your CA’s certificate into all browsers used for operating ServerView products.
l In general, it is recommended to import only the CA certificate. This causes
any other server certificate signed by the same CA to automatically be trusted, which is beneficial in most cases.
l Unless you are absolutely sure that you are connected with the desired end
entity (e.g. ServerView CMS), you should meticulously check the fingerprint (s) of the end entity's certificate.
l Frequently check the imported certificates in your browser’s trust store. Keep
the store as small as possible – remove entries for servers and certificate authorities when they are no longer needed.
l You can avoid importing certificates to the browsers if you install a certificate
on the CMS which is signed by a CA trusted by the browser.
l To prevent attacks (e.g. "BEAST" and "POODLE" ), only use the SSLv2Hello,
TLSv1.1, TLSv1.2, and TLSv1.3 protocols.
l Print out the server certificate’s fingerprint, or copy it onto a medium such as
a USB stick to allow you to compare it with the value given by the browser when establishing the SSL-secured HTTP connection.
l Thoroughly check a certificate before importing it to the trust store. Ensure
that the fingerprints of the certificate, which can be displayed , for example, by using the -printcertor-importcertcommands of the Java Keytool,
match the fingerprints transmitted by the issuer (e.g. by e-mail). For details, see
https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html.
3.2
Certification Authorities (CA)
A CA is responsible for issuing public key certificates which prove public key authenticity by ensuring that the person who claims to be the owner of the key actually is its owner. This prevents the communication endpoints from falling victim to a "man-in-the-middle" attack. Before issuing a certificate, the CA verifies the information provided by the certificate requester, includes his or her identifying data and public key in a standardized data structure (e.g. X.509) and signs this structure with the CA's own private key.
3.2.1
Certificates can be issued by different types of CA
Certificates can be issued by the following types of CA:l Commercial CAs such as VeriSign (http://www.verisign.com), Thawte and TC
TrustCenter GmbH Hamburg.
l Besides commercial CAs, some providers (e.g. CAcert) issue digital
certificates free of charge.
l Large companies and institutions often have their own CAs.
Beyond that, anyone can set up their own CA. The certificates issued by such a CA are signed with the private key of the self-signed certificate previously created for the CA. A self-signed certificate is a certificate that is signed with its own
private key. For details on how to create self-signed certificates, see section "Creating X.509 certificates" on page 44.
3.2.2
Hierarchical trust structure: Root CA and subordinate
(intermediate) CAs
X.509 certificates work with a hierarchical trust structure in the form of a tree, at the top of which a specific CA, the Root CA, is legally liable for ensuring the proven identity of the certificate owners. A distinction is made between a strict hierarchical trust structure and a distributed hierarchical trust structure. Root CA, subordinate CAs, and RAs
The Root CA is identified by a self-signed certificate and according to RFC 4210 represents a CA that is directly trusted by an end entity. Normally, the
trustworthiness of a root certificate is legally attested by passing through an out-of-band process.
For signing requests (certificate signing requests, CSR) from subordinate CAs, the Root CA uses the private key from its self-signed certificate. A self-signed certificate is a certificate that is digitally signed by the same entity (i.e. the Root CA) that the certificate identifies. Subordinate CAs are also known as
intermediate CAs.
A CA may delegate the end entity validation process to a Registration Authority (RA), which may be an integral part of the CA or act as a separate instance. Depending on the CA's policy, the RA may sign the certification signing request (CSR) once validation has completed, or forward the CSR to the CA.
Hierarchical trust structure
In a hierarchical trust structure, interaction between the CAs is as follows: 1. The Root CA certifies its subordinate CAs which in turn certify their
subordinate CAs.
2. A CA may accredit a Registration Authority (RA) to verify an end entity (which sends a certificate signing request, CSR).
3. Depending on the CA's policy, the RA may certify the end entity on its own or forward the CSR to the CA (indicated by 3' in the figure shown below). 4. A CA certifies an end entity.
The following figure outlines a hierarchy of CAs:
Figure 7: CAs - hierarchical trust structure
Certificate chaining
The second-tier CAs get their certificates signed by the Root CA. Third-tier CAs get their certificates from the second-tier CAs and so on, all the way down to the end entities. This way, certificate chains are formed starting from the Root CA certificate down to the individual end entities that form the nodes of the tree. Each certificate of a chain is therefore not only signed by the issuing CA but also by all CAs directly preceding the issuing CA in the trust hierarchy. The Root CA's certificate, which is known as the Root CA certificate, represents the trust anchor of the certificate chain.
To make the certificate chain comprehensible for e.g. the end user's browser, each chain certificate must be installed on the respective server.
The following figure shows an example of a certificate chain together with the issuing CAs:
Figure 8: Certificate chain and issuing CAs
3.2.3
Creating your own CA
The basic concept of creating and operating your own CA consists of creating a self-signed certificate whose private key will be used later on to sign the server certificates. The self-signed certificate thus serves as the Root CA certificate of your own CA.To avoid browser security warnings when accessing the server from a Web browser, the self-signed certificate must be imported to the trust store of all Web browsers which are intended to access the server via HTTPS. A significant advantage of using your own private CA is that it is free of charge.
Before creating your own CA, you should acquire a thorough
understanding of the subject PKI, for example by reading the relevant literature.
The following explains by way of example how you can use the OpenSSL toolkit to create your own CA. Creating your own CA primarily consists of creating a private key, which later on will be used for signing the server certificates. Proceed as follows:
1. Create the private key that is to be used for your CA:
openssl genrsa -aes256 -out rootCAprivate.key 4096
You will then be prompted to enter a passphrase for the key. The created private key is output in the .key file (here: rootCAprivate.key)
Important!
The .key file containing the private key of your CA must be securely protected. An offender gaining unauthorized access to your CA's private key can easily sign certificates which will be trusted by the clients. This risk can be greatly reduced by securing the private key with a passphrase as shown above. Beyond that, it is strongly recommended to store the private key in a specially protected directory (e.g. on a separate server) or even on a smartcard.
2. Create a self-signed certificate (root certificate) using the previously created private key:
openssl req x509 new key rootCAprivate.key days 730 -out rootCApublic.pem
You will be prompted to enter the passphrase for the previously created private key (here: rootCAprivate.key). Then you will be prompted to enter the values for some identifying certificate attributes: Country Name, State or Province Name, City or Locality, Organization Name,
Organizational Unit, Common Name, Email Address. The created root certificate is output in the .pem file (here: rootCApublic.pem)
3.3
X.509 certificates
Public key certificates conforming to the X.509 standard (referred to as X.509 certificates or simply certificates in the following for short) are used in conjunction with SSL. An X.509 certificate is a data structure containing all the information required to identify the server or client, plus the public key of the certificate owner. Certificates are issued by a central authority, the Certification Authority (CA), by signing them with its private key once the identity of the organization named in the certificate and of an authorized representative has been checked. The signature is contained in the certificate and is disclosed at the time of connection setup so that the client can verify the trustworthiness of the certificate. Optionally, the server can also request a certificate from the client. A certificate has a limited lifetime.
3.3.1
Certificate types
SSL certificates can be classified with regard to the following aspects:
l Scope of validity l Issuing instance
3.3.1.1 Certificate types relating to the scope of validity The most important are:
l Single-server certificates
l Intermediate certificates (chain certificates) l Cross certificates
l Multi-domain certificates l Multi-host certificates l Wildcard certificates
These certificate types are not the subject of this manual and are only mentioned here for completeness.
3.3.1.2 Certificate types relating to the issuing instance
l Self-signed certificates l CA certificates
l Root certificates, which are special cases of the above certificate types
Self-signed certificates
A self-signed certificate is a certificate that is signed with the private key
belonging to the public key whose authenticity the certificate is to prove. In other words, the certificate is signed by the same entity that it identifies. Self-signed certificates are preferably used for establishing your own CA or in test
environments.
For details on how to create self-signed certificates, see section"Creating X.509 certificates" on page 44).
CA certificates
A CA certificate is a certificate that a CA issues to a subordinate CA or to an end entity.
For details on how to create a CA certificate, see section"Creating X.509 certificates" on page 44.
Root certificates
A root certificate is a certificate that is not signed by another CA. Therefore, a root certificate is at the top of a certificate chain.
As apparent from the above, there are two different types of root certificate:
l Root CA certificates, i.e. the self-signed certificate of the top-level CA. l "Normal" self-signed certificates.
The"X.509 certificates" on page 37is also an example of a Root CA certificate.
3.3.2
Certificate Revocation Lists (CRL) and OCSP
Situations where it is necessary to withdraw the trust in a certificate within its validity period regularly occur in practice, e.g. in the case of a compromised private key or when the identifying data of a certificate owner has changed.
Certificate Revocation Lists (CRL)
For certificate revocation, CAs maintain Certificate Revocation Lists (CRL). A CRL lists all certificates issued by the CA that have been revoked before their scheduled expiration date.
Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) is defined in RFC 2560 and allows applications to determine the (revocation) state of an SSL certificate online. OCSP claims to provide more timely revocation information than is possible with CRLs and may also be used to obtain additional status information.
Revoking a CA certificate
When a CA certificate is revoked, all certificates issued by the corresponding CA or one of the related subordinate CAs also become invalid.
3.3.3
Structure of an X.509 certificate
X.509 certificates, which are normally issued by a CA, contain all the information required to identify the server or client, plus the public key of the certificate owner. Certificates are stored in separate files. When a connection is negotiated, SSL uses the certificate files to identify the server and, in some applications, also the client.
An X.509 certificate includes a variety of information fields. Some of the most important are listed below:
l Version of the certificate structure (e.g. 3) l Serial number (unique to each issuer)
l Signature algorithm (e.g. SHA-1 with RSA encryption)
l Issuer of the certificate: Distinguished Name (DN) of the issuing authority l Validity (Not before / not after)
l Subject: Distinguished Name (DN) of the entity to which the certificate is
issued
l Subject public information
o Algorithm, i.e. the OID of the public key algorithm used o The subject's public key, denoted as a string
l Extensions (e.g. Certificate Policies (CP), Certificate Practice Statements
(CPS))
l Digital signature covering all the certificate data
3.3.4
Applying for and creating X.509 certificates
Depending on your security considerations, you have the following options for acquiring an X.509 certificate:
l Obtaining an X.509 certificate from a commercial CA. l Creating your own CA.
l Using a self-signed certificate directly.
Obtaining an X.509 certificate from a commercial CA
Generally, you obtain an X.509 certificate from a commercial Certification Authority (CA) such as VeriSign (http://www.verisign.com), Thawte and TC TrustCenter GmbH Hamburg, to name but a few. The certificates issued by the CAs are normally classified by trust levels(e.g. “Class 3”). Alternatively, you can create your own CA which is based on a self-signed certificate, or you can use a self-signed certificate directly.
A distinguishing feature of the individual trust levels is the effort involved in identifying the applicant:
l In the case of low trust levels it is sufficient to be able to deliver e-mails to
the specified-e-mail address.
In the case of higher trust levels the applicant must, for example, supply a verified extract from the commercial register for the company involved. In addition, an authorized signatory or PKI executive of the company must identify themselves using the Post Ident procedure or something similar.
l Higher trust levels generally also mean higher warranty sums in the event
of loss, for example if the CA issues a certificate to an unauthorized entity. Further details can be found on the CAs’ websites.
Creating your own CA
If the certificates are only intended for in-house applications, it may make sense to set up your own CA (see"Certification Authorities (CA)" on page 32).
Self-signed certificates
A self-signed certificate is a certificate that is signed with its own private key, i.e it is signed by the same entity whose identity it proves.
Due to their straightforward availability, self-signed certificates are ideally suited for test environments. However, to fulfill the high safety requirements that are typical for e.g. productive server management, it is strongly recommended to use a certificate that is signed by a trusted Certification Authority (CA certificate), or at least by a CA you have created yourself.
Updating certificates
A new certificate must be obtained and installed in good time before the old one expires. If the private key has been compromised or the information in the certificate is no longer applicable, the certificate must be revoked.
3.3.5
X.509 file formats (extensions) for certificates and keys
From the operating system's point of view, X.509 certificates are files containing digital encoded documents. Two categories of file format (extensions) can be distinguished:l Encoding-specific file formats l Purpose-specific file formats
Encoding-specific file formats
The following file formats (extensions) indicate whether the related contents are binary-encoded or base64-encoded:
l .DER (Distinguished Encoding Rules)
.DER format is the basic container format for storing a single DER-encoded SSL certificate or a single private key. The DER format represents pure certificate and key data in binary ASN.1 notation and contains no header. A .DER file may contain:
o A single private key (RSA, DSA) o A single publc key (RSA, DSA) o A single X.509 certificate
On Windows systems, .DER files are only used for storing digital certificates.
Files conforming to .DER are also used in conjunction with other file extensions (e.g. .CERT, .CRT, .PVK).
l .PEM (Privacy Enhanced Email)
.PEM format is the container format for storing base64-encoded ASN.1 or .DER SSL certificates and/or private keys. The certificate/private key itself is enclosed between two special comment lines. Private keys and/or certificate chains can be stored in the same .PEM file. The .PEM format is the standard with OpenSSL, which also allows you to convert .PEM files to .DER files. A .PEM file may contain:
o Private keys (RSA, DSA) o Public keys (RSA, DSA) o X.509 certificates
On Windows systems, .PEM files are only used for storing digital certificates.
Files conforming to .PEM are also used in conjunction with other file extensions (e.g. .CERT, .CRT, .CSR).
Purpose-specific file formats
The following file formats which are designated for specific purposes can be available.
l .CER, .CRT
The .CER and .CRTformats are used for certificates which may be encoded in binary .DER or as ASCII (base64-encoded) .PEM format. The .CER and . CRT formats are used almost synonymously. Beyond that, .CER and .CRT are safely interchangeable if coded in the same format (.DER or .CRT).
.CER is most commonly used in Windows environments, whereas .CRT is used largely on Linux systems.
l .spc, .p7a, .p7b, .p7c
The .spc, .p7a, .p7b, and .p7c formats conforming to the PKCS#7 standard represent binary file formats which allow you to store one or more certificates in an encrypted and signed format.
l .PFX, .p12
The .PFX and .p12 formats conforming to the PKCS#12 standard are used for storing private keys, public keys, and X.509 certificates in a binary
format.
l .PVK
The .PVK format is a binary file format for storing private keys with a password-based encryption.
l .NET
The .NET format conforming to the PKCS#8 standard is a binary file format for storing private keys. The private key may be optionally encrypted.
l .CSR (Certificate Signing Request)
The .CSR format is used to submit a certificate signing request (CSR) to a Certification Authority (CA). The request can be in .PEM format (base64-encoded) and is enclosed between the comment lines "---BEGIN NEW CERTIFICATE REQUEST---" and "---END NEW CERTIFICATE REQUEST---".
3.4
Software tools for managing certificates and
keys
The following software tools are needed to manage certificates and the associated keys:
l OpenSSL
You can download the OpenSSL tool from the Internet, e.g. from the Shining Light Productions website (http://www.slproweb.com). Another
recommended alternative is to install the Cygwin environment (http://www.cygwin.com).
If you are using the OpenSSL tool from the Shining Light Productions website, you must set the environment variable OPENSSL_CONF to the following value:
< path to the OpenSSL installation directory>/bin/openssl.cfg
l keytool
You can download the keytool from the Oracle website. As the keytool is installed in addition to the Java Virtual Machine, the utility can be found by default on the Central Management Station:
o On Windows systems: e.g. under C:\Program Files (x86)
Java 8, the installation path always contains the release number). o On Linux systems: /usr/java/default/bin
For details on how to manage certificates on Windows systems using Microsoft's own technology, please refer to:https://msdn.microsoft.com
3.5
Creating X.509 certificates
Public key certificates conforming to the X.509 standard (X.509 certificates, in the following certificates for short) are used in conjunction with SSL. An X.509 certificate is a data structure containing all the information required to identify the server or client, plus the public key of the certificate owner. Certificates are issued by a central authority, the Certification Authority (CA), by signing them with its private key once the identity of the organization named in the certificate and of an authorized representative has been checked. The signature is
contained in the certificate and is disclosed at the time of connection setup so that the client can verify the trustworthiness of the certificate. Optionally, the server can also request a certificate from the client. A certificate has a limited lifetime.
3.5.1
Creating a CA certificate
CA certificates are issued by a CA, by signing them with its private key once the identity of the organization named in the certificate has been checked. The signature is contained in the certificate and is disclosed at the time of connection setup so that the client can verify the trustworthiness of the certificate.
The following steps are required in order to create a CA certificate:
1. Create a certificate signing request (CSR, here: certrq.pem), e.g. by using the OpenSSL tool:
openssl req -new -keyout privkey.pem -out certreq.pem-days 365
2. Submit the CSR to your preferred CA.
The procedure of submitting the CSR varies depending on the commissioned CA. The CA returns the signed certificate (Certificate Reply), e.g. in PEM
format as certreply.pem, or in DER format as certreply.cer. In the following it is assumed that the certificate is in PEM format.
If necessary, you can convert the certificate from DER format to PEM format by using the following command:
openssl x509 -in certreply.cer -inform DER -out certreply.pem -outform PEM
If the certificate is to contain an extended key usage, it must be signed for the key usages server authentication (1.3.6.1.5.5.7.3.1) and client authentication (1.3.6.1.5.5.7.3.2), because it is used as both a server certificate and a client certificate.
3. Save the signed certificate to a file.
You can verify the signed certificate e.g. by using the openssl verify command. For details of the openssl verify command, refer to the man page about its use (https://www.openssl.org/docs/manmaster/apps/verify.html).
3.5.2
Creating a self-signed certificate
You have the option to create the self-signed certificate and the related private key either in one go or separately. The latter is the method of choice when using the self-signed certificate to create your own CA (see section"Certification Authorities (CA)" on page 32). To create a self-signed certificate, you can use the OpenSSL tool.
3.5.2.1 Creating the self-signed certificate in one go Enter the following command:
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
You will be prompted to enter the values for some identifying certificate attributes: Country Name, State or Province Name, City or Locality, Organization Name, Organizational Unit, Common Name, Email Address.
3.5.2.2 Creating the self-signed certificate based on a private key Proceed as follows:
1. Create the private key that is to be used for your CA:
You will then be prompted to enter a passphrase for the key. The created private key is output in the .key file (here: rootCAprivate.key)
Important!
The .key file containing the private key of your CA must be securely protected. An offender gaining unauthorized access to your CA's private key can easily sign certificates which will be trusted by the clients. This risk can be greatly reduced by securing the private key with a passphrase as shown above. Beyond that, it is strongly recommended to store the private key in a specially protected directory (e.g. on a separate server) or even on a smartcard. 2. Create a self-signed certificate using the previously created private key:
openssl req -x509 -new -key private.key -days 730 -out selfsignedcert.pem
You will be prompted to enter the passphrase for the previously created private key (here: rootCAprivate.key). Then you will be prompted to enter the values for some identifying certificate attributes: Country Name, State or Province Name, City or Locality, Organization Name,
Organizational Unit, Common Name, Email Address. The created root certificate is output in the .pem file (here: rootCApublic.pem).
3.6
Key store and trust store
Private keys, SSL certificates and the related public keys are stored in the key store and trust store.
l Key store
In the key store an end entity (SSL server or SSL client) stores the following data:
o The SSL private key that the end entity uses during the key exchange algorithm.
o SSL certificate related to the end entities' public keys which is sent to the communication partner for authentication.
l Trust store
In the trust store an end entity stores all SSL certificates it trusts. The Java-based key-and-certificate management of the Web server used by ServerView Operations Manager uses two files to manage key pairs and certificates:
l In the key store file (file name: keystore) the Web server (e.g. Tomcat)
stores its own key pairs and certificates.
l The trust store file (file name: cacerts) on the Web server contains all
Suite
Chapter 4 explains
l When certificates are needed within the ServerView Suite. l How you can get a certificate.
l How you can import a certificate into a ServerView component. l What further configuration is required.
Once you have read this chapter, you should be able to:
l Establish an SSL-secured connection between the individual components of
the ServerView Suite.
l Establish an SSL-secured Web-based connection with the individual
components of the ServerView Suite.
l Avoid browser security warnings when accessing a server from a Web
browser.
This chapter provides a general description of how to proceed with the ServerView components. For detailed instructions and explanations of the individual steps can, see the user guides for the respective ServerView components.
This chapter describes the management of certificates on Windows and Linux systems.
Managing certificates on VMware ESXi systems is the responsibility of VMware and therefore not covered here.
Purpose and usage of certificates by ServerView products
Web-based communication with and between the individual components of the ServerView Suite is secured by SSL connections. The following table shows which ServerView components use certificates and for what purpose:
ServerView component SSL certificates are used for ... Default SSL certificate ServerView Operations Manager Encryption, Identification, Authentication P
ServerView Agents Encryption, Authentication P iRMC S4 Encryption, Identification,
Authentication
P
ServerView System Monitor
Encryption, Authentication P
ServerView Raid Manager Encryption, Identification, Authentication
P
Table 1: Certificates used in the components of the ServerView Suite
Important!
It is strongly recommended that you replace the component's default certificate (self-signed certificate) with one signed by a CA as soon as possible.
4.1
Managing SSL certificates for server
management with ServerView Operations
Manager and ServerView Agents
To communicate with Web browsers and managed nodes, the Central
Management Station (CMS) uses a public key infrastructure (PKI) with secure SSL connections including authentication by accounts. How to configure Microsoft IIS or Apache for the SSL is described in the installation guides "ServerView
Operations Manager – Installation under Windows” and “ServerView Operations Manager – Installation under Linux”.
To prevent attacks (e.g. "BEAST" and "POODLE" ), the Web server used by ServerView Operations Manager only supports the following SSL/TLS protocols:
l As of ServerView Operations Manager V7.10, only SSLv2Hello,
TLSv1.1, and TLSv1.2 are supported.
l With ServerView Operations Manager < V7.10, only SSLv2Hello,
TLSv1.0, TLSv1.1, and TLSv1.2 are supported by default.
For details on how to modify the SSL configuration of OpenDJ and JBoss, please refer to the white paper "Secure PRIMERGY Server Management -Enterprise Security".
The CMS authenticates itself to the Web browser via server authentication
Web browsers always use an HTTPS connection (i.e. a secure SSL connection) to communicate with a Central Management Station (CMS). Therefore, the Web server used by ServerView Operations Manager on the CMS needs an X.509 certificate to authenticate itself to the Web browser via server authentication. The X.509 certificate contains all the information required to identify the Web server used by ServerView Operations Manager, plus the public key of the Web server.
Unless you are absolutely sure that you are connected with the desired CMS, you should meticulously check the fingerprint(s) of the CMS’s server certificate.
The CMS authenticates itself to the managed node via client authentication
A managed node (e.g. PRIMERGY server) on which Role Based Access Control (RBAC) functionality is used requires X.509 certificate-based client
authentication. Therefore, a CMS has to authenticate itself when connecting to a managed node. Client authentication prevents the managed node from being accessed by a non-trusted CMS or a non-privileged application running on the CMS.
Client authentication requires that the certificate of a trusted CMS has been previously installed on the managed node.
Client authentication of the CMS is achieved via the ServerView Connector Service (SCS). Based on a patent owned by Fujitsu Technology Solutions GmbH, the ServerView Connector Service is a TCP/IP Web service with one port number (3172) for SSL and non-SSL calls. The SCS has a SOAP interface and comprises various security topics (e.g. RBAC/Single Sign-On (SSO) combined with SSL encryption).
To enable a CMS to authenticate itself as a client to the managed node, the CA certificate and the corresponding configuration files must be made available in the trust store of the SCS on the managed node (see the "User Management in ServerView" user guide for details).
4.1.1
Managing SSL certificates on the CMS
To communicate with the Web server used by ServerView Operations Manager, Web browsers always use an HTTPS connection (i.e. a secure SSL connection). Therefore, the Web server used by ServerView Operations Manager needs a certificate (X.509 certificate) to authenticate itself to the Web browser. The X.509 certificate contains all the information required to identify the Web server used by ServerView Operations Manager, plus the public key of the Web server. 4.1.1.1 Self-signed certificate
A self-signed certificate in PEM format is created automatically for the (local) Web server used by ServerView Operations Manager during the Operations Manager setup. Due to their straightforward availability, self-signed certificates are ideally suited for test environments. However, to fulfill the high safety
