When you buy a cert there is usually a bundle that includes the server certificate and the intermediate and root certificates.
The root CAs are usually included with most current operating systems (or browsers in the case of Firefox). Not so with the intermediates. If you are using tomcat listening on ssl then the whole chain will need to be included in the keystore that tomcat uses. Then the web server will provide the intermediate cert to the browser. If you are using Apache as the web server and an ajp connector to tomcat the chain can be included in the apache config. Much easier than adding things to the tomcat keystore. Mearl From: Sheffield, Evan [mailto:[email protected]] Sent: Wednesday, October 24, 2012 4:01 PM To: [email protected] Cc: [email protected] Subject: Re: [cas-user] Certificate confusion Hi Philippe, Thanks so much for your response. I tried using a certificate signed by our internal certificate authority as the certificate for the CAS server (rather than the self-signed one I was using before). Then I gave the .crt for our certificate authority to phpCAS, and everything works nicely. I suppose this is similar to your setup, except there is no intermediate CA, only the root. This is perfectly fine for development, but I'm curious how things would differ in production. Naturally, I will want to use a certificate authority such as Thawte, GoDaddy, etc. to sign my CAS server's certificate, rather than our self-signed internal CA. I've never purchased certificates like this before so I don't quite know how it would work, but I'm sure I can safely assume that I won't have access to the CA chain that one of those companies uses. In such a case, what am I to provide to the phpCAS client? Or because they are signed by these widely recognized authorities, would phpCAS not even need the CA chain to validate the server? Right now I'm pondering using a certificate signed by Thawte, etc. as an "external" certificate to identify the CAS server to the browser, and keeping the one signed by our own CA as an "internal" certificate to identify the CAS server to our client applications. I've been trying to configure such a setup in Tomcat, though I'm not sure if this recommended or even possible. Thanks, Evan Sheffield iVantage Health Analytics On Mon, Oct 22, 2012 at 7:29 AM, Philippe MARASSE <[email protected]<mailto:[email protected]>> wrote: Hello, according to your openssl commands, You seems to use a self signed certificate. So if you want phpCAS to validate server certificate, you have to provide phpCAS the same certificate used by your CAS server. In our case, it's a bit different : Root CA => Intermediate CA => server certificate. "server certificate" (and corresponding private key) is used by our CAS server. Certificates of root and intermediate CA are bundled into a single file and provided to phpCAS to validate server certificate Rgds. Le 19/10/2012 23:33, Sheffield, Evan a écrit : Hi everyone, I have a question regarding certificates and in particular what certificate should be provided to a service provider. I admit that I know very little about how certificates work, so please bear with me. For my CAS instance, I've created my own Certificate Authority which I'm using to make a self-signed certificate. I've created a keystore with my certificate, CA, and key, which I'm providing to Tomcat in the server.xml. This lets me access tomcat and the CAS server over HTTPS. Next, I have a php application which I've CASified with phpCAS. I'm calling phpCAS::setCasServerCACert($cas_server_ca_cert_path) to enable certificate checking. Where I'm confused is that in the sample config.php, there is a comment saying that the certificate path is the "path to the ca chain that issued the cas server certificate". This led me to believe that I should give it my Certificate Authority, ca.crt. However, authentication failed and the logs reported CURL error #60, SSL Certificate Problem. Instead I tried giving it the actual certificate that I created, cas.crt. Doing so, authentication works just fine. But AFAIK, cas.crt is just the certificate that the cas server uses, which is public. If this is the case, I don't see how it affords any extra security to have the SP check the identical certificate against the server. I would have thought that maybe it would have the private Certificate Authority which could assert the validity of the server's certificate. I feel completely lost on this, so any explanation that you could provide would be incredibly helpful. If it helps at all, below I've included the steps I used to create my certificates via OpenSSL. Thanks, Evan Sheffield iVantage Health Analytics ~~~~~~~~~~~~~~~~~~~~~~~~~~ openssl genrsa -out ca.key 1024 // Create private key openssl req -new -key ca.key -out ca.csr // Create certificate signing request openssl x509 -req -days 3652 -in ca.csr -signkey ca.key -out ca.crt // Certificate authority openssl x509 -req -days 3652 -CA ca.crt -CAkey ca.key // Certificate openssl pkcs12 -export -in cas.crt -inkey ca.key -out keyst.p12 -name tomcat -CAfile ca.crt -caname root // keystore In Tomcat's server.xml: <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="keyst.p12" keystorePass="changeme" keystoreType="PKCS12"/> Providing ca.crt to the SP doesn't work, providing cas.crt does work. -- 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 -- Philippe MARASSE Service Informatique - Centre Hospitalier Henri Laborit BP 587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19 -- 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
