|
|
 FAQ
 Search
 Memberlist
 Usergroups
 Register
 Profile
 Private messages
 Log in
|
|
| Author |
Message |
JohnO
Guest
|
 Posted: Tue Oct 17, 2006 1:08 am Post subject: SSL certificates |
 |
|
Does anyone know of a good explanation of SSL and certificates?
Hopefully one written for idiots like me who have no security system
background. I've found a few extremely basic descriptions, and a few
very deep discussions, but little that sums up the process and what can
go wrong and how to fix it. I'm desperately trying to understand how
and why one would receive warnings about invalid certificates, and what
to do about them, and the role of caches in the process.
And this IS on topic. ;-)
-John O |
|
| Back to top |
|
 |
|
|
JohnO
Guest
|
| Posted: Fri Oct 20, 2006 2:25 pm Post subject: Re: SSL certificates |
|
|
smackedass wrote:
Unfortunately, not really. The theory is out there, everywhere, but a
tutorial on the practical use of the certs as I described earlier is
elusive.
-John O |
|
| Back to top |
|
|
MF
Guest
|
| Posted: Mon Oct 30, 2006 12:57 am Post subject: Re: SSL certificates |
|
|
"JohnO" <t696asm@yahoo.com> wrote in message
news:1161029304.151137.297560@i42g2000cwa.googlegroups.com...
| Quote: | Does anyone know of a good explanation of SSL and certificates?
Hopefully one written for idiots like me who have no security system
background. I've found a few extremely basic descriptions, and a few
very deep discussions, but little that sums up the process and what can
go wrong and how to fix it. I'm desperately trying to understand how
and why one would receive warnings about invalid certificates, and what
to do about them, and the role of caches in the process.
|
Yeah. I'll just answer the end of your question. A certificate has no
inherent validity. It depends strictly on trust. We agree to trust the
entity that issued the certificate - the way a cop trusts that a drivers
license identifies you because the cop trusts the state. Thus, for public
use, the public has to agree to trust whoever issues the certificate. I
could issue you one right now, using Windows Server, but few would trust it.
Thus, if there is a question about the issuer, or the identity of the person
offering the cert the cert is declared invalid. As if I offered a Jersey
cop a drivers license issued in Transylvania, or a license saying that I was
Mickey Mantle.
How do such questions and the resulting warnings arise? Several ways:
1. To get a certificate, you buy and pay for it. It is issued for a
specific length of time .e.g 1/1/07 to 12/31/ 07. You typically get the
amount of time you pay for: more time=more money. If the certificate is out
of date when your browser downloads and reads it (one of the functions of
SSL), the cert is said to have expired and you get an invalid certificate
warning.
2. The cert is issued to a certain company with a certain company name.
This info is included on the cert, and if the cert is to be used for SSL
validation over the web, the cert should contain the name of the website as
well. Companies change their names and the names of their sites. If your
browser goes to a site whose name does not match the names on the cert, you
get an invalid certificate warning.
Both of these are quite common for obvious (money and forgetfulness)
reasons. Another common one:
3. Cert issuers, called Certificate Authorities among other things, use more
than one computer to issue certs. Well, then, why can't you, I, or anyone
issue certs in the name of Thawte? Because to be valid, any given
certificate has to be traceable back to ONE SINGLE COMPUTER of origin. That
computer is the root certificate authority and issues a root certificate
which must be held by and referenced by every computer that issues
certificates in that company's name.
Okay, why can't you issue a cert that refers to the root cert of Verisign?
Because to recognize a certificate as valid, your computer must possess a
copy of the root certificate (or a validated cert from a validated
subordinate certificate server). These copies are installed when you
install the OS (if the OS comes from a big national brand). Thus you can
issue a cert that references some so-called root certificate signed by
Verisign, but the cert that your certificate references will not be an any
remote computers certificate store (sometimes called a cache) and thus will
be declared invalid when a remote user accesses a site that uses your
certificate.
So this is another reason you get warnings: Sometimes the chain of
validation is broken. The root referenced by the cert on the website you
are visiting is not the same as the one on your computer.
This can happen because the site's cert references a new root issued by the
certificate authority, or references a root certificate issued by new
certificate authority (I just got one of those the other day) or because a
certificate in the chain of validation - from subordinate #4 that issued the
cert, to subordinate #3 and so on back to the root - has expired. (The copy
of the root cert on your computer is not cached, it's in a "permanent" file
on your hd, sometimes called incorrectly called a cache. As with msft's
"dll cache," the correct name of which would be something like "dll
backups". Of course, while browsing, everything is cached, including the
cert offered by the site and the cert the site gives to your computer -
functions of SSL- but this is not important to the question at hand.)
4 And Finally  Certificates get revoked. E.g.,a disastrous situation,
the root is compromised, somebody steals it. Companies that issue certs
are required to publish a Certificate revocation list or CRL. Your browser
can be forced to check the CRL, incidentally. In the case of a compromised
root, that root and every cert ever issued that refers to that root must be
revoked and published to issuer's the CRL. A mess. A similar, but less
disastrous, situation would be that some company gets a cert issued to it -
and then proceeds to set up a website using that cert to steal financial
info. As soon as this becomes known, it's the issuer's duty to revoke that
cert and publish the revocation to the CRL. The CRL, btw, should be public
and easily available, i,e. maintained on several easily accessible servers.
And this last instance will also result in an invalid certificate warning.
_These_ are the warnings you need to worry about and heed.
hth
Mike |
|
| Back to top |
|
|
|
|
