tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark H. Wood" <mw...@IUPUI.Edu>
Subject Re: About certificates in Tomcat SSL support
Date Fri, 13 Jan 2012 17:51:43 GMT
On Thu, Jan 12, 2012 at 09:14:28AM -0800, James Lampert wrote:
> Scenario:
> I created a self-signed certificate for the box I was testing:
> CN = James Lampert

As already pointed out, there's your problem.  To identify a networked
service, the value of CN should be the FQDN of the host providing the
service.  (This is why people suddenly became interested in securing
DNS:  we are relying on it to validate certificate bindings to services!)

Yes, the prompts are confusing.  A recent release of OpenSSL, for
example, just updated the CN prompt from "Common Name (eg, YOUR name)"
to "Common Name (e.g. server FQDN or YOUR name)".

> OU = Development Lab
> O = Touchtone Corporation
> L = Costa Mesa
> ST = California
> C = US
> I then installed it into the Tomcat server on that box. Connecting to 
> the site with Firefox, I was told that the certificate was not trusted, 
> and asked whether to trust it. After I said to trust it, Firefox now 
> lets me in without further question.

Yup.  A certificate not already trusted must be validated by a higher
authority.  If it is signed by another certificate, that is the
authority (subject to validation itself); if self-signed, the only
available higher authority is you.

> Then, I temporarily installed the certificate on a customer's Tomcat 
> server, just to verify that SSL support was working there. When I 
> connected to it with Firefox, the initial message questioning the 
> validity of the certificate said something about it being for a 
> different server (so far as I'm aware, it isn't for *any* particular 
> server).

I would consider that the proper behavior.

> Looking at the two Tomcat servers in Microsloth Imploder, even after 
> telling it to trust the certificate, I consistently get a message, "The 
> security certificate presented by this website was issued for a 
> different website's address."

I'm concerned that you did *not* get this from the first instance of
Firefox, since that cert. couldn't possibly identify *any* networked
service.  The browser should complain, because there is no DNS domain
named "James Lampert".

> Looking at the two Tomcat servers in a different version of Firefox, on 
> a different WinDoze box, both Tomcat servers give me the message, that 
> it is not trusted because it is self-signed, and that it is only valid 
> for James Lampert.

Every root CA certificate is self-signed.  Your cert. is not trusted
because no one told the client to trust the certificate at the top of
the chain of signatures which, for a self-signed certificate, is that
very certificate.  There's nothing inherent in any certificate which
makes it trustworthy; someone has to tell each client which
authorities to trust, thus which end certificates it can validate
without help.  Browsers usually don't kick up a fuss because their
makers have made that trust decision for you with regard to bales of
CAs' certificates before you got your copy of the browser.

> Also: we have a CA-signed certificate that we use to sign JARs. Is that 
> the same sort of certificate used for Tomcat?

In that both are (presumably) X.509 certificates, yes.  Otherwise you
need to describe "same sort" more precisely.

Typically you would want to use a cert. signed by a well-known CA, so
that most browsers will have already been told to trust that CA and so
will be able to validate your certificate without bothering the user.

If you coin your own cert.s then anyone who uses the affected servers
will have to add those cert.s to their truststores or put up with the
"are you sure you want to trust these guys?" dialog every time they

Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.

View raw message