I was wondering why you need a certificate of the server at client side. Can't you just fetch it from the CA itself? I am using mbedtls to program some small client, and in all the client examples they use a certificate of the server. However, if you need to specify the server certificate to be able to make a connection to it, then how are browsers able to verify all secure websites? I don't think they have all certificates of all servers hard coded (which is off course not possible as new secure websites arise every day)
1
-
$\begingroup$ Could you provide with the sample code you are talking about? That way we would know, which certificates you are actually talking about. $\endgroup$– matJul 3, 2017 at 14:24
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
I think you are confusing something in the mbedTLS ssl_client1 example. The example does not specifiy the server certificate, but the CA (Certificate Authority) certificate. The client loads the CA certificate into its CA chain. Later on it still requests the certificate from the server (ssl_handshake step) and uses the public key inside the CA certificate to verify the certificate it received from the server.
$\begingroup$
$\endgroup$
Part of the TLS handshake is that the server sends the client its certificate before setting up the secured connection. The client should verify that the certificate is valid, e.g. check whether the CA has indeed signed the certificate, whether it has not been revoked/expired, etc.
It would not make much sense to fetch the certificate from the CA, as the server (1) needs to tell you who the CA is, you then (2) have to craft a request to the CA to obtain the certificate, you then (3) have to send out the request and (4) wait for a response. It is much easier if the server sends its own certificate: it is more time-efficient, while it is not in any way less safe than requesting it directly from a CA (because of the aforementioned checks).
