Thanks Mearl! This really helps me out a lot! Evan
On Wed, Oct 24, 2012 at 5:15 PM, Danner, Mearl <[email protected]> wrote: > 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]> 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] as: > [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] 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 > > -- Evan Sheffield *Developer* iVantage Health Analytics™ | Formerly HMC, Inc. 300 Chestnut Street, Suite 101 | Needham, MA 02492 o: 781.449.5287 | f: 781.449.8058 email: [email protected] web: www.iVantageHealth.com<http://www.ivantagehealth.com/> -- 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
