OT: TomCat WebCerts and Linux? - Hewlett Packard
This is a discussion on OT: TomCat WebCerts and Linux? - Hewlett Packard ; Date: Wed, 24 Sep 2008 17:24:28 -0700
On: "Bahrs, Art"
> Anybody ever deal with the above combination? Throw in Internet
> Explorer not liking the certs?
This is likely caused by using a self-signed PKI certificate for the
service ...
-
OT: TomCat WebCerts and Linux?
Date: Wed, 24 Sep 2008 17:24:28 -0700
On: "Bahrs, Art"
> Anybody ever deal with the above combination? Throw in Internet
> Explorer not liking the certs?
This is likely caused by using a self-signed PKI certificate for the
service or using a certificate signed by a private certificate authority.
The major browsers are distributed with a predefined list of "TRUSTED"
Certificate Authorities (CA). Certificates signed by said authorities are
accepted by IE, Firefox, etc. without complaint and generally without
notice. If the certificate presented by your service is not signed by one
of these then the solution varies according to what your situation is and
the type of certificate you are providing.
The most common case is that the service certificate is self-signed. In
this case to use the service you must tell the browser to accept the
certificate, either temporarily for the current session, or permanently in
which case the certificate is added to the certificate store held in the
browser. For instance, in Firefox 3 you can see installed certificates
under the "Preferences/Advanced/Encryption/View Certificates"
tabs/buttons.
The second most common case is that the certificate is issued by a private
CA and the root CA certificate has not been added to the Browser's list of
TRUSTED CAs. In this case you can apply the same technique as for
self-signed certs, or you can add the issuing CA's root certificate to the
list of trusted sites and all certificates signed by that CA will
henceforth be treated in the same manner as those for VeriSign or Thwait,
etc., BY THAT BROWSER/USER combination ONLY.
The third case occurs when a private CA has been used to create the
certificate but the serial number has either been left unset (0) or is set
to some arbitrary non-zero constant value for all certificates issued by
that CA. For recent versions of Firefox and MS-IE this problem can only be
cleared by first removing the existing certificate with the same serial
number issued by the same CA from the browser certificate store and then
applying one of the remedies outlined above.
Hope that this helps.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
-
Re: OT: TomCat WebCerts and Linux?
> The most common case is that the service certificate is self-signed. In
> this case to use the service you must tell the browser to accept the
> certificate, either temporarily for the current session, or permanently in
> which case the certificate is added to the certificate store held in the
> browser. For instance, in Firefox 3 you can see installed certificates
> under the "Preferences/Advanced/Encryption/View Certificates"
> tabs/buttons.
>
> The second most common case is that the certificate is issued by a private
> CA and the root CA certificate has not been added to the Browser's list of
> TRUSTED CAs. In this case you can apply the same technique as for
> self-signed certs, or you can add the issuing CA's root certificate to the
> list of trusted sites and all certificates signed by that CA will
> henceforth be treated in the same manner as those for VeriSign or Thwait,
> etc., BY THAT BROWSER/USER combination ONLY.
>
> The third case occurs when a private CA has been used to create the
> certificate but the serial number has either been left unset (0) or is set
> to some arbitrary non-zero constant value for all certificates issued by
> that CA. For recent versions of Firefox and MS-IE this problem can only be
> cleared by first removing the existing certificate with the same serial
> number issued by the same CA from the browser certificate store and then
> applying one of the remedies outlined above.
A fourth case, which I just encountered, is if you buy a cheap domain cert
from GoDaddy or somesuch and your web server is behind a firewall or NAT
router. The address of the web server is known to the world as
www.domain.com but the webserver is known locally on your network as
something like shemp.mycompany.local. The FQDN on the certificate and the
FQDN of the web server must match or the browser will throw an error. In
ISA, there's a setting indicating where web requests should be redirected
and what the return headers should look like. In order to get this to work,
one has to forward requests to the external domain (www.domain.com) but that
causes an endless loop in the ISA. The trick is to add an entry to the host
file on the ISA machine that points www.domain.com to the local IP address
bypassing DNS and preventing the looping error. (The service must be
restarted before this works).
Mark W.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
