Re: About certificates in Tomcat SSL support
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
Re: About certificates in Tomcat SSL support
Mark H. Wood wrote: 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). Thanks for the additional detail. We now have the customer set up with a less-frightening self-signed certificate, specific to their domain, pending installation of a CA-signed certificate (which I sincerely hope is domain-specific). -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
About certificates in Tomcat SSL support
Scenario: I created a self-signed certificate for the box I was testing: CN = James Lampert 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. 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). 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. 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. What exactly do I need to do, for a certificate to be recognized as the correct one for a given server? Also: we have a CA-signed certificate that we use to sign JARs. Is that the same sort of certificate used for Tomcat? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About certificates in Tomcat SSL support
On 12 Jan 2012, at 17:15, James Lampert jam...@touchtonecorp.com wrote: Scenario: I created a self-signed certificate for the box I was testing: CN = James Lampert 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. 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). 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. 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. What exactly do I need to do, for a certificate to be recognized as the correct one for a given server? The Common Name must match the domain name of the server as seen by the client. Also: we have a CA-signed certificate that we use to sign JARs. Is that the same sort of certificate used for Tomcat? You would need to purchase a different one to comply with the terms of purchase anyhow. p -- JHHL - 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: About certificates in Tomcat SSL support
I created a self-signed certificate for the box I was testing: CN = James Lampert Pid * wrote: The Common Name must match the domain name of the server as seen by the client. Hmm. So where Keytool asks What is your first and last name? you answer not with what it's asking for, but with the intended domain name. Makes perfect sense. Thanks. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
