Certificates

Encryption Is Here to Stay, but SSL / TLS Certificate Levels Still Matter

When you are on a website that is encrypted with a DV-level SSL / TLS certificate (domain validation is the lowest level), you cannot verify who is providing the service. You might have been redirected to a scam site that mimics the original site and gives false information. SSL / TLS technology ensures that communication between the user’s browser and your site are encrypted, as indicated by the https:// prefix and lock image on your website address. But an OV-level certificate will also ensure that the organisation providing the service in question has been verified by a verification expert and checked against public registries.

To ensure the safety of your online traffic, you may want to order these certificates from companies such as Wesentra that specialise in them, as these companies maintain systems that assume responsibility by guaranteeing the reliability of certificates. Certificates are provided by a CA (a trusted third party) and sold by resellers. The CA is similar to the authority that issues passports and identity cards – it is the responsibility of the CA to ensure that the individuals and organizations that order certificates actually own the sites and servers for which that certificate is issued. This is an important process and will only be done properly by the very best. The CA is a public entity and its activities are regulated very strictly by the CA Browser Forum, which in practice dictates how certification should be carried out.

Certificate Types

Entrust Standard OV

Entrust’s Standard OV protects the traffic on your website simply and easily. The certificate not only allows the browser / client to reliably identify the server, but also to establish an encrypted connection with it. The Entrust Standard OV certificate makes single domain services and traffic secure (example.com and www.example.com). And if something goes wrong or the certificate needs to be renewed for any other reason, the certificate can be flexibly reissued up to 60 days before the certificate expires, e.g., with a new certificate signing request (CSR).

Entrust Advantage OV

Entrust’s Advantage OV protects two domains with the same certificate. It is also suitable for ensuring traffic is secure between servers, such as the Active Directory Federation Service (ADFS), as it can also ask for browser authentication. In addition to the two domains, Entrust Advantage OV contains by default both a common name (CN), e.g., www.asiakas.fi, and a subject alternate name (SAN), e.g., asiakas.fi. And if something goes wrong or the certificate needs to be renewed for any other reason, the certificate can be flexibly reissued up to 60 days before the certificate expires, e.g., with a new certificate signing request (CSR).

Entrust Wildcard OV

Entrust’s Wildcard OV protects the entire root domain with a single certificate. For example, when you protect the domain *.asiakas.fi it will also cover additional domains, such as www.asiakas.fi, mail.asiakas.fi, etc. You can also arrange it so there are additional *features in the same Entrust certificate – such as *.portal.asiakas.fi, for instance. Entrust Wildcard OV also includes a ReKey feature, meaning you can create duplicates of the same certificate at no extra charge. As the most flexible and feature-laden Wildcard OV on the market, this certificate has up to 250 additional SANs for an additional fee. And if something goes wrong or the certificate needs to be renewed for any other reason, the certificate can be flexibly reissued up to 60 days before the certificate expires, e.g., with a new certificate signing request (CSR).

Entrust Multi-Domain OV

Entrust’s UC Multi-Domain OV is suitable for protecting business servers and environments, such as Exchange, Lync or Skype. Either way, it should be used when multiple domain names need to be protected with the same certificate. With the Entrust UC Multi-Domain OV, it is possible to protect up to 250 domain names (e.g., autodiscover.ssl-apua.fi, sip.ssl-apua.fi, service1.ssl-apua.fi, www.ssl-apua.fi, ssl-apua.com). And if something goes wrong or the certificate needs to be renewed for any other reason, the certificate can be flexibly reissued up to 60 days before the certificate expires, e.g., with a new certificate signing request (CSR).

Entrust Document Signing

Entrust Document Signing Certificate is for signing various kinds of document – for instance, when you need to prove who produced the document. These are useful for official documents to ensure that they are as they should be and have not been modified by any third parties.

Entrust S/MIME-Certificate

Entrust S/MIME Certificate is for encrypting and signing emails, and is commonly used to protect email traffic. S / MIME therefore works with most email software.

Entrust Code Signing

Entrust’s Code Signing Certificate is used to sign and protect software code. Developing and distributing software you can trust nowadays requires the code to be signed using a public certificate. Code signing certificates always requires an EV-certified domain for their users – in other words, the highest level of security authentication – and this means an EV or OV code signing certificate protected by a token / HSM device. From a data security point of view, it is essential that the machine on which the code is signed is kept secure and is only accessible to those responsible for signing the code.

The Certificate Authority Browser Forum (CAB) has made it a standard that all code signing certificates must be ‘hardware-protected’ (in other words using a token). Although the OV Code Signing certificate can be used on its own, these certificates are therefore shipped with the token by default. If the certificate is to be used without a token, then the user assumes responsibility for the security of the certificate. A token-protected version will not work without the token in use at the time of signing, and the certificate provider also has the right to revoke the certificate if abuses are detected.

Qualified Web Access Certificates (QWAC)

Entrust’s Qualified Web Access Certificates (QWAC) provide the securest levels of electronic identity for companies and organizations.

QWAC certificates are SSL / TLS certificates based on the EU’s eIDAS regulations and the finance sector’s Payment Services Directive 2 (PSD2). QWAC certificates both increase the security of e-transactions and strengthen the electronic identity of organizations and companies. Verification follows the extended validation (EV) process – as required by eIDAS and PSD2, and face-to-face identification of a representative from the company or organization is also required before a QWAC can be successfully issued. QWAC certificates can only be issued by operators who have Qualified Trust Service Provider (QTSP) status in EU and EEA countries. Read more about Qualified certificates and QSeals here.

Three Different Levels of Validation

OV – Organizational Validation

OV certificates are the kind most commonly used to secure traffic on the internet (websites) and between different servers (e.g., firewalls, load balancers, and VPN devices). OV verification is based on using the certificate as a means to verify the organisation.

OV certificates reassure the person visiting your website:

-that they are definitely on a website made by your organization, and

-that the information they are entering in to your site will not fall into the hands of an outsider.

Information required for the OV process

The OV process is speeded if the following information is up-to-date in the public registers:

1. Official details of the company (name and street address). This name can be found in the trade register (in Finland for example) or official international business registers (such as Hoovers, or Dunn & Bradstreet).

2. Domain names you want to protect with the OV-level SSL / TLS certificate. Ownership of these domains must be verifiable in one of three ways:

  • EMAIL
    To accept a domain via email, an email is sent to the address found in the domain’s WHOIS information or to a specific generic email address. The recipient accepts by simply replying to the email or opening the verification link in the message.
  • WEB SERVER
    To accept a domain via web server, a small file is provided, with instructions for placing it on the web server under the domain address. The domain is accepted once the file is detected, the contents checked, and the contents are found to be correct.
  • DNS
    To accept a domain via DNS, a series of letters and numbers is sent to the domain’s TXT record for DNS. The domain is accepted once the correct sequence of letters and numbers is identified.

3. Authorised contact person. This is the person who will confirm the authenticity of the application for the OV-certificate; is responsible for authorising the roles of the technical contact (admin); and is responsible  for receiving and confirming the online consent form. The authorised contact’s full name (including their title in English), telephone, email, and street address are required.

4. Technical contact (admin). This is the person who makes certificate requests on behalf of an organisation. There may be more than one, and often the authorised contact person also acts as a technical contact. The technical contact’s full name (including their title in English), telephone, email, and street address are also required.

ov-varmenne

EV – Extended Validation

EV certificates are used when an organisation needs to invest in greater security for their users or when the website in question requires important or personal information about the user. For instance, financial institutions and online stores are typically EV-certified.

EV certificates reassure a person visiting the website:

-that they are definitely on a website made by your organization, and

-that the information they are entering in to your site will not fall into the hands of an outsider.

Information required for the EV process

The EV process is speeded if the following information is up-to-date in the public registers:

1. Official details of the company (name and address). This name can be found in the trade register (in Finland for example) or official international business registers (such as Hoovers, or Dunn & Bradstreet).

2. Domain names you want to protect with the EV-level SSL / TLS certificate. Ownership of these domains must be verifiable in one of three ways:

  • EMAIL
    To accept a domain via email, an email is sent to the address found in the domain’s WHOIS information or to a specific generic email address. The recipient accepts by simply replying to the email or opening the verification link in the message.
  • WEB SERVER
    To accept a domain via web server, a small file is provided, with instructions for placing it on the web server under the domain address. The domain is accepted once the file is detected, the contents checked, and the contents are found to be correct.
  • DNS
    To accept a domain via DNS, a series of letters and numbers is sent to the domain’s TXT record for DNS. The domain is accepted once the correct sequence of letters and numbers is identified.

3. Business HQ / place of business. The official address of the company’s headquarters, which can also be found via third party information (e.g., trade register or other official business registers such as Hoovers or Dunn & Bradstreet).

4. Higher Authority. This is someone in the company at a managerial level who who will confirm the authenticity of the application for the EV certificate, and is responsible for authorising the roles of the contract signer and authorised contact person. This person must be reachable by third party sources over the phone, and they cannot be the same person as either the contract signer or authorised contact person. The higher authority’s full name (including their title in English), telephone, email, and street address are also required.

5. Contract signer / certificate approver. These roles consist of receiving and confirming the subscription agreement and online consent forms, but they absolutely cannot be carried out by the higher authority. Contract signing and certificate approval can be carried out by different people, but if one person assumes both roles, it will speed up the verification process in the future.

6. Technical contact (admin). This is the person who makes certificate requests on behalf of an organisation. There may be more than one, and often the authorised contact person also acts as a technical contact. The technical contact’s full name (including their title in English), telephone, email, and street address are also required.

ev-varmenne

DV – Domain Validation

The lowest level of certification is Domain Validation (DV). In this case, the CA only checks if the certificate applicant has sufficient rights to the domain address they want the certificate for. The process is inexpensive, but not necessarily reliable. If an organisation wants to guarantee the authenticity of its certificates and minimise the risk of misuse, they should apply for OV or EV certificates.

 

Here’s an example. The name of the organisation doesn’t appear anywhere simply because no one has verified which organization set up the domain or authorised it.

domain_varmenne