Re: SSL issue
On 08/26/2011 11:24 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Savitha, On 8/25/2011 7:01 PM, Savitha Akella wrote: Connector protocol=org.apache.coyote.http11.Http11Protocol port=443 maxThreads=150 scheme=https secure=true SSLEnabled=true Okay. keystoreFile=d:/users/apache-tomcat-7.0.11/keystore/key.keystore keyAlias=keyalias keyPass=changeit Okay. clientAuth=true truststoreFile=D:/users/apache-tomcat-7.0.11/keystore/trust.keystore truststorePass=changeit SSLVerifyClient=require Okay. sslProtocol=TLS Should probably be SSLProtocol, but might not matter. Also, TLS is not a documented valid value for this attribute. http://tomcat.apache.org/tomcat-7.0-doc/config/http.html Kindly double-check your data. I see that its the default and doesn't need to be defined but is probably defined for clarity. SSLEngine=on SSLEngine is not a recognized attribute. It is for the Listener container. This would turn on/off APR. Seems like a simple mistake. SSLVerifyDepth=4 / Regards, Savitha On Thu, Aug 25, 2011 at 11:46 AM, Christopher Schultz ch...@christopherschultz.net wrote: Savitha, On 8/25/2011 12:53 PM, Savitha Akella wrote: We have given the trustStorePass value to point to a keystore which has only the certificate for our web services. Do you mean truststoreFile? Of course the clientAuth parameter is set to true. Good. Can you post yourConnector configuration for us? Remember to remove any passwords from it. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Xur0ACgkQ9CaO5/Lv0PC4sACgraqr86G+o/CQ4m4pfn7SRoVy NkYAoJhi4pR9EVYbeXbEEcYdSAgJ28+b =jKq/ -END PGP SIGNATURE- - 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: SLL Certificate Chain
On 05/23/2011 04:53 AM, Dipl.-Ing. Mag. Bernhard Hobiger wrote: Hi, I am running Tomcat 6.0.18 64bit on Windows Server 2008 R2 Enterprise. I obtained a certificate for my server from StartCom, installed it and configured the Connector. The server, intermediate and root certificates are in a keystore file. So far all went fine, except for one problem: Tomcat sends only the server certificate, not the whole certificate chain. This means that Firefox (all newer versions) thinks the certificate is invalid. I tried to import the StartCom certificates into the default keystore cacerts, no difference. The problem is not that Tomcat cant validate the certificate, but that the intermediate certificate is not sent (verified with Wireshark). I tried to set all entries in logging.properties to ALL, but I dont get anything in my logs. Has anyone encountered the same behaviour? server.xml: Connector protocol=org.apache.coyote.http11.Http11Protocol port=443 SSLEnabled=true maxThreads=150 scheme=https secure=true keystoreFile=C:\Program Files\Apache Software Foundation\Tomcat 6.0\tomcat.keystore keystorePass=... keyAlias=intern clientAuth=false sslProtocol=TLS / keytool -list -keystore tomcat.keystore: Keystore-Typ: JKS Keystore-Provider: SUN Ihr Keystore enthält 3 Einträge. startcom.ca.sub, 23.05.2011, trustedCertEntry, Zertifikatsfingerabdruck (MD5): 4F:9B:88:B0:78:F3:16:9F:19:DC:F1:A3:8A:50:DD:82 startcom.ca, 23.05.2011, trustedCertEntry, Zertifikatsfingerabdruck (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 intern, 23.05.2011, PrivateKeyEntry, Zertifikatsfingerabdruck (MD5): 30:93:DB:AD:5A:DB:76:00:49:EC:EA:0F:4B:9E:C3:3C keytool -list -v -keystore tomcat.keystore: (output shortened) Keystore-Typ: JKS Keystore-Provider: SUN Ihr Keystore enthält 3 Einträge. Aliasname: startcom.ca.sub Erstellungsdatum: 23.05.2011 Eintragstyp: trustedCertEntry Eigner: CN=StartCom Class 2 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Aussteller: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Seriennummer: b Gültig von: Wed Oct 24 22:57:08 CEST 2007 bis: Mon Oct 22 22:57:08 CEST 2012 Digitaler Fingerabdruck des Zertifikats: MD5: 4F:9B:88:B0:78:F3:16:9F:19:DC:F1:A3:8A:50:DD:82 SHA1: A9:C3:A1:41:78:DF:B2:B1:D1:94:1D:5E:3F:56:DA:FA:E2:E1:40:37 Unterschrift-Algorithmusname: SHA1withRSA Version: 3 ... *** *** Aliasname: startcom.ca Erstellungsdatum: 23.05.2011 Eintragstyp: trustedCertEntry Eigner: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Aussteller: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Seriennummer: 1 Gültig von: Sun Sep 17 21:46:36 CEST 2006 bis: Wed Sep 17 21:46:36 CEST 2036 Digitaler Fingerabdruck des Zertifikats: MD5: 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 SHA1: 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F Unterschrift-Algorithmusname: SHA1withRSA Version: 3 ... *** *** Aliasname: intern Erstellungsdatum: 23.05.2011 Eintragstyp: PrivateKeyEntry Zertifikatskettenlänge: 1 Zertifikat[1]: Eigner: EMAILADDRESS=postmas...@htl-klu.atmailto:EMAILADDRESS=postmas...@htl-klu.at, CN=intern.htl-klu.at, OU=StartCom Verified Certificate Member, O=Bernhard Hobiger, L=Klagenfurt, ST=Karnten, C=AT, OID.2.5.4.13=165616-YmmhPnif68b3zfKu Aussteller: CN=StartCom Class 2 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Seriennummer: 1a3d Gültig von: Thu Mar 18 09:26:36 CET 2010 bis: Mon Mar 19 00:20:28 CET 2012 Digitaler Fingerabdruck des Zertifikats: MD5: 30:93:DB:AD:5A:DB:76:00:49:EC:EA:0F:4B:9E:C3:3C SHA1: AD:21:D5:1B:83:BB:DF:A7:61:BA:BD:E0:F9:7A:13:8B:F9:EF:8A:CC Unterschrift-Algorithmusname: SHA1withRSA Version: 3 ... *** *** Hello, Please take notice at the following lines in your output... My German(?) isn't all that good, but I see this, Zertifikatskettenlänge: 1, which I know in English should read something to the affect of... 'Certificate Chain Length' This is why Tomcat (JSSE) is only serving up the one certificate (depth 0) and when I see this output, it would appear the '-trustcacerts' flag was not used when importing the certificate(s). See this page for reference [ http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html ] Here's also a blog posting from a fellow StartCom customer. http://magictrevor.wordpress.com/2011/01/26/startssl-startcom-certificates-and-tomcat/ I hope this helps! --Crypto.Sal
Re: Need help with SSL Certificate install on Tomcat 6.0.29 APR.
Hi Jin,
In my experiences with the APR and Tomcat, you need to use 'OpenSSL' to
generate the keypair (CSR/key) I am fairly certain the APR can't read
Java Keystore files. You would only use a keystore (JKS) using 'keytool'
with JSSE.
I think you have at least 2 options at this point:
1. Generate new key pair with OpenSSL using the 'req' utility.
2. Export new keystore that was created with 'keytool' to a PKCS12 file
and then use openSSL to create PEM key, certificate and Certificate
authority files.
I would suggest you do #1 vs. that of #2, unless #2 cause you extra
money or you don't mind doing a little 'work'. :-P
--Crypto.Sal
On 04/19/2011 05:54 PM, Jin H wrote:
Hi. We are a school running Tomcat 6.0.29 for Windows server 2003 with APR. I
currently have an SSL certificate installed. I'm trying to update it with the
renewed SSL certificate but I'm having no luck.
Here are the commands I used to create the CSR.
in the jdk1.6.0_17\bin folder i used this command:
keytool -certreq -keyalg RSA -alias alias2011 -file cert.csr -keystore
key2011.key -keysize 2048
It then asks for a password which i enter.
I generated the CSR and sent it to my SSL vendor. They e-mailed my ssl
certificate back to me.
But they told me that I had to install 2 intermediate Certificate files.
I dowloaded a primary.crt and secondary.crt files from them.
I then ran this command to import the primary.crt
keytool -import -trustcacerts -alias primary -keystore key2011.key -file
primary.crt
Then the secondary.crt
keytool -import -trustcacerts -alias secondary -keystore key2011.key -file
secondary.crt
finally the SSL certificate they e-mailed back.
keytool -import -trustcacerts -alias alias2011 -keystore key2011.key -file
2011.crt
After this I copy the key2011.key and 2011.crt to the root of tomcat.
I edited server.xml to this:
Connector port=8443 maxHttpHeaderSize=8192
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
enableLookups=false disableUploadTimeout=true
acceptCount=100 scheme=https secure=true
SSLEnabled=true
SSLCertificateFile=${catalina.home}/2011.crt
SSLCertificateKeyFile=${catalina.home}/key2011.key
keystorePass=somethingkey
keyalias=alias2011
SSLPassword=somethingkey/
I didn't know the difference between SSLPassword and keystorePass so I put both
in there.
I never put a password for my previous ssl certificate and it worked so I'm
confused why I have to put one in now.
BTW here is the current server.xml that works with the about to expire SSL
certificate.
Connector port=8443 maxHttpHeaderSize=8192
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
enableLookups=false disableUploadTimeout=true
acceptCount=100 scheme=https secure=true
SSLEnabled=true
SSLCertificateFile=${catalina.home}/hostname.crt
SSLCertificateKeyFile=${catalina.home}/hostname.key /
Please help. Thanks in advance.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with Tomcat 6.0 Renewing SSL cert using keytool
Hi Sean, Have you tried to specify just TLS or SSL for the sslProtocol? You presently have this set at TLSv1, which I do not believe is valid. http://tomcat.apache.org/tomcat-6.0-doc/config/http.html --Sal On 02/14/2011 02:46 PM, Sean Killeen wrote: It doesn't -- it tells me that a certificate already exists with that alias, and the import fails. -- Sean On Mon, Feb 14, 2011 at 12:54 PM, Mark Thomasma...@apache.org wrote: On 14/02/2011 14:03, Sean Killeen wrote: The next step seems to throw tomcat off. I believe I need to replace the tomcat alias certificate. Barring a replace function in keytool (which I don't think exists, though I could be wrong), I think this means I have to delete the old tomcat certificate and replace it with the new one. That will delete the key. I'm fairly sure you can just import the new certificate and it will replace old one. Mark - 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: Tomcat 5.5.23 with SSL
Hi Alexander, As Mark has previously mentioned, there's no entry type of 'privateKeyEntry' which is *required* for the certificate to work. I suspect what has happened is that you might not have been in the directory with your keystore file or you did not specify the right keystore as keytool is a little sneaky in this regard. If the keystore doesn't exist in the location that is specified, it will create it for you, but it will of course be missing the Private Key. I see this happen all too often. See if you have another 'keystore.kdb' file on your system and then try installing your certificate into it. --Crypto.Sal On 02/14/2011 12:52 PM, Mark Thomas wrote: On 14/02/2011 15:45, Alexander Mills wrote: For reference, keytool -list -keystore keystore.kdb [root@localhost tomcat5]# keytool -list -keystore keystore.kdb Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry tomcat, Feb 14, 2011, trustedCertEntry, Certificate fingerprint (MD5): FC:XX:XX:87:74:CF:29:7A:F1:XX:9B:6E:18:32:7E:XX That is just a certificate - there is no key so that is never going to work. Mark - 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 Certificate : Unable to configure Tomcat server.xml
On 10/26/2010 04:08 AM, Richard da Silva wrote: Thanks for your response, Darryl But, the certificate is not the problem. The Tomcat Configuration is the issue (server.xml) Richard da Silva Richard, Are you sure that the certificate isn't also the problem? As Brett has previously mentioned, the APR is enabled [ Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on ] , thus you need OpenSSL/mod_ssl style syntax and not the standard JSSE way of defining a keystore. SSLCertificateFile=/usr/local/ssl/server.crt SSLCertificateKeyFile=/usr/local/ssl/server.pem SSLCertificateChainFile/usr/local/ssl/chain.pem Your best bet at this time is to create a key and CSR with OpenSSL. openssl req -nodes -newkey rsa:2048 -nodes -keyout myserver.key -out server.csr -subj /C=US/ST=NY/L=NY/O=MyCompany Ltd./OU=IT/CN=mysubdomain.mydomain.com Then, send it to your CA to re-key the certificate. After all of that, modify the SSL connector as per the docs for the APR [ http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html ] (as per Brett too) In your original server.xml file, I do not see an SSL definition, yet the SSL Engine is on. Are you sure this server is enabled with SSL in the original configuration? --Sal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Installing certificate chain on Tomat
On 04/10/2010 12:01 AM, /U wrote:
i am installing certificate chain on tomcat 6.x (JRE 1.6). From my CA I have
private key (PEM),
identity cert (PEM) (CA X trusts myhost)
and a cert chain file (PEM file) (entrust trusts CA X)
The cert chain is: (entrust) === trusts == (CA X) == trusts == myhost
I have converted the private key and identify cert into DER form
and have imported into /etc/keystore (tomcat's keystore).
I have imported the certificate chain PEM file into
${JAVA_HOME}/jre/lib/security/cacerts.
when I login to tomcat i get warning that certificate
myhost isused by CA X is not trrusted.
It seems like browser does not get full cert chain (entrust = CA X =
myhost).
what could I be doing wrong? pl help.
Regs,
/U
Hello,
You may want to take a look at Comodo's documentation for Tomcat.
https://support.comodo.com/index.php?_m=knowledgebase_a=viewarticlekbarticleid=1204
It shows how to easily install a trusted certificate for use with Tomcat
(and most Java based Web Servers). I've used this documentation quite a
few times and it has always been spot on.
You may want to view the contents of the keystore: keytool -v -list
-keystore KEYSTORE_FILE; to see what is missing. Tomcat should have the
Intermediate Cert(s) and the Entity/Domain Cert inside the keystore.
Hope this helps!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple SSL certificates on same server
On 03/08/2010 06:46 PM, Richard Huntrods wrote: Does anyone know if it is possible, or has anyone done this: I have two applications running on a single server. The applications use different domains and URLs, so the single Tomcat instance can easily tell them apart. (Note: this part is currently working just fine). https://domain1/application1 https://domain2/application2 Again, both domains point to the same static IP, and yes, it is possible for someone to access either application from either domain. Normally, that is not an issue with the clients. However, I currently have only one SSL certificate on the server - this is for domain1. So if you use domain1 to access application1, it's all fine. The security cert comes up green and all that. BUT - if you try and access application2 via domain2, you get the red security cert (wrong domain / server name). I would like to purchase a second certificate for the second domain, and am wondering if this can be done, and how one would tell Tomcat (in server.xml) to acknowledge the second certificate. Currently the stuff in server.xml looks like this: Connector port=443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 enableLookups=false scheme=https secure=true keystoreFile=./keys/.keystore keystorePass=myPassword clientAuth=false sslProtocol=TLS / I have a bad feeling it's not possible, but wanted to ask anyway. Thanks in advance. -R Richard, It's possible. It doesn't appear that Tomcat or Java(SUN) support RFC 3546 just yet (For Server Name Indication) even though Apache httpd does. However Windows XP users of IE will not be able to take advantage of SNI at this time anyway (to further rain on your parade). Vista and greater do make use of SNI though. Gotta wait for XP to die I guess. :-P End result: Multi-Domain Certificate, separate ports, separate IPs or a load balancer that distributes the load to an internal IP based on FQDN, to which you could then use X amount of different SSL certs.(This last bit may be a wee bit complicated) Hope this helps - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5 SSL keytool error: java.lang.Exception: Public key in reply and keystore don't match
Nicholas, You bring up a good point about the alias. It's what I feel most people mess up on when installing SSL Certificates to a keystore. If no alias is specified upon creation of the keystore, the alias is mykey. You can import ANY certificate you want into the keystore. You don't need it's private key. So keytool will act as if nothing is wrong. It's very sneaky in this regard. One can easily see the contents of the keystore: `keytool -keystore KEYSTORE_FILE -v -list -storepass PASSWORD SOMEFILE.TXT ` and one can see the alias here if they so forget what they gave it. Miguel, In regards to your issue, make sure the CSR and Certificate's modulus match. Easiest way is via OpenSSL. Since, you're on CentOS, you probably already have this. `openssl x509 -noout -modulus -in YOUR_CERT.crt | openssl md5` and `openssl req -noout -modulus -in YOUR.CSR | openssl md5 ` Compare these two hashes. And if they're different... `openssl x509 -noout -serial -in YOUR_CERT.crt`, and verify the serial number with Network Solutions, your CA as they might have sent you the wrong certificate. Worst comes to worst, you might have to get a re-issue and make your keystore and csr have unique matching file names. On 10/20/2009 12:19 PM, Nicholas Sushkin wrote: Miguel, I just installed a cert using our own CA, had a bit of trouble myself, but it worked in the end. I found comodo's and Herong Yang's instructions useful. See http://www.herongyang.com/crypto/OpenSSL_Signing_keytool_CSR.html and https://support.comodo.com/index.php?_m=knowledgebase_a=viewarticlekbarticleid=1204 One thing to note is that when you import cert, use the same certificate alias as the key's (for example, -genkey -alias tomcat followed by -import -trustcacerts -aliast tomcat) On Tuesday 20 October 2009 10:36, Miguel Ortiz wrote: I have a tomcat 5 web server setup on CentOS, I am currently working on installing a SSL cert but don't seem to be having any luck. I get the following error: keytool error: java.lang.Exception: Public key in reply and keystore don't match I have reissued the cert through Network Solutions and followed the following instructions to generate and install the cert. I have run out of my patience with them. Is there anything else that I may be missing? Thanks http://www.networksolutions.com/support/csr-for-java-based-webservers-su ch-as-tomcat-using-keytool/ http://www.networksolutions.com/support/installation-for-java-based-webs ervers-such-as-tomcat-using-keytool/ Miguel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache/Tomcat with SSL
Miguel, Do you have Tomcat serving up Port 80 traffic or is that Apache's httpd? I suggest you have one web server handle both normal web traffic and SSL traffic (if possible), since this page is a login page, you might want to FORCE https on that page and not allow HTTP. It would almost appear that you have Tomcat serving up port 80 traffic and Apache serving up SSL/TLS connections. So if that were the case, use Tomcat to do the SSL as well and configure tomcat accordingly in the server.xml file. Do keep in mind there is a difference between Tomcat and Apache (httpd). Please clarify your setup for us. On 09/28/2009 01:47 PM, Miguel Ortiz wrote: Jorge, I have setup the SSL through Apache and Tomcat, if there is a different procedure for mod_ssl, I will try that as well. The site comes up fine when I access it without the https, however when I use the https, all I see is the jsp script. Miguel Ortiz Network Engineer x4818 wk: 954-331-4818 bbry: 954-649-1863 miguel.or...@macneillgroup.com -Original Message- From: Jorge Medina [mailto:jmed...@e-dialog.com] Sent: Monday, September 28, 2009 10:55 AM To: Tomcat Users List Subject: RE: Apache/Tomcat with SSL Also, in order to configure Apache with SSL you must have the module mod_ssl -Original Message- From: Jorge Medina [mailto:jmed...@e-dialog.com] Sent: Monday, September 28, 2009 10:40 AM To: Tomcat Users List Subject: RE: Apache/Tomcat with SSL Hola Miguel, did you set up SSL in Apache ? Or did you do it in Tomcat ? Or in both ? I am assuming that you want Apache to be the exposed server, therefore SSL must be configured in Apache. You must also have configured Apache to forward the requests to Tomcat by using the Apache modules mod_jk or mod_proxy -Jorge -Original Message- From: Miguel Ortiz [mailto:miguel.or...@macneillgroup.com] Sent: Monday, September 28, 2009 8:32 AM To: users@tomcat.apache.org Subject: Apache/Tomcat with SSL I recently setup a SSL cert on our Apache/Tomcat server. When I load our page, I can see the lock in my browser with all the SSL info, but the page only loads as a the jsp script and not the full page. Is there some configuration setting that I have missed. I can provide snippets from the server.xml, httpd.conf, and ssl.conf. Thanks in advance. Miguel Ortiz Network Engineer x4818 wk: 954-331-4818 bbry: 954-649-1863 miguel.or...@macneillgroup.com This email and any files transmitted with it are the confidential property of Focus Holdings, LLC and its subsidiaries, and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. - 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.112/2390 - Release Date: 09/28/09 05:51:00 This email and any files transmitted with it are the confidential property of Focus Holdings, LLC and its subsidiaries, and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. - 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
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
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
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
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
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
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
