If you encounter Signature is invalid error (error.signature.invalid), please consider the following:
- Documentation regarding Signature creation:
- Help Centre article regarding eIDAS signing:
- An example in our documentation:
Use our Postman collection with your data and check if a request passes (if the Signature works it shows everything is in order from Nordea side):
- Compare Signature received from Postman Pre-Request script to your own script. Postman Pre-Request script generates working Signatures
- Send the request without "\" (backslashes) in the Signature header
- A valid request sequence is: code, grant_type, redirect_uri (as in Postman collection)
- Digest and Signature headers values are not hardcoded. These values are generated according to:
Postman collection includes the logic for generating these values as a pre-request script:
(Sandbox) Signature is generated based on a private key (variable: eidasPrivateKey) and Sandbox testing with any other certificate than the sample QSealC which is downloadable from:
will always lead to an unsuccessful request. You can set Signature header to SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX in case you want to test without a signature. Refer to:
- (Sandbox) change x-nordea-originating-host value from Production host:
to Sandbox host:
in the signature, so it matches the value sent in X-Nordea-Originating-Host header
- Ensure that headers values in the request are exactly the same as the values used to calculate the Signature (for example: if the Signature string is created based on application/json content-type, the request must also include application/json)
- Headers shouldn't contain content-type and digest. For GET requests it should be:
headers="(request-target) x-nordea-originating-host x-nordea-originating-date"
- Do not miss content-type: application/json in normalized string:
Preserve a proper order of headers:
Ensure they are sent in the right order and that /n is not present at the end
- Use relevant private key for signing
- Make sure you don't miss space characters between ":" and the value of headers:
(request-target): POST /corporate/v2/authorize
x-nordea-originating-date: Mon, 14 Aug 2023 06:25:45 GMT
- Don't include whitespace characters in the payload and while generating the Digest:
- Both endpoint URL and Digest value are taken into consideration when a Signature is calculated
- When calling /corporate/v2/authorize endpoint you should have this endpoint in the normalized string:
(request-target): POST /corporate/v2/authorize
x-nordea-originating-date: Mon, 07 Aug 2023 09:21:22 GMT
- Request-target is a part taken to build normalised string, hence make sure it doesn't contain double-slashes (//).
- (Sandbox) When we try to upload a test certificate to Microsoft Azure Key Vault, we get an error message: “More than one certificate with private key found in the specified X.509 certificate content. Please specify X.509 certificate content with only one certificate containing private key.” We downloaded the test certificate and changed the file extension to .pfx (Azure Key Vault does not support .p12 format). The Sandbox certificate is expired and Microsoft Azure doesn't allow expired certificates. When will you have a valid certificate for Sandbox available?
We recommend skipping the signature signing with SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX in the Signature header or use alternative way of storing the certificate if your secure secret store doesn't allow you to store our test certificate.
(Sandbox) We are testing GET requests on the endpoint corporate/premium/v4/accounts and having trouble with the signature-argument in the header “Signature”. We are using a test eIDAS Certificate. What format the signature code must be provided in? Do we have to encode with base64? Do you have an example request?
Example code: eIDAS signature creation (Access Authorization API)
signature="Base64(RSA-SHA256(signing string))". We provide an example on how the signature can be created with Java in the same section. In case of POST, PUT or PATCH method you have to also add "Content-Type" and "Digest" header with value
Digest. Example on how to create Digest can be found in our documentation:
- Are the following steps correct?
- Define the signing string as desired:
“(request-target): get corporate/premium/v3/accounts\n
x-nordea-originating-date: Fri, 31 Mar 2023 08:31:34 GMT\n”
- Encrypt the signing string using RSA-SHA256 and the private key from the test certificate
- base64-encode the encrypted signing string
- Assign the encoded signing sting to the signature-header and define the remaining headers
- Make the get request
If you still need our assistance, please submit a request:
- a full body of an Open Banking API request/response with an exact endpoint, headers, message_identification and creation_date_time included - please see: API Responses
- normalized string before encryption
- your algorithm (don't disclose your certificate) in order to show how you create a Signature