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?
Related
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.
I wonder if anyone can provide more detailed description of point 2 of the answer to How are ssl certificates verified?.
What algorithms are used to verify that the certificate was signed by the trusted CA? What ideas are they based on? Why it is not possible to simulate trusted CA signature (make a certificate that the browser will treat as valid)?
It's a digital signature. You can verify it via the public key in the associated certificate. The algorithms are as specified in the certificate itself.
I have a self signed CA which has 1024 bit key length. Is it possible to sign a server certificate with longer key length (2048 bit) using this CA? I want to sign a server certificate and configure that for Active Directory service.
I'm able to do this using bouncy castle. My concern is about
1) Is this a good idea?
2) How would the certificate trust be established? Would that be okay.
Yes, you can use your 1024-bit RSA private key to sign a certificate for a server that is using a 2048-bit key. The length, and even the type, of the key in the certificate you're signing (the server's certificate) has no relation to the key you're using to do the signing. For example, you could have your 1024-bit RSA private key sign a certificate for a server using a 256-bit EC key if you wanted.
(Technically, you aren't signing the certificate itself, but a hash of the certificate. See this question and answer for details. But conceptually, you can think of it as "signing the certificate".)
Trust is established the same as with any other certificate chain:
Your client contains your CA's 1024-bit public key in its trust store.
Your client connects to a server, which sends its certificate, signed by your CA.
Your client sees that the certificate is signed by a CA in your trust store, so it verifies the CA's signature on the server's certificate using the CA's public key in the client's trust store.
The signature matches, so the client trusts the server's 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'm trying to create web application with client certificates, generated programmatically. My main problem is following: I've added generated .p12 keystore to my web browser, but it doesn't send certificate to the server.
How does browser understand which x509 certificate it should use? And is it possible to debug SSL in Chrome of Firefox?
SSL/TLS server sends Certificate Request message (see RFC 4346 for TLS 1.1 or others). In this message there is only certificate type and acceptable certificate authorities names, so server doesn't tell anything about particular certificate.
The possible reason is that your certificate of invalid type (i.e. DSA instead of RSA but key exchange algorithm depends on client RSA certificate), or server requests certificate of different certificate authority.