Everything you need to know about Certificate Ownership

code certificate

TLS server certificates provide a secure backbone to digital infrastructure across the globe, yet a lot of organisations are severely lacking the policies and processes needed to guarantee sound certificate management. These organisations are further challenged by the vast scale at which TLS certs must be managed and lack the modern, automated technology stack that would enable them to do so.

Until these issues are addressed, incidents and downtime resulting from TLS certificate issues will continue to abound.

The Challenge of Effective Certificate Management

Some of the key factors that make certificate management so difficult for many organisations include the fast-paced deployment of TLS servers, the numerous roles that take part in the issuance and management of certificates, how certs are diffusely allocated amongst enterprise groups and environments and the convoluted processes required to manage them. In many organisations it’s commonplace for a Public Key Infrastructure (PKI) team, or a Certificate Services team, to handle the issuance of TLS certificates. Yet once these certificates are issued, they tend to be installed and maintained by the certificate owners – the teams of system administrators who manage the servers, network appliances and various other devices on which the certificates reside.

The Certificate Services team is often the group in charge of handling interactions with public CAs as well as internal CAs. This team is usually composed of between one to three employees. Though the team members have substantial skills and experience in TLS server certificates, they lack the means and permissions necessary to directly administer certificates on the vast array of devices where certificates are installed. When TLS certificate issues, like outages, happen, the Certificate Services crew is frequently held responsible.

Dedicated Teams & Defined Responsibilities 

“Certificate Owner” is a title that designates an individual or a group as maintainers for systems where the certificates reside. A certificate owner group may contain members from a diverse set of positions, such as sys admins who are in charge of overseeing specific systems and the certificates on them, application owners who can evaluate and authorize certificate requests from system administrators to make sure that only approved certificates are granted and the executives who have the ultimate responsibility for making sure that any duties relating to certificates are fulfilled.
Certificate owners are often unaware of the risks connected with certificates or the recommended best practices for handling certificates correctly.

Certificate Provision in a Rapidly Changing Environment 

The emergence of widespread virtualization means DevOps teams now often provide systems and software programmatically. Technology stacks involving containerisation and orchestration may utilise short-living applets, which create a new category of certificate owner as well as novel kinds of TLS server certificate challenges for enterprises. As enterprises strive for faster and more effective application deployment, some DevOps teams’ resort to distributing certificates without first consulting with their Certificate Services division.
Bugs and flaws in DevOps tools or scripts can generate erroneous deployment or updating of certificates, which in turn may lead to certificates for essential applications not being adequately monitored. As recently seen by the serious outage for Spotify’s Megaphone podcast platform, poorly tracked, expiring certificates can cause huge problems that harm even the largest and most innovative organisations. Moreover, it is crucial to keep an eye on certificates and apps delivered and maintained by previous DevOps frameworks and tools when DevOps teams embrace modern practices.

As you can see, the landscape of certificate ownership is not without its perils and improper management of certificate ownership can cause major headaches for organisations. It’s recommended that all organisations have clearly defined certificate owners and to ensure that the Certificate Services team have a constantly updated list of owners. Furthermore, the certificate owners need to be actively preserving correct certificate policy enforcement.

If you need any helping creating a system that ensures best practice of certificate ownership (or any other PKI related needs) please feel free to contact one of our sales reps at sales@trustzone.com or call +45 88 33 10 00

What you need to know about TLS 1.3

TCP illustration

How TLS works

TLS (Transport Layer Security) is an encryption protocol for securing data that is sent between a client and a server over the Internet. It is the most familiar to users when browsing websites, where the padlock icon appears as part of a secure session that has been established through an SSL certificate. However, TLS does not secure data on end systems. It simply ensures the safe delivery of data over the Internet, thereby avoiding any possible eavesdropping and/or alteration of the content exchanged between applications.

What are the advantages of TLS 1.3 over previous versions?

TLS 1.3 offers several improvements, notably a faster handshake and a simpler and more secure set of cipher suites. By also supporting zero-round-trip-time (0-RTT) key exchanges, TLS handshakes are further streamlined. As a result, performance and security are enhanced.

The faster handshake

TLS somewhat degrades secure network communication because it requires CPU time and adds latency. Under TLS 1.2, the initial handshake is carried out in clear text, meaning it has to be encrypted and decrypted. A typical handshake involves 5-7 packets exchanged between the client and the server, which adds considerable overhead to the connection. With version 1.3, server certificate encryption is adopted by default. With this change, a TLS handshake can be accomplished with 0-3 packets, as illustrated below, reducing or eliminating this overhead, and enabling faster and more responsive connections.

TLS1.2 vs. New TLS 1.3

Improved security through stronger Cipher Suites

The problem with TLS 1.2 is that it is often not appropriately configured, which leaves websites vulnerable to multiple attacks, e.g. POODLE, Heartbleed, or The ROBOT attack. TLS 1.3 removes the obsolete and insecure cryptographic features from TLS 1.2 and only supports Ciphers and Algorithms with no known vulnerabilities, including any that do not support Perfect Forward Secrecy (PFS). In addition, TLS 1.3 removes the ability for the client and server to “renegotiate” that would have allowed clients and servers to generate new keys and parameters during their already established TLS connection, which is a function that would have increased risk.

The good and the bad of Zero Round Trip Time (0-RTT)

In short, Zero Round Trip Time Resumption or 0-RTT optimizes the performance for clients who are revisiting your site. However, the improvement comes at a cost. More precisely, it is a security concern when it comes to 0-RTT, which does not provide a guarantee of non-replay between connections. If an attacker somehow manages to get hold of your 0-RTT encrypted data, it can fool the server into believing that the request came from the server since it cannot know where the data initially came from. If an attacker sends this request multiple times, you could be vulnerable to “a replay attack”.

Is it time to upgrade your web applications to TLS 1.3?

The decision to upgrade to TLS 1.3 at this point will depend on your requirements and motivations. Some browsers do not support TLS version 1.3, which could result in a bad user experience. However, if you disable vulnerable features like renegotiation and use Perfect Forward Secrecy (PFS), TLS 1.2 will have the same security and privacy benefits as TLS 1.3.

There is no doubt that TLS 1.3 is the future of cryptographic protocols, but TLS 1.2 will continue to exist for quite some time. If you want to inspect your domains for supported TLS-versions and any possible vulnerabilities, check out SSL360®.

Get in touch with us for a non-binding quote


Børsen: “We never had this kind of overview before”

Our partners

Who: Brian Skibby, IT Manager at Børsen

What: SSL360®


Business setup

I manage a team of three people. Together, we are responsible for all IT security tasks, including IT operations and internal IT support.

We started using SSL360® a little over a month ago.

Before SSL360®

Before I joined Børsen, the IT team members would buy one certificate here and one there:

One would be a star [Wildcard –Ed.] certificate, one would be a regular certificate, and “Hey, here’s a cheap one! And wow, a free one!” – and over time, certificates of all kinds from lots of different CA’s [Certificate Authorities –Ed.] and suppliers would just accumulate.

Of course, a certificate would expire from time to time, and everyone would be like: “What? We had a certificate there as well?”

Back then, no one took the time to get an overview. And I completely understand why, because it was an impossible feat: There was absolutely no way of knowing where all these different certificates were. Instead, you would deal with each certificate on an ad hoc basis every time an issue arose.

When I joined the team, there was no comprehensive picture of our certificate setup. Eventually, I managed to create a pretty decent manual overview – though every once in a while, I’d discover a certificate that I knew nothing about.

Of course, a certificate would expire from time to time, and everyone would be like:

’What? We had a certificate there as well?’

Choosing SSL360®

When I heard that you’d launched SSL360®, one of the first things I noticed was that it’s very reasonably priced: There are so many cool IT tools with all sorts of neat features, and then, BAM! – you find out how much it’ll cost you.

That’s why every time I research something that might be relevant for us, the first question I ask is: “What’s the price?”

That way, if it’s clearly out of our league in terms of costs, I can stop right there. But with SSL360®, the pricing is both transparent and very affordable.

Apart from being budget-friendly, the opportunity to get a complete overview of our certificates is what convinced me to try out SSL360®.

I briefly talked with my boss about it, but it wasn’t a big, difficult decision to make with a product in this price range. At this cost, it just makes a lot of sense for us. If the price had been 10 x higher, it might have been out of our range budget-wise, but it’s worth every krone.

And there’s nothing risky about adding it to your security stack because everything runs automatically in the cloud. It’s not like saying, “Hey, let’s add this third-party honeypot” – that kind of setup would definitely have put me on guard.

I briefly talked with my boss about it, but it wasn’t a big, difficult decision to make with a product in this price range.

At this cost, it just makes a lot of sense for us.

Getting started with SSL360®

We were up and running in no time, really. I did a quick introduction online with Sune [Børsens’s TRUSTZONE Account Manager –Ed.], but even if I hadn’t, I would’ve quickly figured out what to look for and where because the SSL360® dashboard is very intuitive.

It’s also “safe” to play around with, meaning that nothing will blow up in your face or disappear if you click on something by mistake.

It’s mostly me who uses SSL360®. The first week, I spent a little time getting an overview of our certificates.

After that, I haven’t needed to check up on anything manually. But I plan to set up a routine where I regularly check our dashboard to stay one step ahead of things.

The SSL360® dashboard is very intuitive.

The benefits of SSL360®

For the first time ever, we now know which certificates we have. We get peace of mind.

And we don’t even have that many certificates – there are so many organizations that have a lot more than we have.

I suppose there are teams out there with 200 or more certificates who keep a flawless backlog – who continuously maintain a full overview of every certificate they own, buy, and install while also keeping track of who supplied what, which certificates are installed where, and so on.

But I also know that many organizations don’t have that kind of overview. And for them, I can only imagine what a gamechanger SSL360® would be.

And hey, some of them may even be paying for something they don’t have a clue what is! We sure had a couple of surprises when we looked through the lens of SSL360® – I found a couple of certificates that we didn’t have control over and even found some that we don’t need at all.

I found a couple of certificates that we didn’t have control over and even found some that we don’t need at all.

The conclusion

My advice is: Get it today. With SSL360®, it’s so affordable to get this overview that there’s no reason not to. We’ll keep using it, that’s for sure.

With SSL360®, it’s so affordable to get this overview that there’s no reason not to.

Working with TRUSTZONE

In two words: Awesome supplier!

Today, you can buy certificates in lots of ways and from lots of different suppliers. I enjoy doing business with you because it’s a much more local and personal experience:

We can ask questions in our native language. You know who we are; you understand our needs and requirements quickly and effortlessly, and you offer personalized support and suggestions.

Sure, we could buy equally good certificates slightly cheaper somewhere else, but we get full support and lots of help with everything when we buy from you.

Your support is incredibly valuable to us because we usually focus very little on our certificates once everything’s up and running. However, every once in awhile, we need to act on something regarding our certificates, and then it can be hard to recall how to do everything correctly. In those situations, you’ve always been very gracious and supportive.

With you, we get value for money! I’ve recommended you to every IT professional that I know.

With you, we get value for money!

I’ve recommended you to every IT professional that I know.

Founded in 1896, Dagbladet Børsen is the leading financial and business newspaper in Denmark. The paper is published on weekdays, reaching more than 100,000 daily readers.

Dagbladet Børsen A/S has 225 full-time employees. The website borsen.dk has more than 15 million pageviews/month as well as over 540,000 unique users/month.

Maximum SSL/TLS Certificate Validity is Now One Year

Starting on September 1, SSL/TLS certificates can not be issued for longer than 13 months (397 days). This change was first announced by Apple at the CA/Browser Forum Spring Face-to-Face event in Bratislava back in March.

Then, a couple of weeks ago, at the CA/B Forum’s Summer event (held virtually), Google announced its intention to match Apple’s changes with Google’s own root program.

There is also a browser-driven ballot that seeks to align the industry’s baseline requirements with the new root program changes. The CA/B Forum is currently debating this.

We realize there might be a lot to unpack here, so in the interest of providing a little clarity, we’re going to cover it in this article.

The reason for shorter SSL/TLS certificate lifespans

From a high-level, theoretical standpoint, there are two primary benefits for shorter-lived certificates:

The first is the technical component – longer lifespans means that it takes longer to roll out updates or changes organically. A real-world example would be the SHA1-to-SHA2 transition: Unless you’re going to revoke a whole bunch of certificates and force the customer to reissue, it can take years before all of the old certificates have been replaced. In the case of SHA1, it took three. That creates risk.

The other benefit has to do with identity: How long should information that is used to validate an identity stay trusted? The longer between validation, the higher the risk. Google has said that in an ideal world, domain validation would occur about every six hours.

Before 2015, you could get an SSL/TLS certificate issued for up to five years. That was reduced to three years, and then again in 2018 to two years. At the end of 2019, a ballot was proposed at the CA/B Forum that would have reduced it to one year – however; it was voted down soundly by the Certificate Authorities.

So, why are certificates still being reduced to one year?

The CA/Browser Forum is an industry group that meets to vote on a set of baseline requirements for the issuance of trusted digital certificates.

What the CA/Browser Forum is not, however, is a governing body. Therefore, even though the CAs expressed concerns and reluctance to decrease maximum validity again, Apple and Google are well within their right to update the policies for their root programs as they see fit.

We understand that we’ve just thrown a whole bunch of industry terms at you, so let’s step back really quick and make sure the previous paragraph makes sense:

Certificate Authorities and browsers have an interdependent relationship. Browsers need to use certificates to make trust determinations about websites and for help securing connections. From a CA’s point of view, what good is a public certificate if it’s not trusted by a browser?

The way this is all managed is through the root programs. There are four major root programs of note:

  • Microsoft
  • Apple
  • Mozilla
  • Google (the last two known as Googzilla – LOL)

Incidentally, you’ll notice those four are equivalent to the forces behind the major browsers on both desktop and mobile. For a CA to have its certificates trusted by the root programs and, by extension, the browsers and OSs that make use of them, the CA must adhere to that root program’s guidelines.

The CA/B Forum is an industry forum that ideally helps to facilitate changes to the root programs (and to the ecosystem itself). But the root programs, which participate as browsers, can still act unilaterally and make changes as they see fit.

When this happens, the need for interoperability basically dictates that whatever root program policy has the most stringent standards becomes the new de facto baseline requirement.

That’s how we got here. Now, let’s talk about what this means for your website and what you as a company can do to optimize your certificate management.

For a CA to have its certificates trusted by the root programs and, by extension, the browsers and OSs that make use of them, the CA must adhere to that root program’s guidelines.

What shorter SSL/TLS validity means for website owners

First things first: this change goes into effect on September 1, 2020. So, if you are using a two-year certificate that was issued before September 1, your certificate will stay valid until its original expiration date. You just won’t be able to renew it for two years moving forward.

Or, to put it another way: you have until September 1 to get two-year certificates. After that, they will be relegated to the desktop recycling bin of history. From a bigger-picture standpoint, this might be a good time to start considering automating more of your certificate lifecycle management:

Automated lifecycle management is especially crucial for larger organizations managing dozens of publicly-trusted website certificates, but also for organizations using publicly-trusted email certificates and any organization leveraging private CA or PKI-based electronic signatures.

The way things are headed with the root programs continuing to push for shorter validity, organizations will pretty much be forced to automate a lot of these things at some point in the future. Better to explore this now than when your feet are held to the fire.

How TRUSTZONE will handle one-year certificates

In the interest of making the process as straightforward as possible, starting on August 31, TRUSTZONE will provide SSL/TLS customers with the maximum validity of 397 days when ordering one-year certificates. This new standard applies to new certificate orders as well as certificate renewals. This way, we can provide you with the maximum possible validity for your benefit.

You will still want to renew your certificate before it expires. Also, since we can no longer provide up to 90 additional days to your validity, we recommend that you renew your certificate within 30 days of expiration.

What about reissuing my certificates?

You may wonder what happens when you reissue one of your two-year certificates after this change goes into effect. Well, we have good news for you!

If you reissue a certificate and lose validity (we’re required to limit validity to 397 days), you can reissue the certificate later ideally less than 397 days before your original certificate expires and recover the lost validity from your first reissue. This works the same way it did in 2018 when we went from three-year maximum validity down to two years.

One thing worth noting is that the EV reissue process is a bit different due to the EV Guidelines (EVGL) requirements for reissuing certificates.  While you can still reissue your certificates, they will be queued for manual review, and we will need to make sure that all validations are up-to-date before we can release them.

If you have any questions about how these changes may uniquely affect your organization or website, please don’t hesitate to contact us – just fill out the contact form below:


TRUSTZONE Support Service Level Agreement


Monday to Thursday: 8:30 AM to 4:30 PM GMT+1

Friday: 8:30 AM to 4:00 PM GMT+1

With the exception of public holidays.


+45 88 33 10 00




Our Goal

Due to the critical nature of the infrastructure and security solutions that TRUSTZONE provides, we understand that we need to provide the best possible support to eliminate any downtime.

By working closely with our customers, partners, and resellers through our support framework, we will provide a seamless transition of customer-facing issues through the organizations to ensure a positive experience.


Service Availability

The nature of every service we offer, and the way customers, partners, and resellers rely on them demand different levels of service.

The table below lists the availability goals for each service:

Measurement of Availability

When calculating availability each month, the amount of time each trouble ticket representing an outage was without a resolution (either temporary or permanent) is totaled and divided by the minutes each month.

For example, in a 30-day month where there are 720 hours, a 1-hour unplanned outage that month would result in a 99.86% uptime.

Support Programs Overview

TRUSTZONE offers two levels of support, Standard, and Premier.

While Standard is included with all products and services, Premier offers increased response times and availability and may be purchased at an additional cost.

Both programs offer several channels for accessing support, including phone, live chat, email, and a self-service portal. Service Time, Availability for Phone Support, and Response Times will vary based on the support program purchased.

Support types and availability

Support type


Phone Support Monday to Thursday: 8:30 AM to 4:30 PM and Friday: 8:30 AM to 4:00 PM (with the exception of public holidays).

Premier customers can have access to extended phone support.

Live Chat Support Live Chat Support is available from our website Monday to Thursday: 8:30 AM to 4:30 PM and Friday: 8:30 AM to 4:00 PM (with the exception of public holidays).
Self-Service Support Using a variety of resources on our website, you can solve many of the most common problems yourself.

Here, you can search our knowledge base for rich content, FAQs, up-to-date resolutions, white papers, and technical notes:



Response Times by Program

This section provides information about response times based on support cases received through the various support channels:

Key term definitions

Key Event Definition
Response Time The time between notification of a problem to TRUSTZONE during support hours and acknowledgment of customer, partner, or reseller (answering telephone calls or sending a reply mail in case of email notification).
Time-To-Restore The time to restore the solution to a functioning state prior to the observation or find and implement an acceptable workaround, which solves (remedies) the unavailability or degradation.
Time-To-Solve The time to find and implement an acceptable workaround or agree on a plan, which solves (remedies) the unavailability or degradation in the service.

Support level definition and description

Support level  Definition Description
Priority 1 (P1) Critical Business Impact Complete or significant loss of service for which no workaround exists and work cannot reasonably continue – Breach of security or privacy would be an example of a P1.
Priority 2 (P2) Serious Business Impact Degraded loss of service due to performance issues – Fault tolerance environmental failure.
Priority 3 (P3) Minor Business Impact Minor loss of service. A minor product flaw with a workaround represents this type of flaw.
Priority 4 (P4) No Business Impact Service is working within operational parameters, but a minor irritant or frustration exists using a specific feature.

Standard support

Priority 1 (P1) Priority 2 (P2) Priority 3 (P3) Priority 4 (P4)
Response Times 4 hours 8 hours 1 business day 2 business days
Restore Times 8 hours 2 business days 3 business days Not applicable
Resolution Time 5 business days 31 calendar days 60 calendar days Not applicable

Premier support

Priority 1 (P1) Priority 2 (P2) Priority 3 (P3) Priority 4 (P4)
Response Times 2 hours 6 hours 1 business day 1 business day
Restore Times 4 hours 8 hours 1 business day Not applicable
Resolution Time 5 business days 31 calendar days 60 calendar days Not applicable

Support Workflow Phone

Through this channel, support representatives will be available to gather information about new issues. They will be able to offer initial troubleshooting, enter a new case, and notify a support analyst if they are unable to resolve the issue.

Fatal, Severe Impact, or Security Incidents should always use this channel for first contact.

Monday to Thursday: 8:30 AM to 4:30 PM

Friday: 8:30 AM to 4:00 PM

With the exception of public holidays.

Premier customers can have access to extended phone support.

Live Chat

On our website, https://trustzone.com, customers, partners, and resellers can reach our support staff via a live chat.



By emailing support@trustzone.com, a new case will be created within the TRUSTZONE case management system.

This case will be placed in the appropriate support queue, and we will get back to you within the Response Times listed above.


Self-service Portal

Through the self-service support site https://trustzone.com/knowledge-base/, customers, partners, and resellers can search our Knowledge Base, use support tools, and initiate contact with support.


Escalation Process

Problems associated with service will be handled according to a negotiated timetable between TRUSTZONE and the customer, partner, or reseller. The following legend will be used to describe the terms agreed upon to handle escalation procedures:

Support level and escalated timescale

Support level Escalated timescale
Priority 1 (P1) 4 hours after initial call, escalated to Manager of Support. 24 hours after initial call, escalated to their superior.
Priority 2 (P2) 24 hours after initial call, escalated to Manager of Support. 48 hours after initial call, escalated to their superior.
Security Incident Resulting tickets will be immediately flagged as P1 and escalation procedures activated based on the following:

P1: Immediately escalated to Manager of Support; 1 hour after initial call, escalated to their superior.

Notification of Downtime

The delivery of a secure, highly reliable system requires downtime; this downtime will be planned in advance so you may plan accordingly. Such downtime will be limited to no more than 4-6 hours of downtime each month.

In the unlikely event that unplanned downtime is experienced, you have the option of being notified of these events.

Additionally, the status of the system, as well as notifications of the planned service windows, are always available on our website.



TRUSTZONE is Scandinavia’s largest SSL/TLS certificate supplier and a leading provider of scalable PKI and IoT solutions for encryption, authentication, and automated certificate lifecycle management.

With a full suite of compatibility-optimized, fully scalable certificate products and solutions, we offer custom options for companies and organizations across industries.

Our options fit all company sizes — from small, one-person businesses and startups needing one or two SSL/TLS certificates to large international companies looking for full-scale, enterprise-grade solutions.

We have more than 15 years’ experience with PKI, SSL/TLS, and certificate management. 3,000+ companies of all sizes have already trusted us with their certificates, and more than 80% of the Danish banking sector is protected by TRUSTZONE certificates.

Learn more on our About page here.

TF Bank: More Agility and Flexibility

Our partners

TF Bank AB is a fast-growing North European niche bank that offers consumer banking services with a high degree of automation. The bank is a Swedish growth success story and offers financial services through its proprietary IT platform.


TF Bank’s IT platform is designed to be scalable and adaptable to various financial products, countries, and digital banking solutions.

The TF Bank setup

TF Bank has a number of SSL certificates, of which about 90% are EV SSL certificates provided by TRUSTZONE, and manage their certificates with Managed SSL.

Previously, TF Bank handled their certificates through a domain name registrar, who then issued and managed the bank’s Symantec certificates.

However, this setup came with “an entirely different price tag” as Daniel Baagöe-Larsen, Web Officer at TF Bank, puts it.

Another downside was the lack of agility:

“Every time I had to issue a new certificate, I had to get hold of an employee at the domain name registrar who could assist me,” remembers Baagöe-Larsen.

Every time I had to issue a new certificate, I had to get hold of an employee at the domain name registrar who could assist me

Daniel Baagöe-Larsen, TF Bank

A complete overview

For TF Bank, the flexibility and autonomy that Managed SSL offers have eliminated the previous need for continuous anticipation and planning:

“The built-in features in Managed SSL help save us time, and we never experience any issues,” says Baagöe-Larsen.

The built-in features in Managed SSL help save us time, and we never experience any issues

Daniel Baagöe-Larsen, TF Bank

Rapid issuance and personal support

He now issues new EV SSL certificates in just 10 minutes when domains are pre-validated “— even on a Sunday if there’s an urgent need.”

Baagöe-Larsen also highlights TRUSTZONE’s service and support: The personal contact and the opportunity for continuous sparring and support is highly valued.

TF Bank carries out deposit and lending activities in Sweden, Finland, Norway, Denmark, Estonia, Latvia, Lithuania, Poland, Germany, and Austria either through branch or cross-border banking.

The bank operates through three complementary segments with cross-selling opportunities made possible by its scalable and flexible IT-platform. TF Bank is listed on Nasdaq Stockholm.

JN Data: Great Support in Our Own Language

Our partners

JN Data provides the financial sector with secure and stable IT operations, infrastructure, and services. The company’s solutions reach more than 40,000 employees at 200 banks and mortgage providers in both Denmark and the Nordic countries. 


Since 2016, JN Data has been relying on TRUSTZONE as a dedicated partner for everything related to the company’s digital certificates.

Switching to TRUSTZONE

IT security administrator Jytte Langhoff lists several reasons why JN Data switched to TRUSTZONE:

“We ran an internal survey, and every employee highlighted different advantages: TRUSTZONE’s prices were more favorable, and their service seemed better.

TRUSTZONE’s organizational structure is flatter, and they offer support in our own language. It just all adds up,” explains Jytte Langhoff.

TRUSTZONE’s prices were more favorable, and their service seemed better

Jytte Langhoff, JN Data

Competent advice and a custom setup

She describes a competent and welcoming start-up process:

TRUSTZONE quickly got a solid, custom structure set up for JN Data with separate profiles for four companies under the same Managed SSL account.

TRUSTZONE’s organizational structure is flatter, and they offer support in our own language. It just all adds up

Jytte Langhoff, JN Data

Apart from providing JN Data with an instant and much-needed overview, the company’s custom setup also makes it easy to manage the considerable number of certificates that are continuously issued and re-issued.

The ability to instantly issue certificates for pre-validated domains is also a gamechanger and everyday convenience.

“Generally, we expected a user-friendly, intuitive certificate management solution with fast and competent support available—and that’s what we got, so we can only be happy with the outcome,” Jytte Langhoff concludes.

Generally, we expected a user-friendly, intuitive certificate management solution with fast and competent support available—and that’s what we got

Jytte Langhoff, JN Data

JN Data services 35% of the Danish banking market and 50% of the Danish mortgage banking market. Among other services, their solutions include money transfer via online banking, use of debit cards, and use of MobilePay and Apple Pay.

JN Data is owned by Jyske Bank, Nykredit, Bankdata, SDC, and BEC. A total of 40.000 employees in the financial sector use systems operated by JN Data, meaning that capacity, response times, availability, and security are vital operational components.

Atea: We’re Never Just a Number in a Queue

With approximately 7,500 employees and 85 across seven countries, Atea is the largest Nordic IT infrastructure supplier, designing, implementing, and managing highly complex IT solutions.


Apart from providing deep expertise—the company’s 4,000 consultants hold a total of 7,500 technical certifications—Atea supplies customers with a complete selection of hardware and software from the world’s leading suppliers and technology companies.

New certificates are issued instantly

For the last 12 years, Atea has worked with TRUSTZONE in regards to their digital certificates as well as clients’ certificates:

Atea uses Managed SSL when managing their certificates, mainly because the platform allows new certificates for pre-validated domains to be issued instantly.

In the past: Inconvenient and expensive

Atea uses Customer Portal for clients’ certificates:

“Before we started using Customer Portal, we didn’t have any partner agreement in regards to digital certificates.

Back then, our clients had to order and handle certificates on their own.

We would advise them in terms of which certificates were required and how to install them.

Still, it would end up being both inconvenient, expensive, and very time-consuming,” says Theis Haubirk, manager of Infrastructure as a Service at Atea.

We are never just a number in a queue, which would be the case if we used a large CA. We get the attention we need

Theis Haubirk, Atea

An integrated part of infrastructure and workflow

The current setup allows Atea to offer digital certificates as an integrated part of the infrastructure that the company already designs, builds, and runs for its customers.

One key advantage of using Customer Portal is that Atea’s consultants can register new clients and issue the necessary certificates almost instantly:

“Customer Portal is accessible at all times. It’s user-friendly, and it offers a great overview of our customer’s certificates as well as insight into when certificates need to be renewed,” says Theis.

Fast-tracking of orders and qualified advice

When a new SSL certificate is issued, the mandatory validation process starts. Depending on the type of certificate, these validation steps can be more or less comprehensive.

Sometimes, a customer needs to accelerate their certificate validation. The fact that TRUSTZONE has an in-house vetting team makes this quick and straightforward:

“Vetting is effective when things need to go quickly,” says Theis.

Summing up the long-standing TRUSTZONE/Atea partnership, Theis describes the successful collaboration like this:

“We are never just a number in a queue, which would be the case if we used a large CA. We get the attention we need.

We get extremely qualified advice very quickly.”

We get extremely qualified advice very quickly

Casper Glasius Nyborg, Atea

As the leading provider of IT infrastructure solutions for businesses and public-sector organizations in the Nordic and Baltic region, Atea offers a full range of hardware and software from the world’s top technology companies.

By combining technology and vendor partnerships with skilled consultants, the company helps customers solve problems and get maximum productivity from their IT investments. In 2019, Atea’s revenue was NOK 37 billion.

Email Security With GDPR Compliance

New requirements and procedures

GDPR pronounces your rights in relation to the personal data that companies and organizations can collect and store within the EU:

For instance, it dictates that a company cannot refuse if you ask for insights into the data it stores about you.

You also have the right to be forgotten: You can now demand that an organization deletes all their data about you.

As such, GDPR sets new requirements for workflows and procedures to be carried out by employees working with sensitive data.

Additionally, the data protection regulation defines some purely technical requirements for our IT systems: As of May 25, 2018, data protection must be incorporated into the systems that process personal data.

This means that by design, systems must process and protect data in accordance with the GDPR. This, of course, applies to email systems as well.

GDPR and email security

Compliance with GDPR prevents you from being fined up to 20,000,000 EUR or 4% of the company’s total revenue globally.

However, in the email area, compliance also implies other business benefits:

More secure email systems counteract hacker attacks. Worldwide, we are currently sending about 280 billion emails a day.

A large number of hacker attacks lead back to infected emails: Viruses spread through clicks on malicious URLs or attachments.

Email gives rise to phishing attacks, Nigerian letters, and similar email fraud such as Business Email Compromises (the so-called BEC attacks) where a hacker sends an email with the manager of a company as the sender to fool money from a vendor to the company.

In one way or the other, all these attacks compromise personal data. This can give rise to enormous unforeseen expenses for the affected company or organization.

The solution

Luckily, it’s neither particularly difficult nor expensive to significantly improve security when it comes to email data protection:

S/MIME certificates like TRUSTZONE’s PersonalSign certificates are already supported by most email systems—including Microsoft Outlook, Thunderbird, Apple Mail, Lotus Notes, Mulberry Mail, and more.

Give emails a digital signature with S/MIME 

Via Secure/Multipurpose Internet Mail Extensions (S/MIME), a recipient can identify the sender of an email with certainty:

Let’s say you are an internet company that sells a subscription service. Often you will find that a customer changes his payment card and that the card that should pay your service therefore no longer works.

When that happens, you will have to ask the customer to update his payment information.

In that case, it will promote trust in your business if you are able to show the customer that it’s definitely your company asking.

In addition, it’s a clear business advantage that a hacker cannot snatch and abuse this email to lure payment information out of gullible customers.

Once the email is digitally signed, you will be notified immediately should someone try to forward the email in a modified edition.

The PersonalSign certificates enabling definite sender identification can be issued as a token of the individual employee.

In addition, a department in the company or the company itself can be issued as the sender of emails.

Depending on the certificate, issuing takes place through an identification process of varying levels.

By using the most authoritative certificates, you will subsequently be able to sign emails and office documents with the same weight as your signature has on physical letters and documents.

Protects personally sensitive emails 

When the S/MIME standard is used to encrypt emails, both the sender and recipient can rest assured that messages are not read by a third party—or changed somewhere during dispatch for that matter.

Only the recipient has the key that will decrypt the email and not even the sender will be able to decrypt it when sent with S/MIME.

The be-all, encrypt-all?

So, why not encrypt all emails?

Well, in order to do that, both the sender and the recipient would need to install the appropriate PersonalSign certificates.

Having said that, you should be aware that 100% security is never available.

Also in relation to S/MIME technology, you will be able to imagine a situation where a hacker steals a user’s private key and is able to decrypt personally sensitive data in an email.

However, this risk is mainly due to a lack of care from the key owner’s side. The technology itself will keep you safe if you are properly trained to use it.

Get in touch with us for a non-binding quote


Certificate Transparency

Guest article by Hanno Böck

What is certificate transparency? 

While the changes needed for server operators happen largely automatically, it’s good to know why Certificate Transparency was introduced, what it means for the ecosystem, and how it can be used to improve security, detect incidents, and help security research.

Let’s dive into a (quite detailed) account of Certificate Transparency:

Based on a simple idea

At the core, the idea is simple:

Every certificate used on the public Internet and trusted by browsers is stored in at least two public logs. Everyone can access these logs. That is Certificate Transparency.

To understand, however, why this system was introduced we have to look a few years back:

In 2011 and 2012 a series of hacks and incidents showed the vulnerability of the companies issuing the certificates, the so-called certificate authorities (CAs).

In early 2011 hackers had been able to issue rogue certificates from the certificate authority Comodo. These certificates were used in hacker attacks on services like Google, Yahoo, Skype, and others.

Later that year the Dutch certificate authority DigiNotar suffered from an even more severe incident: 500 rogue certificates were found. Some of them were used to spy on Iranian Gmail users.

DigiNotar was subsequently distrusted as certificate authority by all major browsers.

In 2012, the certificate authority Trustwave admitted to having sold an intermediate certificate that enabled its owner to sign digital certificates for virtually any domain on the Internet.

Trustwave said that the certificate was used within a private network as part of a data loss prevention system – in other words, to intercept Internet communications within a company.

This is a common, yet controversial, practice: Usually, it is done with a locally generated root certificate which is only valid within a company network.

Having an intermediate certificate from a trusted certificate authority allowed for a capacity of communications monitoring way above a ‘”need to have” level.

In the wrong hands, internet communication could be intercepted—also outside the company—without any of the communicating parties knowing it.

Mozilla subsequently discussed distrusting Trustwave as a certificate authority, but eventually decided against it.

An ecosystem in need of security improvements

Incidents like these created the impression that the TLS business was the wild west of the Internet.

Control of CA operations was very limited. There were a lot of CAs out there and if even one of them got compromised, their certificates could easily be abused to attack any TLS connection out there.

When that actually happened it often had little or no consequences for the companies responsible.

Some people discussed whether it would be best to get rid of the CA system altogether and start over with a new system.

However, alternatives like DANE, Convergence, or the Sovereign Keys project never gained any real traction and none of them got default support by modern browsers.

Usually, the alternatives had other problems that made them impractical in other ways.

Consequently, people started to think of ways to improve the certificate authority system.

This included measures like the creation of the Baseline Requirements – a set of rules agreed upon by browsers and certificate authorities.

But one of the most impactful changes to improve the CA system was invented by Google.

It was called “Certificate Transparency”(CT).

Certificate Transparency (CT)

CT is an open framework for monitoring the TLS/SSL certificate system and auditing specific TLS/SSL certificates.

At its core, it consists of several logs that store certificates. Anyone can access these logs.

The content can be extracted with a public API. Submission to logs is also open, though log operators can decide for themselves which submissions to accept.

While some logs accept all certificates issued by browser-trusted certificate authorities, others are restricted to certificates from certain time frames or specific certificate authorities.

Having these certificates logged enables both site operators and security researchers to keep an eye on certificate authorities.

A security-conscious web page operator can monitor the logs and compare the certificates they actively use to the ones appearing in the public logs.

This can also be outsourced:

A discovery tool like TRUSTZONE’s SSL360® will send you an email when a new certificate for a specific domain appears in the logs.

This is a powerful tool when monitoring the web for rogue certificates.

Let’s assume you operate a very sensitive service at example.org. By monitoring the logs you learn that somebody has issued a certificate you don’t know about for example.org.

Upon further investigation, it seems that the certificate has been issued by a certificate authority due to hacker involvement.

You raise an alarm, warn users and inform the public that most likely this authority has to deal with a security problem.

It is not only site operators that can benefit from checking the logs through. Security researchers constantly use Certificate Transparency data to identify oddities.

The Symantec distrust

In January 2017 Andrew Ayer found several suspicious certificates issued by Symantec. In one example he found a certificate issued to the names test.com, test1.com, test2.com, and so on.

These domains belonged to different people and companies. Therefore, it seemed highly unlikely that they were legitimately issued.

This incident turned fatal for Symantec. Further investigations uncovered that in may cases, the company had breached rules and issued illegitimate certificates.

Ultimately, the discoveries made via the Certificate Transparency logs led to a decision by browser providers to distrust Symantec root certificates.

Eventually, the company sold off their certificate business to competitor DigiCert.

Transparency mandatory for new SSL certificates

A crucial change happened in the spring of 2018: As of April 2018, the Chrome web browser requires new certificates to be logged.

Every certificate issued since this date must show two so-called Signed Certificate Timestamps (SCTs) to be considered valid.

Before this mandatory logging requirement, you could never be sure that certificates would make it into the logs. But now they are almost certain to do so.

As you may know, Chrome has the largest market share of all browsers. It’s not likely that anyone would use a certificate that is not accepted by this browser.

Bear in mind, though, that rogue certificates issued before April 2018 still can be used and not logged. Their timestamp can be backdated.

This will change as soon as certificates issued before April 2018 expires, that is in less than two years from this date.

Compliance with Certificate Transparency

So, what do web site owners have to do to be compliant with Certificate Transparency?

In most cases the answer is simple: nothing!

The reason is that certificate authorities usually put the Signed Certificate Timestamps directly into the certificate itself.

Thus, if you got your certificates quite recently, they are probably already compatible with Chrome’s new rules. There are other ways to deliver Signed Certificate Timestamps, but they’re more complicated and not used very often.

Secret hostnames don’t work anymore

Certificate Transparency has a side effect that many site owners may not be aware of.

It’s gotten much harder to keep your hostnames a secret:

If a company has an internal site, e.g. under the name internal.example.org, and gets a certificate for it, anyone can discover the existence of it simply by looking in the logs.

This can be prevented by using wildcard certificates that cover the root and all subdomains (e.g. *.example.org), but that is not always a practical solution.

Having secret hostnames was never a good idea to begin with, though. Hostnames are not encrypted in TLS connections and even if they were, the DNS query would still prevent them from really being a secret.

Nevertheless, Certificate Transparency makes it much easier to uncover hidden hostnames.

Bug finders, but also attackers, use the capability to find out which subdomains companies run.

The author of this article presented a way to abuse this capability to attack common web applications like WordPress during installation. The method was presented at last year’s Def Con conference:

While Certificate Transparency allows an attacker to learn about new certificates showing up it also often points to new websites being created.

These sites are often not fully installed when receiving their TLS certificate.

By scanning them, a hacker may discover ongoing unsecured installation processes. These can be used to hack the websites in question.

A search engine for certificates

A popular site related to Certificate Transparency is crt.sh. It’s a search engine for certificates.

Try it out yourself: By typing in %.trustzone.com, you can see all the certificates for TRUSTZONE subdomains. If you try this for your own domain, you’ll see the certificates logged for it.

Just looking at the list may be helpful.

You may discover services that you forgot all about and that runs without the knowledge of your company.

This is what happened to the security team at Facebook:

The team started looking into the Certificate Transparency logs and found that there were unexpected certificates for Facebook’s domains.

These were issued by a hosting company with the agreement of other Facebook employees but without the knowledge of the security team.

Certificate Transparency is one of the largest changes in the TLS certificate ecosystem in recent years. It has many security advantages, but some unexpected side effects: It can be useful for attackers as well. Both users and web site owners should be aware of that.

Get in touch with us for a non-binding quote