You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by James Lampert <ja...@touchtonecorp.com> on 2012/01/12 18:14:28 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: About certificates in Tomcat SSL support
Posted by James Lampert <ja...@touchtonecorp.com>.
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: About certificates in Tomcat SSL support
Posted by Pid * <pi...@pidster.com>.
On 12 Jan 2012, at 17:15, James Lampert <ja...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: About certificates in Tomcat SSL support
Posted by James Lampert <ja...@touchtonecorp.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: About certificates in Tomcat SSL support
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
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 mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.