RE: SSL with multiple Tomcat instances
Crypto Sal, Thank you so much! That was apparently the problem. I got a new certificate from GoDaddy and once it was installed webui ran with no problems. Thanks for all your help. Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Wednesday, August 26, 2009 10:03 PM To: users@tomcat.apache.org Subject: Re: SSL with multiple Tomcat instances Don, I think we found our culprit. (Java). The reason that webadvisor works, because it functions like a true server, your browser is speaking directly to the web server. webui is failing due to Java not trusting the IPS root certificate (which doesn't exist by default in Java 3-6+) Most people should have Java 5 or 6 installed, with some still using Java3(rare) or Java4(some linux people and older Windows users).Java5 is soon to be deprecated by Sun. As you may already know, Java compiling is done client-side vs. server side for your applet. So all of your users must have the IPS root installed in their instance of Java for this cert to work. There's a way to do it, but it is not all that practical. (adding root certs to Java on ALL clients, which may beyond your control) Your best bet is to go with a more ubiquitous Commercial CA (Comodo, Versign, Thawte, GoDaddy, etc.), which would be ones that extend much further than Web Browsers. Java's default cert store is in a file called ca-certs, which is located in the security folder of where java resides. A simple locate cacerts will reveal its locate on the server. From here you can do a keytool -v -list -keystore PATH_TO_KEYSTORE OUTPUT_FILE , keystore pass is changeit, by default. Multiple versions of Java can exist on the same machine, if you would like to see which CAs are more ubiquitous for your installation. --Sal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL with multiple Tomcat instances
Sal, Thanks again. When I connect using port 8443 or 443, or using the FQDN or the IP address, I get the same response from the s_client request. The reason I am using port 8443 is so I don't have to have root running the tomcat instance. My understanding was that you had to be root to allocate ports under 1024. Just to have that extra little bit of security we have a user 'tomcat' that runs the tomcat instances. I didn't want to have to specify the port number in URLs, and we had some problems with people who weren't able to connect out through their company's firewall on port 8443, so we wanted to make it appear that they were connecting on port 443, but really be using 8443. So, when I connect in a browser, I use https://webui.ashland.edu Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Tuesday, August 25, 2009 11:28 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, No problem. You're seeing valid output and yes a Root certificate is self-signed. As per the TLS protocol, it's optional and doesn't need to be there for things to function. What's strange is it's the same output as the webadvisor instance, outside of the FQDN entries of course. When you connect in browsers are you using https://webui.ashland.edu or are you using https://webui.ashland.edu:8443? (I realize you state that you have iptables running to redirect traffic, but you shouldn't really need to do that, unless you have something dire need for Tomcat to be on anything but 443) I'm curious to see what 443's output is. Could you also use s_client to connect to both the FQDN and the IP (using port 443 and 8443), so that we can rule out a DNS issue? --Sal On 08/25/2009 10:49 AM, Don Prezioso wrote: Sal, Thanks so much for the reply. I think the server.xml reference is correct. Here is the connector segment from that instance: Connector port=8443 address=172.18.19.16 maxThreads=600 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=conf/webui.keystore/ We are using 8443 instead of 443 and have iptables set up to reroute any outside traffic that comes in on 443 to 8443. The other instance uses 172.18.19.15 and the default keystore (~/.keystore). As far as I can tell, that is all working OK. Here is what I get from the command openssl s_client -connect webui.ashland.edu:8443: CONNECTED(0003) depth=2 /C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu i:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com 1 s:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es 2 s:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es --- Server certificate -BEGIN CERTIFICATE- MIIGMzCCBZygAwIBAgIDExqhMA0GCSqGSIb3DQEBBQUAMIIBEjELMAkGA1UEBhMC RVMxEjAQBgNVBAgTCUJhcmNlbG9uYTESMBAGA1UEBxMJQmFyY2Vsb25hMSkwJwYD VQQKEyBJUFMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgcy5sLjEuMCwGA1UEChQl Z2VuZXJhbEBpcHNjYS5jb20gQy5JLkYuICBCLUI2MjIxMDY5NTEuMCwGA1UECxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEuMCwGA1UEAxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GCSqGSIb3 DQEJARYRZ2VuZXJhbEBpcHNjYS5jb20wHhcNMDkwODIwMDczNDQ0WhcNMTEwODIw MDczNDQ0WjCBgzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE9oaW8xEDAOBgNVBAcT B0FzaGxhbmQxGzAZBgNVBAoTEkFzaGxhbmQgVW5pdmVyc2l0eTEaMBgGA1UECxMR QWRtaW5pc3RyYXRpdmUgSVQxGjAYBgNVBAMTEXdlYnVpLmFzaGxhbmQuZWR1MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDBbiTihyoSVlDyVkIoMu97eZxKJrv e0SvdhRO5JIG9O5ov82Pa4NtE2xYPvjMOk20ffEs76m/pAUz3CLao4UxjjpfhxNp 1Y2gQc+0u22R6pPmaPHk2hUEBTCGdHaCVHJ0LwFb+mN4lnZg1dntM7KouKMBGAiV AL9HzMAtoRjiQQIDAQABo4IDITCCAx0wCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBkAwCwYDVR0PBAQDAgP4MBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQW BBQwuRGoE8SxdjtLQPKJoHffiYQeizAfBgNVHSMEGDAWgBQOB2DUOckbW12QeyPI
Re: SSL with multiple Tomcat instances
Don, It's very strange that one works and the other does not especially since they're from the same CA and presenting the same information. (Just different common names) I can't connect to your external site [webadvisor] via Firefox 3.5 or Chrome 4.0 due to the fact that your CA's OCSP responder is down.[ Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202) ]. I have to disable OCSP in Firefox 3.5 to continue, but I do get a valid connection. Has the error message changed at all since we've been working? Or are you still getting a response that relates to Unknown Issuer? On Wed, Aug 26, 2009 at 9:01 AM, Don Prezioso dp...@ashland.edu wrote: Sal, Thanks again. When I connect using port 8443 or 443, or using the FQDN or the IP address, I get the same response from the s_client request. The reason I am using port 8443 is so I don't have to have root running the tomcat instance. My understanding was that you had to be root to allocate ports under 1024. Just to have that extra little bit of security we have a user 'tomcat' that runs the tomcat instances. I didn't want to have to specify the port number in URLs, and we had some problems with people who weren't able to connect out through their company's firewall on port 8443, so we wanted to make it appear that they were connecting on port 443, but really be using 8443. So, when I connect in a browser, I use https://webui.ashland.edu Don
RE: SSL with multiple Tomcat instances
When I connect to webui.ashland.edu I get the message in msg1.jpg. When I click on 'More Information...', I get the message in msg2.jpg When I click on 'Certificate Details...' I get what you see in msg3a-c.jpg Now this is the really strange thing. It appears to be a perfectly valid certificate with a valid CA. When connecting to webadvisor.ashland.edu, I see almost identical certificate details (the signature and CN are appropriately different). These are the same messages I have been getting all along. The only thing that I can think is different between the two instances is that the webui instance is behind the firewall and cannot be seen from off campus. I didn't think that was an issue with validating certificates, is it? Thanks again Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Wednesday, August 26, 2009 4:48 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, It's very strange that one works and the other does not especially since they're from the same CA and presenting the same information. (Just different common names) I can't connect to your external site [webadvisor] via Firefox 3.5 or Chrome 4.0 due to the fact that your CA's OCSP responder is down.[ Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202) ]. I have to disable OCSP in Firefox 3.5 to continue, but I do get a valid connection. Has the error message changed at all since we've been working? Or are you still getting a response that relates to Unknown Issuer? On Wed, Aug 26, 2009 at 9:01 AM, Don Prezioso dp...@ashland.edu wrote: Sal, Thanks again. When I connect using port 8443 or 443, or using the FQDN or the IP address, I get the same response from the s_client request. The reason I am using port 8443 is so I don't have to have root running the tomcat instance. My understanding was that you had to be root to allocate ports under 1024. Just to have that extra little bit of security we have a user 'tomcat' that runs the tomcat instances. I didn't want to have to specify the port number in URLs, and we had some problems with people who weren't able to connect out through their company's firewall on port 8443, so we wanted to make it appear that they were connecting on port 443, but really be using 8443. So, when I connect in a browser, I use https://webui.ashland.edu Don - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL with multiple Tomcat instances
Sorry, my pictures got stripped from the message so... msg1.jpg basically says The web site's certificate cannot be verified. Do you want to continue? Name: webui.ashland.edu Publisher: webui.ashland.edu and has a link for more information... msg2.jpg says The certificate was issued by a source that is not trusted. and has a link for Certificate Details... msg3a-c show the certificate chain, including webui.ashland.edu, ipsCA CLASEA1, and IPS SERVIDORES. -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Don Prezioso Sent: Wednesday, August 26, 2009 5:15 PM To: Tomcat Users List Subject: RE: SSL with multiple Tomcat instances When I connect to webui.ashland.edu I get the message in msg1.jpg. When I click on 'More Information...', I get the message in msg2.jpg When I click on 'Certificate Details...' I get what you see in msg3a-c.jpg Now this is the really strange thing. It appears to be a perfectly valid certificate with a valid CA. When connecting to webadvisor.ashland.edu, I see almost identical certificate details (the signature and CN are appropriately different). These are the same messages I have been getting all along. The only thing that I can think is different between the two instances is that the webui instance is behind the firewall and cannot be seen from off campus. I didn't think that was an issue with validating certificates, is it? Thanks again Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Wednesday, August 26, 2009 4:48 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, It's very strange that one works and the other does not especially since they're from the same CA and presenting the same information. (Just different common names) I can't connect to your external site [webadvisor] via Firefox 3.5 or Chrome 4.0 due to the fact that your CA's OCSP responder is down.[ Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202) ]. I have to disable OCSP in Firefox 3.5 to continue, but I do get a valid connection. Has the error message changed at all since we've been working? Or are you still getting a response that relates to Unknown Issuer? On Wed, Aug 26, 2009 at 9:01 AM, Don Prezioso dp...@ashland.edu wrote: Sal, Thanks again. When I connect using port 8443 or 443, or using the FQDN or the IP address, I get the same response from the s_client request. The reason I am using port 8443 is so I don't have to have root running the tomcat instance. My understanding was that you had to be root to allocate ports under 1024. Just to have that extra little bit of security we have a user 'tomcat' that runs the tomcat instances. I didn't want to have to specify the port number in URLs, and we had some problems with people who weren't able to connect out through their company's firewall on port 8443, so we wanted to make it appear that they were connecting on port 443, but really be using 8443. So, when I connect in a browser, I use https://webui.ashland.edu Don - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL with multiple Tomcat instances
Don, ipsCA is having some issues right now. Both OCSP (Online Certificate Status Protocol) and their CRL are DOWN. (It's not a good sign). Earlier, you stated that webui is the problem child, but webadvisor was working fine cross browser (Chrome, Firefox, IE, etc), correct or is this incorrect? Are both serving up pretty much the same content? Based on your description of the error message, it almost sounds like a Java issue. Is it a Java dialog box that comes up? Does it look like this at all? https://knowledge.verisign.com/resources/sites/VERISIGN/content/staging/SOLUTION/9000/SO9007/en_US/0.1/EV%20error.bmp ipsCA does not exist in Java5 or 6 by default. It is in Browsers (IE, Firefox, Chrome, Safari), but not Java or Opera. Attachments are pretty much stripped from this list. You'd either need to use imageshack.us or host elsewhere and provide the URL. --Sal On 08/26/2009 05:21 PM, Don Prezioso wrote: Sorry, my pictures got stripped from the message so... msg1.jpg basically says The web site's certificate cannot be verified. Do you want to continue? Name: webui.ashland.edu Publisher: webui.ashland.edu and has a link for more information... msg2.jpg says The certificate was issued by a source that is not trusted. and has a link for Certificate Details... msg3a-c show the certificate chain, including webui.ashland.edu, ipsCA CLASEA1, and IPS SERVIDORES. -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Don Prezioso Sent: Wednesday, August 26, 2009 5:15 PM To: Tomcat Users List Subject: RE: SSL with multiple Tomcat instances When I connect to webui.ashland.edu I get the message in msg1.jpg. When I click on 'More Information...', I get the message in msg2.jpg When I click on 'Certificate Details...' I get what you see in msg3a-c.jpg Now this is the really strange thing. It appears to be a perfectly valid certificate with a valid CA. When connecting to webadvisor.ashland.edu, I see almost identical certificate details (the signature and CN are appropriately different). These are the same messages I have been getting all along. The only thing that I can think is different between the two instances is that the webui instance is behind the firewall and cannot be seen from off campus. I didn't think that was an issue with validating certificates, is it? Thanks again Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Wednesday, August 26, 2009 4:48 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, It's very strange that one works and the other does not especially since they're from the same CA and presenting the same information. (Just different common names) I can't connect to your external site [webadvisor] via Firefox 3.5 or Chrome 4.0 due to the fact that your CA's OCSP responder is down.[ Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202) ]. I have to disable OCSP in Firefox 3.5 to continue, but I do get a valid connection. Has the error message changed at all since we've been working? Or are you still getting a response that relates to Unknown Issuer? On Wed, Aug 26, 2009 at 9:01 AM, Don Preziosodp...@ashland.edu wrote: Sal, Thanks again. When I connect using port 8443 or 443, or using the FQDN or the IP address, I get the same response from the s_client request. The reason I am using port 8443 is so I don't have to have root running the tomcat instance. My understanding was that you had to be root to allocate ports under 1024. Just to have that extra little bit of security we have a user 'tomcat' that runs the tomcat instances. I didn't want to have to specify the port number in URLs, and we had some problems with people who weren't able to connect out through their company's firewall on port 8443, so we wanted to make it appear that they were connecting on port 443, but really be using 8443. So, when I connect in a browser, I use https://webui.ashland.edu Don - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL with multiple Tomcat instances
Hmmm... Webadvisor serves up pretty much straight HTML, a little javascript, and much of the HTML is generated from another server, but what tomcat is serving up is mostly normal HTML. WebUI however only serves up a single java applet. From that point on, the applet is talking to a completely different server and tomcat is out of the picture. Also, the graphic you sent looks almost identical to the message I am seeing. So... Would the java applet be using the certificate in addition to tomcat? Would I need to add the root certificate to a keystore that Java has somewhere? Thanks for all your help. Don -- Donald Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio From: Crypto Sal [crypto@gmail.com] Sent: Wednesday, August 26, 2009 7:55 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, ipsCA is having some issues right now. Both OCSP (Online Certificate Status Protocol) and their CRL are DOWN. (It's not a good sign). Earlier, you stated that webui is the problem child, but webadvisor was working fine cross browser (Chrome, Firefox, IE, etc), correct or is this incorrect? Are both serving up pretty much the same content? Based on your description of the error message, it almost sounds like a Java issue. Is it a Java dialog box that comes up? Does it look like this at all? https://knowledge.verisign.com/resources/sites/VERISIGN/content/staging/SOLUTION/9000/SO9007/en_US/0.1/EV%20error.bmp ipsCA does not exist in Java5 or 6 by default. It is in Browsers (IE, Firefox, Chrome, Safari), but not Java or Opera. Attachments are pretty much stripped from this list. You'd either need to use imageshack.us or host elsewhere and provide the URL. --Sal On 08/26/2009 05:21 PM, Don Prezioso wrote: Sorry, my pictures got stripped from the message so... msg1.jpg basically says The web site's certificate cannot be verified. Do you want to continue? Name: webui.ashland.edu Publisher: webui.ashland.edu and has a link for more information... msg2.jpg says The certificate was issued by a source that is not trusted. and has a link for Certificate Details... msg3a-c show the certificate chain, including webui.ashland.edu, ipsCA CLASEA1, and IPS SERVIDORES. -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Don Prezioso Sent: Wednesday, August 26, 2009 5:15 PM To: Tomcat Users List Subject: RE: SSL with multiple Tomcat instances When I connect to webui.ashland.edu I get the message in msg1.jpg. When I click on 'More Information...', I get the message in msg2.jpg When I click on 'Certificate Details...' I get what you see in msg3a-c.jpg Now this is the really strange thing. It appears to be a perfectly valid certificate with a valid CA. When connecting to webadvisor.ashland.edu, I see almost identical certificate details (the signature and CN are appropriately different). These are the same messages I have been getting all along. The only thing that I can think is different between the two instances is that the webui instance is behind the firewall and cannot be seen from off campus. I didn't think that was an issue with validating certificates, is it? Thanks again Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Wednesday, August 26, 2009 4:48 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, It's very strange that one works and the other does not especially since they're from the same CA and presenting the same information. (Just different common names) I can't connect to your external site [webadvisor] via Firefox 3.5 or Chrome 4.0 due to the fact that your CA's OCSP responder is down.[ Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202) ]. I have to disable OCSP in Firefox 3.5 to continue, but I do get a valid connection. Has the error message changed at all since we've been working? Or are you still getting a response that relates to Unknown Issuer? On Wed, Aug 26, 2009 at 9:01 AM, Don Preziosodp...@ashland.edu wrote: Sal, Thanks again. When I connect using port 8443 or 443, or using the FQDN or the IP address, I get the same response from the s_client request. The reason I am using port 8443 is so I don't have to have root running the tomcat instance. My understanding was that you had to be root to allocate ports under 1024. Just to have that extra little bit of security we have a user 'tomcat' that runs the tomcat instances. I didn't want to have to specify the port number in URLs, and we had some problems with people who weren't able to connect out through their company's firewall on port 8443, so we wanted to make it appear
Re: SSL with multiple Tomcat instances
Don, I think we found our culprit. (Java). The reason that webadvisor works, because it functions like a true server, your browser is speaking directly to the web server. webui is failing due to Java not trusting the IPS root certificate (which doesn't exist by default in Java 3-6+) Most people should have Java 5 or 6 installed, with some still using Java3(rare) or Java4(some linux people and older Windows users).Java5 is soon to be deprecated by Sun. As you may already know, Java compiling is done client-side vs. server side for your applet. So all of your users must have the IPS root installed in their instance of Java for this cert to work. There's a way to do it, but it is not all that practical. (adding root certs to Java on ALL clients, which may beyond your control) Your best bet is to go with a more ubiquitous Commercial CA (Comodo, Versign, Thawte, GoDaddy, etc.), which would be ones that extend much further than Web Browsers. Java's default cert store is in a file called ca-certs, which is located in the security folder of where java resides. A simple locate cacerts will reveal its locate on the server. From here you can do a keytool -v -list -keystore PATH_TO_KEYSTORE OUTPUT_FILE , keystore pass is changeit, by default. Multiple versions of Java can exist on the same machine, if you would like to see which CAs are more ubiquitous for your installation. --Sal On 08/26/2009 09:19 PM, Don Prezioso wrote: Hmmm... Webadvisor serves up pretty much straight HTML, a little javascript, and much of the HTML is generated from another server, but what tomcat is serving up is mostly normal HTML. WebUI however only serves up a single java applet. From that point on, the applet is talking to a completely different server and tomcat is out of the picture. Also, the graphic you sent looks almost identical to the message I am seeing. So... Would the java applet be using the certificate in addition to tomcat? Would I need to add the root certificate to a keystore that Java has somewhere? Thanks for all your help. Don -- Donald Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio From: Crypto Sal [crypto@gmail.com] Sent: Wednesday, August 26, 2009 7:55 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Don, ipsCA is having some issues right now. Both OCSP (Online Certificate Status Protocol) and their CRL are DOWN. (It's not a good sign). Earlier, you stated that webui is the problem child, but webadvisor was working fine cross browser (Chrome, Firefox, IE, etc), correct or is this incorrect? Are both serving up pretty much the same content? Based on your description of the error message, it almost sounds like a Java issue. Is it a Java dialog box that comes up? Does it look like this at all? https://knowledge.verisign.com/resources/sites/VERISIGN/content/staging/SOLUTION/9000/SO9007/en_US/0.1/EV%20error.bmp ipsCA does not exist in Java5 or 6 by default. It is in Browsers (IE, Firefox, Chrome, Safari), but not Java or Opera. Attachments are pretty much stripped from this list. You'd either need to use imageshack.us or host elsewhere and provide the URL. --Sal On 08/26/2009 05:21 PM, Don Prezioso wrote: Sorry, my pictures got stripped from the message so... msg1.jpg basically says The web site's certificate cannot be verified. Do you want to continue? Name: webui.ashland.edu Publisher: webui.ashland.edu and has a link for more information... msg2.jpg says The certificate was issued by a source that is not trusted. and has a link for Certificate Details... msg3a-c show the certificate chain, including webui.ashland.edu, ipsCA CLASEA1, and IPS SERVIDORES. -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Don Prezioso Sent: Wednesday, August 26, 2009 5:15 PM To: Tomcat Users List Subject: RE: SSL with multiple Tomcat instances When I connect to webui.ashland.edu I get the message in msg1.jpg. When I click on 'More Information...', I get the message in msg2.jpg When I click on 'Certificate Details...' I get what you see in msg3a-c.jpg Now this is the really strange thing. It appears to be a perfectly valid certificate with a valid CA. When connecting to webadvisor.ashland.edu, I see almost identical certificate details (the signature and CN are appropriately different). These are the same messages I have been getting all along. The only thing that I can think is different between the two instances is that the webui instance is behind the firewall and cannot be seen from off campus. I didn't think that was an issue with validating certificates, is it? Thanks again Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Wednesday, August 26, 2009 4:48 PM To: Tomcat Users List Subject: Re
RE: SSL with multiple Tomcat instances
: None Krb5 Principal: None Start Time: 1251211149 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- The certificate chain appears to be correct, but I'm not sure about the few lines before it: depth=2 /C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es verify error:num=19:self signed certificate in certificate chain verify return:0 Isn't the root certificate supposed to be self-signed? I get the same message when I run the command against webadvisor.ashland.edu (the other instance) which doesn't appear to have the same problem. Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Monday, August 24, 2009 8:31 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Hi Don, A few questions: 1) Does server.xml reference the appropriate IP and keystore for webui? 2) What's the output of: [ openssl s_client -connect webui.ashland.edu:443 ] from the box, more specifically just the top area that mentions the certificate chain. It should look something like this... --- Certificate chain 0 s:/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu i:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com 1 s:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es 2 s:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es --- 3) Have you stopped and started the instance in question each time you made a change to the certificates(keystore) or the server.xml file? I don't see any issues with the way you generated the keystore, CSR or how you imported the certificates as that's how I would do it. It's pretty much the way Comodo, Verisign, Thawte, and DigiCert suggest you do so. Without knowing what the server is presenting, it is hard for me to tell you exactly what's wrong. As per RFC2246(TLS protocol), in a chained certificate environment the server must present the full chain (just Intermediates, Root is optional.) so that all RFC compliant clients (Chrome, Firefox, Opera, Safari, etc), can connect easily. (Internet Explorer actually tries to go behind the scenes and grab the intermediates from WindowsUpdate) Using OpenSSL's s_client command, should open things up a bit more and provide us with good information to use. --Sal On 08/24/2009 10:47 AM, Don Prezioso wrote: These are standalone Tomcat instances (Tomcat is the web server, no Apache) running on Red Hat. Each instance has it's own IP address (verified via netstat) and each address has a separate DNS entry (webadvisor.ashland.edu and webui.ashland.edu), each which resolve correctly. Each certificate is generated using the DNS name for the service it is intended for. As far as I can tell, the certificate store is valid. When I use the keytool command to list the original keystore (the one with both certificates loaded in the same keystore), I get the attached listing. When I look at the new one (separate keystores, each with only one certificate) it looks the same except that it is missing the tomcat (the first instance) certificate and only has the webui certificate. The commands I used to create the keystore were: keytool -genkey -alias webui -keyalg RSA -keystore webui.keystore keytool -certreq -alias webui -keystore webui.keystore keytool -import -trustcacerts -alias IPSROOT -file IPSServidores.crt -keystore webui.keystore keytool -import -trustcacerts -alias IPSCAA1 -file IPSCACLASEA1.crt -keystore webui.keystore keytool -import -trustcacerts -alias webui -file webui.crt -keystore webui.keystore The IPSServidores.crt is the IPS root certificate, IPSCACLASEA1.crt is the intermediate certificate, and webui.crt is the certificate reply from IPS. These are the same steps I followed for the webadvisor instance and it is working properly. The only things that I can think are different between these two tomcat instances are: a) The webadvisor instance is visible through our firewall from off campus, and the webui instance is not (I am connecting from on campus) b) The webadvisor instance is using the network device eth0, and webui is using eth0:0 Don
Re: SSL with multiple Tomcat instances
Don, No problem. You're seeing valid output and yes a Root certificate is self-signed. As per the TLS protocol, it's optional and doesn't need to be there for things to function. What's strange is it's the same output as the webadvisor instance, outside of the FQDN entries of course. When you connect in browsers are you using https://webui.ashland.edu or are you using https://webui.ashland.edu:8443? (I realize you state that you have iptables running to redirect traffic, but you shouldn't really need to do that, unless you have something dire need for Tomcat to be on anything but 443) I'm curious to see what 443's output is. Could you also use s_client to connect to both the FQDN and the IP (using port 443 and 8443), so that we can rule out a DNS issue? --Sal On 08/25/2009 10:49 AM, Don Prezioso wrote: Sal, Thanks so much for the reply. I think the server.xml reference is correct. Here is the connector segment from that instance: Connector port=8443 address=172.18.19.16 maxThreads=600 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=conf/webui.keystore/ We are using 8443 instead of 443 and have iptables set up to reroute any outside traffic that comes in on 443 to 8443. The other instance uses 172.18.19.15 and the default keystore (~/.keystore). As far as I can tell, that is all working OK. Here is what I get from the command openssl s_client -connect webui.ashland.edu:8443: CONNECTED(0003) depth=2 /C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu i:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com 1 s:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es 2 s:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es --- Server certificate -BEGIN CERTIFICATE- MIIGMzCCBZygAwIBAgIDExqhMA0GCSqGSIb3DQEBBQUAMIIBEjELMAkGA1UEBhMC RVMxEjAQBgNVBAgTCUJhcmNlbG9uYTESMBAGA1UEBxMJQmFyY2Vsb25hMSkwJwYD VQQKEyBJUFMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgcy5sLjEuMCwGA1UEChQl Z2VuZXJhbEBpcHNjYS5jb20gQy5JLkYuICBCLUI2MjIxMDY5NTEuMCwGA1UECxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEuMCwGA1UEAxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GCSqGSIb3 DQEJARYRZ2VuZXJhbEBpcHNjYS5jb20wHhcNMDkwODIwMDczNDQ0WhcNMTEwODIw MDczNDQ0WjCBgzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE9oaW8xEDAOBgNVBAcT B0FzaGxhbmQxGzAZBgNVBAoTEkFzaGxhbmQgVW5pdmVyc2l0eTEaMBgGA1UECxMR QWRtaW5pc3RyYXRpdmUgSVQxGjAYBgNVBAMTEXdlYnVpLmFzaGxhbmQuZWR1MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDBbiTihyoSVlDyVkIoMu97eZxKJrv e0SvdhRO5JIG9O5ov82Pa4NtE2xYPvjMOk20ffEs76m/pAUz3CLao4UxjjpfhxNp 1Y2gQc+0u22R6pPmaPHk2hUEBTCGdHaCVHJ0LwFb+mN4lnZg1dntM7KouKMBGAiV AL9HzMAtoRjiQQIDAQABo4IDITCCAx0wCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBkAwCwYDVR0PBAQDAgP4MBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQW BBQwuRGoE8SxdjtLQPKJoHffiYQeizAfBgNVHSMEGDAWgBQOB2DUOckbW12QeyPI 0jSdSppGOTAJBgNVHREEAjAAMBwGA1UdEgQVMBOBEWdlbmVyYWxAaXBzY2EuY29t MHIGCWCGSAGG+EIBDQRlFmNPcmdhbml6YXRpb24gSW5mb3JtYXRpb24gTk9UIFZB TElEQVRFRC4gQ0xBU0VBMSBTZXJ2ZXIgQ2VydGlmaWNhdGUgaXNzdWVkIGJ5IGh0 dHBzOi8vd3d3Lmlwc2NhLmNvbS8wLwYJYIZIAYb4QgECBCIWIGh0dHBzOi8vd3d3 Lmlwc2NhLmNvbS9pcHNjYTIwMDIvMEMGCWCGSAGG+EIBBAQ2FjRodHRwczovL3d3 dy5pcHNjYS5jb20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3JsMEYGCWCG SAGG+EIBAwQ5FjdodHRwczovL3d3dy5pcHNjYS5jb20vaXBzY2EyMDAyL3Jldm9j YXRpb25DTEFTRUExLmh0bWw/MEMGCWCGSAGG+EIBBwQ2FjRodHRwczovL3d3dy5p cHNjYS5jb20vaXBzY2EyMDAyL3JlbmV3YWxDTEFTRUExLmh0bWw/MEEGCWCGSAGG +EIBCAQ0FjJodHRwczovL3d3dy5pcHNjYS5jb20vaXBzY2EyMDAyL3BvbGljeUNM QVNFQTEuaHRtbDCBgwYDVR0fBHwwejA5oDegNYYzaHR0cDovL3d3dy5pcHNjYS5j b20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3JsMD2gO6A5hjdodHRwOi8v d3d3YmFjay5pcHNjYS5jb20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3Js MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuaXBzY2Eu Y29tLzANBgkqhkiG9w0BAQUFAAOBgQBWxO6m/tvgkW9Ig55akiS9qeUA9pAmPv3O nvNnVOuEkaEFJTBKHRbV1QfijXg2Dnj8oQymSaDO7uZAJ6+anvuZCyySBDNzKDDq
RE: SSL with multiple Tomcat instances
These are standalone Tomcat instances (Tomcat is the web server, no Apache) running on Red Hat. Each instance has it's own IP address (verified via netstat) and each address has a separate DNS entry (webadvisor.ashland.edu and webui.ashland.edu), each which resolve correctly. Each certificate is generated using the DNS name for the service it is intended for. As far as I can tell, the certificate store is valid. When I use the keytool command to list the original keystore (the one with both certificates loaded in the same keystore), I get the attached listing. When I look at the new one (separate keystores, each with only one certificate) it looks the same except that it is missing the tomcat (the first instance) certificate and only has the webui certificate. The commands I used to create the keystore were: keytool -genkey -alias webui -keyalg RSA -keystore webui.keystore keytool -certreq -alias webui -keystore webui.keystore keytool -import -trustcacerts -alias IPSROOT -file IPSServidores.crt -keystore webui.keystore keytool -import -trustcacerts -alias IPSCAA1 -file IPSCACLASEA1.crt -keystore webui.keystore keytool -import -trustcacerts -alias webui -file webui.crt -keystore webui.keystore The IPSServidores.crt is the IPS root certificate, IPSCACLASEA1.crt is the intermediate certificate, and webui.crt is the certificate reply from IPS. These are the same steps I followed for the webadvisor instance and it is working properly. The only things that I can think are different between these two tomcat instances are: a) The webadvisor instance is visible through our firewall from off campus, and the webui instance is not (I am connecting from on campus) b) The webadvisor instance is using the network device eth0, and webui is using eth0:0 Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Thursday, August 20, 2009 8:00 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Hi Don, Is this Tomcat for Windows or Tomcat for a UNIX variant? Have you verified the keystore as correct via * keytool -v -list -keystore KEYSTORE_PATH/FILE* ? (Redirect that text to a file if need be!) Did you use the *-trustcacerts* flag upon importing the certificates or was this omitted? Keystore type: jks Keystore provider: SUN Your keystore contains 4 entries Alias name: webui Creation date: Aug 10, 2009 Entry type: keyEntry Certificate chain length: 3 Certificate[1]: Owner: CN=webui.ashland.edu, OU=Administrative IT, O=Ashland University, L=Ashland, ST=Ohio, C=US Issuer: emailaddress=gene...@ipsca.com, CN=ipsCA CLASEA1 Certification Authority, OU=ipsCA CLASEA1 Certification Authority, O=gene...@ipsca.com C.I.F. B-B62210695, O=IPS Certification Authority s.l., L=Barcelona, ST=Barcelona, C=ES Serial number: 131938 Valid from: Mon Aug 10 16:25:00 EDT 2009 until: Wed Aug 10 16:25:00 EDT 2011 Certificate fingerprints: MD5: 2D:97:A3:54:26:FE:8F:A6:09:09:DB:BA:A4:E5:A2:7D SHA1: 28:CD:12:8D:D6:42:CC:FA:A4:20:56:04:E4:E3:08:C6:BE:EA:EA:02 Certificate[2]: Owner: emailaddress=gene...@ipsca.com, CN=ipsCA CLASEA1 Certification Authority, OU=ipsCA CLASEA1 Certification Authority, O=gene...@ipsca.com C.I.F. B-B62210695, O=IPS Certification Authority s.l., L=Barcelona, ST=Barcelona, C=ES Issuer: emailaddress=...@mail.ips.es, CN=IPS SERVIDORES, OU=Certificaciones, O=IPS Seguridad CA, L=BARCELONA, ST=BARCELONA, C=ES Serial number: 9018 Valid from: Sun Dec 30 08:36:11 EST 2001 until: Mon Dec 29 08:36:11 EST 2025 Certificate fingerprints: MD5: BB:3A:D2:38:EB:40:C2:EA:BA:F2:CE:62:2E:33:C8:BB SHA1: BD:B7:46:A9:82:7E:9E:19:DD:43:C1:B8:48:10:55:22:D0:13:E7:EC Certificate[3]: Owner: emailaddress=...@mail.ips.es, CN=IPS SERVIDORES, OU=Certificaciones, O=IPS Seguridad CA, L=BARCELONA, ST=BARCELONA, C=ES Issuer: emailaddress=...@mail.ips.es, CN=IPS SERVIDORES, OU=Certificaciones, O=IPS Seguridad CA, L=BARCELONA, ST=BARCELONA, C=ES Serial number: 0 Valid from: Thu Jan 01 18:21:07 EST 1998 until: Tue Dec 29 18:21:07 EST 2009 Certificate fingerprints: MD5: 7B:B5:08:99:9A:8C:18:BF:85:27:7D:0E:AE:DA:B2:AB SHA1: 24:BA:6D:6C:8A:5B:58:37:A4:8D:B5:FA:E9:19:EA:67:5C:94:D2:17 *** *** Alias name: ipscaa1 Creation date: Jan 9, 2008 Entry type: trustedCertEntry Owner: emailaddress=gene...@ipsca.com, CN=ipsCA CLASEA1 Certification Authority, OU=ipsCA CLASEA1 Certification Authority, O=gene...@ipsca.com C.I.F. B-B62210695, O=IPS Certification Authority s.l., L=Barcelona, ST=Barcelona, C=ES Issuer: emailaddress=...@mail.ips.es, CN=IPS SERVIDORES, OU=Certificaciones, O=IPS Seguridad CA, L=BARCELONA, ST=BARCELONA, C=ES Serial number: 9018 Valid from: Sun Dec 30 08:36:11 EST 2001 until: Mon Dec 29 08:36:11 EST 2025 Certificate fingerprints: MD5: BB
Re: SSL with multiple Tomcat instances
Hi Don, A few questions: 1) Does server.xml reference the appropriate IP and keystore for webui? 2) What's the output of: [ openssl s_client -connect webui.ashland.edu:443 ] from the box, more specifically just the top area that mentions the certificate chain. It should look something like this... --- Certificate chain 0 s:/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu i:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com 1 s:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es 2 s:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es --- 3) Have you stopped and started the instance in question each time you made a change to the certificates(keystore) or the server.xml file? I don't see any issues with the way you generated the keystore, CSR or how you imported the certificates as that's how I would do it. It's pretty much the way Comodo, Verisign, Thawte, and DigiCert suggest you do so. Without knowing what the server is presenting, it is hard for me to tell you exactly what's wrong. As per RFC2246(TLS protocol), in a chained certificate environment the server must present the full chain (just Intermediates, Root is optional.) so that all RFC compliant clients (Chrome, Firefox, Opera, Safari, etc), can connect easily. (Internet Explorer actually tries to go behind the scenes and grab the intermediates from WindowsUpdate) Using OpenSSL's s_client command, should open things up a bit more and provide us with good information to use. --Sal On 08/24/2009 10:47 AM, Don Prezioso wrote: These are standalone Tomcat instances (Tomcat is the web server, no Apache) running on Red Hat. Each instance has it's own IP address (verified via netstat) and each address has a separate DNS entry (webadvisor.ashland.edu and webui.ashland.edu), each which resolve correctly. Each certificate is generated using the DNS name for the service it is intended for. As far as I can tell, the certificate store is valid. When I use the keytool command to list the original keystore (the one with both certificates loaded in the same keystore), I get the attached listing. When I look at the new one (separate keystores, each with only one certificate) it looks the same except that it is missing the tomcat (the first instance) certificate and only has the webui certificate. The commands I used to create the keystore were: keytool -genkey -alias webui -keyalg RSA -keystore webui.keystore keytool -certreq -alias webui -keystore webui.keystore keytool -import -trustcacerts -alias IPSROOT -file IPSServidores.crt -keystore webui.keystore keytool -import -trustcacerts -alias IPSCAA1 -file IPSCACLASEA1.crt -keystore webui.keystore keytool -import -trustcacerts -alias webui -file webui.crt -keystore webui.keystore The IPSServidores.crt is the IPS root certificate, IPSCACLASEA1.crt is the intermediate certificate, and webui.crt is the certificate reply from IPS. These are the same steps I followed for the webadvisor instance and it is working properly. The only things that I can think are different between these two tomcat instances are: a) The webadvisor instance is visible through our firewall from off campus, and the webui instance is not (I am connecting from on campus) b) The webadvisor instance is using the network device eth0, and webui is using eth0:0 Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: Crypto Sal [mailto:crypto@gmail.com] Sent: Thursday, August 20, 2009 8:00 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances Hi Don, Is this Tomcat for Windows or Tomcat for a UNIX variant? Have you verified the keystore as correct via * keytool -v -list -keystore KEYSTORE_PATH/FILE* ? (Redirect that text to a file if need be!) Did you use the *-trustcacerts* flag upon importing the certificates or was this omitted? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL with multiple Tomcat instances
I have two instances of Tomcat 5.5 set up on a Red Hat box, each using separate IP addresses. I have obtained two certificates, one for each instance, and have put them in separate keystores. Both certificates are from IPSCA and both keystores have been set up in the same manner. Each keystore is properly referenced in the associated server.xml The first instance (on eth0) is working with no problems. The second instance (on eth0:0), appears to work fine in IE, but when I connect using Firefox, Chrome, or Safari, I get the message: The web site's certificate cannot be verified. Do you want to continue? The certificate cannot be verified by a trusted source. When I view the certificate, it appears valid. If I click on 'Yes', then check the certificate, it says it is 'Verified by: IPS Certification Authority s.l.' and again, all appears fine. Any ideas on why I am only getting the warning only on the second instance? I can't believe it is an issue with IPSCA since the first instance does not exhibit the problem. Any help is greatly appreciated. Thanks Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio
Re: SSL with multiple Tomcat instances
2009/8/20 Don Prezioso dp...@ashland.edu: I have two instances of Tomcat 5.5 set up on a Red Hat box, each using separate IP addresses. I have obtained two certificates, one for each instance, and have put them in separate keystores. Both certificates are from IPSCA and both keystores have been set up in the same manner. Each keystore is properly referenced in the associated server.xml The first instance (on eth0) is working with no problems. The second instance (on eth0:0), appears to work fine in IE, but when I connect using Firefox, Chrome, or Safari, I get the message: The web site's certificate cannot be verified. Do you want to continue? The certificate cannot be verified by a trusted source. When I view the certificate, it appears valid. If I click on 'Yes', then check the certificate, it says it is 'Verified by: IPS Certification Authority s.l.' and again, all appears fine. Any ideas on why I am only getting the warning only on the second instance? I can't believe it is an issue with IPSCA since the first instance does not exhibit the problem. Hmm. This probably won't help you, but I recently had exactly those symptoms when I hadn't installed the intermediate certificate for a GlobalSign cert on an IIS server. IE didn't care; everything else got upset. Do IPSCA use intermediate certs? If so, are you *sure* they're installed correctly on both keystores? ;-) - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL with multiple Tomcat instances
Peter, Thanks for the reply. When I first started having this problem I was actually using a single keystore for both certificates. Yes there is both an intermediate and a root certificate that get loaded in the keystore, and I'm sure, at least when I was using a single keystore that they were loaded correctly because the other instance (and certificate) were working correctly. With the second instance using a separate keystore, I get the same results whether the intermediate certificate is loaded in the keystore or not. That makes me think that somehow the second instance of Tomcat can't access the intermediate certificate, but somehow the first instance doesn't have that trouble? Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Thursday, August 20, 2009 4:40 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances 2009/8/20 Don Prezioso dp...@ashland.edu: I have two instances of Tomcat 5.5 set up on a Red Hat box, each using separate IP addresses. I have obtained two certificates, one for each instance, and have put them in separate keystores. Both certificates are from IPSCA and both keystores have been set up in the same manner. Each keystore is properly referenced in the associated server.xml The first instance (on eth0) is working with no problems. The second instance (on eth0:0), appears to work fine in IE, but when I connect using Firefox, Chrome, or Safari, I get the message: The web site's certificate cannot be verified. Do you want to continue? The certificate cannot be verified by a trusted source. When I view the certificate, it appears valid. If I click on 'Yes', then check the certificate, it says it is 'Verified by: IPS Certification Authority s.l.' and again, all appears fine. Any ideas on why I am only getting the warning only on the second instance? I can't believe it is an issue with IPSCA since the first instance does not exhibit the problem. Hmm. This probably won't help you, but I recently had exactly those symptoms when I hadn't installed the intermediate certificate for a GlobalSign cert on an IIS server. IE didn't care; everything else got upset. Do IPSCA use intermediate certs? If so, are you *sure* they're installed correctly on both keystores? ;-) - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL with multiple Tomcat instances
Hi Don, Is this Tomcat for Windows or Tomcat for a UNIX variant? Have you verified the keystore as correct via * keytool -v -list -keystore KEYSTORE_PATH/FILE* ? (Redirect that text to a file if need be!) Did you use the *-trustcacerts* flag upon importing the certificates or was this omitted? On 08/20/2009 04:49 PM, Don Prezioso wrote: Peter, Thanks for the reply. When I first started having this problem I was actually using a single keystore for both certificates. Yes there is both an intermediate and a root certificate that get loaded in the keystore, and I'm sure, at least when I was using a single keystore that they were loaded correctly because the other instance (and certificate) were working correctly. With the second instance using a separate keystore, I get the same results whether the intermediate certificate is loaded in the keystore or not. That makes me think that somehow the second instance of Tomcat can't access the intermediate certificate, but somehow the first instance doesn't have that trouble? Don -- Don Prezioso Director of Administrative I.T. Ashland University Ashland, Ohio -Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Thursday, August 20, 2009 4:40 PM To: Tomcat Users List Subject: Re: SSL with multiple Tomcat instances 2009/8/20 Don Preziosodp...@ashland.edu: I have two instances of Tomcat 5.5 set up on a Red Hat box, each using separate IP addresses. I have obtained two certificates, one for each instance, and have put them in separate keystores. Both certificates are from IPSCA and both keystores have been set up in the same manner. Each keystore is properly referenced in the associated server.xml The first instance (on eth0) is working with no problems. The second instance (on eth0:0), appears to work fine in IE, but when I connect using Firefox, Chrome, or Safari, I get the message: The web site's certificate cannot be verified. Do you want to continue? The certificate cannot be verified by a trusted source. When I view the certificate, it appears valid. If I click on 'Yes', then check the certificate, it says it is 'Verified by: IPS Certification Authority s.l.' and again, all appears fine. Any ideas on why I am only getting the warning only on the second instance? I can't believe it is an issue with IPSCA since the first instance does not exhibit the problem. Hmm. This probably won't help you, but I recently had exactly those symptoms when I hadn't installed the intermediate certificate for a GlobalSign cert on an IIS server. IE didn't care; everything else got upset. Do IPSCA use intermediate certs? If so, are you *sure* they're installed correctly on both keystores? ;-) - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL with multiple Tomcat instances
Any ideas on why I am only getting the warning only on the second instance? I can't believe it is an issue with IPSCA since the first instance does not exhibit the problem. Hi Don, Are you certain that each tomcat instance is bound to a seperate IP? (netstat -anp | grep java is useful for confirming this). Do you have distinct DNS entries for each IP, and were the SSL certificates each created using these distinct DNS names? Cheers, Ben - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
