A World Where SSL Certificates Do Not Allow Organizational Unit Fields

There’s a healthy discussion in the world of public SSL certificates: the OU field. Standing for Organizational Unit and currently unrestricted in its use, many IT professionals feel the data often placed in this field leads to confusion. It is an unauthenticated field that may soon be greatly restricted in usage — or even eliminated altogether.

Why have so many public SSL certificate users turned against the OU field? To better answer this question, let’s first take a look at some of the ways in which the OU field has historically been used.

The Original Intent of The OU Field Seemed Sensible Enough

While there are no issues surrounding OU fields with private certificates – that's actually a very sensible thing to do – the controversy centers around public certificates.

The OU field has been a component of SSL certificates since the beginning of the internet age, going all the way back to the 1990s. Its original intent was for a placeholder field in which companies could place data that would help them to make sense of a certificate and how it was meant to be used. Reference data for billing is often placed in the field so that finance teams know which cost center to attribute the purchase. Other snippets of data that the OU field might be used to convey include:

• The department of the organization that uses the certificate

• The party that paid for the certificate

• The project for which the certificate was generated

• The intended use of the certificate

So, the OU field might contain data that is rather vague and nondescript, something like “infrastructure” or “UK” (indicating that the UK office is using it). But it’s a completely unauthenticated field that can, in fact, contain virtually anything that the issuing administrator might decide to put in the field. That’s where problems begin.

Sowing Seeds of Confusion In The OU Field

Using the OU field to convey any information organizations want can lead to trouble. Here’s one example: Let’s say that an organization’s client is the United States Department of Defense. That’s what would be revealed by the OU field: Department of Defense.

Why is that a problem? There is no set standard dictating the type of data that can be inserted in the OU field, resulting in confusion. In the example above, the “Department of Defense'' in the OU field might be confused as the organization to which the certificate was issued, even though it was meant to refer to the client of the organization that requested the certificate.

The wide-open, non-standardized use of the OU field offers lots of opportunities for confusion. In the world of cybersecurity, confusion is most decidedly NOT a good thing.

It’s Time For A Change

In the early days, there were far fewer certificate authorities (CAs) issuing certificates than there are today. The original intent was the few CAs in operation would be carefully hand-checked by browsers, resulting in a high degree of confidence that the CAs were doing everything as securely as possible.

Back then, cybercriminals attacked the integrity of certificates with far less advanced tactics. Today, there’s a growing sense in the cybersecurity world that the OU field has become sort of a virtual vestigial organ, like an appendix — it’s there, but it’s not really needed, and not doing much of anything that’s useful. There are alternative means of conveying the same information.

It’s only a matter of time before the CA Browser (CA/B) Forum prohibits OU fields.

Prepare To Do Without OU Fields

Every organization that uses the OU field for its own specific needs should prepare now for the abolishment of the OU field. It’s time to find alternative means of conveying the information, possibly a checkable value or identifying attribute, currently saved in that spot.

Waiting until the OU field is gone will likely result in a bit of stress, confusion, and maybe even chaos for companies that haven’t prepared for the change. Quite simply, the OU field just doesn’t reflect the precision standards required for maintaining integrity in the face of the modern cybersecurity landscape. Learn more in the Root Causes podcast episode, The Trouble With OU Fields, here.