What stops someone from MITM-attacking the request to the
certificate authority to verify the
certificate?
When a browser is presented with a certificate by , it doesn't connect to the issuing certificate authority (CA) to verify the certificate; it must already trust the CA, a priori. Depending on the certificate, the CA, and the browser, it may connect to a URL contained in the CA Certificate to check if the cert presented by the site has been revoked (a revocation list), but that connection is secured by the CA cert and not the cert presented by the site. As far as I am aware, most browsers don't actually do this, although most can be configured to. If a CA cert is compromised, then the CA cert will need to either be manually removed, or removed by a patch or new version of the browser code.
Does the browser come
pre-loaded with the public keys of the
trusted certificate authorities
(thereby providing authentication)?
Yes. More than just public keys though, it is actually self-signed certificates from the CAs, which contain public keys, should contain URLs for verifying the Cert itself in addition to Revocation Lists, and potentially much more. Basically, every browser maker has to decide which CAs to pre-install and which ones to leave out, and this is a topic of much discussion and big business. Most CAs generate a lot of money selling certificates, and it benefits them to be pre-installed in every browser, so they push hard on browser makers to install them. But the trustworthiness of the CAs is a topic which can cause much debate among security folks.
Whenever I think about MITM attacks, I
think that any defence requires a
"safe" connection to be established
for authentication, and that the
initial establishment of any "safe"
connection always seems to be subject
to a MITM attack itself. So for
example, if the public keys of the
trusted certificate authorities above
are indeed distributed with the
browser, the distribution of the
browser would be subject to MITM
attacks.
While true, this is a significantly more difficult attack vector than other approaches, and you can combat it by verifying the distribution file of the browser prior to installing it (i.e. verify the SHA1 hash of the installation file based on the published hash of the website). At that point, an attacker would have to infiltrate either the browser manufacturer or the Certificate Authority, which again are more difficult attack vectors (although certainly not unheard of).
As I understand it, even if
you physically handed someone a public
key / certificate / anything on a
piece of paper, you had better know
them from elsewhere otherwise they
could be a MITM.
Well, giving someone else your public key (or a certificate containing a public key) is harmless. All it means is that they can verify that stuff you signed with said certificate actually came from you (and they could encrypt things that only you can decrypt).
But fundamentally, you are right. At some point, you have to trust someone. That is an important thing to remember about security, networking, business, and life. Of course, you need to temper this with a healthy dose of skepticism, and continually reevaluate your trust relationships. And of course, you should also keep in mind some sage advice from the Gipper: "Trust, but Verify" (or, if you prefer: follow the sound advice of the old Russian proverb: ""doveryai, no proveryai" [Russian: Доверяй, но проверяй]"). To really secure your computer, you will need to power it off, take it apart, destroy the components, then destroy the remains.
As far as establishing a trust relationship with someone else goes, it helps to have a mutual friend that already trusts them. That is the whole point behind the "ring-of-trust"
At some point you have to have a little faith. How do you know that the person that issued you your driver's license is REALLY an employee of the state. Of course, you could generate your public key, memorize the fingerprint, and install the pub key on the target system
Do I understand this correctly?
I'm not sure, but I suspect so. Please repeat it all back to me, paraphrased into your own words and I'll let you know.
EDIT: And really, as GregD points out, all this is academic, because most people click the "Proceed anyway" button when their browser warns them that it doesn't trust the cert, and then it is game over. Of course if you work in an enterprise, and control the system that the users are issued, you can probably configure it so it doesn't present them that button, but you will have to deal with the fall-out. The only time it is ever acceptable to click that button is when you are not connected to a network and have single wire between you and the system presenting the untrusted certificate (and even then, it is arguable).
Best Answer
Basically the error response you got from the SSL signature verification is:
The issuer is the signing authority that received your certificate signing request (CSR), signed it, and returned you the server certificate (which you installed along with the private key that you generated with the CSR). The server certificate is a PEM file with a
.cer
or.crt
extention. It is a text file with certificates encoded in blocks between:The error text explains:
But for this verification to happen, at least one other certificate is needed, namely the certificate of the issuer, and possibly also the one of the certificate root authority (CA).
A count of 1 in
grep -c BEGIN /etc/pki/tls/certs/yourserver.crt
will show that, when you have such a local issuer, its certificate is not available. It takes at least 2 certificates to verify.A scanner, such as the PCI DSS External Vulnerability Scan, needs to know about these additional certificates. They can either be well-known/built-in CA's like Verisign or Thawte, but quite possible they can be unknown, because the CA could be your company's. The canonical name (CN=), and the (missing) domain components, in your output, show that the certificate was not signed by a CA that is built-in to the scanner by its vendor.
It is common practice to append the issuer certificate and the root ca certificate (in that order) to the server certificate, as of to tell the SSL client about the trust chain.
cat issuer.cer root_ca.cer >> etc/pki/tls/certs/yourserver.crt
But this does not establish trust. The scanner, and SSL clients in general, need to have the issuer’s root CA’s certificate. If your company has its own CA, then you need to install it everywhere.