PHINMS Frequently Asked Questions

A Collaboration Protocol Agreement (CPA) is a business-level agreement between the PHINMS Sender and Receiver. The CPA stores information necessary for partners to communicate with one another. It includes the transport protocol and security constraints both partners have agreed to use when messaging one another. A CPA is required for each location which has installed PHINMS. The CPA file name consists of the Receiver’s and Sender’s PartyID with an .xml extension. The file is stored in both the PHINMS Receiver’s CPA directory and the Sender’s CPA directory.

The Centers for Disease Control and Prevention (CDC) PartyID is a unique object identifier (OID) for each instance of the PHIN MS Sender and Receiver used when sending messages to the CDC. The CDC PHIN MS Help Desk issues the PartyID at no cost. The value of the PartyID must be the same as the Message Receiver’s PartyID in the Collaboration Protocol Agreement. A PartyID would resemble “1.23.456.7.891234.5.6.7.8.9.0.1”.

A PartyID is an object identifier (OID) used by PHIN MS. It is a unique OID assigned to an organization by the CDC PHIN MS Help Desk.

Note: A CDC PartyID is an OID but an OID is not necessarily a PartyID.

A Digital Certificate is a digital identity of a person, computer, or organization. It is a binary file used for Authentication, Encryption, Signature, etc. Digital Certificates are typically issued by Organizations or Root Certificate Authorities.

There is no concept of higher-priced certificates rather encryption strength. PHIN MS recommends 1024 bit encryption strength both on Client certificates (Sender) and SSL certificates (IIS Proxy Server).

SSL Certificates should be 2048 bit length.

PHIN MS Sender Side:

Client Certificate: Most CDC related programs will issue a CDC SDN issued Digital Certificate to an individual. This is used to authenticate the Sender in an Organization to the Receiver (example – sender.pfx). The client certificate is a combination of both a private key and a public key of the Sender’s certificate.

Encryption Certificate: This is the public key of the Receiver (example – state.cer). The encryption certificate can be downloaded by doing a LDAP lookup or obtaining the information in an email from the Receiver. The data sent to the Receiver is encrypted using the encryption certificate (example – receiver.cer).

Certificate Authority Certificates: A Certificate Authority (CA) Certificate is a Key Store which comes bundled with the PHIN MS product. When a Sender is trying to make a HTTPS SSL (Secure Socket Layer) connection to the Receiver’s IIS server, it needs to validate the certificate chain of the SSL certificate installed on the IIS server. PHIN MS uses this key store to look up for trust chain. When the Root and Intermediate Certificate of the SSL certificate are not present in the CA cert file then the HTTPS connection fails. The Receiver will need to provide the Root and Intermediate of the SSL certificate to the Sender in an email. The Sender will then need to import the information.

PHINMS Receiver Side:Secure Socket Layer Certificate: This is the certificate installed on IIS proxy server to provide HTTPS SSL connection to the Sender. The SSL connection creates a secure tunnel between the Sender and the IIS server. This certificate has to be purchased from a Vendor. An existing certificate or generate certificate using Open SSL can also be used. When using the non-popular of open source, ensure the root and the intermediate (if exists) is provided to the Sender to add to the trust chain (example – state.us.gov).

Client Certificate (Public Key): A client certificate on the IIS proxy server refers to the public key of the Sender’s client certificate. This is allows the Receiver to trust the Sender by providing Authentication and Authorization. The Sender will need to provide the public key of the client certificate to the Receiver in an email (example – sender.cer).

Decryption Certificate: Most CDC related programs will issue a CDC SDN issued Digital Certificate to an individual. This is used in decrypt the data sent by a Sender (example – receiver.pfx). The Decruptioin Certificate is a combination of both the private key and the public key of the Sender’s certificate.

There are many vendors which issue Digital Certificates like Client Certificate and SSL Server Certificates. Some included are Verisign, Thawte, Entrust, Equifax, Geotrust to name a few. PHINMS does not recommend one over the other. An existing and self-signed certificate may be used.

An email notification will be sent as a reminder to re-apply for a new Digital Certificate when the certificate is either PHINMS Staging or Production. The reminders are sent three times (1 month, 15 days, and 5 days) before the date of expiration. Contact PHINTech@cdc.gov to apply for a new Digital Certificate.

There may be several reasons for a certificate problem. The most convenient way to diagnosis the problem is to review the log files. Some of the most common issues are as follows:

• SSL and Client Certificate expiration,
• encrypting with a wrong public key on the Sender’s side,
• the Sender not being able to trust the Receiver’s SSL certificate chain, and/or
• the wrong private key password using the Sender’s or Receiver’s console.

A Digital Certificate is required for security purposes when using PHINMS to send messages to the CDC. The Digital Certification verifies the identity of the Sender and provides the Receiver with the means to encrypt a response. The CDC Secure Data Network (SDN) issues user identity Digital Certificates. A Digital Certificate is also required when partners are sending messages directly to other partners and the messages are not sent to the CDC. A Digital Certificate can be purchased from a Certificate Authority (CA). Instructions for requesting a Digital Certificate to send messages to the CDC are located in the PHINMS 3.2 Implementation Guide [4 MB, 58 Pages, 508].

The timeout connection is used to set the number of milliseconds the Message Sender waits before timing out the attempt to connect to the SML.

PHINMS 3.2 Implementation Guide [4 MB, 58 Pages, 508]

The message is encrypted using the private key infrastructure. Refer to FAQ #4 for additional information.

PHINMS 3.2 Implementation Guide [4 MB, 58 Pages, 508]

Currently the latest version is PHINMS 3.2 and recommended for installation. Upgrade options are documented in the PHINMS Implementation Guide.

PHINMS 3.2 Implementation Guide [4 MB, 58 Pages, 508]

PHINMS is platform-independent. Any operating system can be used; however, PHINMS has only been tested with a select few. The PHINMS Team does not support the platforms which have not been tested. The following platforms are tested and guaranteed to work with PHINMS and they are supported by the PHINMS team:

• Windows Server 2016.
• Windows 10.

There is no cost to use the PHINMS software. The software has been designed by the CDC for the Public Health communities.

When the default database is started any data changes should be reflected when the PHIN MS console is refreshed. The request to restart indicates the Tomcat server requires to be stopped then restarted whenever a configuration changes or installing a new component such as Web Services Adapters.