PKB API Network Connectivity
- Andrew Turner (Unlicensed)
- Suzanne Joyce
- Andy Clowe
In order to interact with our APIs, you will need to ensure you have connectivity to the appropriate endpoint(s).
On this page, you’ll find:
Links to information pages about each of our different endpoint services (e.g. HL7 or FHIR).
See below for an example of the details you can expect to find
Link to guidance on how test your connectivity
Link to the PKB Connectivity Roadmap
Link to Connectivity FAQs
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 of what to expect in the Endpoint Service pages
Click the arrow 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:
Claims about the server
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.
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).
Connectivity FAQs
General FAQs