Not true by any stretch.

Not to be rude (hey, I'm in a good mood this morning :) but I don't think you have a clue about how this works, based on your posts in the pfsense forum.

The certificates are for authentication, not for signing. When you want an SSL certificate for your website/mail server/whatever, you generate a .csr and submit that to the CA to sign. They, in turn, issue you a signed certificate (usually a .crt), and you use that along with a .key file to establish to your clients that you (whatever "you" happens to be) are who you say you are.

There is no signing that goes on in any connection to the server. Period.

And by the way, as far as your comment about Gmail not caring, you should really learn how something works before you make snide comments to people who know more than you and are trying to help you. The root CA that Gmail uses is already installed in your browser. Again, THERE IS NO SIGNING GOING ON.

If you read the full pfsense thread, you would see that originally I didn't know how the signing worked.

Then at the end I realized that the user submits a self signed certificate to gmail. I already knew that the Thawte certificates were installed in the browser.

hence my statement at the end of the thread,

"As for gmail, I guess they don't care who you are, so as long as you sign your own certificate they'll accept the connection."

was correct. I could have also added, "and as long as the client successfully verifies the gmail certificate".

I read the full thread completely, a few times, actually. It appears that you still don't fully understand PKI, since you keep mention "signing" when you mean "exchange."

The EXCHANGE occurs during the initial connection to establish trust and verification.

SIGNING is when you submit a .csr to a CA, who then signs it and returns to you an actual certificate that is used from then on in order to establish a trusted connection (this is what's used during the "exchange" mentioned above.)

Still wrong. The user doesn't submit anything to Gmail. The browser has a certificate signed by the root CA already installed, and THAT is what's used to establish the trust between the browser and the server. Nothing is being "signed" anywhere in that entire process. Certificates are being VERIFIED - that's it.

No, that's NOT correct. I've already explained it, so I'm not going to waste time re-typing everything again.

I'd recommend you follow up with some research into PKI in general so you understand how the entire thing works. A good place to start is www.cacert.org, which makes certificates available for free (DISCLAIMER: I've been an Assurer with them since almost their inception.)

Gmail doesn't send you unencrypted data when the https connection has been established. They encrypt data with your public key.

Why do they encrypt data with your public key? Because they feel like it? No, because the certificate has been has been verified.

Gmail has received the user's certificate and used the public key contained within to decrypt the signature to obtain the hash of the "Data" part of the certificate. Gmail then hashes the "Data" part, compares the two and if they are equal the certificate has been verified.

Gmail does do this- if they don't care who you are, they at least make sure the public key is used to decrypt messages encrypted with the private key.

The assumption I was making was, the user gives Gmail a self signed certificate. Then Gmail verifies that certificate using the public key contained within. I don't care if you don't understand what I'm saying, I understand what I'm saying.

"This is an example of a self-signed certificate, as the issuer and subject are the same", http://en.wikipedia.org/wiki/X.509.


Here, read some wikipedia:

http://en.wikipedia.org/wiki/Cryptog..._hash_function
http://en.wikipedia.org/wiki/X.509
http://en.wikipedia.org/wiki/Image:D...re_diagram.svg
http://upload.wikimedia.org/wikipedi...w_it_works.jpg
http://en.wikipedia.org/wiki/Digital_signature
http://en.wikipedia.org/wiki/Public_key_cryptography
http://en.wikipedia.org/wiki/Public_key_certificate
http://en.wikipedia.org/wiki/Image:P...astructure.svg
http://en.wikipedia.org/wiki/Public_key_infrastructure
http://en.wikipedia.org/wiki/Certificate_Authority
http://en.wikipedia.org/wiki/Certifi...igning_request

After reading your posts in this forum and others, it's wonderful how you became an expert on this subject in so little time. It seems like just yesterday (maybe because it was?) you were a n00b asking basic questions about various networking and Linux subjects, and here you are today citing wikipedia references to me (as if wikipedia was the end-all-be-all about everything.)

(And just to remind you, your original question was pertaining to authentication to a different application (OpenVPN), using certificates, not a web server. If you're such an expert on this, why are you asking this same question in various forums? I'm just curious...)

OK, let's go with it..

[QUOTE=shwick;768194]Gmail doesn't send you unencrypted data when the https connection has been established. They encrypt data with your public key.[QUOTE]

The data is encrypted over a Secure Socket Layer (SSL) connection. There *is* no "public key", since we're dealing with certificates here. If you were using GnuPG or PGP, then you have a public key, as well as a private key (which, by the way, is used for encrypting data in a different fashion, but I won't confuse you with that stuff right now.) Not so with certificates - you have the server certificate (held on the server, in your example by Google) and the client certificate installed within the browser, and BOTH of them are signed by the root Certificate Authority (aka "root CA".) A "user" is never asked about the transaction (provided the certificates are issued and signed by the same authority and still valid, and provided the certificate on the server hasn't expired or is being used at a different address.) The only "key" file that exists is used when creating a .csr with OpenSSL (in this example), and that stays on the SERVER - no clients ever come in contact with it.

Yes, verified, but not with your "public key" - by the client certificate installed within the browser.

There is no "user certificate" in this process.

1. A self-signed certificate wouldn't be signed by the same root CA, so there would be no trust established.

2. The client CERTIFICATE is already installed in your browser, which is signed by the same root CA and issued by the same authority as the server certificate (held on Google's server.)

No thanks, I'll stick with authentic, accurate sources.