User: System administrator
Within your Futurama application at several parts it can be necessary to use certificates. This page gives some basic information about (the use of) certificates.
Security certificates are used to secure information that is sent to a server. When developing with Futurama it can be desired to use these certificates. For example to create a https page for your Futurama webapplication. Although the use of certificates is not Futurama specific this tutorial page is created to give some basic information about security certificates, as used on the web (also known as PKI (public key infrastructure) and X.509 (a series of standards)). Information from this page is used to give the basic certificate information.
Encryption is used, when you want to protect information from being stolen. However, encryption by itself is insufficient. Suppose that you have some private information that you want to send to your bank. If you encrypt that information, but you mistakenly send the information to thieves and encrypt it in a way that the thieves can read it, then you have not protected the information at all. The certificate system is supposed to provide the basis for you to be able to trust that you are sending the data to the intended people (your bank, not the thieves), and that you have encrypted it in a way that only the intended recipients can read it.
Public key infrastructure
A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.
Without PKI, sensitive information can still be encrypted (ensuring confidentiality) and exchanged, but there would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.
A typical PKI consists of hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates. Digital certificates are at the heart of PKI as they affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.
A typical PKI includes the following key elements:
- A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities;
- A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root;
- A certificate database, which stores certificate requests and issues and revokes certificates;
- A certificate store, which resides on a local computer as a place to store issued certificates and private keys.
Public key encryption
The system is built on the use of public key encryption. With public key encryption, there are two keys. One of those keys is made public and the other is kept private and known only to the owner of the key. In one typical use, a message is encrypted using the public key. Then only the owner of the private key can decrypt it. In an alternative use, a special message is encrypted with the private key, and can be decrypted with the public key. In this alternative use, the message is typically a signature, and the arrangement is intended to allow only the owner of the private key to create the signature while anybody can verify that the signature is correct (because the public key is made public so available to anybody). The mathematical relationship between the public key and the private key is sufficiently complex that it would be very difficult to compute the private key from the known public key.
What’s in a certificate?
A certificate is just a document (in this case, a digital document for use in computer networks). It contains the name of the owner (or alleged owner) of the certificate. That owner name could be a web site name, an email address, etc. There can be other identifying information. There is a begin date and an expiration date, and the certificate is only useful between those dates. And there is a list of constraints on the permissible uses of the certificate.
In addition to that information, there is a public key. The public key is digital information, mainly of use by software. The owner of the certificate should have the corresponding private key.
The certificate itself is signed, and the signature is part of the certificate. It is a digital signature, generated with a private key. The purpose of the signature is to certify the validity of the information in the certificate. That’s where the name 'certificate' comes from. The certificate should not be trusted unless the signature has been verified. The verification step requires using the public key of the signer. The signature is generated in such a way that if any of the important information in the certificate has been tampered with, then the signature will not verify.
The CA or Certification Authority
A certificate is signed by a CA. When you trust a certificate, you are implicitly trusting the CA. What you can trust, and how trustworthy a CA is, has to be decided outside of the certificate system. In many cases, CAs have web sites where they state their certification policies.
Who appoints the CA?
The CA appoints himself or herself or itself. Anybody can appoint himself a CA. This might sound scary, but it isn’t. Suppose X decided to appoint himself as a CA, and signed some server certificates. The chances are that you will never come across those certificates from X. If, by some chance, you were to come across such a certificate (browsing a web site using a certificate that X has signed), your browser would give you a certificate warning saying that it did not know how to verify the CA signature that X had created to sign that certificate. If X is running a private web site, then X might distribute his CA certificate to members of that private group. They could then add that to their browser certificate store so that they could use the private site of X without seeing certificate warnings. Anybody else would see a warning. So, the fact that CAs appoint themselves is not an actual problem.
The certificate system is one of hierarchical trust. There are several parallel hierarchies. At the top of the hierarchies, are the root CAs. The root CAs are the ones that are self-appointed. The root CA has a certificate that is used for certifying other certificates. The root CA certificate is itself signed (thus certified). It is self-signed. Roughly speaking, that the root CA certificate is self-signed indicates that the CA has certified itself. That may sound silly, but is actually important. Since a certificate will not verify if there has been tampering, the signature on the root CA certificate is a protection against tampering. In a simple case, the root CA can directly sign a server certificate. Verification of the server certificate then requires access to the CA certificate. In a more complex case, the root CA can sign a secondary CA certificate, and that secondary CA can then sign a server certificate. There can be several levels. The constraints that are part of a certificate are what indicate whether the certificate is allowed to be used as a secondary CA certificate.
The certificate chain
In order to verify a certificate, you (or your software) needs access to the chain of certificates. That would include the root CA certificate, the certificate of a secondary CA signed by the root, and so on, down to the server certificate that you are trying to verify. If you access a well run web server, that server will provide the server certificate and the certificate chain (except for the root CA certificate). It will normally also provide the root CA certificate, but your browser won’t use that in normal use.
How does trust work
Typically your software vendor (operating system vendor or browser vendor, for example) will provide a bundle of root CA certificates with the software that the vendor supplies. The root CA bundle might also contain some secondary CA certificates, depending on the practices of the software vendor.
Your software, by default, is set to trust any CA certificate in the bundle provided by the software vendor. Usually, the software allows you to tweak this. There is typically a provision where you can mark some of the provided certificates as untrusted, and where you can add some additional CA certificates which you decide for yourself that you want to trust.
When you visit a site that uses certificates, your client software (typically a browser or mail client) asks the server for its server certificate. The server should provide a chain of certificates, as needed. Your software starts by trusting the root store of certificates provide by your software vendor, though it should be verifying those signatures to protect against tampering. Then your client software should verify the signatures all the way down the chain to the server certificate. It should also check the dates on certificates (that they have not expired). And it should check the name on the server certificate to ensure that it matches the site that you are visiting. If some of those checks fail, the sofware should alert you.
Once your client software has verified the certificates, it use the public key on the server certificate to establish an encrypted connection to the server. Since only the owner of that certificate has the associated private key, this ensures that only the certificate owner can read this encrypted connection.
What can you trust
If the verifications all succeed, then you can trust that the certificate was signed by a CA that you trust. Beyond that, how much you can trust depends on the CA policies. Most CAs do some checking of the identity of the server (the name of the certificate owner, as shown on the certificate). However, most do not check whether the server runs an honest business. Some CAs may do those extra checks, but their certificates will cost more (a cost paid by the server).
The record of CAs has been spotty. Some CAs have high standards and inspect business records before they will sign that they trust the identity of a server. Other CAs do only more skimpy checks. Even the most stringent of CAs can make mistakes and sign certificates that they should not have signed. And this all depends on your software vendor, and what root CA certificates that your software vendor chooses to include in the provided bundle.
PKIoverheid (only applicable for Dutch market)
PKIoverheid is de Public Key Infrastructure (PKI) van de Nederlandse overheid. Net als elke andere PKI is het een systeem waarmee uitgiften en beheer van digitale certificaten kan worden gerealiseerd. PKIoverheid wordt beheerd door Logius.
Qua techniek is PKIoverheid identiek aan een andere PKI. Een groot verschil is de technische hoogste autoriteit (root CA). In een commerciële PKI-variant is dat bijvoorbeeld VeriSign. Bij PKIoverheid is dat de Staat der Nederlanden. De Nederlandse overheid is verantwoordelijk voor het stamcertificaat op de root CA, waardoor PKIoverheid niet afhankelijk is van (buitenlandse) commerciële partijen. PKIoverheid is een stelsel van voorwaarden voor het uitgeven van certificaten. Commerciële CA's (Certificate Services Providers genoemd - CSP-) kunnen aansluiten bij PKIoverheid. De CA van deze CSP wordt dan opgenomen in de hiërarchie van PKIoverheid. PKIoverheid geeft zelf geen eindgebruikerscertificaten uit, alleen certificaten aan de CSP's. PKIoverheid stelt voorwaarden voor uitgifte van certificaten. Deze zijn overeenkomstig aan de voorwaarden voor gekwalificeerde certificaten. Eén van die voorwaarden is dat de aanvrager fysiek zijn gezicht moet laten zien (identificeren) bij bijvoorbeeld een notaris. Deze voorwaarden gelden niet alleen voor de persoonsgebonden certificaten, maar ook voor de certificaten op organisatieniveau. PKIoverheid streeft naar één hoog betrouwbaarheidsniveau voor alle certificaattypen.
Voor het gebruik van DigiD als authenticatie is het verplicht om gebruik te maken van de bovengenoemde PKIoverheidscertificaten.
Certificates and Futurama applications
Certificates can be used when developing your Futurama application. Typically when a Futurama Website application is built, certificates are used to create a HTTPS connection. Another example is the use of certificates to create a secure webservice connection. Futurama supports WCF webservices. This enables for example the creation of a wsHttp binding using certificates (see for example this page).
There are two ways to install a certificate:
- Import the Certificate Request Response (CRR) provided bij the Certificate Authority
- Install the complete certificate provided by the Certificate Authority
Import Certificate Request Response
In this situation a certificate is installed by first make a Certificate Signing Request (CSR), then send this CSR to a Certificate Authority and then import the Certificate Request Response (CRR).
In public key infrastructure (PKI) systems, a certificate signing request (or certification request) is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate) which must be signed using the applicant's private key. The CSR also contains the public key chosen by the applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information.
After receiving your CSR the CA will check your request and sign it using the private key of the CA. The CA will send you a Certificate Request Response that contains the signed public-key certificate for the application server. Once you have received this response, import it. Check the tutorials of your operating system how to create a CSR and import the CRR.
Dependable on the security policy of the CA a way will be chosen to export the CRR from the CA to the applicant. As the CRR can only be used to create a certificate at the server where the CSR is started it isn’t necessary to highly secure the transport of the CRR to the applicant.
Install complete certificate
Another option is that the CA will create the complete certificate to be installed by the applicant. In this case it is necessary to have a secure connection between the CA and the applicant as the certificate can be used by others when they intercept it.
Note that if a server certificate is signed by an intermediate CA, you also must import each intermediate certificate in the certificate chain.
If you have any questions about this subject or if you want to provide us feedback please send us an e-mail.