Managing SSL certificates in the ServerView Suite

Transcription

1 Overview - English FUJITSU Software ServerView Suite Managing SSL certificates in the ServerView Suite Secure server management using SSL and PKI Edition September 2015

2 Comments Suggestions Corrections 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 to 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 Copyright and trademarks Copyright 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.

3 Contents 1 Introduction Target groups and objectives of this manual ServerView Suite link collection Documentation for the ServerView Suite Typographic conventions 10 2 Communication security: SSL, PKI and certificates Communication security on the Internet Fundamentals of cryptography Encryption methods Symmetric key encryption Asymmetric key encryption (public key encryption) Hybrid encryption methods Cryptographic hash functions Message Authentication Code (MAC) Digital signatures SSL (overview) SSL in the TCP/IP protocol stack SSL handshake Cipher suites Digital certificates and Certification Authorities (CA) Public key infrastructure (PKI) 28 3 Managing digital certificates using PKI Security recommendations Certification Authorities (CA) Certificates can be issued by different types of CA Hierarchical trust structure: Root CA and subordinate (intermediate) CAs Creating your own CA X.509 certificates Certificate types Certificate types relating to the scope of validity 37 Managing SSL certificates 3

4 Contents Certificate types relating to the issuing instance Certificate Revocation Lists (CRL) and OCSP Structure of an X.509 certificate Applying for and creating X.509 certificates X.509 file formats (extensions) for certificates and keys Software tools for managing certificates and keys Creating X.509 certificates Creating a CA certificate Creating a self-signed certificate Creating the self-signed certificate in one go Creating the self-signed certificate based on a private key Key store and trust store 46 4 SSL communication in the ServerView Suite Managing SSL certificates for server management with ServerView Operations Manager and ServerView Agents Managing SSL certificates on the CMS Self-signed certificate Replacing the certificate on the CMS Managing certificates for SSO and RBAC on the managed node Installing the CMS certificate on the managed node(s) via ServerView Update Manager Overview Installing the CMS certificate on the managed node(s) Uninstalling the CMS certificate from the managed node(s) Trust state column in the ServerView server list on the CMS Managing SSL certificates on the irmc S Pre-installed default certificates Uploading SSL certificates and Root CA certificate onto the irmc S Uploading a Root CA certificate into the trust store of the irmc S Uploading an SSL certificate into the key store of the irmc S Generating a self-signed SSL certificate No ServerView Update Management support Secure SSL communication with the ServerView RAID Manager Secure SSL communication with the SSM Web Interface 70 4 Managing SSL certificates

5 Contents Requirements and overview Requirements for using a secure HTTPS connection Steps needed to establish a secure HTTPS connection via strategy Creating your own CA Importing the Root CA certificate into the browsers of the communication end devices Preparing the managed server for secure HTTPS communication with the end devices Creating a server certificate for the managed node Creating the ServerView Connector Service certificate Configuring the ServerView Connector Service 77 Managing SSL certificates 5

6 6 Managing SSL certificates

7 1.1 Target groups and objectives of this manual 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: Create your own certification authority (CA). Create a CA Certifcate. Create a self-signed certificate. Managing SSL certificates 7

8 1 Introduction Use certificates within the ServerView Suite. o o o To ensure secure communication between the individual components of the ServerView Suite. To ensure secure Web-based communication with the individual components of the ServerView Suite. 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: Forum Service Desk Manuals Product information Security information Software downloads Training The downloads include the following: o o o Current software statuses for the ServerView Suite as well as additional Readme files. 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. The current versions of all documentation on the ServerView Suite. You can retrieve the downloads free of charge from the Fujitsu Web server. 8 Managing SSL certificates

9 1.3 Documentation for the ServerView Suite For PRIMERGY servers, links are offered on the following topics: Service Desk Manuals Product information 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. 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: In the selection list on the left, select x86 Servers. 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. In the start window of the ServerView Suite DVD 2, select the option ServerView Software Products. 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 at under the link x86 Servers. Managing SSL certificates 9

10 1 Introduction 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 bold Indicates various types of risk, namely health risks, risk of data loss and risk of damage to devices. Indicates additional relevant information and tips. Indicates references to names of interface elements. monospace Indicates system output and system elements, e.g., file names monospace semibold <abc> [abc] [key] and paths. Indicates statements that are to be entered using the keyboard. Indicates variables which must be replaced with real values. Indicates options that can be specified (syntax). 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. 10 Managing SSL certificates

11 2 Communication security: SSL, PKI and 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: Communication security on the Internet Fundamentals of cryptography SSL X.509 certificates 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 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. Managing SSL certificates 11

12 2 Communication security: SSL, PKI and certificates 2.1 Communication security on the Internet Communication security comprises the following aspects: 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. Data confidentiality Data confidentiality prevents data from being read by unauthorized persons. Data integrity Data integrity guarantees that transferred data has not been modified. Anti-replay Anti-replay prevents data from being intercepted and read in again by an intruder. Confidentiality of the traffic flow Confidentiality of the traffic flow prevents unauthorized persons from obtaining information through unauthorized analysis of the message traffic. 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. 12 Managing SSL certificates

13 2.2 Fundamentals of cryptography 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: Encryption methods ensure data confidentiality. Cryptographic hash functions and Message Authentication Codes (MACs). Digital signatures ensure non-repudiation. Most cryptographic methods require strong random numbers Encryption methods There are two classes of encryption methods which, because of their specific advantages and disadvantages, are tailored to different application areas: Symmetric key encryption methods. Symmetric key encryption methods are used for encrypting the payload (confidentiality). Asymmetric (public) key encryption methods. Asymmetric key encryption methods are used: o o In key exchange protocols. To create digital signatures (non-repudiation). 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 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. Managing SSL certificates 13

14 2 Communication security: SSL, PKI and certificates 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: AES (Advanced Encryption Standard) Candidates for AES, the successor standard to DES, were sought in a competition, the winner being a method named Rijndael. 3-DES ( Triple DES ) 3-DES comprises consecutive three-fold DES encryption. 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. 14 Managing SSL certificates

15 2.2 Fundamentals of cryptography 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 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: Public key The public key is known to all communication partners and is used to encrypt messages. 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.) 4. B decrypts the message with the aid of his/her private key. Managing SSL certificates 15

16 2 Communication security: SSL, PKI and certificates The following figure outlines the principles of public key encryption: Figure 2: Public key encryption The best-known asymmetric key encryption methods are: RSA RSA stands for the inventors Rivest, Shamir and Adleman. 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). 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. 16 Managing SSL certificates

17 2.2 Fundamentals of cryptography 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 Hybrid encryption methods Hybrid encryption methods combine the specific advantages of symmetric and asymmetric encryption while at the same time bypassing the weaknesses. 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. Due to its ease of managing keys, asymmetric encryption is employed for key exchange and digital signatures 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. Managing SSL certificates 17

18 2 Communication security: SSL, PKI and certificates A hash algorithm suitable for cryptographic purposes must satisfy a number of requirements: For identical input, a hash algorithm must return the same output. Minimal changes to the input must result in a significantly changed message digest. Under no circumstances should it be possible to reconstruct the input from the message digest. 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 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 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: Data integrity Data integrity means that the document has not been changed since the time the signature was created. Data origin (authenticity) 18 Managing SSL certificates

19 2.2 Fundamentals of cryptography 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. Managing SSL certificates 19

20 2 Communication security: SSL, PKI and certificates 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. 20 Managing SSL certificates

21 2.3 SSL (overview) 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 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 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 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: Managing SSL certificates 21

22 2 Communication security: SSL, PKI and certificates 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. 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). 22 Managing SSL certificates

23 2.3 SSL (overview) 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. Managing SSL certificates 23

24 2 Communication security: SSL, PKI and certificates The following diagram outlines the steps required for an SSL handshake: Figure 6: SSL handshake 24 Managing SSL certificates

25 2.3 SSL (overview) 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. 2. Server Hello The cipher suite used by client and server for the first steps (including ChangeCipherSpec (Client) message) of the SSL handshake is TLS_ NULL_WITH_NULL_NULL (null cipher suite). The related messages are therefore sent without encryption. 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 Managing SSL certificates 25

26 2 Communication security: SSL, PKI and certificates 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). 26 Managing SSL certificates

27 2.3 SSL (overview) 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 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. RSA is the key exchange algorithm. WITH_3DES_EDE_CBC specifies the symmetric cipher for encrypting the payload data traffic (here: Triple DES with Cyclic Block Chaining). SHA specifies 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: RSA_WITH_3DES_EDE_CBC_SHA RSA_WITH_AES_128_CBC_SHA Managing SSL certificates 27

28 2 Communication security: SSL, PKI and certificates 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. 28 Managing SSL certificates

29 2.5 Public key infrastructure (PKI) The following components and services are part of a PKI: Digital certificates Support for non-repudiation Certification Authority Registration Authority Certificate repository Certificate revocation Key backup and recovery Automatic key update Key history management Cross-certification Time-stamping Certificate policies (CP) and Certification Practice Statements (CPS) 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. Managing SSL certificates 29

30 30 Managing SSL certificates

31 3.1 Security recommendations 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: Security recommendations Certification Authorities (CA) X.509 certificates Software tools to manage certificates and keys Creating X.509 certificates Key store and trust store 3.1 Security recommendations When using certificates, you are strongly advised to keep the following recommendations in mind: 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. It is recommended to use certificates that are signed by a trusted Certification Authority (CA certificate). 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. 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. 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. 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. Managing SSL certificates 31

32 3 Managing digital certificates using PKI 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. To prevent attacks (e.g. "BEAST" and "POODLE" ), only use the SSLv2Hello, TLSv1.1, TLSv1.2, and TLSv1.3 protocols. 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. 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 -printcert or -importcert commands of the Java Keytool, match the fingerprints transmitted by the issuer (e.g. by ). For details, see 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 Certificates can be issued by different types of CA Certificates can be issued by the following types of CA: Commercial CAs such as VeriSign ( Thawte and TC TrustCenter GmbH Hamburg. Besides commercial CAs, some providers (e.g. CAcert) issue digital certificates free of charge. 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 32 Managing SSL certificates

33 3.2 Certification Authorities (CA) private key. For details on how to create self-signed certificates, see section "Creating X.509 certificates" on page 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 outof-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. Managing SSL certificates 33

34 3 Managing digital certificates using PKI 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. 34 Managing SSL certificates

35 3.2 Certification Authorities (CA) 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 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. Managing SSL certificates 35

36 3 Managing digital certificates using PKI 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 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, Address. The created root certificate is output in the.pem file (here: rootcapublic.pem) 36 Managing SSL certificates

37 3.3 X.509 certificates 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 Certificate types SSL certificates can be classified with regard to the following aspects: Scope of validity Issuing instance Certificate types relating to the scope of validity The most important are: Single-server certificates Intermediate certificates (chain certificates) Cross certificates Multi-domain certificates Multi-host certificates Wildcard certificates These certificate types are not the subject of this manual and are only mentioned here for completeness. Managing SSL certificates 37

38 3 Managing digital certificates using PKI Certificate types relating to the issuing instance Self-signed certificates CA certificates 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: Root CA certificates, i.e. the self-signed certificate of the top-level CA. "Normal" self-signed certificates. The "X.509 certificates" on page 37 is also an example of a Root CA certificate 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. 38 Managing SSL certificates

39 3.3 X.509 certificates 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 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: Version of the certificate structure (e.g. 3) Serial number (unique to each issuer) Signature algorithm (e.g. SHA-1 with RSA encryption) Issuer of the certificate: Distinguished Name (DN) of the issuing authority Validity (Not before / not after) Subject: Distinguished Name (DN) of the entity to which the certificate is issued Subject public information o o o Algorithm, i.e. the OID of the public key algorithm used The subject's public key, denoted as a string Algorithm used for public key encrytion (e.g. RSA) Managing SSL certificates 39

40 3 Managing digital certificates using PKI Extensions (e.g. Certificate Policies (CP), Certificate Practice Statements (CPS)) Digital signature covering all the certificate data Applying for and creating X.509 certificates Depending on your security considerations, you have the following options for acquiring an X.509 certificate: Obtaining an X.509 certificate from a commercial CA. Creating your own CA. 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 ( 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: In the case of low trust levels it is sufficient to be able to deliver s to the specified- 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. 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). 40 Managing SSL certificates

41 3.3 X.509 certificates 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 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: Encoding-specific file formats Purpose-specific file formats Encoding-specific file formats The following file formats (extensions) indicate whether the related contents are binary-encoded or base64-encoded:.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 o o A single private key (RSA, DSA) A single publc key (RSA, DSA) A single X.509 certificate On Windows systems,.der files are only used for storing digital certificates. Managing SSL certificates 41

42 3 Managing digital certificates using PKI Files conforming to.der are also used in conjunction with other file extensions (e.g..cert,.crt,.pvk)..pem (Privacy Enhanced ).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 o o Private keys (RSA, DSA) Public keys (RSA, DSA) 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..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..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..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 42 Managing SSL certificates

43 3.4 Software tools for managing certificates and keys format..pvk The.PVK format is a binary file format for storing private keys with a password-based encryption..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..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: OpenSSL You can download the OpenSSL tool from the Internet, e.g. from the Shining Light Productions website ( Another recommended alternative is to install the Cygwin environment ( keytool 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 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\jre7\bin or e.g. under C:\Program Files\Java\jre1.8.0_60 (with Managing SSL certificates 43

44 3 Managing digital certificates using PKI o Java 8, the installation path always contains the release number). 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: 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 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 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 44 Managing SSL certificates

45 3.5 Creating X.509 certificates 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 ( ) and client authentication ( ), 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 ( 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 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, Address 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: openssl genrsa -aes256 -out private.key 4096 Managing SSL certificates 45

46 3 Managing digital certificates using PKI 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, 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. Key store In the key store an end entity (SSL server or SSL client) stores the following data: o o The SSL private key that the end entity uses during the key exchange algorithm. SSL certificate related to the end entities' public keys which is sent to the communication partner for authentication. 46 Managing SSL certificates

47 3.6 Key store and trust store 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: In the key store file (file name: keystore) the Web server (e.g. Tomcat) stores its own key pairs and certificates. The trust store file (file name: cacerts) on the Web server contains all certificates the Web server rates as trustworthy. Managing SSL certificates 47

48 48 Managing SSL certificates

49 4 SSL communication in the ServerView Suite Chapter 4 explains When certificates are needed within the ServerView Suite. How you can get a certificate. How you can import a certificate into a ServerView component. What further configuration is required. Once you have read this chapter, you should be able to: Establish an SSL-secured connection between the individual components of the ServerView Suite. Establish an SSL-secured Web-based connection with the individual components of the ServerView Suite. 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: Managing SSL certificates 49

50 4 SSL communication in the ServerView Suite ServerView component SSL certificates are used for... Default SSL certificate ServerView Operations Manager Encryption, Identification, Authentication ServerView Agents Encryption, Authentication P irmc S4 ServerView System Monitor Encryption, Identification, Authentication Encryption, Authentication ServerView Raid Manager Encryption, Identification, Authentication 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. P P P P 50 Managing SSL certificates

51 4.1 Managing SSL certificates for server management with ServerView 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: As of ServerView Operations Manager V7.10, only SSLv2Hello, TLSv1.1, and TLSv1.2 are supported. 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. Managing SSL certificates 51

52 4 SSL communication in the ServerView Suite 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) 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 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 52 Managing SSL certificates

53 4.1 Managing SSL certificates for server management with ServerView requirements that are typical for productive server management using the Operations Manager, it is strongly recommended to use a certificate that is signed by a trusted Certification Authority (CA certificate). When connecting to the Web server used by ServerView Operations Manager whose certificate is not signed by a CA but only self-signed, a Web browser will not open ServerView s start page, but will display a warning such as This Connection is Untrusted or There is a problem with this website's security certificate and ask you whether you want to proceed with loading the page. If you proceed at this point and are not totally sure which server you are connected, you should not issue any sensitive datasuch as passwords, but first thoroughly check the server certificate by comparing its fingerprint(s) with those of the server s private key. You get the fingerprint(s) on the CMS by issuing the following command using an administrative account (or the account which the Web server used by ServerView Operations Manager is started with): On Windows systems: %JAVA_BIN_PATH%keytool -keystore %PKI_PATH%keystore - storepass %STOREPASS% -list -v On Linux systems: ${JAVA_BIN_PATH}keytool -keystore ${PKI_PATH}keystore - storepass ${STOREPASS} -list -v The meaning of the placeholders is as follows: JAVA_BIN_PATH Path to the bin directory of the Java installation, e.g. C:\Program Files (x86)\java\jre6\bin\ PKI_PATH Path to the pki directory of the ServerView Suite installation, e.g. C:\Program Files (86)\Fujitsu\ServerView Suite\jboss\server\serverview\conf\pki\ STOREPASS The password of the key store. Currently this is always "changeit". In the extensive output of this command, the lines under the heading "Certificate Fingerprints contain the requested information, as in the following example: Certificate Fingerprints MD5: B9:6E:38:F4:B6:9C:80:0D:79:C4:ED:D4:FC:92:69:E4 Managing SSL certificates 53

54 4 SSL communication in the ServerView Suite SHA1: 58:DE:5C:0B:62:E2:94:77:51:09:40:9C:0A:6D:99:B1:0C:53:B5:C5 You will need this fingerprint when importing the server certificate of the CMS into the trust store of your browser. Therefore print it out, or copy it to a secure medium so that you have it for the comparison later on Replacing the certificate on the CMS Generally speaking, the following steps are required on the CMS, e.g. to replace the initially created self-signed certificate with a certificate of a trusted CA. 1. Replacing the certificate on the CMS a. Importing the new certificate into the key store file b. Importing the new certificate into the trust store file 2. Creating the key store file in PEM format and storing it in the appropriate PKI folder on the CMS. 3. Creating the file <system_name>.scs.pem in PEM format and storing it in the appropriate PKI folder(s). This file is required by the ServerView Remote Connector Service. 4. Restarting the service of the Web server used by ServerView Operations Manager and the ServerView services to activate the changes. Before importing a certificate into the key store, thoroughly check the server certificate by comparing its fingerprint(s) with those of the server s private key. To get the fingerprint(s), proceed as described above (see page 53). For detailed instructions and explanations of the individual steps, see the "User Management in ServerView" user guide Managing certificates for SSO and RBAC on the managed node Generally speaking, preparing a managed node for client authentication and RBAC requires the following steps: 1. Transferring the certificate files (<system_name>.scs.pem) and <system_ name>.scs.xml) from the CMS to the managed node. 2. Installing the transferred files on the managed node. 54 Managing SSL certificates

55 4.1 Managing SSL certificates for server management with ServerView For detailed instructions and explanations of the individual steps, see the "User Management in ServerView" user guide Installing the CMS certificate on the managed node(s) via ServerView Update Manager Overview Prerequisites ServerView Update Agent and ServerView Agents as of version 5.0 must be installed on the managed node. For each managed node displayed in the server list, the update mechanism of the ServerView Update Manager allows you to install the CMS certificate on the managed node directly from the server list. As in the case of other update components, the Update Manager offers you the CMS certificate as software available for installation. You can automatically transfer the certificate to one or more managed nodes by creating and starting an update job. For this purpose, each certificate file generated for the CMS must be located in the repository that is assigned to the Update Manager (path name:...\tools\certificates (Windows) and.../tools/certificates (Linux/VMware). In the regular initial configuration of the repository, the configuration wizard of the Update Manager automatically adds the certificates to the repository at the end of the configuration. During an update installation the certificates are automatically added to the repository by executing the corresponding install scripts. Important! It is only allowed to specify a local repository because the added data is exclusively valid for the respective CMS. You can control the installation of the CMS certificate on the managed node by using the Update Manager main window as described below. For details on the ServerView Update Manager, refer to the "ServerView Update Manager" user guide. Managing SSL certificates 55

56 4 SSL communication in the ServerView Suite Server Details tab of the Update Manager main window (before installing the CMS certificate on the managed node) Figure 9: CMS certificate not yet installed (Server Details tab) As long as the CMS certificate is not installed on a managed node, not certified is displayed for this node under Agent Access in the Server Details tab. If not both ServerView Update Agent and ServerView Agents on a managed node are as of version 5.0, the string restricted or unrestricted is displayed for this node under Agent Access in the Server Details tab. 56 Managing SSL certificates

57 4.1 Managing SSL certificates for server management with ServerView Update Details tab of the Update Manager main window (before installing the CMS certificate on the managed node) Figure 10: CMS certificate not yet installed (Update Details tab) In the Upgrades view of the Update Details tab, a separate line indicates the option to install the CMS certificate on the selected node. Now you can create and start a new update job that performs this installation on the managed node. The update job may optionally comprise additional update components. For details on how to create an update job, refer to the "ServerView Update Manager" user guide. Managing SSL certificates 57

58 4 SSL communication in the ServerView Suite Server Details tab of the Update Manager main window (after successful installation of the CMS certificate on the CMS window) Figure 11: CMS certificate successfully installed (Server Details tab) Once the CMS certificate has been successfully installed on the managed node, certified is displayed for this node under Agent Access in the Server Details tab. 58 Managing SSL certificates

59 4.1 Managing SSL certificates for server management with ServerView Update Details tab of the Update Manager main window (after successful installation of the CMS certificate on the CMS window) Figure 12: CMS certificate successfully installed (Update Details tab ) Once the CMS certificate has been successfully installed on the managed node, a separate line in the Installed Updates view of the Update Details tab informs of the successful installation of the CMS certificate on the managed node Installing the CMS certificate on the managed node(s) To install the CMS certificate on one or more managed nodes, proceed as follows: 1. Open the Update Manager main window. There are two ways to open the Update Manager in the ServerView Operations Manager: On the start page of the ServerView Operations Manager, choose Update Management/Update Manager. In the ServerView menu bar, choose Update Management/Update Manager. Managing SSL certificates 59

60 4 SSL communication in the ServerView Suite 2. Under All Servers, select the managed node(s) on which you want to install the CMS certificate. 3. In the Upgrades view of the Update Details tab, select the line indicating the option to install the CMS certificate on the selected node(s). 4. Create and start a new update job that installs the CMS certificate on the managed node(s) Uninstalling the CMS certificate from the managed node(s) To uninstall the CMS certificate from one or more managed nodes, proceed as follows: 1. Open the Update Manager main window. There are two ways to open the Update Manager in the ServerView Operations Manager: On the start page of the ServerView Operations Manager, choose Update Management/Update Manager. In the ServerView menu bar, choose Update Management/Update Manager. 2. Under All Servers, select the managed node(s) from which you want to uninstall the CMS certificate. 3. In the Downgrades view of the Update Details tab, select the line that displays "Uninstall" in the New Version column. 4. Create and start a new update job that uninstalls the CMS certificate from the managed node(s). 60 Managing SSL certificates

61 4.1 Managing SSL certificates for server management with ServerView Trust state column in the ServerView server list on the CMS The server list in the ServerView Operations Manager main window contains columns with icons that can describe the status of an object in more detail, e.g. in terms of its alarm level, archive data and update status. It also contains a column which describes the trust state of an object. Column header icon. RBAC1-capable service and trust data are available (including certificate). The managed server trusts this management station. RBAC-capable service is available but trust data is missing (including certificate). The managed server does not trust this management station. The ServerView service on the managed server is not RBACcapable (older). This managed server requires user/password settings. No It could be that the corresponding ServerView service is not available on icon the managed node. Figure 13: Trust icons in the server list You can click the column header icon to sort the server list accordingly. Managing SSL certificates 61

62 4 SSL communication in the ServerView Suite 4.2 Managing SSL certificates on the irmc S4 The irmc S4 requires SSL certificates for the following purposes: An SSL certificate is always required in the key store of the irmc S4 Web server to ensure that the irmc S4 can authenticate itself at a Web client (Web browser). For security reasons, it is strongly recommended that you enable SSL certificate verification for an irmc S4 participating in an SSO domain (see the "irmc S4 - integrated Remote Management Controller" user guide). Enabling SSL certificate verification requires the following steps: o o Enabling the Verify SSL Certificate option in the irmc S4 Web interface. The Root CA certificate corresponding to the server certificate of the CAS server (e.g. on the ServerView CMS) must be uploaded into the trust store of the irmc S4. All SSL certificate-related actions on the irmc S4 can be initiated in the irmc S4 - Certificate Upload and irmc S4 - Generate a self signed RSA Certificate pages of the irmc S4 Web interface. To prevent attacks (e.g. "BEAST" and "POODLE" ), the irmc S4 by default only supports the following SSL/TLS protocols: TLSv1.0 TLSv1.1 TLSv1.2 If you still want to enable SSLv3, you can do this by enabling the Enable SSLv3 option on the Network Settings - Ports and Network Services page of the irmc S4 Web interface Pre-installed default certificates The irmc S4 comes with pre-installed certificates (default certificates): Root CA certificate located in the irmc S4's trust store. SSL certificate located in the key store of the irmc S4 Web sever. 62 Managing SSL certificates

63 4.2 Managing SSL certificates on the irmc S4 It is strongly recommended that you replace the pre-installed certificates with certificates signed by a CA as soon as possible Uploading SSL certificates and Root CA certificate onto the irmc S4 You use the Certificate Upload page of the irmc S4 Web interface to upload a Root CA certificate and/or an SSL certificate onto the irmc S4. Figure 14: Certificate Upload page of the irmc S4 Web interface The Certificate Information and Restore group allows you to display information on the currently installed certificates and to restore the default certificates. Figure 15: Displaying the currently installed certificates and restoring the default certificates Managing SSL certificates 63

64 4 SSL communication in the ServerView Suite Uploading a Root CA certificate into the trust store of the irmc S4 The CA Certificate upload from file group allows you to upload the contents of the base64 (PEM) encoded X.509 CA certificate from a local file. To avoid certificate error messages when the irmc S4 is accessed via CASbased single sign-on (SSO) and the Verify SSL Certificate option has been enabled in the CAS configuration of the irmc S4: Ensure that the CAS server's key store contains a CA certificate that is signed by the Root CA which has signed the certificate in the irmc S4's trust store. Figure 16: Uploading a CA certificate onto the irmc S4 Once the file has been uploaded, all current HTTPS connections of the irmc S4 will be closed and the irmc S4 Web server will be automatically restarted. This can take up to 30 seconds. No irmc S4 reset is required Uploading an SSL certificate into the key store of the irmc S4 The groups SSL Certificate and DSA/RSA private key upload from file and SSL Certificate and DSA/RSA private key via copy & paste allow you to upload the contents of a base64 (PEM) encoded X.509 SSL certificate and/or the base64 (PEM) encoded DSA/RSA private key. For uploading the SSL certificate and the private key, you have the following options. Use SSL Certificate and DSA/RSA private key upload from file to simultaneously upload the SSL Certificate and the DSA/RSA private key from separate files: 64 Managing SSL certificates

65 4.2 Managing SSL certificates on the irmc S4 Figure 17: Uploading an SSL certificate and private key onto the irmc S4 from files Once the files have been uploaded, all current HTTPS connections of the irmc S4 will be closed and the irmc S4 Web server will be automatically restarted. This can take up to 30 seconds. No irmc S4 reset is required. Use the SSL Certificate or DSA/RSA private key via copy & paste to upload the SSL Certificate and the DSA/RSA private key in two separate steps by copying the corresponding contents into the text box. Do not use this method for uploading your Root CA certificate onto the irmc S4. Figure 18: Uploading an SSL certificate or private key onto the irmc S4 via copy & paste Once the file(s) has/have been uploaded, you will need to restart the irmc S4 manually. Managing SSL certificates 65

66 4 SSL communication in the ServerView Suite Generating a self-signed SSL certificate You use the Generate a self signed RSA Certificate page of the irmc S4 Web interface to generate a self-signed SSL certificate and private key and upload them onto the irmc S4. Figure 19: Generate a self signed RSA Certificate page of the irmc S4 Web interface The Certificate Information and Restore group allows you to display information on the currently installed certificates and to restore the default certificates. In the Certificate Creation group, you can enter the information needed for creating the self-signed certificate and start certificate generation. When creating a new RSA certificate and key, all current HTTPS connections of the irmc S4 will be closed and the irmc S4 Web server will be automatically restarted. Depending on the key size, this process may take up to five minutes. No reset of the irmc S4 is required. 66 Managing SSL certificates