SSL/TLS certificates: What you need to know

Firefox's new way of handling SSL/TLS certificates is fueling significant debate due in large part to misunderstanding the SSL/TLS certificate process. I'd like to help clear up the confusion by explaining what SSL/TLS certificates are and how they work.

The problem, quite simply, is that human intervention is required to verify the authenticity of certain types of certificates. This became apparent when Mozilla changed how its newest Web browser (Firefox 3) handles Web sites with expired or self-signed SSL/TLS certificates. The article "New SSL Policy in Firefox Hurting Tens of Thousands of Sites" on Pingdom's Web site does an excellent job of explaining the changes:

"If you visit a Web site with either an expired or a self-signed SSL/TLS certificate, Firefox 3 will not show that page at all. Instead, it will display an error message, similar to any other browser error (for example a "page not found" 404 message). To get past this error page, users have to go through four different steps before they can access the Web site, which from a usability standpoint is far from ideal."

The error occurs because Mozilla has decided to take SSL/TLS Web page security to the next level, challenging any certificate that isn't in the Web browser's certificate database, has incorrect information, or is expired. This is a good thing; it will make Web browsing and online commerce a great deal safer. In order to understand why, let's take a quick look at the SSL/TLS process.

SSL/TLS processes

SSL/TLS consists of two important and independent processes: authentication and data stream encryption. With today's tough Internet environment, it's vital to have strong encryption to protect the data packets as they travel to their destination. Thank goodness that using a SSL/TLS VPN is secure and working properly. The weak link, I'm afraid, is part of the authentication process, so I'd like to focus on that.

Authentication is all about digital certificates, so it might be best to start by describing what a digital certificate is. A digital certificate is a data file that contains information about the Web site's certificate holder and is used to verify that the Web site is indeed what it portrays to be. The Web server's host name, issue and expire time, and the public key for the Web server are just a few of the details contained in a certificate. To look at certificates installed on your computer, use the following paths:

Internet Explorer: Tools | Internet Options | Contents | Certificates

Firefox: Tools | Options | Advanced | Encryption | View Certificates

The following image shows certificate details:

I can hear everyone saying that's nice, but it doesn't help me at all. I'm happy to say that understanding the exact details isn't important, but the overview explanation will help make the following concepts easier to fathom. Just remember -- digital certificates verify the identity of the Web server to the Web browser that's trying to set up a SSL/TLS connection with the Web server.

Different types of SSL/TLS certificates

There are two major categories of certificates, trusted and untrusted. Trusted certificates are those residing on the Web browser and signed by a trusted certificate authority (CA). In order to understand this, let's say I want to create a trusted Web server SSL/TLS certificate that's signed by VeriSign, a well-known and respected CA. The following example will show the steps I need to take:

I create a certificate request on my Web server for www.mpksecuresite.com; doing so initiates a PKI key chain consisting of a private/public key combination.

I create a certificate request required by the signing CA, which in this case is VeriSign. The request includes domain name (distinct DNS name) of the Web server, distinct IP address, the public key (needed for signing and verification), and locality information. VeriSign will also ask for very specific information as it tries to verify that I'm the rightful owner of the domain.

The Web server signs the request with the private key, and it's sent to VeriSign.

Responsible CAs such as VeriSign then go through a great deal of effort to make sure the request is valid. Once satisfied, VeriSign also checks the validity of the key pair, since the request contained the public key and was signed using the private key (both developed in step 1).

Everything checks out, so VeriSign adds its pertinent information to the certificate and signs the request using VeriSign's private key.

VeriSign sends the certificate back to me, and I install it on my Web server.

Now my Web server has all the required components to set up a SSL/TLS connection with Web browsers. So let's take a look at how a Web browser goes about the SSL/TLS certificate exchange.

Web server/Web browser certificate exchange

Begging your indulgence, I'd like to continue using the above example to explain the certificate exchange between the Web server and Web browser. Since everything is now in place in the example, I can set up a test SSL/TLS connection. Let's see what happens by following the certificate exchange steps during a SSL/TLS connection setup:

I open my Web browser and type the URL https://www.mpksecuresite.com. Through the normal TCP/IP process, the Web server for www.mpksecuresite.com receives the Web page request.

The Web server for www.mpksecuresite.com responds by returning the certificate for mpksecuresite.com back to my Web browser.

My Web browser runs several checks, including certificate expiration and host name on the certificate.

My Web browser notices that the certificate from the mpksecuresite.com Web server was signed using VeriSign's private key. My Web browser immediately checks its certificate database to see if it has VeriSign's certificate information.

The Web browser locates VeriSign's certificate information. My Web browser then uses the public key found in VeriSign's certificate information to validate the signature on the certificate sent by the mpksecuresite.com Web server. Please remember that the certificate from the mpksecuresite.com Web server was signed using VeriSign's private key.

The certificate signature checks out. My Web browser knows VeriSign is a trusted CA, so it now trusts the mpksecuresite.com Web server as well.

That's how a SSL/TLS certificate exchange works. If you remember anything from the above process, it should be step 4 and the reasons why my Web browser trusted www.mysecuresite.com:

My Web browser lists VeriSign as a trusted signing CA.

VeriSign verifies that www.mysecuresite.com is what it claims to be, so my Web browser trusts the Web site as well.

It's vital to realize there's a pre-installed list of trusted certificates on every Web browser. This is done to set up a "chain of trust." This chain of trust starts with the Web browser developers, who include this list of trusted signing CAs in the Web browser installation program. So, it's automatically installed and presumed to be secure and accurate.

Therefore, if everything is as it should be (Web sites using certificates signed by trusted signing CAs) the whole SSL/TLS connection process is automatic. In fact, so automatic that we tend to become complacent about whether or not the connection is indeed encrypted and authenticated. When the automated process breaks, we get into trouble as exemplified by the new Firefox Web browser.

Self-signed certificates aren't automatically trusted

Self-signed certificates are the next most widely used certificates and belong to the untrusted category. This type of certificate requires manual approval and installation on the Web browser. It might be best to walk through a SSL/TLS certificate exchange with a Web server that's using self-signed certificates:

I open my Web browser and type the URL https://www.mpkselfsign.com. Through the normal TCP/IP process, the Web server for www.mpkselfsign.com receives the Web page request.

The mpkselfsign.com Web server sends the self-signed certificate for www.mpkselfsign.com back to my Web browser.

My Web browser runs several checks, including certificate expiration and host name on the certificate.

My Web browser checks its certificate database to see if it has certificate information for www.mpkselfsign.com.

Since I have never been to this Web site, there isn't a certificate in the Web browser database. So the process stops right here and a window (like the one below) pops up asking me what I want to do.

This is where it gets complicated. I have to decide whether I trust this site or not. I can look at all the certificate information and make a decision from that or I can do further research to increase my confidence that the certificate is real. The only way to truly validate the certificate is to get a copy of the self-signed certificate via some other trusted method (fax, e-mail, or even snail mail) and manually verify the electronic certificate with the one you asked for.

I realize it's very cumbersome, but it's the only way to positively determine the validity of a self-signed certificate. I also know that once the window pops up asking whether to accept the self-signed certificate or not, most people automatically accept the certificate. They want to get to the Web site, all the time wishing this window would just go away.

Firefox 3 and raising the bar

It doesn't take much effort to visualize the potential attacks that can be precipitated by malicious self-signed certificates. This is why the people at Mozilla took a stance, and I agree with them. Just raising user-awareness of what it means to automatically okay a self-signed certificate is a huge leap forward.

Final thoughts

Thanks for reading through yet another long article. It's a tough topic to understand completely, but that's not required. Everyone just needs to know what his or her options are when the "Unknown Authority" window pops up in the Web browser.

Michael Kassner has been involved with wireless communications for 40 plus years, starting with amateur radio (K0PBX) and now as a network field engineer for Orange Business Services and an independent wireless consultant with MKassner Net. Current certifications include Cisco ESTQ Field Engineer, CWNA, and CWSP.

About Michael Kassner

Information is my field...Writing is my passion...Coupling the two is my mission.

Great article Michael. I like your one on Perspectives as well. I installed that today and will keep an eye on it over the next few weeks.
Some useful feedback on using trusted CA for public facing to allow internal un-trusted certificates to be safely downloaded for home working staff.

A very good article showing the ever raging battle between security vs. convenience. I do understand the monitary issue that some organizations have with paying money to verisign or some other CA to have them sign CSR's. Working for a school district and because of the boards policy, the certs we do purchase, must expire every year. So, after a while, we have lots of certs to renew every year. It is a pain.
My thoughts are:
1) You can get your own CA. Any MS server can install the CA service and you can sign your own certificates. Even Novell's Netware has this feature.
2) When to use an Internal CA vs. a public CA like Verisign? After reading this article and many of the posts, I am thinking that any Internal web service that is https, we will be using our own CA that we can push out to all of our workstation's browsers anyway. For those servers that are public, like our webmail, webserver and guest wireless authentication server, we probabley ought to use a public CA because it is those services that the public will be using.
Thanks for the article, it got me thinking of changes we need to do.

is NOT a good thing.
The CA's listed are issuing certificates that end users see as confirmation that the site is good to do business with because they have been paid to do so.
In essence, the CA's are saying this is a good person / company, because they have been paid to say so, just like having a famous person endorse a product in a commercial.
I agreee that SSL/TLS is important to protect data being transmitted online, but I completely disagree with the whole trusted CA list.
There is no ... oversight for the CA's, there is no regulations requiring any sort of verification, no ... penalties if the site / person does rip off their clients because they had X CA issue a cert.
pay me $4,000.00 US / year [ Verisign's rate for top cert ] and I'll tell everyone you are good to do business with also.
just as VALID as any other cert.

I would agree that it is a worthwhile exercise, if CA signed certificates really required much more than just the money to buy one. As it is, most CAs are little more than a tax on internet encryption, as they can't be relied on to get it right anyhow.

I get it, I understand the rational but one thing that is missing is the legitimate use of seflsigned certs. Remote access, corporate webmail, accessing firewalls, secure applications such as antivirus etc all have a legitiamte need to set up a secure session. Many times these need to be set up with accounts that only have user access.
This is a substantial road block for many users who have a legitmate need to access private systems (that have no need of verisign to validate the authenticity of the certificate.
Soon there will be utilities that automate the 4 step process then we're right back where we started.
The only long term answer is education, education, education.

I've seen that with our own WiFI authentication system and I must say it is a pain, but the fact is that it's a great way to protect end-users and consumers from potentially bogus websites. Can't really argue here on security.

I maybe wrong, but I think I must have not explained a few concepts very well and for that I apologize.
I understand about how encryption is essential to avoid sniffing of personal information when visiting Web sites. I still submit there's a more important purpose to SSL than encryption and that's authentication.
From the comments, it appears that we are forgetting about making sure the end point that the SSL VPN is attaching to is the actual one we asked for. The only way that happens, using SSL/TSL VPN, is if the certificate is undeniably valid. That's really hard to do and using trusted signing CAs such as VeriSign or EV certificates is a step in the right direction.
I'm just trying to point out that there are precious few ways to make sure the certificate is for real. I'm just as guilty as the next. I have on more occasions than I care to admit have just OK'd a self-signed certificate. I've been lucky though.

I think that the major mistake people make is in assuming that any site with an SSL certificate is who they say they are.
An unsigned SSL certificate doesn't guarantee anyone's identity. It guarantees that your traffic will not be sniffed over the ether.
A signed SSL certificate only guarantees that the signing agency believes you are who you say you are.
The security is in the transit, not in the identification.

I would appreciate hearing your thoughts on Perspectives. I'm talking to the researchers and they are pretty excited about this and are still improving the application.
I'm not sure if it was coincidence, but Firefox had a few auto shutdowns for me yesterday, when I had Perspectives on high security and that stopped after I changed to medium security. Not a scientific test, but one of those Hmmm things.

I agree with your assessment, as it's how I normally advise clients to proceed.
Not trying to be pushy, but you may be interested in my next article about a new way of insuring that the certificate is valid. It's not perfect and requires a browser add-on.
So, with that in mind having a trusted signing CA verify your certificates is still the best approach IMO.

And that can be used against customers. A fly-by-night could be set up with real certificates, which can add to the "company's" credibility for those who do not understand what CAs are. Or, as JCitizen pointed out, the site could simply host a Verisign or Thawte logo, which also implies trust to those who are ignorant of what certs are for.
I agree that there should be some set of requirements to which CAs must adhere.
No ... kidding. ;)

Playing the devil's advocate, I'd like to mention that we have to start somewhere. I'm hoping that if enough interest is generated that the signing CAs will feel compelled to use due diligence when signing certificates. It's in everyone's best interest.

While my organisation primarily uses Entrust certs for our publically available sites/resources we do make use of our own in-house CA for external access to restricted systems.
For domain-connected Windows machines this isn't a problem as we can push out the CA via a GPO but for standalone machines (such as users' home PCs) we come across the familiar distribution problem.
We found a happy middle ground was to publish the root CA cert on a site using a pre-trusted third-party (such as Entrust) which they can then download using a browser. Using the browser's pre-established trust list the browser can verify our site and that way the user can be sure that the CA root cert is from our servers.
Admittedly they can't verify that the cert has not been tampered with prior to being hosted on our server but you can't have everything! :)
The only problem we've had so far is that the procedure for importing a root CA cert seems to change every version of OS and/or browser. Not really a problem but it over-complicates the user guidance we offer...
The next best thing would be to get other organisations, say trusted partners, to host a copy of your certificate. Users could then compare the two certificates to ensure that they are the same. This would reduce the possibility that the certificate had been tampered with as both unconnected sites would have had to have been compromised. Unless the certificate was compromised prior to distribution.
All in all it may be easier if we all had our own PKIs and cross-certified CA roots we trusted. :)

If encryption is all that is desired, then self-trusted certificates are OK because they accomplish exactly that. (The end point is effectively saying, "I am who I say I am and who's to say otherwise.") The user needs to make a decision regarding the value of information that will be encrypted; this is exactly what FireFox achieves. Personally, for me, in this day and age of phishing and hijacking, 'who I say I am' ain't gonna cut it for anything where real dollars or credit card numbers are involved, but might for innocuous information like my preferred personal email address.
So, to any website owners out there, I say go to GoDaddy and pay the $17/yr to gain my (and thousands of other's) trust. If you're that cheap that you won't, I probably don't want to do business with you anyway.
It doesn't have to be Verisign to achieve the 'trusted' result.

You're absolutely right. When I go to my bank's website, I want to be damned sure that I'm at my bank's website, and that I haven't fat-fingered the url.
The ultimate solution seems to be that everyone creates a public / private key pair, and when an account is opened, the user gives the bank their public key, and the bank gives the user their public key. Then, whenever the user visits the bank site, the bank and the user communicate via the pre-established key trusts.
Of course, that's never going to happen, at least like that. There's no system in place for it. Key revocations, for example, would cause calamity.
So what's the next best thing? How do you verify that the entity on the other end represents your bank? How paranoid can you get? Pretty paranoid.
The absolute best way I've heard of in real life is to have a bank that does two way verification. I've heard of it 2nd hand, so I can't tell you for sure who does it, but there is at least one bank I've heard of that, when you go to login to their site, has you log in with username and password, then they send a text message to your cellphone with a string of numbers. You enter that string, and then you get access to the bank. I call it the poor man's RSA token.
It all boils down to, how can you trust the site you're visiting? To what lengths are the bad guys willing to go to impersonate your bank?
If you take mistrust to it's logical end, how sure are you that the bank branch you walked into wasn't a front run by criminals? They had the logo and the paperhead, but that's easier to fake than a web site's certificate.
There's got to be a happy medium where you are reasonably sure that the site is your bank. Two way authentication (be it pictures with text or a textmessage to your phone), along with a certificate that matches the url that you typed is enough in my mind.

getting those requirements is that there would have to be a global authority that could enforce repercussions against CAs that failed to meet the requirements.
then the instant ssl certs would all be a cause for rrepercussions, since how can they validate anything but domain name in minutes, when their office is closed and it's just a script issuing the cert?

I didn't realize that they offered that service. That seems like a definite work-around. Is that an additional supplied feature or an added expense?
Thank you for mentioning it, I'm certainly looking into it as an option.

"how sure are you that the bank branch you walked into wasn't a front run by criminals?"
Aren't they all???
Putting my cynicism aside, I use Netcraft's anti-phishing Toolbar:
http://toolbar.netcraft.com/
It may not be perfect but does help to sooth my paranoia. I'm aware that there are alternatives.

I'll have to digest the PKI two-way authentication process before I comment. As an anal security type, I see all sorts of benefit from that.
As for two-part authentication, it's as you mentioned available now. For example, Paypal and eBay have recently started using the secondary RSA style SecurID devices. I have mine to be sure.
http://cavemonkey50.com/2007/08/paypals-new-security-key-opens-a-world-of-possibilities/
I must play the devil's advocate though. Using the SecurID verifies that you are who you say you are to Paypal. It doesn't prove to you that Paypal is who it says it is. That comes via the SSL certificate.

that was registered to a previous IT person instead of the owner of the site. They (Comodo) put us through the wringer and we actually had to contact the previous IT person to get them to verify his information before they would issue a cert. (can you say 2 weeks of down time) And this was only for online booking of condominiums. Comodo is very strict about issuance of certificates and very careful about owner verifications. Can't speak for any of the others but it appeared to me, IMHO, they do a good job of verifying ownership.

Enough to make it worth the while of the companies interested, anyway.
What would best "best", imho, is if there were two levels of cert trust. One, the version that companies use now, with some more expense thrown on to verify that the companies are who they say they are, and a lower level, where the certificate is only used to encrypt the session.
Take TechRepublic, for instance. I'm not giving TechRepublic any money. They don't have access to my bank account, so I don't particularly care that they have the big expensive signed certificate. I just don't want my password submitted in plaintext.
If I ran a forum for user submission, I'd want it to (at the very least) authenticate over SSL. Since I don't offer goods or services for sale, I'd just want to encrypt the traffic and to do it cheaply, I'd self sign my certificate. Of course, now Firefox flips out when users visit this theoretical page, because it assumes my certificate is meant to identify me, when I really want it to encrypt traffic.
PKI is being used for two entirely different things and Firefox is misapprehending the purpose in that case.
How do you tell the difference? Different types of keys, I suppose. Not that a solution like that is implemented at the moment, but it would be a nice thing to have.

but I recognize the bar. A couple of my financial institutions have apparently jumped on board.
I like the idea. All that is left is to get the browsers to behave rationally in the event of a non-EV cert

The topic of browsers came up during one of the question/answer sections of a talk. They mentioned that IE7 was currently the only browser confirming authenticity.
I was rather surprised myself but the comment was not made to support any particular platform during a talk on hardware.
(I believe it is the talk on cold boot techniques for accessing data left in the RAM chips but I can confirm if interested.)

when I had always understood it was Mozilla that started the color bar approach.
Sites that I feel need this validation usually feel my [b]teeth[/b] chewing on the webmaster's butt. Now I'm not sure how reliable it is, by reading doubts cast by Wikipedia. That depends on how much you believe the data there of course.

I see now. That's how many companies approach it. Entrust is a trusted signing CA on all browsers as far as I know.
You might be interested in my next article (out today I hope), it's about a novel approach in how to determine trust levels without signing CA's involvement.

When I first read your reply I wasn't sure what you were talking about. After re-reading my own post though I see I missed an important word:-
"We found a happy middle ground was to publish the root CA cert on a site using a pre-trusted third-party CERTIFICATE(such as Entrust) which they can then download using a browser. Using the browser's pre-established trust list the browser can verify our site and that way the user can be sure that the CA root cert is from our servers."
Even with the missing word though I can see that is still a little ambiguous. The third-party Entrust certificate was used to verify one of our public-facing servers.
Apologies for the confusion! :)

You can suppress alerts in Comodo, and some people do because they don't want to see everytime a file is modified; but I actually want to know that so I let it run normally.
When suppressed Comodo will still flag critical events so it shouldn't be any problem most generally. It does seem to get Alzheimers when doing approvals sometimes, but that is generally because the file changed so was therefore untrusted again.

Michael:
I have been trying out Online Armor, and I like it for the information available in Firewall status display. So far, nothing has bumped up against it, but that may be due to my firewall router, which actually seems to be pretty good.
I ended up turning off Program guard as I became tired of training it. I already trust everything on my system, and nothing new and evil is allowed in. It is a nice feature, but it was duplicating efforts of previously installed utilities.
Comodo, I thought, was also a good firewall, but I haven't used it in quite some time (years).

Switched to it from Zone Alarm last year. It's as good as everyone says.
"Quiet" Michael? I heard about it on Windows Secrets.
Why is it that TR limits good discussion when M$/Linux Flame Wars are allowed to go on ad nauseum?

when I try new utilities that clash with Comodo, all I have to do is click a few buttons and submit a report to Comodo and within a week I receive an update that automatically configures the firewall to trust and work with the appication/utility that may be my favorite.
You can set it manually of course; but this feature is great for newbies; and strangely enough the company doesn't brag about it in the feature list! It takes very little user intervention to make the firewall work.(other than approving installations)
I had so much trouble with Outpost I had to delay using it until they get their problems worked out; but they have a personal data protection feature that would have been worth paying for, if it hadn't been for Comodo coming out with its free iVault application. I haven't tested it yet but definitely will soon.
I see AppArmor mentioned in Linux forums, I haven't investigated whether it's cross-platform./?

I was pleasantly surprised to see my Online Armor firewall way up there as well. I h've been very impressed with it and have even recommended the free version to people that don't want to pay for one.
I was curious as to why they had N/A in the recommendation box.

I had a very similar experience with VeriSign. At the time it was hard to explain to the client that the entire verification process was for their benefit. It all worked out, and I'm impressed in that regard.
I'd really like to hear about other signing CAs and their procedures. The only one that I've heard it being relatively easy to obtain one, (minutes) is GoDaddy. Has anyone else heard that?

EV certificates pretty much require that you are a registered company with lots of cash to spare. If you are an average web user who hasn't that much cash to spare, and aren't registered as a company, then you are left out in the cold. Which is sad really, as the "extended validation" is pretty much exactly the tests the CAs were always claiming to do for the original set of certificates - to justify having to pay for them instead of just generating your own.