asked on How do signed SSL / HTTPS certificates and certificate authorities work?
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?
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?
SSL / HTTPSEncryptionRouters
Last Comment
CERTExpert
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
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
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
Can you define CRL? OCSP?
What is the CDP / AIA path?