I'm looking at this example, and I can see that as part of client authentication the user should pass the --key holding the private key used for certificate signing request to the curl command, I'm not sure why this is needed if it's for encryption shouldn't the public key of the server to be used?
Having the certificate itself doesn't prove anything. Certificate is never secret, can be shared freely and as such multiple parties could be in a possession of a valid client certificate.
As part of the TLS handshake with mutual authentication, client sends CertificateVerify message to prove it also has the private key matching the certificate it sent in Certificate message before. With TLS server already having client's certificate (and thus its public key), it can verify the signature.
I have done some research on this but still have some trouble connecting the dots as to what exactly happens when the server send its certificate to the client in terms of verifying signature and root certificates.
When you create a CSR, it generates a private key along with it, and you send it to the CA to generate the cert and sign it, but doesn't the CA use it's own private key to sign? So what is the point of the private key you generated with your CSR?
When server sends its certificate for client to validate, how exactly does client validate that it is a valid CA cert. It has a collection of trusted CA certs, ok - but how exactly are they used to verify that it was a valid CA that signed the server's certificate using the signature and public key of the server certificate? What things are compared to make sure it was not forged?
Is there any point in encrypting your internal self signed certs? How about an internal root cert? Or is the private key the only one worth encrypting?
If we don't keep a database of encrypted data for our web service (over SSL) for example, would we ever care about storing our own private key once we generated the self signed cert, and if we do, they why?
When you create a CSR, it generates a private key along with it
Or you have already generated your own private key.
and you send it to the CA to generate the cert and sign it
You send the CSR. You don't send your private key. It's private. You don't send it to anyone.
but doesn't the CA use it's own private key to sign?
Yes.
So what is the point of the private key you generated with your CSR?
It pairs with the public key contained in the certificate and it is part of the process used to prove that you and only you own that certificate, as only you can generate digital signatures with that private key that can be verified by the public key in the certificate.
When server sends its certificate for client to validate, how exactly does client validate that it is a valid CA cert. It has a collection of trusted CA certs, ok - but how exactly are they used to verify that it was a valid CA that signed the server's certificate using the signature and public key of the server certificate? What things are compared to make sure it was not forged?
The certificate itself is verified, by verifying its digital signature; it is checked for being within its validity period; and then an attempt is made to form a certificate chain using the alleged signer of the certificate (the 'issuer') and the trusted certificates in the collection.
Is there any point in encrypting your internal self signed certs?
No. They are public documents. Only the private key is private, and that isn't in the certificate.
How about an internal root cert?
No.
Or is the private key the only one worth encrypting?
Yes.
If we don't keep a database of encrypted data for our web service (over SSL) for example, would we ever care about storing our own private key once we generated the self signed cert, and if we do, they why?
Because it's private. It is a critical part of your identity. If you leak it, others can impersonate you.
As I understand, the root of SSL security is based on the public key of certificate authority. And I don't know why this key can be faked by a man in the middle:
The man in the middle received this CA public key but then sends me a public key and fake certificate of his own and pretends that it is valid. I use this key to compute the certificate signature to verify it but if this key is fake, how can I know certificate is not from a trusted source?
In order for any PKI to work, each party should have a list of public keys for CA they trust. These keys have been obtained out of band, securely, from a software vendor.
The SSL certificate (containing the SSL server's public key) received from the server is signed by the private key of one of AC. There is no way to forge a valid certificate without access to one of the CA's private key, so the man in the middle can not send a forged one that will look valid.
The is two things that we need trust in order to use PKI :
1/ that we can securely retrieve the CA's public keys
2/ that the CA won't mess up by signing forged certificates or by getting their keys stolen.
Let's say server S sends it's certificate to client C. What is the method used to validate that this certificate is authentic?
What are the steps carried out to ensure that this is indeed the certificate issue to server S by a CA ?
The server sends a digital signature over the handshake data, signed by the private key coresponding to the public key in the certificate. The client verifies the signature with the public key. That establishes that the server owns the private key.
The client attempts to establish a trust relationship between the CAs that it trusts and the IssuerDN chain of the certificate. If successful, that establishes that the chain of CAs all believe in the next one's identity all the way to the SubjectDN of the certificate.
So at this point we know that the server owns the private key implied by the certificate's public key, and that the owner of the certificate is who it says he is. So now we know who he is.
I need to setup a 2 way SSL communication channel between a .NET/WCF application and a third party web server. Right now I am trying get a successful handshake with the host in order to validate that all the elements are setup correctly (client certificate, server certificate authority, network communication...). I'm using the openSSL command line tool to try and validate this, using the s_client command.
Here is what is stopping me, and what I don't understand:
whatever I do, openSSL is expecting to find a private key for the
client certificate
the client certificate was given to me by the third party, but it
does not contain any private key
if I just generate my own private key file using openSSL, I'm getting
a key values mismatch error
Keep in mind that I have just started getting my hands into SSL so I have a very basic understanding of the whole protocol. From what I've been reading, it seems that both server and client need their private key in a 2 way SSL setting. However, I can't figure out how to get a working private key on my client (working with the client certificate that was given to me).
I would very much appreciate if somebody could shed some light on client certificate private keys, as this is giving me a major headache.
Certificates on their own are only public pieces of information. What links a public key certificate to the name it contains is the fact that whoever has legitimate control over that name (e.g. your name or your server's name) also has the private key for it.
Certificates are used to prove the identity of the remote party by challenging the remote party to perform an operation that can only be done with the corresponding private key: signing something (which can be verified with the public key) or deciphering something that was encrypted with the public key. (Both can happen in the SSL/TLS handshake, depending on the cipher suite.)
During the SSL/TLS handshake, the server sends its certificate (in clear) and proves to the client that it has the corresponding private key using an authenticated key exchange.
In your case, you also want to use client-certificate authentication. It's not enough to send the client certificate during the handshake: the client must also prove it has the private key. Otherwise, anyone who receives that certificate could clone it. The point of using certificates is to prevent any cloning, in such a way that you never have to show your own secret (the private key).
More specifically, the client has to sign the handshake messages in the Certificate Verify message of the TLS handshake so that the server can verify it against the public key sent in the client certificate. Without this step, no client-certificate authentication would be taking place.
the client certificate was given to me by the third party, but it does
not contain any private key
Giving you your certificate without its private key seems a bit pointless, unless you're expected to have generated a certificate request on your side beforehand (in which case you would have the private key).
Indeed, rather than being given a certificate and its private key, it's better practice for you to generate your key-pair, create a certificate request (CSR), and have your CA issue a certificate from that CSR (but without them ever knowing your private key). In this case, you would be expected to have kept your private key, and you would be able to use it with the cert you would have received.
This is an interesting question. I was puzzled by TLS related errors while configuring LDAPS, my learnings here.
The names, "public key" and "private key" sound like it's an one-way operations, but it works both ways, anything encrypted by one key and be decrypted by another key - just that one key is made public
Info = openly available data, with unknown integrity - it could be tampered by 3rd party
Signature = Info encrypted by a private key, accompanies Info
Verifying signature = use public key to decrypt the signature and get Info back thus proving "whoever created the signature knows the private key", or, the Info is untouched after it's signed
That is, unless the private key is stolen
Certificate = Info + Signature + public key + private key
Info = the meat
Signature = to verify integrity of Info
public key = to verify other certificates, see Certificate Chain
private key = not included in certificate itself but should be kept by certificate owner, could be used to sign other certificates
Certificate Authority (CA) = Anyone who holds a public / private key pair and creates certificates
CA identity is indicated in Info on a certificate
Certificate Chain = Use public key on mother-certificate to verify the signature on a child-certificate, to ensure child-certificate was created and signed by mother CA
And mother created and signed by grandma, so forth
Root CA = Root CA is the CA you trust unconditionally
Because their certificates (Root Certificates) are pre-loaded in your browser or OS as a source of trust
Also because their certificates are self-signed, its Signature is created using its own private key, verified by its own public key
This could be confusing, but think it as the origin of certificate-based encryption - only when people found out that relying on a few Root CA's to create and sign countless certificates are insecure (private keys might get stolen) and impossible (rapidly increasing demands of certificates), they came up with the idea of certificate chains
Root CA's only create and sign certificates for some Intermediate CA's so private keys are not used too often and is safer
Intermediate CA's can create and sign millions of certificates and get their certificate revoked when a private key is known to be leaked
This is the reason you don't often see the Root Key Ceremony, which signifies the importance of the private key for a Root Certificate: the less the private key is used, the less it could be exposed
Self-Signed Root Certificate = virtually the same as a Root Certificate - just no one but the creator would trust
TLS Handshake = server sends certificate, client validate is against the certificate chain, when verified, exchange a "password" securely
The "password" is then used to encrypt actual data transfer using symmetric encryption
Asymmetric encryption is not used for actual data due to its need for intense computation powers
Client Certificate Authentication = in addition to previous process which authenticates the server, the server demands a valid certificate to be provided by the client, also a signature of previous handshake messages
The signature is created using the private key of the certificate and can be verified by the public key on the certificate
This proves the ownership of the certificate
This is used usually for restricting access to known individual clients
Using certificates means no man-in-the-middle or replay attack could happen
This is often seen in finance or IoT
This is also utilized by LDAPS, which caused mystic error messages when I had a valid certificate in my local keystore but it was not accompanied by its private key
...So, in terms of openssl, when you use -cert you indicate Client Certificate Authentication, with which you will need -key to specify the corresponding private key.
However, for many Web scenarios, even if the certificate for a server is signed by a homemade CA, one only need to add the homemade CA to truststore or keychain then server certificate can be validated. This is done by using -CAfile.
Bottom-line.. If you're sending client certificates, then you would need the client certificates' private key to encrypt the pre-master secret