Certificate Management in Environments with Multiple HP

OpenView Products

Version 1.1 May 29, 2007
Abstract.............................................................................................................................................. 2
Introduction......................................................................................................................................... 2
SSL in HP OpenView............................................................................................................................ 3
Certificate Deployment ......................................................................................................................... 5
Merge and Share Approaches for Establishing Trust ................................................................................ 6
Lack of Trust between Separate SSL Environments ................................................................................ 7
Establishing Trust by Merging Certificate Authorities............................................................................. 8
Establishing Trust by Sharing a Single Certificate Authority ................................................................... 9
Current Issues with HP OpenView Certificate Management..................................................................... 10
QXCR1000289820....................................................................................................................... 10
Problem Summary: ..................................................................................................................... 10
Problem Cause........................................................................................................................... 10
Problem Repair: ......................................................................................................................... 10
Problem Scope:.......................................................................................................................... 12
Problem Prevention ..................................................................................................................... 12
QXCR1000353406....................................................................................................................... 12
Problem Summary: ..................................................................................................................... 12
Problem Cause........................................................................................................................... 12
Problem Repair: ......................................................................................................................... 13
Problem Scope:.......................................................................................................................... 14
Problem Prevention: .................................................................................................................... 14
Future Considerations for Certificate Installation in HP OpenView............................................................ 14
QXCR1000373248....................................................................................................................... 14
References and Further Reading .......................................................................................................... 15

Abstract
A number of HP OpenView software products have implemented Secure Sockets Layer (SSL) for
purposes of authentication and HTTPS communication. SSL requires that a trust relationship be
established between two communicating systems. A trust relationship between systems requires
appropriate SSL certificate installation and configuration.

Some HP OpenView products install their own certificate authority. Other products do not install a
certificate authority, but require a certificate to enable SSL functionality. During software installation,
HP OpenView products follow default behaviors regarding certificates. Sometimes it is necessary to
apply additional certificate management techniques when the default is not adequate. This is
especially true in environments with multiple HP OpenView products installed on a common set of
networked systems.

This paper provides information about SSL certificate issues in environments with multiple HP
OpenView products. Current software CRs are also discussed, including problem symptoms and
workarounds, and a longer term proposal to eliminate some current problems.
Introduction
The source of trust within an SSL environment is the certificate authority. HP OpenView provides its
own software components for certificate authority, certificate server, and certificate client
functionality.
These software components enable the following:
Creation of industry-standard X.509 certificates.
Installation of certificates.
Validation of certificates.
Management of new certificate requests.
Several HP OpenView products currently install and establish their own certificate authority for an
SSL environment. Other products do not establish a certificate authority, but can be configured to
use SSL. Table 1 below provides a summary of how SSL is used across HP OpenView products,
which products establish a certificate authority, and which products do not. Across HP OpenView
products, certificate authority is established by installation of the common HP OpenView certificate
server component. Refer to product documentation for complete details regarding installation and
configuration requirements for enabling SSL and HTTPS.

2
Table1. SSL Usage by HP OpenView Products
Product Version SSL Usage Establishes Certificate Authority?
OVOU >=8 1. HTTPS agent communication
with OVO server.
2. HTTPS agent communication
with the OVO embedded
performance component
(CODA).
3. Optional OVO server to
server HTTPS.
4. Optional Java GUI to OVO
server HTTPS.
Yes, the certificate server component is installed on the
OVOU server system.
OVOW 7.5 None. No.
OVOW >=8
(version 8
currently in
Beta test)
1. HTTPS agent communication
with OVO server.
2. HTTPS agent communication
with CODA.
3. Optional OVO server to
server HTTPS.
Yes, the certificate server component is installed on the
OVOW server system.
OVIS

>= 6 Optional HTTPS communication
between TIPs server and TIPs
runner.
Optionally, the certificate server component is installed on
the TIPs serve system. TIPs server runs on the OVIS
measurement server system. TIPs runner may run on the
OVIS measurement server or may be deployed for
execution on remote systems. TIPS runner system is
sometimes referred to as the OVIS probe system.
Service
Desk
>= 5 User authentication at logon,
but no HTTPS.
Yes, the certificate server component is installed on the
primary Service Desk server system, but not on secondary
Service Desk servers.
OVPA >= 4.5 When OVPA is installed in an
OVO 8.x HTTPS environment, it
can optionally use HTTPS
communication with OVPM and
Reporter.
No.
OVPM >= 5 1. Optional HTTPS
communication with CODA in
an OVO 8.x environment.
2. Optional HTTPS
communication with OVPA in
an OVO 8.x environment.
No.
Reporter >= 3.7 1. Optional HTTPS
communication with CODA in
an OVO 8.x environment.
2. Optional HTTPS
communication with OVPA in
an OVO 8.x environment.
No.

SSL in HP OpenView
Every node within an HP OpenView SSL environment contains a private key. SSL uses the private
key to initiate data transfer from one node to another. The integrity of the SSL environment requires
that each private key in the SSL environment is secure. Each private key must reside only on the
node to which it belongs and must be protected from inappropriate access. Every node in the SSL

3
environment also contains a public key. Unlike private keys, public keys are shared with SSL
communicating partners during initiation of communication.
Data encrypted by a nodes private key can be decrypted only by using the nodes public key. This
feature of SSL provides the digital signature functionality of SSL. When a node digitally signs a
message to be sent to a communicating partner, an algorithm is applied to the data that includes
encryption of a portion of the message. The private key owned by the sending node is used for the
encryption. The receiving node applies an algorithm that includes decryption using the public key of
the sending node. If the decrypted data makes sense, the receiving node has confirmation that the
message is valid. In the nomenclature of SSL, signed by a root certificate means that data has
been encrypted using the private key of a certificate authority, and thus can be decrypted by the
public key of the same authority.
Note that the private key and public key interactions described above occur only during the SSL
handshake phase initiation of communication between two SSL nodes. During the handshake
phase, a secret key is negotiated between the two SSL partners. The secret key is used for data
encryption for the remainder of the communication session between the SSL pair. Using the
negotiated secret key for the remainder of the session provides superior data transfer speed.
There are two kinds of certificates in the HP OpenView implementation of SSL: root certificates and
node certificates. A root certificate is controlled by the certificate authority of the SSL environment,
and must be made available to each node that trusts the certificate authority. The certificate server
system that provides certificate authority within the SSL environment is also responsible for creating
node certificates for all nodes in the SSL environment.
Associated with the root certificate is the private key of the certificate authority. The root certificate
does not contain the private key of the certificate authority, but is digitally signed with the private key
of the certificate authority. The root certificate does contain the public key of the certificate authority.
Every node certificate granted to nodes within the SSL environment by the certificate authority is
digitally signed with the private key of the root certificate.
Every node in the SSL environment has a node certificate. Associated with each node certificate is
the nodes OVCoreID. The OVCoreID is a unique identifier assigned to each node in the SSL
environment. The OVCoreID value remains fixed, even though other network attributes, such as the
IP address or hostname, may change. Each node can be authenticated using the root certificate to
verify a node certificates signature. Node certificates are used to enable HTTPS communication
between communicating pairs. For example, in order for node n1 to establish HTTPS
communication with node n2, n1 must present its node certificate to n2. Because all node
certificates have been signed with the root certificate, node n2 can verify that n1 is a valid
communicating partner by using the public key of the certificate authority.
A list of trusted certificate authorities, or trusted root certificates, resides on each SSL node. In a
simple SSL environment one certificate server providing authority for all nodes each nodes
trusted list contains one entry. However, in more complex SSL environments with multiple certificate
authorities, trusted lists can contain more than one entry. When the trusted list contains more than
one entry, a certificate presented from another node must be validated by one of the root certificates
in the list. As in the above example, for node n1 to establish HTTPS communication with node n2,
n1 must present its node certificate to n2. If node n2 has multiple entries in its trusted list, then one
of the entries in the list must be capable of validating the certificate presented by n1. If not, the
communication attempt from n1 is refused.
Currently, HP OpenView does not support integration with external certificate authorities. HP
OpenView implements its own software components to provide for creation and management of
certificates. These components are:
Certificate server
Includes certificate authority functionality and is responsible for the creation of certificates for all
nodes in the SSL environment. The certificate server software resides only on the certificate
server system. The certificate server system provides certificate authority within the SSL
environment. The terms certificate server and certificate authority are often used
synonymously.
Key store
Provides management of local storage on each node necessary for SSL implementation,
including protection of data that must be secured to maintain integrity of the SSL environment.

4
The key store component resides on every node in the SSL environment, including the certificate
authority system.
Certificate client
Resides on every node in the SSL environment (including the certificate authority system). The
client component verifies that every node contains a valid certificate and provides an interface to
the certificate server for tasks such as certificate installation.
The following list briefly summarizes HP OpenView command line interfaces that provide for
implementation of certificate management techniques discussed in this paper. For complete
information on these commands, refer to product documentation.
ovcoreid
Displays the OVCoreID value for a node.
ovcert
Provides an interface to the certificate client for a number of certificate-related functions. The list
option provides a formatted dump of key store data. The exporttrusted option, run on a
certificate authority system, creates a root certificate that can be used to update the trusted list of
other nodes using the importtrusted option.
ovc
Provides control and status reporting of HP OpenView services.
ovcreg
Controls registration of HP OpenView services.
ovcm
Provides an interface to the certificate server component. This command is available only on the
certificate server system. ovcm provides visibility of pending certificate requests from other nodes,
and provides the ability to take action on these requests.
ovconfchg
Allows configuration settings to be changed for HP OpenView services.
Certificate Deployment
The process of certificate deployment between the OVOU server and the HTTPS OVO agent
illustrates the use of some of these software components and their command line interfaces.
Certificates can be created and deployed automatically from the OVOU server to the OVO HTTPS
agent, or the process of creation and deployment can be done manually.
The most common deployment method is to let the OVOU server create and deploy certificates
automatically during installation of the HTTPS agent on a managed node. A summary of automated
certificate deployment follows.
The newly installed HTTPS agent starts, and through the certificate client determines that no valid
certificate exists on the managed node.
The certificate client creates a new public / private key pair and generates a certificate request to
the OVOU server based on the unique OVCoreID value of the managed node. Additional node
properties, such as DNS name and IP address are included in the certificate request.
The certificate server on the OVOU server receives the certificate request, and determines from
the information included whether or not the request should be automatically granted.
After the certificate server automatically grants the request, the new certificate is received on the
managed node and installed by the certificate client.

Certificates may also be deployed manually. Manual certificate deployment may be the method of
choice in highly secured environments, because it avoids sending any certificate-related information
over the network prior to establishing SSL communication. A summary of manual certificate
deployment follows:
On the OVOU server system, ovcm (or the opccsacm wrapper) is used with the issue option to
generate a new certificate to a file.

5
The file is placed on storage medium and moved to the HTTPS agent node, thus avoiding
network transfer of security-related information.
On the HTTPS agent node, the certificate is installed from the file using the ovcert command with
the importcert option.

A variation of manual deployment permits manual deployment of an installation key. A summary of
this approach follows:
On the OVOU server system, ovcm (or the opccsacm wrapper) is used with the geninstkey
option to generate an installation key to a file.
The file is placed on storage medium and moved to the HTTPS agent node, again avoiding
network transfer.
On the HTTPS agent node, a certificate request is generated using the ovcert command with the
certreq and instkey options. The certificate request is sent to the OVOU server.
The certificate server on the OVOU server decrypts the installation key; if the certificate request is
valid a signed certificate is sent to the managed node, and installed on the managed node by the
certificate client.

Refer the HTTPS Agent Concepts and Configuration Guide for further details on certificate
deployment. For access to this document, see the References for Further Reading section.

Merge and Share Approaches for Establishing Trust
The trust relationship between two HP OpenView nodes enables SSL authentication and HTTPS
communication. To establish trust, each node must present a certificate signed by a trusted
certificate authority.
The following diagrams depict simplified SSL environments for the purpose of illustrating three
situations:
SSL failure due to lack of a trust.
Establishing trust by merging two certificate authorities.
Establishing trust by sharing a single certificate authority.
In addition to trust relationships, the diagrams contain the following key elements of HP OpenViews
SSL implementation:
Certificate authority
In HP OpenViews implementation of SSL, certificate authority is provided by the certificate server
system. Each certificate authority holds a root certificate. A private key is associated with the root
certificate. This key is restricted to the certificate authority.
Node certificates
All nodes (including certificate servers) within the SSL environment possess a node certificate. A
private key is associated with each node certificate. Each private key is restricted to and secured
on its node.
Trust lists
All nodes (including certificate servers) possess a trust list. This is a list of trusted root certificates.
The trust list always contains at least one entry but may contain more. To enable SSL, a node
must present a certificate signed by a trusted root certificate. Trust lists are often referred to as
trusted certificates.

6

Lack of Trust between Separate SSL Environments
Figure 1 below shows a very simple case of two separate SSL environments, one consisting of
nodes A and A1, the second consisting of nodes B and B1. Nodes A and B provide the certificate
authority for their respective environments. Nodes A1 and B1 are nodes only.
When node A1 establishes HTTPS communication with node A:
1. Node A1 initiates the process by presenting its node certificate to node A.
2. Node A is able to validate A1s node certificate because it was signed by root certificate A.
3. Node A responds by presenting its node certificate to node A1.
4. Node A1 is able to validate As node certificate because it was signed by root certificate A.
5. With trust established between nodes A and A1, HTTPS communication is enabled.

However, if node A1 attempts HTTPS communication with node B or node B1, the attempt will fail.
Neither B nor B1 are able to trust A1s certificate.



7

Establishing Trust by Merging Certificate Authorities
In Figure 2 below, trust has been established by merging of certificate authorities A and B. This
consists of updating the trust list on all nodes to contain entries for root certificates of both
authorities A and B. This is usually implemented by first establishing a trust relationship between the
certificate authorities. Then, nodes can download the updated trust list using the ovcert command
with the updatetrusted option.
Following successful merge of the two certificate authorities, when node A1 establishes HTTPS
communication with node B1:
1. Node A1 initiates the process by presenting its node certificate to node B1.
2. Node B1 is able to validate A1s node certificate because it was signed by root certificate A, and
there is an entry for root certificate A in the trust list on node B1.
3. Node B1 responds by presenting its node certificate to node A1.
4. Node A1 is able to validate B1s node certificate because it was signed by root certificate B, and
there is an entry for root certificate B in the trust list on node A1.
5. With trust established between nodes A1 and B1, HTTPS communication is enabled.


OV Certificate Server
OVCoreID: A
OVCoreID: A1
OV Certificate Server
OVCoreID: B
OVCoreID: B1
Figure 2
Root Certificate A
Node Certificate A
Trust
No Trust
Trust List Entry: A
Root Certificate B
Node Certificate B
Trust List Entry: B
Node Certificate
A1
Trust List Entry: A
Node Certificate
B1
Trust List Entry: B
Signed by Authority A
Signed by Authority B
Trust List Entry: A
Trust List Entry: A
Trust List Entry: B
Trust List Entry: B


8

Establishing Trust by Sharing a Single Certificate Authority
In Figure 3 below, trust has been established by placing all nodes under one certificate authority, A.
Under this approach, B relinquishes the role of certificate authority. The only trusted root certificate
is that of certificate authority A. Node A1 retains its original node certificate, signed by A. The
original node certificates on B and B1 have been removed because they were signed by B, which
no longer exists as a certificate authority. New node certificates for nodes B and B1 have been
issued from certificate authority A.

OV Certificate Server
OVCoreID: A
OVCoreID: A1
OVCoreID: B
OVCoreID: B1
Figure 3
Root Certificate A
Node Certificate A
Trust
No Trust
Trust List Entry: A
Node Certificate B
Node Certificate
A1
Trust List Entry: A
Node Certificate
B1
Trust List Entry: A
Signed by Authority A
Signed by Authority B
Trust List Entry: A


9
Current Issues with HP OpenView Certificate Management
This section covers some current issues with HP OpenViews implementation of certificate
management and certificate installation. QXCR1000289820 and QXCR1000353406 describe
problems that can occur due to certificate conflict at install time. Symptoms and solutions are
discussed.

QXCR1000289820

Problem Summary:
The problem described by this CR occurs on an OVOU server system. An HTTPS OVIS probe
(TIPs runner) is also installed on the same system. The OVOU server is removed and re-installed
using ovoremove and ovoinstall. Removal and re-installation of OVOU appears to be successful,
but subsequent attempts to restart all process (ovstop; ovc kill; ovc start; ovstart) do not succeed.
The certificate server process, ovcs, aborts.

Problem Cause:
Normally during ovoremove, the certificate server and certificate client components are both
removed, and during the subsequent ovoinstall the certificate server and certificate client
components would both be installed. However, in the case described by this CR, the existence of
the OVIS probe on the system causes a dependency on the certificate client component. Thus, the
certificate client is never removed and re-installed. The residual node certificate is now unknown to
ovcs, causing ovcs to abort.

Problem Repair:
Per the HP OpenView Operations HTTPS Agent Concepts and Configuration Guide, periodic
backups of certificate information on the OVOU server are recommended. Assuming such backups
exist, following re-installation of the OVOU server environment, the
/ opt / OV/ bi n/ OpC/ opcsvcer t backup utility should be run with the r est or e option to recover the
original certificate state on the OVOU server system. Refer the HTTPS Agent Concepts and
Configuration Guide for details.

If certificate backups do not exist, repair may be performed as follows. Note that the following steps
will require a significant amount of effort if there are a large number of HTTPS managed nodes,
such as a typical production environment. In a production environment (if certificate backups exist),
it is highly recommended that you use the opcsvcer t back utility as described above. Use the
following steps in a production environment only if there are no certificate backups available. The
following steps may be used in a small test environment, or possibly a new production environment
with a small number of HTTPS managed nodes.

The ovcoreid command displays the OVCoreID value specific to this node. The ovcert list
command displays the certificate key store content for the agent and server. Sample output from
these commands on an OVOU server system follows. In the example below, there are multiple
trusted certificate authorities. However, the steps necessary to implement the repair will involve only
entries associated with this nodes ovcoreid value.

10
ovcoreid
816bc882-624c-750e-1324-e5ea979e818b
ovcert -list
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Keyst or e Cont ent |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Cer t i f i cat es: |
| 816bc882- 624c- 750e- 1324- e5ea979e818b ( *) |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Tr ust ed Cer t i f i cat es: |
| CA_260a0712- d533- 7507- 1c68- e5d0d06b2196 |
| CA_75f 77906- f 6c4- 750b- 0d1b- f 91259ba7bf b |
| CA_816bc882- 624c- 750e- 1324- e5ea979e818b |
| CA_d5610164- cd9b- 7508- 1d34- 9c38a4ecbd5d |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Keyst or e Cont ent ( OVRG: ser ver ) |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Cer t i f i cat es: |
| 816bc882- 624c- 750e- 1324- e5ea979e818b ( *) |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Tr ust ed Cer t i f i cat es: |
| CA_260a0712- d533- 7507- 1c68- e5d0d06b2196 |
| CA_75f 77906- f 6c4- 750b- 0d1b- f 91259ba7bf b |
| CA_816bc882- 624c- 750e- 1324- e5ea979e818b ( *) |
| CA_d5610164- cd9b- 7508- 1d34- 9c38a4ecbd5d |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
After this problem occurs, the situation can be corrected by applying the following steps.
1. Remove the old certificates associated with this node and ovcoreid using the following commands:
ovcer t r emove $( ovcor ei d)
ovcer t r emove $( ovcor ei d) ovr g ser ver
2. Remove the CA certificate from the agent section:
ovcer t r emove CA_$( ovcor ei d)
3. Export and import the trusted CA certificate. This CA certificate was created during the ovoinstall
installation.
ovcer t expor t t r ust ed f i l e / t mp/ t r ust edcer t i f ovr g ser ver
ovcer t i mpor t t r ust ed f i l e / t mp/ t r ust edcer t i f
4. Issue a new certificate, where mypwd is an arbitrary password you assign on the command line.
ovcmi ssue f i l e / t mp/ cer t i f name $( host name) pass mypwd cor ei d $( ovcor ei d)
5. Import the new certificate for the local agent, where mypwd is the password assigned in step 4.
ovcer t i mpor t cer t f i l e / t mp/ cer t i f pass mypwd
6. Import the new certificate for the server.

If in a cluster environment:
r mf / t mp/ cer t i f
ovcmi ssue f i l e / t mp/ cer t i f name <vi r t ual node> pass mypwd cor ei d
$( ovcor ei d ovr g ser ver )
ovcer t i mpor t cer t f i l e / t mp/ cer t i f pass mypwd ovr g ser ver

If in a non-clustered environment:
ovcer t i mpor t cer t f i l e / t mp/ cer t i f pass mypwd ovr g ser ver
7. Cleanup remove temporary files and templates in the OVO template cache that were signed with
the old certificate.
r mf / t mp/ t r ust edcer t i f / t mp/ cer t i f
f i nd / et c/ opt / OV/ shar e/ conf / OpC/ mgmt _sv/ t empl at es t ype f exec r mf {} \ ;

At this point, the certificates on the OVOU server system have been recovered to a consistent state,
and the ovcs process should run. However, in a production environment, there may be many
HTTPS agents that are no longer able to communicate with the OVOU server. Old node certificates
on these agents, signed by the original root certificate of the OVOU server, are useless and should
be deleted. New certificates must be created and deployed to these agents to restore HTTPS

11
communication between the OVOU server and HTTPS agents. Refer to the HP OpenView
Operations HTTPS Agent Concepts and Configuration Guide for details.

Problem Scope:
This problem can potentially occur upon de-installing and re-installing an SSL HP OpenView
product in the following situation:
HP OpenView products A and B co-exist on the same system.
Product A has a dependency on both the certificate server and certificate client components.
Product B has no dependency on the certificate server, but does have a dependency on the
certificate client.
If product A is de-installed and re-installed, product Bs dependency on the certificate client can
cause the problem.

Problem Prevention
Prior to de-installation, make sure that certificates on the certificate server system are backed up
using the / opt / OV/ bi n/ OpC/ opcsvcer t backup utility. ALWAYS MAINTAIN CURRENT
BACKUPS OF CERTIFICATES FOR A CERTIFICATE SERVER SYSTEM! Following re-
installation, use / opt / OV/ bi n/ OpC/ opcsvcer t backup with the r est or e option to recover the
original certificates.

QXCR1000353406

Problem Summary:
Installation of the OVO HTTPS agent can cause problems with other SSL HP OpenView products
already existing on the same node. The example cited in this CR describes the OVO HTTPS agent
and a Service Desk primary server co-existing on the same node. The following steps produce the
problem.
Add a node to the OVOU node bank and install the OVO HTTPS agent on the remote system.
The remote system sets its OVCoreID and requests and receives a node certificate from the
OVOU server.
Re-image the managed node. The agent, as well as the OVCoreID entry, is no longer on the
system. However the OVOU server maintains the original OVCoreID entry associated with the
node definition.
Install a Service Desk primary server on the remote system. This installs a certificate server and
certificate client, assigns a new OVCoreID to the remote system, and installs a node certificate
signed by the Service Desk certificate authority.
Re-install the OVO agent on the remote system.

Following re-installation of the OVO agent, the Service Desk SSL environment has become
corrupted because the OVO agent install incorrectly over-writes several configuration entries.
Problem Cause:
The OVO HTTPS agent installation over-writes the following configuration entries, ignoring the co-
existence of the Service Desk primary server installation on the same system. This results in
corruption of the Service Desk SSL environment.
The CERTIFICATE_SERVER setting is changed to point to the OVOU server instead of the local
Service Desk server system.
The OVCoreID value assigned during Service Desk installation is over-written by the OVCoreID
value from the OVOU node bank for the remote system. There are also now problems with
communication between the OVOU server and the managed node, because there is no node
certificate for the OVCoreID.

12

Problem Repair:
The starting point for problem repair should be to return the system to the state of a clean Service
Desk install without the OVO agent. This can be done by restoration from system backups, or by
de-installation of the OVO agent and Service Desk, followed by re-installation of Service Desk.
The following information closely follows information covered in the white paper HP OpenView
Internet Services 6.10 and HP OpenView Operations Agent 8.x: Co-existence and Certificate
Management. Note that the paper mentions CRs QXCR1000222525 and QXCR1000214514. Both
of these problems are fixed in current software versions and patch levels; therefore these CRs are
not mentioned in the steps below. For access to the white paper, see the References and Further
Reading section at the end of this document.
The following steps describe both a merge process and a shared process for establishing trust
within the SSL environment. Use the merge process if you want certificate authority provided by
both the OVO server and Service Desk primary server. Use the shared process if you want all
certificate authority provided from the OVO server.
To implement the merge process:
1. On the Service Desk primary server system, determine the OVCoreID value with the ovcor ei d
command.
2. On the OVOU server system, update the node definition for the Service Desk system with the
command:
/ opt / OV/ bi n/ OpC/ ut i l s/ opcnode chg_i d i d=xxx node_name=f dqn
where xxx is the OVCoreID value and fdqn is the fully qualified domain name of the Service Desk
system. (Note, the OVCoreID value is the value obtained from the ovcoreid command when run on
the Service Desk system.)
3. On the Service Desk system, run:
ovcer t expor t t r ust ed f i l e <f i l ename1> - ovr g ser ver
Transfer filename1 to the OVOU server system.
4. On the OVOU server system, run:
ovcer t expor t t r ust ed f i l e <f i l ename2> ovr g ser ver
Transfer filename2 to the Service Desk server system.
5. On the Service Desk system, run:
ovcer t i mpor t t r ust ed f i l e <f i l ename2> - ovr g ser ver
6. On the OVOU server system, run:
ovcer t i mpor t t r ust ed f i l e <f i l ename1> - ovr g ser ver
7. On the Service Desk system, run:
ovcer t updat et r ust ed
8. On the OVOU server system, run:
ovcer t updat et r ust ed
9. Install the OVO agent on the Service Desk system following standard installation procedures.

To implement the shared process:
1. On the OVOU server system, add a node entry for the Service Desk system if a node entry does
not already exist.
2. On the OVOU server system, update the node definition for the Service Desk system with the
command:
/ opt / OV/ bi n/ OpC/ ut i l s/ opcnode chg_i d i d=xxx node_name=f dqn
where xxx is the OVCoreID value and fdqn is the fully qualified domain name of the Service Desk
system. (Note, the OVCoreID value is the value obtained from the ovcoreid command when run on
the Service Desk system.)

13
3. On the Service Desk system, list all certificates by running ovcer t l i st

4. On the Service Desk system, for each certificate id listed, run the following commands:
ovcer t r emove <cer t _i d>
ovcer t r emove <cer t _i d> - ovr g ser ver
ovcer t r emove CA_<cer t _i d>
ovcer t r emove CA_<cer t _i d> - ovr g ser ver
5. On the Service Desk system, run ovcer t l i st again to verify that all certificate ids have been
removed.
6. On the Service Desk system, unregister the certificate server component (ovcs):
ovcr eg del ovcs
7. Install the OVO agent on the Service Desk system following standard installation procedures.
8. Because certificates were removed from the Service Desk system, the OVO agent installation will
automatically request a certificate from the OVOU server. If this was a manual agent installation,
remember to grant the certificate request from the OVOU server either using the GUI or the
following command line commands:
ovcml i st pendi ng l
ovcmgr ant <r equest _i d>
Or, use manual certificate deployment to the managed node / Service Desk system.
9. Service Desk remote clients that use SSL authentication to log on to the Service Desk primary server
require a node certificate signed by the shared certificate authority. OVO HTTPS agents should be
installed on these clients.

Problem Scope:
Co-existence of the OVO HTTPS agent and another HP OpenView product that establishes its own
certificate authority can result in SSL problems.

Problem Prevention:
Plan ahead for implementation of either a merged or shared certificate authority in either of the
following situations:
The OVO HTTPS agent is to be installed on a system that already contains an HP OpenView
product with its own certificate authority.
An HP OpenView product that establishes its own certificate authority is to be installed on a
system that already contains the OVO HTTPS agent.

Future Considerations for Certificate Installation in HP
OpenView
QXCR1000373248
This CR is a proposal for changing the way the certificate server component installs on a system
that already has a node certificate, but no certificate server is currently installed on the system.
Examples of this situation are:
The OVO HTTPS agent is already installed on the system, and the OVOU server will be installed
on the same system.
The OVO HTTPS agent is already installed on the system, and the Service Desk primary server
will be installed on the same system.
The OVO HTTPS agent is already installed on the system, and the OVIS measurement server,
including the TIPs server, will be installed on the same system.


14
It is proposed that installation of the certificate server component be modified to support either a
shared or merged certificate environment by providing the following options, selectable at
installation time.
Options supporting a shared certificate authority a single certificate authority for the SSL
environment:
If a CERTIFICATE_SERVER setting is configured then there is already another system providing
certificate authority for this system, and the certificate server installation process does not need to
set up its own authority. Possibly the certificate server installation is not required and can be
bypassed. This option provides for installation into a pre-existing shared certificate authority
environment, with authority provided from another system.
Install the certificate server, but instead of installing a new certificate, simply copy the existing
certificate to ovrg server. This option provides for the possibility that this system should become
the shared certificate authority for the SSL environment, using the existing certificate.
Options supporting a merged certificate authority multiple certificate authorities for the SSL
environment.:
Allow installation of the certificate server to replace the existing certificate. This is proposed for
implementation of QXCR1000289820. This would prevent the problem described above
including the inconsistent state that causes ovcs to abort.
Following installation, the system would not be accessible by other SSL systems because it has just
received a new certificate. Warning messages should be provided explaining that it is now
necessary to exchange root certificates with the original certificate authority, thereby establishing
trust through a merging of certificate authorities.


References and Further Reading
The following references were used in developing the content of this paper and are recommended for
further reading:

The following documents are available at: http://ovweb.external.hp.com/lpe/doc_serv/
HP OpenView Operations HTTPS Agent Concepts and Configuration Guide
White Paper: HP OpenView Internet Services 6.10 and HP OpenView Operations Agent 8.x: Co-
existence and Certificate Management
HP OpenView Performance Manager Installation, Upgrade, and Migration Guide C.06.00
HP OpenView Performance Agent Installation and Configuration Guide C.04.50

The following document is available at: http://devresource.hp.com/drc/resources/ssl_ovou/index.jsp
Certificates and SSL usage in HP OpenView Operations for UNIX

Other references:
Public Key Infrastructure and Design, by Choudhury, Bhatnagar, Haque, NIIT. J ohn Wiley & Sons c.
2002.

15