Infrastructure / Security and Identity / Public-Key Infrastructure

A certificate proves one's identity. But it must still be valid.

A public-key infrastructure is evaluated on the day a certificate expires, not on the day it is issued.

An internal certificate authority issues the certificates that identify your computers, servers, and employees: this is what allows a workstation to join the network without a password, an internal website to open without a warning, and a message to be signed. We design these systems with an eye toward what they will become in three years—not just for the initial demonstration.

Talking About Your Certificates How We Do It

Inventory Before Authority Knowing which services depend on which certificate is what prevents an application from crashing one morning.

Automatic Renewal by Default A certificate that is renewed manually will eventually fail to renew.

The Offline Root The root authority remains offline and disconnected from the network. It’s not very convenient, and that’s what makes it trustworthy.

What leads a company to install one

Almost never the subject itself. It’s another project that requires certificates, and one that comes to a complete halt because it cannot issue them.

The wireless network still requires a shared password

The same catchphrase has been circulating for years; it’s written on a piece of paper in the meeting room, and no one ever changes it when they leave the company.

A certificate stored on the computer replaces this password: the user no longer has to enter anything, and if a device is removed, it loses access.

An internal website displays a security warning

Employees have gotten into the habit of clicking “continue anyway,” which leads them to ignore the very warning that matters most.

A certificate issued by your own authority—one that is recognized by your computers—will make the warning disappear for good.

Conditional access requires a recognized device

You want a service to open only from a company computer. But the computer still has to be able to prove it.

The certificate is what allows the machine to identify itself without asking the user for anything.

A contract requires signed messages

A customer, insurer, or regulator may require that certain messages be signed or that documents bear a verifiable signature.

Certificates issued to individuals make it possible to sign a document and, more importantly, allow the recipient to verify the signature.

An authority already exists, and no one knows who runs it anymore

It was installed for a specific project on a server that has since changed roles, and its root certificate is about to expire.

This is the most common scenario, and the one that requires the greatest caution: you don’t replace one authority by eliminating the old one.

What Certificates Are Used For

A single authority supports uses that are seemingly unrelated. That is why it is designed once and for all, rather than being recreated for every project that needs it.

Join the company's network

The wireless network and remote access recognize the device by its certificate, without the need to circulate a shared password.

Open an internal website without a warning

Internal applications, administration consoles, and network equipment display a certificate that your computers recognize.

Proving that a computer belongs to the company

This is the basis for the "managed device" requirement, and it's what sets your laptop apart from a stranger's.

Signing and Encrypting Messages

The recipient verifies that the message actually comes from the person it claims to be from and that it has not been altered along the way.

Signing Documents

A verifiable signature on a document, when required by a contract or a regulatory obligation.

Encrypt Disks and Backups

Laptop encryption relies on keys, and their storage and recovery are designed to work together.

What Causes an Installation to Fail Three Years Later

A new system always works. Problems arise during the first update, when the person who set everything up has moved on to a different position and nothing has been documented.

No one knows what depends on what

There is no inventory of the certificates issued or the services that use them. The first enforcement ruling reveals the list, as a matter of urgency.

Renewals are processed manually

They remain valid as long as someone remembers them. A vacation, a departure, or a busy week is enough to let a production certificate expire.

The root authority remained active

It is used for daily operations, is connected to the network, and therefore carries the same risk as any other server.

The revocation list is unreachable

When it is no longer published at an accessible address, connections begin to fail without the error message specifying the cause.

The day a certificate expires

An application crashes, or the wireless network stops accepting computers, and the error message almost never specifies which certificate is the problem. The time spent troubleshooting far exceeds the time it would have taken to renew the certificate.

That is why we implement inventory and automatic replenishment at the same time as authorization, rather than as an improvement to be considered later.

How We Do It

Five steps, in this order. The fourth step is the one that determines whether the installation will hold, and it’s the one people skip when they want to go fast.

Identify current and planned uses

The following will require a certificate within three years: wireless networks, remote access, internal sites, devices, and digital signatures. This list determines the structure, and we won’t revise it later.

Conceiving of Authority, and Its Offline Roots

A dormant root certificate, outside the network, used solely to sign the authorities that are active. This restricts its use, and that is what makes the entire system trustworthy.

Post what needs to remain accessible

Revocation lists and publication points must be accessible both internally and externally for the entire lifetime of the issued certificates.

Automate issuance, renewal, and inventory

Computers and servers receive and renew their certificates automatically. Each certificate issued is registered with the service that uses it and its expiration date—it is this inventory that is missing wherever we respond to emergencies.

Write the procedure and have someone else execute it

Issuing, revoking, or renewing the root certificate: The procedure is attempted by someone who was not involved in the installation. If they are unable to complete it, the process is not finished.

What You Need to Know Before Making a Decision

Four questions that come up in every project, and the last one is the one we prefer to address early on.

Do I need a dedicated server?

In practice, at least two: a root server that remains powered off between uses, and at least one authority that issues certificates on a daily basis. The root server can be a virtual machine that is started up for a few hours a year.

Can we use a public certificate instead?

For a website accessible from outside the network, yes, and that’s often preferable. To identify thousands of internal devices, no: no public authority issues this type of certificate.

What if an authority already exists?

It is reactivated rather than replaced. Deactivating the old one invalidates all the certificates it has issued: reactivation occurs through overwriting, until the old certificates expire on their own.

What We Don't Do

We don't set up a certificate authority just for a one-time, temporary use. When a single service needs a certificate, a public certificate or a managed service is less expensive to maintain—and we make that clear up front.

Tell us how you plan to use it, and we'll let you know what you need to install.

The first meeting is meant to identify what will require a certificate and to decide whether an internal authority is the right solution. During this meeting, you’ll meet the people who will be doing the work.

Talking About Your Certificates See Conditional Access

Renens +41 21 806 37 15 · Sion +41 27 552 00 22 · Châtel-Saint-Denis +41 26 322 59 05