Connecting To PKB Endpoints

Connecting To PKB Endpoints

To interact with our APIs, ensure you have connectivity to the appropriate endpoint(s).
To aid this process, we will ask all our customers and partners to complete a connectivity configuration document.

Whats Included

PKB Endpoint Services

Guidance for Testing your Connection to PKB

https://pkbdev.atlassian.net/wiki/spaces/api/pages/3364585480/Network+connectivity+guidance

Connectivity Roadmap

https://pkbdev.atlassian.net/wiki/spaces/api/pages/4353654799/Roadmap+-+Network+Connectivity .

Example Endpoint Service Pages

Click the plus sign below to display the example:

Terminology Explanations

The example above may contain aspects of network connectivity that are not familiar to you, the section below is intended to help with that.

Supported TLS Version(s)

Context: Client software (your integration engine) and our servers needs to be able to agree on a TLS version as part of an initial handshake process to allow for the exchange of data in a secure way.

When client software is out of date, it might not be able to offer a secure enough TLS version, which results in the immediate termination of the connection request.

Supported Cipher Suites

Context: After the client (you) and server (PKB) have successfully agreed on a TLS version, they still need to agree on a set of algorithms, so called cipher suite, that they will use for the rest of the negotiation.

When client software is out of date, the list of cipher suites it recognises might not align with cipher suites accepted by our servers, which results in the immediate termination of the connection request.

Server Certificate

Context: Once the client (you) and PKB server have agreed on a cipher suite, the client software still must assert the identity of the server. For this the client software uses TLS certificates. TLS Certificates are digital objects that are issued by special organisations called Certificate Authorities or CAs for short. The whole process relies on a chain of trust of certificates, where the client software must trust a CA root certificate. CA certificates have typically long lifetimes, but CAs must rotate their certificates from time-to-time.

The list of trusted CAs certificates are distributed to clients with software updates.

Issuer Certificate

Context: CA root certificate is unknown (hence not trusted) by client

When client software is out of date, it might not trust the Issuer’s root certificate. In this case the server certificate cannot be verified, because a chain of trust cannot be established by the client.
In such a case, the correct procedure for the Client is to terminate the connection.

Signature

There are two key parts in a Certificate:

  1. Claims about the server

  2. A digital signature, which prevents undetected tampering of the claims.

It is important what algorithm the Issuer uses to sign a Certificate as client software needs to use the same algorithm to verify that there was no tampering with the claims.

When client software is out of date, it might not contain the implementation of the algoritm that the server used.
This results in the client being unable to verify the server identity.
In such a case, the correct procedure for the Client is to terminate the connection.

Subject CN

Context: Part of asserting the servers identity is to verify that the Subject CN in the Certificate presented by the server is matching the URL of the server itself (aka, the server is presenting its own certificate).

This indicates a server misconfiguration.

Connectivity FAQs

Patients Know Best Wiki Hub | Deploy | Developer | Trust Centre | Manual | Research | Education | Release Notes

© Patients Know Best, Ltd. Registered in England and Wales Number: 6517382. VAT Number: GB 944 9739 67.

This API specification and design is licensed under a Creative Commons Attribution 4.0 International License.