Explaining certificates

RapID Keys and Certificates

If keys and certificates are a bit of a mystery to you, this section will help to explain them. It also describes how RapID uses certificates in a novel way that neatly sidesteps the challenges traditionally associated with large-scale PKI infrastructures.

Cryptographic keys and certificates

RapID is built using public/private key pairs, or 'asymmetric cryptography'. This means that whenever you want to encrypt a bit of data, you use either one of those keys, but to decrypt the data you must use the other. You will have been used to using this technology every time you visit a secure website, as the SSL Certificate (the padlock) is used to prove the authenticity of the website you are visiting.

In the case of a secure website, the site owner generates a keypair, (keeping the private key locked away safely in a secure 'keystore') and then asks a trusted third party (a 'Certification Authority' or CA) to generate a 'certificate' (a blob of data in an x509 standard format) that cryptographically associates the public key with the domain of their website. Once that CA is satisfied in the right of the owner to the domain, a certificate is issued to prove that binding.

When you connect to a secure site from your browser, the https connection protocol performs a challenge-response to prove that the site is in possession of the private key, and that the certificate has been issued by someone they trust (a 'trusted issuer' or 'trusted root'). Operating systems usually ship with a predefined list of 'trusted roots', so the entire process is transparent to you.

This ecosystem of keys and CAs is referred to as a Public Key Infrastructure, or PKI.

Client certificates

The SSL 'padlock' can work both ways. Normally, you just use it in order for you to trust the website or service to which you are connecting. However, the protocol also supports authentication in the other direction, so that you can prove your identity to the service. It is this existing, proven feature that RapID utilizes to deliver high security authentication.

Where is the trust?

One of the problems with traditional PKI is that everyone needs to trust an ever-growing list of 3rd party CAs. This means that these CAs all need to publish and adhere to policies, but the definition and execution of those policies is actually outside of your control.

RapID addresses this by recognizing that the vast majority of client to service interactions only need trust between two people - the customer and the service provider. So, when you sign up for a RapID service account, you are given your own, dedicated certificate issuer.

Further to this, you are also in complete control over authorizing the issuance of those certificates, so you can apply precisely the level of user verification that you require to meet your own policies for registration.

What keys and certificates do I need for my server?

There are two certificates that you need to integrate RapID into your service or website: the trusted issuer certificate, and the service authentication certificate. You can download both of these from your Customer Dashboard.

The trusted issuer certificate is used to sign the certificates issued by RapID to your end-users' devices. Your RapID CA owns the private key for this certificate.

The service authentication certificate is used to authorize certificate requests from your registration service to RapID. As this is concerned with proving your server's identity to the RapID service, this requires a certificate and its private key.

It is very important to protect the service authentication certificate, as this is delivered as a password-protected 'pfx' file that includes the private key. When you download this from the dashboard, you are required to set a password for the file. Please choose a strong password and, once downloaded and deployed to your service keystore, we advise that the pfx file is not left on the server.