3

When we look at StackExchange's server certificate (by clicking on the Lock icon), it says:

This certificate is intended for the following purposes:

Ensures the identity of a remote computer.
Proves your identity to a remote computer.

I thought that the server certificate contains the public key of the server, thus ensuring its identity to the client.

Then how is it also able to ensure the client's identity?

Anmol Singh Jaggi
  • 695
  • 1
  • 6
  • 8

2 Answers2

5

What you see is not how the certificate is used but how the certificate can be used. This certificate can be used and also is used to authenticate a server against a client. It can also be used as a client certificate to authenticate a client against a server - although it is currently not used that way.

Using the same certificate for server and client authentication is useful in cases where a system/application can take both client and server roles. This is for example the case when transferring a mail between two mail servers or when SIP (VoIP) devices communicate with each other (a call might be created by both).

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • This brings another question - Does the client(the browser) has its own ssl certificate? Because I did not create any ever. – Anmol Singh Jaggi Feb 14 '19 at 11:27
  • 3
    @AnmolSinghJaggi: New questions should not be asked in a comment but as a new question. But in short: browsers do not come with a client certificate pre-installed and most sites don't require one. For those site which need client certificates it is possible to import the appropriate client certificates into the browser. – Steffen Ullrich Feb 14 '19 at 11:31
0

To understand how the client is also verified requires understanding a bit about how TLS works. Let's use an https connection to https://security.stackexchange.com as an example:

  1. I connect to https://security.stackexchange.com and am sent their cert signed by Digicert Inc vouching that the cert- and the stackexchange's key I've been sent- belong to the domain stackexchange.com.

  2. I use stackexchange's public key to encrypt data I'll send them to create symmetrical keys to encrypt our session. This ensures that the resulting keys are not compromised.

  3. Only stackexchange can decrypt the data I sent them which was encrypted with their public key- they have the corresponding secret key.

  4. Once the symmetrically key encrypted session has commenced, stackexchange's public key is no longer used.

SO: The result is a pair of symmetric keys: I have one, stackexchange has the same one. Since these keys were built using stackexchange's public key when passing the data, so when I now communicate with stackexchange, it could ONLY be me- unless stackexchange's secret key was somehow fatally compromised.

I could be sure stackexchange was stackexchange at the beginning of our interaction because Digicert endorsed their cert containing their public key. Stackexchange could be sure it was me because I used their Public key to safeguard the key material I passed to them to build the symmetrical keys using their trusted public key ensuring nobody in the middle could derive the symmetrical keys we would now be using.

F1Linux
  • 207
  • 2
  • 6
  • This rather sketchy description of TLS is about 5 years out of date for most web servers today (e.g. Qualys/SSLLabs finds 3/4 of Alexa top 150k use PFS at least with 'modern' browsers) and doesn't address at all the actual Q which is the certificate 'purpose' extension i.e. ExtendedKeyUsage. – dave_thompson_085 Mar 09 '19 at 05:01
  • The question was "Then how is it [server certificate] also able to ensure the client's identity?" and it specifically references stackexchange's server certificate when the poster clicks on the lock in their browser address bar. If you execute `openssl s_client -tls1_2 -connect security.stackexchange.com:443 -servername security.stackexchange.com` you'll see the connection, is in fact, TLS 1.2. Given these set of facts I believe I've addressed exactly the question posed. And the level of detail provided on TLS was to speak to how that connection serves to also verify the client to the server – F1Linux Mar 09 '19 at 09:18