Trying to Understand SSL Certificates

[Jonathan Wood]

I'm writing code that interfaces with Authorize.net to process credit cards.
Obviously, security is very important and post operations using SSL are
required.

To this end, companies like Comodo
(http://www.authorize.net/solutions/merchantsolutions/merchantservices/sslcertificates/)
offers SSL certificates for a reasonable annual fee.

But I can pass the INTERNET_DEFAULT_HTTPS_PORT flag to InternetConnect(),
which the documentation says establishes "a Secure Socket Layer (SSL)" using
port 443. And I can then pass the INTERNET_FLAG_SECURE flag to
HttpOpenRequest().

So what I don't understand is how companies like Comodo make money providing
SSL certificates. How is that different than connecting using SSL the way
I've described above? Is there something they are offering that I'm unaware
of?

Thanks in advance for any tips.

[Daniel James]

Post by Jonathan Wood
I can pass the INTERNET_DEFAULT_HTTPS_PORT flag to InternetConnect(),
which the documentation says establishes "a Secure Socket Layer (SSL)" using
port 443. And I can then pass the INTERNET_FLAG_SECURE flag to
HttpOpenRequest().

That's right. Part of the SSL set-up that goes on behind the scenes is that you
receive an SSL certificate from the server you're connecting to, verify it
against the root certificates Windows holds in its certificate store, and use
the key in that certificate to set up secure communications.

Post by Jonathan Wood
So what I don't understand is how companies like Comodo make money providing
SSL certificates. How is that different than connecting using SSL the way
I've described above? Is there something they are offering that I'm unaware
of?

In the situation above, the server has an SSL certificate that will have been
obtained from Comodo, Verisign, Thawte ... or one of any number of others ...
that is used to set up the connection. You don't need a certificate of your own
because the server provides one.

If you wanted to run a server that other people could connect to, you would
need your own SSL keyset, and you would need to get your public key signed
(i.e. you would need to get a certificate, preferably from an organization
whose root key is already known to Windows) in order to get your clients to
trust that key.

There are also SSL systems that require every client to have an identity
certificate to authenticate them to the server (instead of relying on, say, a
password) but the simple wininet case you outline doesn't use this much higher
level of security.

Cheers,
Daniel.

[Jonathan Wood]

Daniel,

Post by Daniel James
In the situation above, the server has an SSL certificate that will have been
obtained from Comodo, Verisign, Thawte ... or one of any number of others ...
that is used to set up the connection. You don't need a certificate of your own
because the server provides one.
If you wanted to run a server that other people could connect to, you would
need your own SSL keyset, and you would need to get your public key signed
(i.e. you would need to get a certificate, preferably from an organization
whose root key is already known to Windows) in order to get your clients to
trust that key.
There are also SSL systems that require every client to have an identity
certificate to authenticate them to the server (instead of relying on, say, a
password) but the simple wininet case you outline doesn't use this much higher
level of security.

Thanks for the reply! Can I rephrase that back to you to see if I've got it
right?

As I understand it, you're saying that when I connect to a secure server as
in the situation I described, then that server has SSL certificates behind
the scene as part of the secure transaction and so there is nothing else I
need to do.

However, I also plan to add this logic to my own Website in order to process
my customers' orders. In that case, I will also need to provide these SSL
certificates behind the scene as part of the secure transaction between my
Website and the customer's computer.

Is that right?

Thanks!

Jonathan

[Paul Baker [MVP, Windows - SDK]]

Jonathan,

Correct.

On the client-side, WinInet (and probably most other HTTP APIs) will take
care of the SSL protocol for you.

On the server-side, IIS (and probably most web servers) will take care of
the SSL protocol for you simply by installing the certificate.

Paul

Post by Jonathan Wood
Daniel,

Post by Daniel James
In the situation above, the server has an SSL certificate that will have been
obtained from Comodo, Verisign, Thawte ... or one of any number of others ...
that is used to set up the connection. You don't need a certificate of your own
because the server provides one.
If you wanted to run a server that other people could connect to, you would
need your own SSL keyset, and you would need to get your public key signed
(i.e. you would need to get a certificate, preferably from an
organization
whose root key is already known to Windows) in order to get your clients to
trust that key.
There are also SSL systems that require every client to have an identity
certificate to authenticate them to the server (instead of relying on, say, a
password) but the simple wininet case you outline doesn't use this much higher
level of security.

Thanks for the reply! Can I rephrase that back to you to see if I've got
it right?
As I understand it, you're saying that when I connect to a secure server
as in the situation I described, then that server has SSL certificates
behind the scene as part of the secure transaction and so there is nothing
else I need to do.
However, I also plan to add this logic to my own Website in order to
process my customers' orders. In that case, I will also need to provide
these SSL certificates behind the scene as part of the secure transaction
between my Website and the customer's computer.
Is that right?
Thanks!
Jonathan

[Jonathan Wood]

Thanks.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Post by Paul Baker [MVP, Windows - SDK]
Jonathan,
Correct.
On the client-side, WinInet (and probably most other HTTP APIs) will take
care of the SSL protocol for you.
On the server-side, IIS (and probably most web servers) will take care of
the SSL protocol for you simply by installing the certificate.
Paul

Post by Jonathan Wood
Daniel,

Post by Daniel James
In the situation above, the server has an SSL certificate that will have been
obtained from Comodo, Verisign, Thawte ... or one of any number of others ...
that is used to set up the connection. You don't need a certificate of your own
because the server provides one.
If you wanted to run a server that other people could connect to, you would
need your own SSL keyset, and you would need to get your public key signed
(i.e. you would need to get a certificate, preferably from an organization
whose root key is already known to Windows) in order to get your clients to
trust that key.
There are also SSL systems that require every client to have an identity
certificate to authenticate them to the server (instead of relying on, say, a
password) but the simple wininet case you outline doesn't use this much higher
level of security.

Thanks for the reply! Can I rephrase that back to you to see if I've got
it right?
As I understand it, you're saying that when I connect to a secure server
as in the situation I described, then that server has SSL certificates
behind the scene as part of the secure transaction and so there is
nothing else I need to do.
However, I also plan to add this logic to my own Website in order to
process my customers' orders. In that case, I will also need to provide
these SSL certificates behind the scene as part of the secure transaction
between my Website and the customer's computer.
Is that right?
Thanks!
Jonathan

[Daniel James]

Post by Jonathan Wood
Is that right?

Yes.

Cheers,
Daniel.