An introduction to SSL Certificates|
What is a certificate?
A certificate is a means of vouching for your web site's integrity and authenticity. If you set up a secure web site you want people to know that they can trust it. So you install a certificate on the web server.
There are two ways of obtaining a certificate for your web site: create one yourself, or buy one from a company such as VeriSign, Equifax, Thawte et al.
At issue is the concept of trust. As a user, visiting a web site, do you trust the site's assurances about its security? The certificate is how the web site says, "You can trust me, really. Honest, guy, no word of a lie."
That's step one of the process. Step two is you - or rather, your web browser - accepting the site's assurances and deciding to trust it. For the majority of sites out there the process is seamless. This is because the web browser already knows that it can trust certain certificates…
How is a certificate used?
Certificates can be used to "sign", or vouch for, other certificates. This is how your web browser knows whether or not to trust the certificate presented by a web site. Let's take a look at https://www.fastmail.fm/ in Internet Explorer (I'll be using IE for the rest of this introduction; different web browsers use different methods, but the concept is the same). See the little, yellow padlock at the bottom-right of your web browser's window? Double-click on it. You will see this:
This dialog tells you what the certificate's purpose is - in this case it's verifying the web server's identity - as well as who issued it, to whom, and for how long it's valid. At the time of writing this certificate is valid for slightly less than four more months. I hope the site owners are keeping tabs on it!
So far, so good. But how do you know that the certificate is trustworthy and that your web browser didn't just blindly accept the server's assurances without double-checking them? If you click on the Details tab you will see the specific, er, details about this certificate:
You can see here some information which corresponds to what you saw on the General tab: Issuer - in this case Thawte, the dates of validity, and the beneficiary of the certificate - "Subject". The rest of the contents of this tab are more advanced in nature and thus outside the scope of this introduction.
Click on the Certification Path tab:
Here you can see the Certification Authority Hierarchy. In other words, this web site's certificate is part of a chain of certificates with the Thawte Server CA (CA means Certification Authority) at the top. This one has a chain of two certificates. Some Certification Authority Hierarchies have three or even more certificates.
Internet Explorer already trusts the Thawte Server CA, so it therefore trusts any certificates "signed" by that CA, including Fastmail's. The logic runs thus: "I don't know you but I trust him already, and he vouches for you so I'll trust you." If you want to see what the Thawte Server CA looks like then click on it, then click on the - now active - View Certificate button. A new dialog will appear, looking much the same as the one at which you were just looking:
Now, the more perceptive of you may be wondering why the Thawte Server CA is trusted by the web browser. Fastmail's certificate needed to be "signed" before it could be trusted. What was used to "sign" the Thawte Server CA? The answer: nothing. Read on…
Internet Explorer ships with a set of certificates already configured as being trusted. The Thawte Server CA is one of these certificates. These certificates can be found on your PC. To see these certificates click on Tools - Internet Options. Then click on the Content tab, and finally on the Security button. You will see this:
I've blanked out the details of my Personal certificate, for obvious reasons. What you see on this tab, if anything, will depend on your individual computer's configuration. Click instead on the tab at the right marked Trusted Root Certification Authorities:
Quite a long list, no? I've scrolled down to the Thawte Server CA mentioned earlier. If you select it and then click on the View button you will see the same certificate which you saw earlier when investigating the Certification Authority Hierarchy of Fastmail's certificate, but with a couple of subtle differences:
In the instance earlier, the certificate was being used only to verify the identity of Fastmail's server. Certificates can be used for more purposes, as seen here. They can also be used to verify the integrity of software. They can be used instead of user IDs and passwords when signing in to secure systems. There are many other purposes to which certificates can be put, too. Perhaps the best-known use of certificates is with e-mails. One can encrypt e-mails to protect against casual - and even not-so-casual - snooping; there are various means of encrypting the data, some of which use certificates.
One can also use a certificate to "sign" one's e-mail, to affirm to the recipient that the e-mail really did come from the person who appeared to send it. But, such discussions of encryption, authentication and the like are, again, outside the scope of this document. We shall here concentrate on certificates used by web servers and browsers.
What can go wrong with certificates?
Sometimes your web browser may complain about problems with the certificate. There are several reasons why this might be the case. Sometimes you may see this error:
Certificates are occasionally revoked by the signing authority, which maintains a list - called the Certificate Revocation List, or CRL - of such certificates. Your web browser knows to check the CRL to verify that this particular site's certificate hasn't been revoked for any reason.
If you see this message it doesn't mean that the site's certificate is bad, or that there's any danger to your computer; it means merely that the web browser is unable to double-check the CRL to make sure that no-one's revoked it. There may be several reasons for this. I often see this message when viewing web sites through my employer's proxy server. When I'm at home I don't, generally, see this message.
That doesn't mean that the message is unimportant; on the contrary, unless you're absolutely certain that you can trust the site you should click on the View Certificate button and check that it's legitimate.
If the certificate has expired - or is being used too soon - you may see the following:
Be very careful before clicking Yes. Are you sure that you want to be dealing with sites which have expired certificates? Maybe. You might have a perfectly valid reason for doing so, and may even expect such a warning. It depends on what you're doing. Let's take a look at this one in further detail. If I click on View Certificate I see this:
We can see that the certificate expired a long time ago; no wonder the web browser didn't like it! If I click on the Certification Path tab I see this:
The bad certificate is indicated by a red circle with a white X. But there are two red circles! What does it mean?
Earlier in this piece I mentioned that the Certification Authority Hierarchy can have more than two certificates in it. This is one such example, with a chain of three certificates. Not only is the web site's certificate invalid, but the one used to "sign" it is also invalid. If I click on the middle certificate and then on View Certificate I see this:
You can see that this certificate expired on January 7th, 2004. Anything "signed" by this certificate is automatically invalid as a result, even if it is itself still valid. The entire chain must be valid or the web browser doesn't like it, as seen in this, different, example:
The web server's certificate, the final one in the chain (identity disguised by me) is valid. The one above it - the red circle - is invalid. It's the same certificate as mentioned above. The result of this is that the web browser will display a warning about an expired certificate, as seen earlier. For those who are interested, the problem of this particular certificate's expiry has since been resolved by VeriSign. You can see the company's advisory here: http://verisign.com/support/vendors/exp-gsid-ssl.html
Another reason why a certificate might fail is because your web browser doesn't know who "signed" it, so has no means of trusting its authenticity:
Again, be very careful about clicking on Yes. Anyone and his dog can issue certificates without getting them "signed" by a known, trusted authority. A web site might use SSL encryption but that doesn't automatically mean it's trustworthy.
If I click on View Certificate, and then on Certification Path I see the following:
The lack of a trusted certification authority does not automatically mean that the web site is untrustworthy; it means only that the web browser does not know if anyone vouches for it, so doesn't automatically accept it. In this case the certificate has been issued by the company whose web server it is, and they haven't then had it "signed" by a known certification authority such as VeriSign, Thawte et al.
Another reason for failure might be that the server being used does not match the name of the server in the certificate. Let's go back to Fastmail, but using the url https://fastmail.fm/ instead, to see this:
If I click on View Certificate I see the following:
This dialog shows us the first clue about what might be amiss. The URL typed into the web browser was https://fastmail.fm/ yet the certificate was issued to www.fastmail.fm. Those four characters - www. - make all the difference. For more corroboration see the Details tab, specifically the Subject field.
As you can see, there's a lot of effort involved in your web browser making sure that secure web sites are what they claim to be!
How are certificates issued and trusted?
I mentioned before that certificates can be obtained in two ways: either by self-issue, or by buying one from a trusted Certification Authority.
If a webmaster issues a certificate himself, using a special program for the purpose, he can expect his users to see plenty of the "The security certificate was issued by a company you have not chosen to trust…" warning messages.
It is possible for you, the user, to trust self-issued certificates by importing them into your web browser. The exact method varies from browser to browser; Internet Explorer shows an Install Certificate button when viewing a certificate which, when clicked, takes you through a wizard to import the certificate. Let's look at my firewall as an example.
I use IPCop to protect my network from the teeming hordes of ne'er-do-wells on the Internet. IPCop is administered using a secure web page, thus it requires a certificate for my web browser. The certificate it presents to my web browser isn't "signed" by any trusted Certification Authority, so I see the warning message shown earlier in this piece.
If I click on View Certificate I see this:
Yes, my firewall's called Achilles. I just hope it doesn't have a weak heel. Oh, I'm such a wit. Bad jokes aside, my web browser currently doesn't trust this certificate, hence the warning. However, in this instance I don't care what my web browser thinks; I trust this certificate, and that's good enough for me. So I want to import this certificate into my web browser. Clicking on Install Certificate starts the wizard for the process:
I then get asked for a final confirmation that I really want to import this certificate:
If I click on Yes the certificate is added and a confirmation message is displayed. To see the results of what I've just done I can follow the process described earlier to view the Trusted Root Certification Authorities:
Now, because I've told it to, my web browser now trusts my firewall's administration web pages and will stop displaying warning messages when I use them.
Certificates "signed" by already-trusted Certification Authorities are accepted without demur by the web browser. But what makes a trusted CA? Simple: telling your web browser that it can trust a certificate from such-and-such an organisation. In the case of Internet Explorer this is already done for you by Microsoft, which ships Internet Explorer with a default selection of trusted CAs.
These certificates - seen above - have been issued by companies which have a direct financial interest in being "trusted". VeriSign, for example, is a "trustworthy" company therefore any websites with certificates "signed" by VeriSign - for a fat fee - must also be "trustworthy". There are other companies involved in this racket, such as Equifax, Thawte and more. It's in these companies' interests to maintain the chain of trust; if they become known for issuing certificates to untrustworthy web sites then fewer people will trust them, therefore fewer people will buy certificates from them, therefore their profits will suffer.
Their certificates are no different from ones I might issue; the difference is that these companies are more widely known than I am. Who would you trust, some random stranger from the Internet - no matter how trustworthy he claims to be - or a company which already has a reputation for trustworthiness?
Conclusion: why have certificates anyway?
It all comes down to trust, authenticity and integrity. If I'm using a secure web site - say, when doing my banking online - then I want to know that the connection used is genuinely secure from tampering, or even impersonation. The certificate presented by my bank to my web browser is how the bank assures me of its compliance with those conditions. I then choose whether or not to trust my bank's assurances by checking who has vouched for my bank and deciding whether or not I trust them - and also anyone who has vouched for them further up the chain - in turn.
I hope you've enjoyed reading this piece, and perhaps even learned something in the process.
Do you believe? Do you trust?
Copyright © by LWD All Rights Reserved.
Published on: 2004-02-23 (32947 reads)[ Go Back ]