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 visit. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
pgpKV6HHHE0Jj.pgp
Description: PGP signature
