Re: DCM cert for Apache settings

On Wed, Mar 8, 2017 at 4:10 PM, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Nathan,

On 3/8/2017 12:35 PM, Nathan Andelin wrote:

Same with true for web services. Web service clients and servers don't
mess
with certificate authorities. Why do browsers?

Not sure that I agree that SMTP and Web Services don't care about CAs,
but...

Is that to say you're not sure you disagree? You know of any SMTP relays or
Web service clients rejecting self-signed certificates from their trading
partners?

Because SSL was originally created with the thought of opening up stores

where you could buy items with credit cards over the Internet.

The history I've read suggests that SSL was originally a protocol for
encrypted exchange; that the idea of inserting a CA into the mix evolved
over time.

The problem is, having the site encrypted does absolutely no good if you

send your credit card number to a criminal's web site. Sure, your card is
nicely protected as its sent, but if it's sent to a criminal, it's still a
big problem.

Obviously.

The job of a certificate authority is to verify that you really are who you

say you are. So if you claim to be www.amazon.com, the certificate
authority will not issue a certificate unless you somehow "prove" it. (They
might call Amazon's phone number, for example, or something similar...
depending on how serious they take it.)

I understand the role of the CA. But if you KNOW you are connecting to
www.amazon.com, why not trust a certificate issued and signed by
www.amazon.com?

If you go to Amazon.com, but get a certificate for another site, you can be

sure that someone someone is intercepting the session and redirecting it
somewhere else.

Are you alluding to what browsers (the software) do, or what people do?

I believe Charles Wilt was referring to personal devices getting hacked
(DNS Poisoning), whereby the device redirects itself from say www.amazon.com
to www.fraud.com. In that case, www.fraud.com could present a certificate
signed by a certificate authority, and the browser would accept it. No?

You might say "but, nobody does that!" Yeah, and there's a reason... if
they did, it wouldn't match the CA, and so the customer would not be
fooled. You can bet that if SSL wasn't so picky about things, this would
be a common problem.

You appear to be referring to someone, somewhere on the internet,
intercepting someone's browser session. I'm not sure what that means. So I
wouldn't assume anything about that.

Typically, the only time CAs aren't used is when SSL is set up internally

within an organization (vs. the public Internet).

That's what the original poster was referring to. The problem is that some
browser's won't allow the connection, while others present users with
prompts such as Report and Help Us Identify and Block Malicious Sites
(referring to the one run by your organization).

The browser is assuming that the site is malicious, by default.

Here you can reasonably trust things since you know exactly who you are

dealing with. Or, with client-side certificates. Client-side certificates
are almost never used in SSL, but when they are the certificates are
typically used by whomever is running the server, since the purpose is to
make sure only people they allow to use the site can log in. So a public
CA where anyone can get a cert doesn't make much sense for client-side.

I understand the difference between client certificates, and server
certificates. Are you suggesting that client certificates are relevant to
the discussion?

HTH,

Nathan.