Security

This section describes how you should configure communication between the Financial Institution (or it’s Service Provider) and Gjeldsregisteret AS. This quick start covers the most relevant steps, the Security Document v1.3.0 contains the full details.

Scope

We only describe security scenarios relevant to Gjeldsregisteret AS’s use of API’s described in the Standards Specification v1.2.0. For the other security scenarios consult the Security Document v1.3.0.

Scenarios

  1. Common Security
  2. FI/SP push changes to DIC
  3. DIC pull all data from FI/SP

FAQ

Some common questions about client certificates are answered below.

Q: What kind of client certificates are used?

The solution is based on PKI with Enterprise Certificates (Virksomhetssertifikat) issued by a trusted third party (Buypass or Commfides).

Q: Can you trust the client certificate?

When an entreprise order its “virksomhetssertifikat” they will be verified and audited by the Certificate Authority (CA) before any certificate is issued. Only approved enterprises will receive an Enterprise Certificate that contains claims like a Norwegian organisation-number and organisation-name.

Q: What parts of the client certificate must be validated?

You should verify the authenticy of the client certificate by validating the full certificate-chain of the issuer (CA). Verify the certificate key usage, that the certificate has not expired and not been revoked by the CA. If the certificate validates ok and you trust the issuer you can inspect its key claims (like the Norwegian org.number) and decide if you want to accept the request from the certificate owner at the other end of the connection.

Q: How to present the client certificate to the server?

Just like the server-certificate (HTTPS) the client-certificate will be exchanged during initialization of the secured connection (mutual-TLS) and before any real data is sent. If your server does not trust the client-certificate (or the client does not trust your server-certificate) the mutual-TLS connection will fail.

Q : How do you verify a client certificate?

This depends on your setup! A common way is to have your protected resources served by servers behind a layer of load balancers like BigIP, NetScaler, HAProxy, Nginx etc. Such software can be configured to validate client certificates and only let requests with client certificates issued by trusted CA’s through. You could also handle the HTTPS connection on the servers yourself and manually inspect and verify any client certificates.

Q: Do we need to share the public key of the client certificate?

There is no need for parties to exchange public keys of either server-certificate (HTTPS) or client-certificate (Virksomhetssertifikat) up front. The PKI based solution is built on trust. You trust the certificate issuer (CA) and by validating the authenticy of the certificate and making sure that the certificate is valid​​ (ie not expired or revoked), you will also implicitly trust the claims in the certificate.

Any large scale deployment with hundreds of parties involved would quickly become a huge administrative burden if everyone should exchange public keys with everybody else. It would also be mean that when renewing the client certificate a new public key must be distributed to all parties for immediate deployment.

  1. More details in the Security Document v1.3.0.
  2. This type of certificate (virksomhetssertifikat) conforms to Requirements specification for PKI in the public sector (Kravspesifikasjon for PKI i offentlig sektor)
  3. DIFI maintains a list of certificate authorities (CAs) that issue certificates that are in compliance with these demands. This is currently only Buypass and Commfides.