Certificate handling

All Access Worldpay services use HTTPS and provide an X509v3 certificate when you connect. This certificate allows the connecting client (typically yours) to authenticate that the service you are talking to is owned by Worldpay. This document describes appropriate checks you should make to ensure the services are authentic.

Appropriate Checks

The following lists the appropriate checks you MUST make on the certificate provided by the service.

Note: Most TLS libraries in modern languages complete these checks automatically, unless configured not to. Sometimes these checks are disabled for development and testing purposes, however they should never be disabled on your production system.

Certificate subject matches hostname

The service must return a certificate with the domain name, the client is trying to connect to, in the subject alternative name (subjectAltName) field. The value type for this field must be DNS as this indicates a fully-qualified domain.

For example:

To connect to Access Worldpay: The field subject alternative name or subjectAltName with value type DNS, must be https://access.worldpay.com

Note: Certificates may have multiple subject alternative names. Only one of them must match the domain name the client is trying to connect to.

Certificate Expiry Dates

A certificate contains a notBefore and notAfter field that defines the dates outside of which the certificate is invalid. Therefore, only dates inside this window are valid.

Important: The time of your systems must be synchronized with Internet time servers. This ensures the valid time window of the certificate is matching your expectation of certificate expiry.

Certificate Chain Validity

The client should verify each signature on the certificate chain and ensure that the certificate adheres to the policies defined by the certificate authority. All good implementations of TLS are doing this automatically. Please refer to the documentation of your library/framework for more information.

Every client has a list of trusted roots/trust anchors that are usually built into the operating system, browser or application framework. These are certificates from well-known companies such as DigiCert, Comodo, Microsoft, etc.
Access Worldpay certificates are all signed DigiCert certificates. The root certificate is therefore most likely already in the client software's runtime.

Inappropriate Checks

The following are checks that the client should NOT complete because the below values are NOT constant.

Note: The following list is not exhaustive.

Certificate DN

You must not cache or store the certificate's "Distinguished Name (DN)" and check this against a provided certificate.

The DN for our certificate currently looks like this:

C=GB, L=London, O=WorldPay (UK) Ltd, OU=GW2.0, CN=access.worldpay.com

Important: We MAY change this DN, when we refresh our certificates.

Certificate Fingerprint/Thumbprint

You must not cache or store the certificate's fingerprint and check this against a provided certificate.

The fingerprint is unique to a certificate because it's calculated by taking all properties of the certificate and generating a single number based on those values.

Important: The certificate fingerprint WILL change, when we renew our certificate annually.

Public Key

You must not cache or store the public key and check this against a provided certificate.

While not mandatory, we change our public key as part of the renewal as it's a security best practice.

Important: We WILL change the public key, when we renew our certificates. Renewal will happen at least 7 days before expiry.