Aquiring a client certificate
A client certificate is required for communication with the E-Archive REST interface.
For security reasons, only certificates issues by Nets for this specific purpose can be used. To get a test environment and receive a client certificate that has access to it, contact Nets (see Contact us).
Note that when you receive the client certificate, it is very important that you protect the private key. The private key is what identifies your system as legitimate. Accidentally exposing the private key to third parties is equivalent to exposing a password. If that happens, you must contact Nets immediately.
Eurida Connect
The current certificate used is of the type Eurida Connect. When you contact Nets and gain access to the REST service, you will receive a .p12 file containing the client certificate, and the root certificate. The root certificate must be trusted. This can either be done by using the .p12 file both as a trust store and a keystore, or you can separately add the Eurida Connect CA certificate to your trust store. The client certificate also contains a link to an URL where the root certificate can be downloaded.
After you have configured the keystores/certificates, you should test the connection. You can do this by trying to perform a search as described in Step 2.
Error responses
| No connection/connection refused | This is not related to the certificate |
| Handshake failure | The typical cause for this is that the CA certificate chain for the server certificate is missing from the trust store, or that no client certificate is sent in the request. |
| HTTP 302, redirecting to a new URL that will return 403. | The certificate does not have access to the URL specified in the request. |
| Any other http error code | If the X-Archive-Response-Code is set to the same value, the response is from the backend E-Archive solution, which means that TLS access is successful. If this header is not present, then the base URL is likely wrong. |
