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(00000003)
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
FCeMTYPGwaatm7pzCpEB624pFSTh7lTRaXVkWm8H6MAqrnUOCKduwxxwkd99Hc6M
rsRvZa8n7Q==
-----END CERTIFICATE-----
subject=/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative
IT/CN=webui.ashland.edu
issuer=/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
---
No client certificate CA names sent
---
SSL handshake has read 4351 bytes and written 332 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: 4A93F78D22EC7D121452193F531141E5E54860B0FCCC566D5A462F5D5ADC7CAD
Session-ID-ctx:
Master-Key:
AE497F11ACFA4088628F39AFCD30CD04A3F4EA0FAE7C4423338C3AEE22C40F791C6DC110A73F0082FC7870140BDA4560
Key-Arg : 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
>
> --
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
