You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Jeffrey D. Fisher" <je...@cox.net> on 2013/03/15 21:02:46 UTC
SSL Best Practices
Gentlemen (Ladies):
I am looking for a published "best practice" on editing the SERVER.XML
configuration file to use SSL/HTTPS. The key are imported into the
keystore.
Any input is appreciated.
Jeff Fisher
Omaha, NE
RE: SSL Best Practices
Posted by "Harris, Jeffrey E." <Je...@ManTech.com>.
> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Tuesday, March 19, 2013 7:35 AM
> To: Tomcat Users List
> Subject: RE: SSL Best Practices
>
>
> 1)Have you ever tried to coerce IE to accept a self-signed cert 2)if
> you purchase a pfx with a self-signed certificate sold to you by
> chris_is_a_hacker.com for 1.00 then who do you think can break it
I use self-signed certificates from my own CA for testing.
>
> The cert allows browser to contact the sites SSL connector..by
> presenting credentials usually from a Name Server such as ADS or LDAP
>
Most certificates are not backed by a name server. The existence of the certificate
is deemed sufficient to provide proof of identity (if issued by a trusted 3rd party,
such as Verisign).
> the real work involves breaking the algorithm implemented by the key
>
> in order to establish Key exchange on a SSLv2 transport
>
The SSLv2 transport is sufficiently broken (or weak) that most SSL reliant applications
disable it (or recommend in sufficiently strong terms that users disable it).
> I sincerely doubt even chris_is_a-hacker can break any of the RSA
> algorithms implemented by the key inside a versign.pfx
If I am chris_is_a-hacker, I do not need to break anything, because by
providing a PFX file (rather than by submitting a certificate request
and having a certificate issued directly to me), I have a copy of the private
key, and I can impersonate the user or website at will, depending on the kind
of certificate(s) included in the pfx file.
And as for breaking the key algorithm, I do not have to do that all (even if I did
the right steps in having a certificate properly issued). There are a number of
weaknesses in the SSL protocol itself that I can attack any of those to inject
a man-in-the-middle attack.
(In any case, I believe we have moved significantly off topic in this discussion.)
This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Best Practices
Posted by Mark Thomas <ma...@apache.org>.
On 19/03/2013 15:28, Jeffrey D. Fisher wrote:
> Could we dispense with the ego-clanking, please? Really? Keep in
> mind that EVERYONE has the same problem regardless of your IQ level:
> for everything you know there are three to five things you do not
> know and at least one that you do not know you do not know. Accept
> that fact and life gets somewhat clearer. If I had known that this
> was the normal board-of-faire I would not have subscribed to this.
Posts from Martin are somewhat of a special case. If you check the
archives you'll find he has a long history of responding with something
that looks reasonable if you don't know the subject matter but is often
complete and utter nonsense.
To be fair, he does - occasionally - produce a valid, useful response.
Many of us have tried to offer suggestions to Martin as to how he might
improve the quality of his responses. When I tried, I used his answers
from a thread where he was particularly wide of the mark to offer
examples of how he could improve. I was met with hostility and an
insistence that he was right and I was wrong. While I don't always get
things right (and there is plenty of evidence of that in the archives) I
am happy to admit when I get things wrong. This wasn't one of those times.
While most of us simply ignore posts from Martin, someone does sometimes
find it necessary to step in and point out the various errors in his
posts. This is primarily to protect folks searching the archives at some
point in the future wasting their time following some of the more off
the wall suggestions put forward.
If I thought it would actually achieve anything, I'd unsubscribe him
from the mailing list and ban him from re-joining but that is very
likely to turn into a rather pointless game of wack-a-mole as all he'd
have to do is get another gmail address and sign up again.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by "Harris, Jeffrey E." <Je...@ManTech.com>.
> -----Original Message-----
> From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> Sent: Tuesday, March 19, 2013 11:28 AM
> To: 'Tomcat Users List'
> Subject: RE: SSL Best Practices
>
> Could we dispense with the ego-clanking, please? Really? Keep in mind
> that EVERYONE has the same problem regardless of your IQ level: for
> everything you know there are three to five things you do not know and
> at least one that you do not know you do not know. Accept that fact
> and life gets somewhat clearer. If I had known that this was the
> normal board-of-faire I would not have subscribed to this.
>
> Jeff Fisher
> Omaha, NE
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Tuesday, March 19, 2013 9:52 AM
> To: Tomcat Users List
> Subject: Re: SSL Best Practices
>
I have been a member of this mailing list for a few weeks, and I am
actually surprised by how respectful the posters tend to be, compared
to some technical mailing lists I have subscribed to.
Jeffrey Harris
This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
RE: SSL Best Practices
Posted by "Jeffrey D. Fisher" <je...@cox.net>.
Could we dispense with the ego-clanking, please? Really? Keep in mind that EVERYONE has the same problem regardless of your IQ level: for everything you know there are three to five things you do not know and at least one that you do not know you do not know. Accept that fact and life gets somewhat clearer. If I had known that this was the normal board-of-faire I would not have subscribed to this.
Jeff Fisher
Omaha, NE
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Tuesday, March 19, 2013 9:52 AM
To: Tomcat Users List
Subject: Re: SSL Best Practices
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 3/19/13 7:34 AM, Martin Gainty wrote:
> 1)Have you ever tried to coerce IE to accept a self-signed cert
This is a trust issue, not a security issue. They are related, but not equivalent.
> 2)if you purchase a pfx with a self-signed certificate sold to you by
> chris_is_a_hacker.com for 1.00 then who do you think can break it
I'm not sure what a PFX is, but the certificate itself is as strong as the key used to create it. If you generate a 1-bit key, you'll be hacked in 0 minutes. But nobody does that: we all create 4096-bit keys which, theoretically, can't be broken even by a well-funded adversary with unreasonably-limited computing power before the sun gets tired of shining.
> The cert allows browser to contact the sites SSL connector..by
> presenting credentials usually from a Name Server such as ADS or LDAP
Woah, your algorithm has started to bring-in random bits of search results from the Internet. Time to re-set your learning tree and start again.
> the real work involves breaking the algorithm implemented by the key
Yup. Good luck with RSA and friends.
> in order to establish Key exchange on a SSLv2 transport
Anyone using SSLv2 is vulnerable, which is why it's no longer used.
For a long time, now.
> I sincerely doubt even chris_is_a-hacker can break any of the RSA
> algorithms implemented by the key inside a versign.pfx
While true, it's also true of your own self-signature. Verisign uses a 2048-bit key to sign everything. Most sites these days use 4096-bit keys (at least those I configure, apache.org, etc.). (Oddly enough, Facebook uses a 1024-bit key.) If you create a server cert with a 4096-bit key, you are creating a fairly secure certificate no matter who signs it. And, if you sign it yourself and keep the key secure (which is kind of impossible unless you are using a different key for signing than you do for the server's key) then you are doing better than any CA out there.
Again, the CA is only there to provide a trusted 3rd-party: they have nothing to do with the security of the connection, the hackability of the server, etc.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlFIe4cACgkQ9CaO5/Lv0PBlOQCbBMGVp6wcP9aBJUunxWXNzmNz
YRAAnjrY4vSZSX8KlE7mER287II6l6w9
=ADG9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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: SSL Best Practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 3/19/13 7:34 AM, Martin Gainty wrote:
> 1)Have you ever tried to coerce IE to accept a self-signed cert
This is a trust issue, not a security issue. They are related, but not
equivalent.
> 2)if you purchase a pfx with a self-signed certificate sold to you
> by chris_is_a_hacker.com for 1.00 then who do you think can break
> it
I'm not sure what a PFX is, but the certificate itself is as strong as
the key used to create it. If you generate a 1-bit key, you'll be
hacked in 0 minutes. But nobody does that: we all create 4096-bit keys
which, theoretically, can't be broken even by a well-funded adversary
with unreasonably-limited computing power before the sun gets tired of
shining.
> The cert allows browser to contact the sites SSL connector..by
> presenting credentials usually from a Name Server such as ADS or
> LDAP
Woah, your algorithm has started to bring-in random bits of search
results from the Internet. Time to re-set your learning tree and start
again.
> the real work involves breaking the algorithm implemented by the
> key
Yup. Good luck with RSA and friends.
> in order to establish Key exchange on a SSLv2 transport
Anyone using SSLv2 is vulnerable, which is why it's no longer used.
For a long time, now.
> I sincerely doubt even chris_is_a-hacker can break any of the RSA
> algorithms implemented by the key inside a versign.pfx
While true, it's also true of your own self-signature. Verisign uses a
2048-bit key to sign everything. Most sites these days use 4096-bit
keys (at least those I configure, apache.org, etc.). (Oddly enough,
Facebook uses a 1024-bit key.) If you create a server cert with a
4096-bit key, you are creating a fairly secure certificate no matter
who signs it. And, if you sign it yourself and keep the key secure
(which is kind of impossible unless you are using a different key for
signing than you do for the server's key) then you are doing better
than any CA out there.
Again, the CA is only there to provide a trusted 3rd-party: they have
nothing to do with the security of the connection, the hackability of
the server, etc.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlFIe4cACgkQ9CaO5/Lv0PBlOQCbBMGVp6wcP9aBJUunxWXNzmNz
YRAAnjrY4vSZSX8KlE7mER287II6l6w9
=ADG9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by Martin Gainty <mg...@hotmail.com>.
1)Have you ever tried to coerce IE to accept a self-signed cert
2)if you purchase a pfx with a self-signed certificate sold to you by chris_is_a_hacker.com for 1.00 then who do you think can break it
The cert allows browser to contact the sites SSL connector..by presenting credentials usually from a Name Server such as ADS or LDAP
the real work involves breaking the algorithm implemented by the key
in order to establish Key exchange on a SSLv2 transport
I sincerely doubt even chris_is_a-hacker can break any of the RSA algorithms implemented by the key inside a versign.pfx
'Nuf Said
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> From: Jeffrey.Harris@ManTech.com
> To: users@tomcat.apache.org; chris@derham.me.uk
> Date: Tue, 19 Mar 2013 06:04:52 -0400
> Subject: RE: SSL Best Practices
>
>
>
> > -----Original Message-----
> > From: cjderham@gmail.com [mailto:cjderham@gmail.com] On Behalf Of chris
> > derham
> > Sent: Tuesday, March 19, 2013 1:58 AM
> > To: Tomcat Users List
> > Subject: Re: SSL Best Practices
> >
> > > If the system is only for testing, or communicates with a limited
> > > number of systems (i.e., it is a firewalled backend system that only
> > > communicates with a front-end system), then again, a self-signed
> > certificate would be fine.
> >
> > +1
> >
> > > I do agree that if this is a public facing system, or one in an
> > > organization with a large number of users that does not have its own
> > > CA infrastructure, then a commercial certificate would be the best
> > choice.
> >
> > Commercial certificate authorities are actively targeted by hackers,
> > and when they are broken into, the trust each os has configured of such
> > certificates can cause issues. The recent google ssl certificate issue
> > shows what happens when things go wrong. If users will access the site
> > via a browser, then the browser warning will confuse them/make them
> > used to ignoring security warnings. For applications communicating with
> > each other, a self signed certificate will actually be more secure than
> > a certificate authority issued certificate - assuming you trust your
> > internal security more than you trust that of a commercial certificate
> > authority. It all depends on what the certificate will be used for.
> >
> > Chris
> >
>
> What you say is all true, but if the public is accessing the site,
> there is no real alternative to a commercial certificate, because there will
> be no way to ascertain the trust of the site at all, and as you say users will be
> confused by the browser warnings.
>
> Unfortunately, the security of the Internet is dependent on a relatively handful
> of commercial certificate authorities, several of whom have either been hacked,
> or who have not properly vetted requesters for certificates.
>
> Jeffrey Harris
>
> This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: SSL Best Practices
Posted by "Harris, Jeffrey E." <Je...@ManTech.com>.
> -----Original Message-----
> From: cjderham@gmail.com [mailto:cjderham@gmail.com] On Behalf Of chris
> derham
> Sent: Tuesday, March 19, 2013 1:58 AM
> To: Tomcat Users List
> Subject: Re: SSL Best Practices
>
> > If the system is only for testing, or communicates with a limited
> > number of systems (i.e., it is a firewalled backend system that only
> > communicates with a front-end system), then again, a self-signed
> certificate would be fine.
>
> +1
>
> > I do agree that if this is a public facing system, or one in an
> > organization with a large number of users that does not have its own
> > CA infrastructure, then a commercial certificate would be the best
> choice.
>
> Commercial certificate authorities are actively targeted by hackers,
> and when they are broken into, the trust each os has configured of such
> certificates can cause issues. The recent google ssl certificate issue
> shows what happens when things go wrong. If users will access the site
> via a browser, then the browser warning will confuse them/make them
> used to ignoring security warnings. For applications communicating with
> each other, a self signed certificate will actually be more secure than
> a certificate authority issued certificate - assuming you trust your
> internal security more than you trust that of a commercial certificate
> authority. It all depends on what the certificate will be used for.
>
> Chris
>
What you say is all true, but if the public is accessing the site,
there is no real alternative to a commercial certificate, because there will
be no way to ascertain the trust of the site at all, and as you say users will be
confused by the browser warnings.
Unfortunately, the security of the Internet is dependent on a relatively handful
of commercial certificate authorities, several of whom have either been hacked,
or who have not properly vetted requesters for certificates.
Jeffrey Harris
This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Best Practices
Posted by chris derham <ch...@derham.me.uk>.
> If the system is only for testing, or communicates with a limited number of systems (i.e.,
> it is a firewalled backend system that only communicates with a front-end system), then again,
> a self-signed certificate would be fine.
+1
> If his organization already uses PKI certificates, then he should follow the rules
> established in his organization's Certificate Practice Statement, if it has issued
> one.
>
> I do agree that if this is a public facing system, or one in an organization with a large
> number of users that does not have its own CA infrastructure, then a commercial certificate
> would be the best choice.
Commercial certificate authorities are actively targeted by hackers,
and when they are broken into, the trust each os has configured of
such certificates can cause issues. The recent google ssl certificate
issue shows what happens when things go wrong. If users will access
the site via a browser, then the browser warning will confuse
them/make them used to ignoring security warnings. For applications
communicating with each other, a self signed certificate will actually
be more secure than a certificate authority issued certificate -
assuming you trust your internal security more than you trust that of
a commercial certificate authority. It all depends on what the
certificate will be used for.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by "Harris, Jeffrey E." <Je...@ManTech.com>.
> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Monday, March 18, 2013 6:22 PM
> To: Tomcat Users List
> Subject: RE: SSL Best Practices
>
> Jeff
>
> do you have keystore and certificate..if not go to verisign and get a
> CATrusted pfx...
> the cost is worth it and anything you create with a self-signed cert
> will be broken in less than 5 min
>
> Feel free to Pingback if you have any questions.
>
> Martin
>
>
>
>
> > From: Jeffrey.Janner@PolyDyne.com
> > To: users@tomcat.apache.org
> > Subject: RE: SSL Best Practices
> > Date: Mon, 18 Mar 2013 13:34:44 +0000
> >
> > > -----Original Message-----
> > > From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> > > Sent: Friday, March 15, 2013 3:03 PM
> > > To: users@tomcat.apache.org
> > > Subject: SSL Best Practices
> > >
> > > Gentlemen (Ladies):
> > >
> > >
> > >
> > > I am looking for a published "best practice" on editing the
> > > SERVER.XML configuration file to use SSL/HTTPS. The key are
> imported
> > > into the keystore.
> > >
> > >
> > >
> > > Any input is appreciated.
> > >
> > >
> > >
> > > Jeff Fisher
> > >
> > > Omaha, NE
> >
> > I would start by reading the Tomcat Documentation on the subject.
> > It's pretty straightforward.
> > Jeff
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
I am not sure what you mean by "anything you create with a self-signed cert
will be broken in less than 5 min". It depends on the purpose and certificate use in his
organization. If his organization already has its own CA and issues its own certificates,
and this will be used only as an internal system, then self-signed certificates issued
by an internal CA are fine.
If the system is only for testing, or communicates with a limited number of systems (i.e.,
it is a firewalled backend system that only communicates with a front-end system), then again,
a self-signed certificate would be fine.
If his organization already uses PKI certificates, then he should follow the rules
established in his organization's Certificate Practice Statement, if it has issued
one.
I do agree that if this is a public facing system, or one in an organization with a large
number of users that does not have its own CA infrastructure, then a commercial certificate
would be the best choice.
Jeffrey Harris
This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by "Harris, Jeffrey E." <Je...@ManTech.com>.
> -----Original Message-----
> From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> Sent: Tuesday, March 19, 2013 10:34 AM
> To: 'Tomcat Users List'; mgainty@hotmail.com
> Subject: RE: SSL Best Practices
>
> Yes, I do have a CA-issued certificate with a chain to a trusted CA.
> I've imported it to the keystore. I am close to a solution. When I
> attempt to open the default Apache web page using "https:" I get an
> error page that says that the server cannot open the page. It opens
> with "http:" just fine.
> I have configured the normal ports i.e. "80" and "443" to redirect to
> "8443". The reason for this is that the users having to include the
> port numbers (8080 or 8443) would not be acceptable. They need only
> enter the DNS name into the browser and DNS does the rest.
>
> I am missing something in the configuration of SERVER.XML, WEB.XML or
> both to get the server to answer to an https connection. I cannot find
> what it is that I have not done or I have missed!
>
> Any input would be appreciated.
>
> Best...
>
> Jeffrey D. Fisher
> Omaha, NE USA
>
I ran into this same issue; make sure you have 'secure="true"' in the connector:
<Connector protocol="org.apache.coyote.http11.Http11Protocol" port="7443" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true" keystorePass="mypassword"
clientAuth="want" sslProtocol="TLS" keystoreFile=".\conf\myks.jks"
truststoreFile=".\conf\myts.jks" />
Jeffrey Harris
This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> Sent: Tuesday, March 19, 2013 9:34 AM
> To: 'Tomcat Users List'; mgainty@hotmail.com
> Subject: RE: SSL Best Practices
>
> Yes, I do have a CA-issued certificate with a chain to a trusted CA.
> I've imported it to the keystore. I am close to a solution. When I
> attempt to open the default Apache web page using "https:" I get an
> error page that says that the server cannot open the page. It opens
> with "http:" just fine.
> I have configured the normal ports i.e. "80" and "443" to redirect to
> "8443". The reason for this is that the users having to include the
> port numbers (8080 or 8443) would not be acceptable. They need only
> enter the DNS name into the browser and DNS does the rest.
This is a little overkill. Set up the "443" connector as the SSL connector and dump the "8443" connector as unneeded.
The "80" connector should redirect to "443".
And make sure that you are not using the APR, aka "native", library. Either comment out the listener for it, or remove the lib file from the bin directory, or both (best).
As others have suggested, make sure you mark the 443 connector as secure="true", and verify the other settings.
Here's the connectors I use for all my servers.
<Connector address="[IP_ADDRESS]" port="80" maxHttpHeaderSize="8192"
maxThreads="50" enableLookups="false" redirectPort="443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" compression="off" />
<Connector address="[IP_ADDRESS]" port="443" maxHttpHeaderSize="8192"
maxThreads="150" enableLookups="false" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" compression="off"
scheme="https" secure="true" SSLEnabled="true"
SSLCertificateFile="path"
SSLCertificateKeyFile="path"
SSLCertificateChainFile="path"
SSLPassword="password" />
Note this is for Tomcat 6 using the native lib. You'll have to replace the last 4 lines with the properties for the Java keystore, and there are probably some other changes needed for Tomcat 7.
>
> I am missing something in the configuration of SERVER.XML, WEB.XML or
> both to get the server to answer to an https connection. I cannot find
> what it is that I have not done or I have missed!
>
> Any input would be appreciated.
>
> Best...
There are web.xml tags -- security-constraint tree -- that also govern *when* to switch to using the SSL port.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Best Practices
Posted by Ognjen Blagojevic <og...@gmail.com>.
Jeffrey,
On 19.3.2013 15:33, Jeffrey D. Fisher wrote:
> Yes, I do have a CA-issued certificate with a chain to a trusted CA. I've
> imported it to the keystore. I am close to a solution. When I attempt to
> open the default Apache web page using "https:" I get an error page that
> says that the server cannot open the page.
Your HTTPS connector probably isn't configured right, or you are trying
to access a wrong port.
Check with netstat ("netstat -anp tcp" on Windows or "netstat -tnlp" on
Linux) do you have a process listening on port 443.
> It opens with "http:" just fine.
Good, your HTTP connector seems to be working just fine.
> I have configured the normal ports i.e. "80" and "443" to redirect to
> "8443". The reason for this is that the users having to include the port
> numbers (8080 or 8443) would not be acceptable. They need only enter the
> DNS name into the browser and DNS does the rest.
How did you configured redirection? There are several ways to have your
server listen on standard ports 80 and 443 (iptables, jsvc, Apache
httpd...), each with its own peculiarities. Please provide detailed
description how did you do it.
> I am missing something in the configuration of SERVER.XML, WEB.XML or both
> to get the server to answer to an https connection. I cannot find what it
> is that I have not done or I have missed!
Well, it is hard to say, with the information you provided so far. Could
you please post your server.xml configuration with comments and
passwords removed, so we could tell you if it is configured right.
It would also help us if you post relevant parts of your log files. Here
is the sample saying that both HTTP and HTTPS connectors are started on
ports 80 and 443:
Mar 13, 2013 5:32:13 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-80"]
Mar 13, 2013 5:32:13 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-443"]
Mar 13, 2013 5:32:13 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in ... ms
Do you have something similar in your log files?
You also used the phrase "default Apache web page". Apache is ambiguous
term here. I do not understand did you mean "default Apache Tomcat web
page" or "default Apache httpd web page" or something else. Some people
prefer to use Apache Tomcat as a web server, while others use Apache
httpd as front end, and Apache Tomcat as servlet container.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by "Jeffrey D. Fisher" <je...@cox.net>.
Yes, I do have a CA-issued certificate with a chain to a trusted CA. I've
imported it to the keystore. I am close to a solution. When I attempt to
open the default Apache web page using "https:" I get an error page that
says that the server cannot open the page. It opens with "http:" just fine.
I have configured the normal ports i.e. "80" and "443" to redirect to
"8443". The reason for this is that the users having to include the port
numbers (8080 or 8443) would not be acceptable. They need only enter the
DNS name into the browser and DNS does the rest.
I am missing something in the configuration of SERVER.XML, WEB.XML or both
to get the server to answer to an https connection. I cannot find what it
is that I have not done or I have missed!
Any input would be appreciated.
Best...
Jeffrey D. Fisher
Omaha, NE USA
-----Original Message-----
From: Martin Gainty [mailto:mgainty@hotmail.com]
Sent: Monday, March 18, 2013 5:22 PM
To: Tomcat Users List
Subject: RE: SSL Best Practices
Jeff
do you have keystore and certificate..if not go to verisign and get a
CATrusted pfx...
the cost is worth it and anything you create with a self-signed cert will be
broken in less than 5 min
Feel free to Pingback if you have any questions.
Martin
> From: Jeffrey.Janner@PolyDyne.com
> To: users@tomcat.apache.org
> Subject: RE: SSL Best Practices
> Date: Mon, 18 Mar 2013 13:34:44 +0000
>
> > -----Original Message-----
> > From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> > Sent: Friday, March 15, 2013 3:03 PM
> > To: users@tomcat.apache.org
> > Subject: SSL Best Practices
> >
> > Gentlemen (Ladies):
> >
> >
> >
> > I am looking for a published "best practice" on editing the
> > SERVER.XML configuration file to use SSL/HTTPS. The key are imported
> > into the keystore.
> >
> >
> >
> > Any input is appreciated.
> >
> >
> >
> > Jeff Fisher
> >
> > Omaha, NE
>
> I would start by reading the Tomcat Documentation on the subject.
> It's pretty straightforward.
> Jeff
>
>
> ---------------------------------------------------------------------
> 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: SSL Best Practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 3/18/13 6:21 PM, Martin Gainty wrote:
> do you have keystore and certificate..if not go to verisign and get
> a CATrusted pfx...
>
> the cost is worth it and anything you create with a self-signed
> cert will be broken in less than 5 min
Using a "trusted" CA gains you absolutely nothing when it comes to
security through encryption. The only reason to ever use a "trusted"
CA is so that your clients can have some level of trust that your site
is who you say it is. That's why they are called trusted 3rd-parties.
Realistically, even getting a "trusted" CA to sign your certificate
doesn't help: most CAs blindly sign any request they get as long as
you have a couple hundred dollars. At least with "EV" certificates,
the CAs are supposed to verify that you are who you say you are, but
personal experience with a few well-known CAs lets me know that it's
not true research. If you have the cash to pay for the certificate,
you can get an EV certificate *by self-assertion* that you are who you
say you are, which is, of course, contrary to the whole EV scheme.
But, the encryption will work regardless of whether the certificate
has been self-signed. You will not be hacked in 5 minutes (or if you
do, it has nothing to do with whether you signed your own certificate
or not).
Stop spreading FUD.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlFIePkACgkQ9CaO5/Lv0PDqGwCfauMsrxBbfu+PjDkhG/grDozs
3twAoIsRCV45/HfhhnFlE+S/exClhtxQ
=HTHQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Best Practices
Posted by Martin Gainty <mg...@hotmail.com>.
Jeff
do you have keystore and certificate..if not go to verisign and get a CATrusted pfx...
the cost is worth it and anything you create with a self-signed cert will be broken in less than 5 min
Feel free to Pingback if you have any questions.
Martin
> From: Jeffrey.Janner@PolyDyne.com
> To: users@tomcat.apache.org
> Subject: RE: SSL Best Practices
> Date: Mon, 18 Mar 2013 13:34:44 +0000
>
> > -----Original Message-----
> > From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> > Sent: Friday, March 15, 2013 3:03 PM
> > To: users@tomcat.apache.org
> > Subject: SSL Best Practices
> >
> > Gentlemen (Ladies):
> >
> >
> >
> > I am looking for a published "best practice" on editing the SERVER.XML
> > configuration file to use SSL/HTTPS. The key are imported into the
> > keystore.
> >
> >
> >
> > Any input is appreciated.
> >
> >
> >
> > Jeff Fisher
> >
> > Omaha, NE
>
> I would start by reading the Tomcat Documentation on the subject.
> It's pretty straightforward.
> Jeff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: SSL Best Practices
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Jeffrey D. Fisher [mailto:jeff.fisher12237@cox.net]
> Sent: Friday, March 15, 2013 3:03 PM
> To: users@tomcat.apache.org
> Subject: SSL Best Practices
>
> Gentlemen (Ladies):
>
>
>
> I am looking for a published "best practice" on editing the SERVER.XML
> configuration file to use SSL/HTTPS. The key are imported into the
> keystore.
>
>
>
> Any input is appreciated.
>
>
>
> Jeff Fisher
>
> Omaha, NE
I would start by reading the Tomcat Documentation on the subject.
It's pretty straightforward.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Best Practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 3/15/13 4:02 PM, Jeffrey D. Fisher wrote:
> I am looking for a published "best practice" on editing the
> SERVER.XML configuration file to use SSL/HTTPS. The key are
> imported into the keystore.
>
> Any input is appreciated.
What documentation have you read so far? What steps have you taken?
What kind of Connector are you using?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlFDg3kACgkQ9CaO5/Lv0PBxwgCgtvWSU8gJGyvt+3BqADImfLyI
DMwAni+NRXYq6F31B7lWFrb4Vbrzv3hc
=20Dg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org