Telia offers certificate services in following countries:
| Sweden | Finland | Norway | Estonia | Lithuania | Denmark |
CERTIFICATE SERVICE CONTACT
NEWS
--
THE END OF WHOIS VALIDATION
CA/Browser Forum has decided that email domain validation cannot use WHOIS data any more. In practice this means that domains cannot be validated using email addresses found using WHOIS queries. WHOIS service has enabled using of custom email addresses in email validation instead of so-called standard addresses.
Telia CA will discontinue email validation WHOIS queries and expire all valid validations, which have used this method on May 15th, 2025. All certificate requests after May the 15th need to be revalidated by allowed methods for domain previously validated with WHOIS email.
Telia CA continues to support three (3) email-based validation methods as explained below. Recommendation is to transition to use "Email to DNS TXT Contact" described below to keep the similar functionality.
EMAIL TO DNS TXT CONTACT
In this method Telia CA sends an authorization email to the email addresses found in the DNS TXT record. The DNS TXT record MUST be placed on the _validation-contactemail subdomain of the domain being validated e.g. _validation-contactemail.exampledomain.com. The entire RDATA value of this TXT record MUST be a valid email address. In domain validation CA will send email to this address with a link in the email message to perform the validation. Please note that DNS TXT based methods are subject to DNS TTL settings when updating the records.
CONSTRUCTED EMAIL TO DOMAIN CONTACT
CA will send a formatted email to these addresses. Clicking the link in the email at any of these email boxes will perform the validation action:
administrator@exampledomain.com
admin@exampledomain.com
postmaster@exampledomain.com
hostmaster@exampledomain.com
webmaster@exampledomain.com
EMAIL TO DNS CAA CONTACT
In this method CA looks up validation email address from CAA contactemail property tag. You need to set up this to DNS with email address accessible by you. In domain validation CA will send email to this address with a link in the email message to perform the validation. Please note that DNS CAA based methods are subject to DNS TTL settings limitations when updating the records.
A CHANGE IN TELIA CA HIERARCHY
Telia CA has updated its CA hierarchy related to publicly trusted TLS and Client certificates on Oct 1st, 2022. This change was done to provide to Telia CA customers new CA hierarchy, new Telia names and URLs, longer validity times and the most recent certificate profiles.
The old Telia Root (TeliaSonera Root CA v1) is already 15 years old but it is still functional and safe for a long time. All old already delivered Telia certificates can be used until they naturally expire.
From October 1st, 2022 all new Telia TLS certificates will be issued by a new Telia Server CA v3 (OV) or Telia Domain Validation CA v3 (DV) and from November 1st 2022 all new Telia Client certificates will be issued by a new Telia Class 1 CA v3 (FI) or Telia Class 2 CA v3 (SE).
CHANGE IN TLS CERTIFICATES
All new Subscriber Certificate deliveries contain the new CA hierarchy as illustrated below:
| TeliaSonera Root CA v1 | → | Telia Root CA v2* | → | Telia subCA v3 | → | End-Entity certificate |
* cross-certified by Telia’s old root
Alternatively Customer may choose to use the hierarchy below, remembering as a prerequisite that the new hierarchy may only be available in the recent versions of operating system’s / browser’s root storages. Telia’s root Certificate Authority ”Telia Root CA v2” has been included in operating systems / browsers less than one (1) year. For older Operating systems / Browser versions the trust is more likely guaranteed by using above Telia CA hierarchy.
| Telia Root CA v2 | → | Telia subCA v3 | → | End-Entity certificate |
In the most TLS cases it is not essential to put the correct CA hierarchy to Customer devices but in some cases (Android, Java, Apple) there may appear trust issues if the CA hierarchy is not according to information above. Telia CA recommends that configuration is always tested after TLS certificate installation by using special tools for that purpose (for example SSLLabs SSLTest). That will guarantee that Customer installation has been done correctly and trust will work.