Encryption Is Here to Stay, but TLS/SSL Certificate Levels Still Matter
When you are on a website that is encrypted with a DV-level TLS / SSL 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. TLS / SSL 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.

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.

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.

Certificate verification
Once you’ve purchased a certificate, verification of the applicant will begin. The process is carried out by our own verification specialists, which makes delivery of the certificate considerably faster. Learn what verification is all about and what the different stages are.
Read moreSoftware
Finding it a challenge to sign code securely and centrally in today’s software development environment? Code signing certificates allow you agile access while keeping your software secure.
Read moreIdentity
What is your online identity like? Document signing certificates confirm the document’s origins and is the safest and most secure way to make digital signatures. It is also an agile way to ensure the security of your contracts, invoices and other files.
Read moreThese Might Also Be Interesting:
“Can you tell us why we should use you and Entrust when we get certs free of charge e.g. from Let’s Encrypt?”
Pertti Eskelinen
The ICT Manager Teppo Kartano from the city of Rauma sent us a message on Sep-12 2019: “Hi, we had a discussion here about certificates […]
Continue readingAn expiring SSL certificate may take down a critical web service and this risk is now increasing
Pertti Eskelinen
As the maximum life-time of an SSL certificate drops to one year the certificates need to be renewed more often and this adds the risk […]
Continue readingDo we need to renew OV/EV certificates every year after Mar-1 2020? How can Wesentra help its customers to manage the certificates in this scenario?
Pertti Eskelinen
On Aug-8 2019 we learned that a browser vendor has proposed to CA/Browser Forum a ballot to reduce the maximum certificate validity to about 13 […]
Continue readingGuest post by Hackrfi: Why does one buy commercial certificates, and another ends up with Let’s Encrypt?
Pertti Eskelinen
The Let’s Encrypt DV certificates still give rise to discussions. Last month we wrote about answering the customer’s question “Can you tell us why we […]
Continue readingHow SSL Certificates Work
Harri Tuuva
SSL certificates are used to initiate secure communications over computer networks, usually referred as HTTPS traffic. Organization Validated (OV) and Extended Validated (EV) Certificates provide […]
Continue reading