Chris, Here are some links that might help:
http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work http://datacenteroverlords.com/2011/09/25/ssl-who-do-you-trust/ The basic idea is that in that when you surf the web, your browser connects to a web server over a TCP connection (in programming lingo this is sometimes called a "socket"). Inherently, this is open to snooping by 3rd parties, so when HTTP traffic goes over this connection, any expectation of privacy is nil. In order to protect the data flowing over the connection, we use "secure sockets" (where "Secure Socket Layer" or SSL comes from). Through the magic of public-key encryption, your web browser can exchange information with an arbitrary web server over an insecure connection in order to establish a secure connection. Of course, on the Internet, the web server you connect to could be some "bad guy" pretending to be a service you want to use, so encrypting the connection is not enough-- you need some way to verify the identity of the server to which you connect. SSL (later called TLS - "Transport Layer Security") solves these problems. The certificates have 2 parts-- a public part and a private key. To prove you are the owner of the public part, you need to use the private key. There are some big, well known players in this game called "Certificate Authorities" ("CA" for short) who we all agree to trust. Your web browsers and/or OS typically comes with a bundle of public certificates in a "trust bundle" that lets your browser verify that any server presenting one of these certificates is who it says it is. The CAs can't just hand out the private keys to these root certificates, though. Instead, the way it works is that when you are setting up a secure host, *you* will generate your own private key, and then you ask a CA to sign it for you. You browser can look at your certificate and see it is signed by a CA it trusts, so it will trust your certificate. As the second link I provided explains, there are also typically intermediate CAs, too. So the broswer sees that your cert was signed by an authority that was itself signed by an authority it trusts, so it can ultimately trust your certificate. How to use SSL certs in practice really depends on the technology you are using. For Tomcat and other Java-based solutions, you typically use the Java keystore and a utility called "keytool". For Apache and Nginx, you typically use openssl command line tools and have keys and certs in PEM-format. Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Monday, January 19, 2015 8:29:46 AM Subject: RE: [cas-user] certifications Thanks Carl, The answer would be all of the above. I have been struggling with these certs for a couple months. I first followed the Jasig,Cas instructions. There are way more certs there than I need. It took me a couple weeks to figure that out. I found that we only need a CAcert, a tomcat cert and an ldap cert. I don’t need ldap client and browser. Right now we can get tomcat to explode cas.war, log into ldap but when you log into cas is says [cid:[email protected]] Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 From: Carl Waldbieser [mailto:[email protected]] Sent: Sunday, January 18, 2015 5:36 PM To: [email protected] Subject: Re: [cas-user] certifications Chris, Do you need more info on ssl certs in general, or how to configure certs for tomcat, or just why CAS uses certs, or all of the above? Thanks, Carl Waldbieser On Jan 17, 2015 12:04 PM, "Chris Cheltenham" <[email protected]<mailto:[email protected]>> wrote: [cid:[email protected]] Does anyone know a way or a class or a document on server certs? I am constantly fighting with these CAS certs and I have no idea what I am doing really. If it works its because I guessed something right not because I know what I am doing. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369<tel:267-586-2369> -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
