Security Certificates Part 1

February 5, 2016 David Lover

Security is a REALLY hot topic lately in our world of Enterprise Communications. There are a ton of aspects to security. But one of the more foundational aspects is simply how things talk to each other. Are you sure you’re talking to who you think you are? And can anyone see what we’re talking about? These two things, “identity” and “privacy”, are so critical to modern communications. You live it every day. Something as simple as seeing HTTPS:// in a website URL, tells you that your browser and the webserver have negotiated these concepts and can communication successfully and safely. It is also what can completely kill communications if done incorrectly.

Today, I wanted to start a conversation about the piece of security that provides that identity and privacy. It’s called a Security Certificate. These things have been around forever. Ok, maybe not forever. It’s more like July of 1988, when the common standard for defining and using Security Certs, called X509, was started. Good and bad, the typical telecom person has been allowed to be oblivious to them. But that is changing rapidly. I’ve found out how VERY little is known about this topic in our industry of Enterprise Communications. So, I thought I’d take a crack at explaining the basic concepts of security certificates.

For Part 1 of this topic, let’s look at the “Identity” part first. We’ll do “Privacy” in Part 2. When we think of identity, you’re literally thinking of identification. Who are you? In terms of servers and network devices, a Security Certificate states a server’s identity in terms of Common Name (generally the Fully Qualified Domain Name or FQDN of the device), Organization, Organizational Unit, etc. All of this gets embedded into a Certificate that the server makes available, telling you who it is. That way, when the client accesses the server, the server will show it’s certificate, verifying that “Yes, I am who you think I am”.

Hopefully, you’re saying to yourself “Hey, wait a minute, how do we know that that certificate is valid?” This is where “trust” becomes a key part of this. Sure, you can tell me who you are, but do I trust that you’re telling me the truth. How do we ensure Trust? Let’s think about how we do it in our regular life. Think of a very important document that you’ve signed. When it’s important enough, the owner of that document will ask for proof that it was actually YOU who signed it. We do that with a Notary Public. Some higher power has authorized individual people, called Notary Publics to act on their behalf to check the credentials of the person signing a document to prove that you are who you are claiming to be. We do this same exact same thing with X509 Certificates. We don’t call them Notary Publics though. We call them Certificate Authorities or CA’s. They literally take a server’s identity certificate and digitally sign it. Technically, this is done by having the server generate a Certificate Signing Request, or CSR. You then send this CSR to the Certificate Authority, and they “Sign” it.

Again, I hope you’re thinking “But why should I trust the Certificate Authority?” This one’s easy. It’s because you’re told to. When you send a CSR to a Certificate Authority, you get TWO certificates back. One is the signed certificate that verifies the identity of the server. And one is the CA’s certificate that says “Trust me”. You load the Identity Cert onto the server. And you give the CA Certificate (sometimes called a Root CA Certificate) to the clients who will be talking to the Server. So, as an example, when an Internet browser, such as Chrome, goes to, the clients asks to see a copy of the server’s Certificate. It first looks at it to see if it was signed by one of the Certificate Authorities it has a Root Certificate for. If it does, then it “trusts” the server’s cert and then checks to make sure that the cert’s ID values match up with what the client was expecting. If so, then communication proceeds and the browser gets the information needed to display the website.

The next big question is how many Certificate Authorities are there? Actually, based on this model, anyone can be a Certificate Authority. Heck, I run Windows Server Essentials 2012 in my house (for music, video streaming, document storage, and centralized PC backups). Even my personal Windows Server, can be set up to be a Certificate Authority. I tell the computers in my house, to trust my server by simply loading the Root CA Certificate into their “Certificate Trust Store”. As you can imagine, that would kind of suck, if every server was its own Certificate Authority. You’d have to install a TON of Root CA’s on each client. Fortunately, there are some “Public”, “well known” Certificate Authorities out there. And they work with the big OS’s companies (like Apple, Microsoft, Red Hat, etc) and have their Root CA certs pre-loaded on their operating systems.

For example, if you were to go to your PC, and go to your Control Panel, then go to Administrative Tools, then look for the “Manage Computer Certificates”. In here you can look folder for “Trusted Root Certificate Authorities” section, and find certs that came pre-loaded from the manufacturer. You’ll see Certificate Authorities like DigiCert, Entrust, GeoTrust, Thawte, VeriSign, etc. So, if a company goes to one of these public Certificate Authorities to have them sign their certs, they don’t have to worry about issuing the Root CA Certs to the clients, as those Root CA certs are already preloaded. This is also true for modern smartphones. Your iPhone has the exact same type of “Trust Store” with these Root CA certs pre-loaded. As you can imagine, this convenience isn’t free. You have to pay these Certificate Authorities for each and every identity cert that they “sign”. This could be anywhere between $70-300 per year, per cert depending on the CA company. That can get very expensive. AND public certs have a relatively short life. Just like your Driver’s License or Passport expires, so do signed certificates. 1 to 2 years is a very common expiration of a public certificate. Think about how expensive that could get considering the large numbers of certs that a typical company needs to buy.

This is actually where you could create your own “Enterprise” Certificate Authority to sign your own certs. Not only are they free, you can usually set the expiration to be significantly longer than a public cert. The problem is that no one else will trust your certs. Mainly because they don’t have your Certificate Authority’s Root CA Certificate installed. So, while you wouldn’t expect anyone outside of your organization to trust you, you should certainly expect your own clients to trust it. We have enterprise network tools that allow us to “push” our own enterprise root CA certs to our clients. 

You can see this is a pretty complex conversation. Sadly, this just scratches the surface. An infrastructure’s use of certificates is a topic in and of itself. Avaya, as an example, has tried to isolate customers from this complexity. But by doing this, they created a little bit of a security flaw. They let everyone borrow their enterprise certs and their Certificate Authority. These “default” certs were issues a relatively LONG time ago, with weaker encryption keys (that we’ll talk about another time). Customers have always had the option to replace these with their own enterprise certs or even publically well-known certs. But due to its complexity, and complete lack of knowledge in the telephony team, no one ever bothered to do so. Avaya’s now saying “Guys, come on. It’s time. Stop using our certs. Go get your own”. We’re currently working through this ourselves to better understand how to provide consultation to our customers to help them through this. And while I’ll definitely continue to help you learn more about this topic, Google can also definitely be your friend. There’s a TON of info out there. There’s nothing proprietary about Avaya’s use of x509 certs. IT generally has TONs of cert knowledge. They manage this on a very regular basis. Even here at Arrow Electronics, we have a dedicated resource that manages all of our enterprise certs and facilitates the acquisition of our public certs.

I hope this helps to get you started in the world of Security Certificates. Stay tuned for more on this topic!

About the Author

David  Lover

Vice President, Strategy and Technology

David Lover leads the strategy for our core Enterprise Communications portfolio. He focuses on products and solutions to address the customer needs of Unified Communications and Collaboration, Customer Experience, CEBP, and End-User Adoption.

David works closely with the product marketing and development teams of our top partners to understand their strategy, and while representing Arrow SI and their customers, collaborate with those teams to provide guidance and feedback to shape the future direction of those partners’ portfolios. He uses these relationships and set of product knowledge to work with Arrow Systems Integration teams to be in alignment with the total portfolio strategy. As a member of Arrow Systems Integrations executive leadership team, he works with every part of the business.

More Content by David Lover
Previous Article
Previewing Enterprise Connect 2016
Previewing Enterprise Connect 2016

Next Article
Weighing in on Avaya Aura Media Server 7.7
Weighing in on Avaya Aura Media Server 7.7

Want to learn more?

Contact Us!