I may have been under the wrong impression on how servers should be setup and what certificates actually get sent over during the server hello certificate message. I came across this today from Symantec/VeriSign:
Root installed on the server. For best practices, remove the self-signed root from the server. The certificate bundle should only include the certificate's public key, and the public key of any intermediate certificate authorities. Browsers will only trust certificates that resolve to roots that are already in their trust store, they will ignore a root certificate sent in the certificate bundle (otherwise, anyone could send any root).
If this is true, and root cert does not need to be installed on the server, well, there goes what I thought I knew about proper server setup and how the chain gets validated back to the root. Then again, when I look back at this question, under Certificates and Authentication section of Thomas Pornin's answer it says:
So the client is supposed to do the following:
- Get a certificate chain ending with the server's certificate. The Certificate message from the server is supposed to contain, precisely, such a chain.
This says pretty much the opposite of the Symantec/VeriSign message above, unless I am misunderstanding something. So:
Does a server need the complete chain installed, including the root? If not, what does a browser use to compare against for validation since the server won't be supplying its root cert during the handshake? Does it simply look at the identity cert and get it from there? (Like opening up an identity cert on your local machine, and seeing the full chain in the certification path?)
Again if this is true what about stand-alone client apps that use SSL libraries? Will this depend on the application since it may have different path building methods to a trusted root vs a browser?