I have done some research about how do browsers work with CA-signed certificates. The browser comes with a list of trusted CA's public keys. When a CA-signed certificate was received by a browser, the browser decrypts the certificate using the trusted CA's public key to get the server's public key.
I am confused about how does the browser work with self-signed certificates. A self-signed certificate is signed by the server's private key. When a browser receives a self-signed certificate, how does the browser decrypt the cert to get the public key without knowing the public key?
When a CA-signed certificate was received by a browser, the browser decrypts the certificate using the trusted CA's public key to get the server's public key.
The browser does not decrypt the certificate to get the public key. The browser just uses the public key of the CA to verify the issuers signature of the certificate. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.
When a browser receives a self-signed certificate, how does the browser decrypt the cert to get the public key without knowing the public key?
Again, there is no decryption. But apart from that there is no way for the browser to check if the self-signed certificate is valid. A self-signed certificate basically is somebody claiming to be themselves. Contrary to a CA signed certificate there is no trusted third party which says this but just the (untrusted) owner of the certificate itself.
Thus the only way such a certificate can be trusted in the browser is either because it was explicitly added as trusted or if the user of the browser explicitly added an exception after they got a warning about the certificate.
Related
I'm confused on how Self-signed certificate works.
Our application will connect to a server to get some info via SSL or https. This mean we are the client. The server is asking us to provide the Self-signed certificate. I created a RSA Key pair and a self-signed certificate.. What cert or key will provide to them? The public key and the self-signed certificate? and do we expect certificate from them?
What cert or key will provide to them?
Only the self-signed certificate should be provided. The private key should be kept private (hence the name).
... and do we expect certificate from them?
This depends if they also use self-signed certificates at their end or if a publicly trusted CA has issued the certificate. In the first case they need to provide the certificate, in the latter case your client just needs to trust the common publicly trusted CA (i.e. what the browsers do).
I'm trying to understand how TLS protocol works under the hood. I know the TLS handshake is based on X.509 certificate. The certificate includes the public key and authenticates it's origin by CA's digital signature.
But how is the certificate verified by the browser according to CA's digital signature? Does browser has the public key of the CA to verify the signature? Isn't it possible for attacker to forge the certificate, if he can tamper the verifying process itself?
We have a XMPP server using SSL certificates (for both the server and the clients).
We use a self-signed CA to sign those certificates. Now we want to stop using that self-signed CA, but we have no idea how to replace those certificates to ones signed by an authority like Digicert or GlobalSign, since we don't know what to buy to do the same we usually do (we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
Any ideas?
Thanks a lot.
we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
The process is the same as for a Certificate Authority, with the difference you probably have to pay for the certificate
generate a key pair,private and public. (Not only the public)
Generate a Certificate Signing Request including the public key, some data about the certificate as Common Name, and sign it with the private key.
Send the CSR to the Certificate Authority
The CA validates the CSR, builds the certificate and signs it with its private key
Finally the CA sends you the certificate
If I understand SSL/TLS correctly in server only authentication, After the handshake, the server sends the client it's public key and a digitally signed certificate signed by a CA. If the client has this CA's public key, it can decrypt the certificate and establish trust with the server. If it does not trust the CA, then the communication stops. In 2 way SSL where the client needs to authenticate back to the server, after the client receives the public key and the digitally signed cert then the client will send the server over it's public key and a digitally signed cert. The server will check to see if it has a public key for the client's cert and if it does it can establish trust with the client. I am setting up mutual authentication [ 2 way ssl] on a weblogic server [in this case the client, calling outbound to a web service] and the third party sent me a digitally signed cert and a certificate chain. Why do I need these. Isn't this what the server replies with after the handshake?
the server sends the client it's public key and a digitally signed certificate signed by a CA.
The certificate contains the public key. The key is not sent extra.
If the client has this CA's public key, it can decrypt the certificate
The certificate is not encrypted, it is signed by the CA. Thus no decryption is done but the client can verify this signature if the client has the CA's certificate (and thus its public key). But usually the certificate is not signed directly by a CA trusted by the browser but there are intermediate certificates. In this case the server will not only send the servers certificate but also all intermediate certificates which are needed to build the trust chain.
then the client will send the server over it's public key and a digitally signed cert.
Again, the public key is part of the certificate.
the third party sent me a digitally signed cert and a certificate chain. Why do I need these.
The first certificate is the client certificate. The chain certificates are needed to build the trust chain because the server does not trust the issuer CA of the clients certificate directly and thus needs the intermediate certificates.
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.