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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: OT: TomCat WebCerts and Linux?

  1. 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 *


  2. 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 *


+ Reply to Thread