How do signed SSL / HTTPS certificates and certificate authorities work?

c-h-r-i-s-t-o-p-h
c-h-r-i-s-t-o-p-h used Ask the Experts™
on
My questions are at the bottom of this post, but first the I'll try to explain the situation.


I am troubleshooting an issue for a user that I have isolated to encryption negotiation.

When attempting to load a website, the site intermittently hangs during initial load for approximately 30 seconds.

I ran wireshark while accessing the website.


During attempts that failed, each of the "Client Hello" messages during the encryption handshake were using SSL. The client send a few tcp keep-alive messages. Then traffic halts for approximately 30 seconds. Then, the client reattempts encryption handshake using SSLv2 "Client Hello" and the server responds with SSLv3 "Server Hello" as expected.

During attempts that behave normally / do no fail, the initial encryption handshake appears to be handled using TLSv1.0.



And now for the questions...

What is involved in SSL / HTTPS negotiation?

How does a signed certificate get verified? (i.e. a certificate from thawte)

How do CA bundles / certificate authorities come in to play?

If a web server that is using a https / ssl cert is installed and TCP port 443 is allowed between the web server and the end user, are there ANY other ports that would need to be open? (i.e. for certificate authorities, certificate verification, etc)

Based on the symptoms / troubleshooting that I described, can any other suggestions or conclusions be made?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
When we visit a website which is configured for SSL, the client first initiates a TCP 3-way handshake, after this happens, client send a client hello in which it sends which SSL Protocol (SSL 3.1-which is TLS 1.0, SSL 3.0, SSL 2.0 etc) it wants to use, the list of all the cipher suites it can use, client random number etc., on the server end, server replies back with the server hello in which it sends the Session ID to use, Server Random No, SSL Version to use, the strongest cipher it supports which is common between the two, server certificate, list of intermediate certificates etc. Now the client needs to check the Server Certificates to make sure it is valid, it has the correct name, it is not revoked which it does by downloading the CRL which could be an HTTP Path, OCSP can also be used in place of the CRL to check if the server certificate is revoked. So the ports that should be open is pretty much 443 and 80, we might require 389 depending upon the CDP/AIA path in the certificate.

Author

Commented:
Sorry to for the trouble.


Can you define CRL? OCSP?

What is the CDP / AIA path?
CRL is the Certificate Revocation List which contains the Serial No, Date and Time and the reason of the certificate that are revoked by the CA. OCSP is an alternative to using CRL's as it gives benefits in terms of request and response being of constant size so you don't need to download a large CRL File.
Both CRL and OCSP provides a way to validate a certificate to make sure that the certificate has not been revoked.

CDP is CRL Distribution Point which contains the locations like an HTTP or LDAP path from where the client will try to download the CRL's.
AIA (Authority Information Access) is an extension which contains the locations from where the client can download the Certificate of the CA to complete the chain if the CA Certificate does not exist locally on the machine so in case of SSL, a client really need a Root CA to be present in the local store and other intermediate CA Certificate can be downloaded by looking into the AIA Paths which again can be http/ldap.

Read out http://technet.microsoft.com/en-us/library/cc770413(WS.10).aspx for more details

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial