This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
ServerCertificate
ServerCertificate

Version management

Difference between version and

At line 1 added 25 lines
!!! Overview
[{$pagename}] describes a Step within the [TLS Handshake] process.
The server sends a [certificate], which contains its [Public Key]. This message is almost always sent, except if the [Cipher Suite] mandates a handshake without a certificate.
If the server requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.
!! [certificate_list][1]
Actually, the server sends a "certificate_list" which is described in [RFC 5246] as:
''This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list.
Each following certificate __MUST__ directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the [Self-signed Certificate] that specifies the [root certificate authority|Root Certificate] __MAY__ be omitted from the chain, under the assumption that the remote end __must__ already possess it in order to validate it in any case.''
If the certificate_list contains the [Root Certificate] [SSL]/[TLS] will work but is __NOT__ recommended. The properly implemented [client|User-agent] must have all the valid [Root Certificates] in its [Trust Anchor Store] and __MUST NOT__ trust a [Root Certificates] distributed over an __insecure__ connection from a random site.
If a [client|User-agent] wants to exempt your site from certificate validation, they __SHOULD NOT__ add your [Root Certificate] to [Certificate Trust Store|Trust Anchor Store]. More than likely that user is not aware that they open door to nearly all their SSL connections (except pinned ones). They should only ever trust your [Site Certificate] (aka the leaf certificate).
The popular [ssllabs.com test site|https://www.ssllabs.com/|target='_blank'] issues a minor warning in case a root is concatenated, describing the connection with something like "contains anchor".
Technically, the only bad thing that can be told about sending the [Root Certificate] in the [chain|Certificate Chain] is that it uses a bit of network bandwidth needlessly. That's about 1 kB data per connection which includes a [Full TLS Handshake|TLS Full Handshake]. In a typical session between a [client (Web browser)|User-agent] and a server, only one connection will be of that type as the other connections from the client will use "[Abbreviated TLS Handshake|TLS Abbreviated Handshake]" which build on the initial handshake, and do not use certificates at all. And each connection will be kept alive for many successive HTTP requests. So the network overhead implied by the placing the [Root Certificate] in the certificate_list is slight.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [ssltest: Chain issues - Contains anchor|https://security.stackexchange.com/questions/24561/ssltest-chain-issues-contains-anchor/|target='_blank'] - based on information obtained 2016-04-30-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop