Link to home
Start Free TrialLog in
Avatar of c-h-r-i-s-t-o-p-h
c-h-r-i-s-t-o-p-hFlag for United States of America

asked on

How are SSL certificates verified?

What are different methods of verifying / authorizing SSL certificates?

Are there methods that are completed locally on the server and/or client?

Are there methods that can be completed internally in my organization?

Are there methods that require the server and/or client to touch the internet?
Avatar of arnold
arnold
Flag of United States of America image

The verification is part of the issuing process See Verisign, Godaddy, Thwate, or any other SSL issuing entity.
I agree with Mod_MarlEE, seems like a homework question.

TLS V1 standard: http://www.ietf.org/rfc/rfc2246.txt

Baed on SSL V3, SSL was developed by NetScape TLS is the RCF'ed public version of SSL.
Avatar of c-h-r-i-s-t-o-p-h

ASKER

arnold - based on what you have said, am I correct in assuming that ports 443 (and 80?) would need to be open between the server (or client?) and the issuing entity (i.e. thawte, godaddy, verisign, etc). Otherwise, SSL certs will not authorize correctly?

Would the inability for the client and/or server to reach the issuing entity cause clients to hang during initial client hello/server hello handshake?
Avatar of noci
noci

No you need to study further.
port 443 just implements a very specific content (HTTP) over an SSL connection.
port 80 does implement HTTP without SSL.is
like 445 implements CIFS (more or less SMB over SSL)  and port 139 implements SMB without SSL
port 143 is IMAP and 993 IMAP + SSL  etc. etc.

A good starting point: http://www.openssl.org/docs/   this library + toolkit implements SSL (raw SSL)
for the CA part of things try http://wiki.cacert.org/     this organisation has open documentation & sources to create certificates ....

noci - allow me to clarify, I am referring specifically to HTTPS negotiation.
ASKER CERTIFIED SOLUTION
Avatar of noci
noci

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The signing Authorities do not and have no reason to access your sites.
When you request a certificate you present a Certificate Signing Request that includes all the information that identify you/the organization/the site depending on the purpose of the certificate.  The Signing Autority (Certificate Authority, Verisign, Thwate, etc.) have a process on how they validate that the request for the certificate is coming from the correct entity.  Once the documentation/process they have is fullfilled, they use their Certificate to sign your CSR and the result is your certificate.
The distinction between the certificate types comes based on the type of CSR you generate.
I.e. if you use www.somedomain.com, you will get a web certificate, if you use your name and use the appropriate template, you will get a user certificate.  etc.

There are two ways to verify the certificate, OCSP which "checks" at the time of access to make sure this certificate has not been revoked.  The other method deals with checking the signing path to make sure it is Trusted.