You are staring at a certificate order form, or maybe a CSR generator, and there is a field labeled “Common Name” with no explanation of what to type into it. 

Guess wrong, and your certificate either fails to issue or works but throws a mismatch warning at your visitors. 

You want to know, in plain terms, what this field wants from you.

Here is the answer. 

The Common Name is simply the one exact domain your certificate protects, written without http, without www, unless that is the actual address, and without anything else attached to it. 

Get that single detail right, and everything else about ordering an SSL certificate gets much easier.

The Short Answer

Think of the Common Name as the name tag on your certificate’s digital passport.

 It states, in one line, exactly which website this certificate belongs to and nothing more. 

When your browser lands on a secure site, it checks the address in the bar against this name tag to confirm it matches.

If you are securing example.com, your Common Name is example.com. If you are securing the www version specifically, it is www.example.com. 

A certificate treats these as two different addresses, even though they point to the same site in a browser’s address bar. 

As a result, it trips up more people than almost any other part of the SSL setup process.

This one distinction accounts for a large share of the confused support tickets certificate providers see. 

Someone orders a certificate for their bare domain, assumes it automatically covers the www version too, and only discovers the gap when a visitor lands on the wrong one and sees a warning instead of a padlock.

What the Common Name Actually Looks Like

The Common Name is not a web address in the way you would type one into a browser. It excludes the protocol entirely, so neither http:// nor https:// belongs in this field. 

It also excludes port numbers and file paths, meaning something like example.com:8080 or example.com/login is incorrect, no matter how tempting it is to include that extra detail.

What you are left with is a clean, bare domain name. 

For a single site, that looks like example.com or www.example.com, depending on which one your visitors type or land on. 

For a wildcard certificate designed to cover every subdomain under one name, it takes the form of an asterisk followed by the domain, written as *.example.com.

This format has to match the exact server name where you are installing the certificate. 

If you are securing a subdomain like api.example.com, your Common Name needs to be api.example.com specifically, not the bare example.com. 

A certificate issued for the wrong version of your domain will not automatically cover the one your visitors are reaching.

It helps to think of the Common Name as answering a single, narrow question: which one address is this certificate for? 

It does not describe your business, your hosting provider, or anything about the content on your site.

It is purely a label pointing at one specific domain string, formatted in one specific way.

Why Browsers Care So Much About This One Field

This single field exists to answer one question for every visitor: Is this really the site I think it is? 

Without that check, a certificate would prove that some encryption is happening, without confirming which website is on the other end of it.

Every time someone visits your site over HTTPS, their browser compares the address in the bar against the name recorded inside your certificate. 

When those two match, the connection proceeds quietly with a padlock icon and no interruption.

When they do not match, browsers do not treat this as a minor inconsistency. 

They block the page with a full warning screen, telling the visitor the connection may not be private and that continuing could be risky.

This mismatch happens more often than you might expect, usually for a simple reason rather than anything malicious. 

A site owner secures www.example.com specifically, but a visitor types the address without www, or an old link points to the bare domain. 

The certificate is technically valid, just not for the exact address the visitor landed on, and the browser has no way to know that was an innocent mismatch rather than something suspicious.

The warning itself is designed to be hard to miss and, in most browsers, mildly inconvenient to bypass on purpose. That design is intentional. 

A mismatch is exactly the pattern a genuine man-in-the-middle attack would also produce.

So browsers treat every mismatch with the same level of caution regardless of how innocent the actual cause turns out to be.

For a small business owner, the consequence is straightforward and costly. 

A visitor who sees this warning has no way to distinguish an innocent www mismatch from a genuine attack, and most will leave rather than take the risk. 

The technical cause behind the warning carries far less weight with them than the fact that their browser just told them something was wrong.

Common Name vs. Subject Alternative Name: Why This Field Is Becoming Legacy

Here is where a lot of outdated explanations of the common name lead people astray. 

The Common Name field can only ever hold one single entry, either one exact domain or one wildcard pattern. 

It was never designed to cover multiple different addresses on a single certificate.

That limitation is exactly why the Subject Alternative Name field, usually shortened to SAN, was introduced. 

SAN allows a single certificate to list several domains at once, something like example.com, www.example.com, and shop.example.com, all covered under one certificate rather than requiring a separate one for each.

This solved a genuine practical problem for anyone running more than one address off the same domain. 

Before SAN existed, covering a main site and a handful of subdomains meant either:

• Buying and managing several separate certificates.

• Accepting that some of those addresses would go unprotected. 

SAN turned that into a single certificate with a list attached to it. The shift has gone further than simply adding an option.

The CA/Browser Forum, the industry group that sets the rules that certificate authorities and browsers follow, now requires that whatever value goes into the Common Name also gets duplicated inside the SAN field. 

In practice, this means the SAN field has become the actual reference browsers rely on for matching, while the Common Name survives mostly as a legacy holdover from an older version of the standard.

Some newer browser and system updates have already started deprioritizing the Common Name field entirely in favor of checking SAN exclusively. 

The Common Name has not disappeared from certificates yet, and knowing what it means still helps when you are filling out a CSR. 

But it is no longer doing the heavy lifting it once did on its own.

Field	What It Covers	Current Role
Common Name (CN)	Exactly one domain or wildcard pattern	Legacy field, still present but no longer the primary match
Subject Alternative Name (SAN)	Multiple domains, subdomains, or wildcards on one certificate	The field browsers check for hostname matching

Common Name Mistakes That Break Certificates

Most Common Name problems trace back to a handful of repeatable mistakes, and knowing them ahead of time saves you a reissue request later.

Mixing up the www and non-www versions of your domain is the most common one

If your Common Name lists www.example.com, but visitors regularly reach your site at the bare example.com, half your traffic sees a mismatch warning. 

The fix includes both versions, either by choosing the version your DNS redirects visitors to, or by making sure both appear somewhere in the SAN field.

Typing in a full URL instead of a bare domain is another frequent slip

Copying https://example.com directly from your browser’s address bar into a Common Name field feels natural. 

But the protocol prefix does not belong there and will cause the request to fail validation.

Leaving out a subdomain that later gets added to the site is a related, quieter problem. 

A certificate ordered when your site only had a main domain will not automatically extend to a blog or shop subdomain added months later. 

This is unless that certificate was set up as a wildcard from the start. 

Reviewing which addresses your certificate covers whenever you add a new subdomain avoids this gap entirely.

Ordering a single-name certificate for a domain that needs subdomain coverage 

 If your setup includes:

• A blog

• A shop

• An app subdomain in addition to your main site

A single Common Name covering only the bare domain leaves those subdomains completely unprotected.

 It happens even though the site owner assumed the whole domain was covered.

Getting This Right When You Order a Certificate

None of this needs to become guesswork on your end. 

At Truehost, we  issue SSL certificates for the Kenyan market with the Common Name and SAN fields configured correctly as part of the setup, rather than leaving you to fill in a form that assumes you already know the difference between the two.

A Domain Validated certificate through Truehost starts from KSh 750 a year and covers your exact domain correctly from the moment it is issued.

If your setup spans multiple subdomains, wildcard certificates are available from around Ksh 1,000 a year. 

They automatically extend coverage across every subdomain under your main name instead of leaving you to track down which specific addresses need their own separate certificate.

Every certificate includes 256-bit SHA-2 encryption and a 7-day money-back guarantee, and support is available directly if you are unsure which version of your domain, www, or otherwise, should be listed as the primary name. 

Getting this one detail right from the start avoids the mismatch warnings and reissue requests that come from guessing.

Get Your SSL Setup Right the First Time

A wrong Common Name does not fail quietly. It shows up as a security warning in front of your visitors, at the exact moment you are trying to earn their trust rather than lose it. 

Knowing this one field is a small detail with an outsized effect on whether your certificate protects the address people are using to reach you.

Do not leave this to guesswork on your next certificate order. 

Set up your SSL certificate through Truehost and get your Common Name and SAN fields configured the first time, with support on hand if anything about your domain setup is not straightforward.