Re: ALv2 Tomcat Training material

[Don Flinn]

Hi Mark,

I think this is an excellent and useful task. The first step is to define
the audiences of which I would like to suggest five.

1. Experienced System administrators with experience in security and SSL
2. Experienced System administrators with no or little experience in
security and SSL
3  Non system administrators with  experience in security and SSL
4. Non system administrators with  no or little experience in security and
SSL
5. Overarching each of the above is the different CAs that might be used

A question would be are audiences 3 and 4 populated.  I for one fall
somewhere between 3 and 4, but maybe I'm the only one.  It seems to me that
small companies would fall into 3 and 4.  A big further complication is
item 5, which applies to each of the others.

I wrote a short write-up to this site about a month age addressing
audiences 2, 3 and 4, mostly 4 and was told that this was not what was
wanted, that all the information was somewhere on the web.  That is true
but trying to find it, absorb and apply it is difficult.

Don


On Thu, Jan 4, 2018 at 5:16 AM, Mark Thomas  wrote:

> Hi,
>
> One of the things on my TODO list is to put together some Tomcat
> training material licensed under the Apache License (version 2). i.e.
> material that would be made freely available for folks to use.
>
> I'd also like to make the training material available on YouTube as well
> as run some training courses (for a small fee) to deliver the material
> face to face.
>
> The structure I have in mind is a series of modules (say 30 mins in
> length) that can be organised in different ways to suit different needs.
> e.g. put the introductory modules for each area together to provide an
> 'Introduction to Tomcat course', put all the TLS modules together to
> provide an in depth 'Tomcat and TLS' course etc.
>
> I think a lot of the raw content is already available. We have the
> various Tomcat presentations that have been given over the years and my
> employer has agreed to let me make use of the material from our (now
> possibly a little dated) Tomcat training courses.
>
> I can't do this alone. Not in any reasonable time frame anyway. So I am
> reaching out to the community for help.
>
> The first step is to come with:
> - a list of modules
> - potential courses formed from combinations of modules
>
> I am asking for your ideas for modules, courses and combinations of
> modules that could make up those courses.
>
> We have a blank wiki page to host this:
> https://cwiki.apache.org/confluence/display/TOMCAT/Tomcat+Training+Course
>
> Feel free to ask for edit access to that page (you'll need to create an
> account and let us know the user name) so you can add ideas directly or
> add ideas to this thread and I'll add them to the wiki page.
>
> The second step is to start populating the modules with actual content.
> As a motivator to get this done, I'd like to run a public Tomcat
> training course in late March / early April using this material. My
> current thinking is that the course would cost ~£100 plus food per
> person for the full day. Possible locations for this course are:
> - Cardiff
> - Birmingham
> - Manchester
> - Glasgow
> (all in the UK - if successful we can expand to mainland Europe and beyond)
>
> My second request is for feedback on which location(s) are preferable
> and what content would you like to see in the training course. I'll take
> this feedback, put together a course and then make it available to book.
>
> I look forward to all your ideas.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

re: Comments on my first 'SSL for Tomcat' write-up

[Don Flinn]

Chis Schultz and Mark Thomas,

I started a new thread as the old one was getting too long and getting off
subject.
Chris Schultz wrote -

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

tificate (as described in the previous
section):
* keytool -genkey -alias tomcat -keyalg RSA
-keystore 
Note: In some cases you will have to enter the domain of your website (i.e.
www.myside.org) in the field "first- and lastname" in order to create a
working Certificate.
* The CSR is then created with:
* keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr
-keystore 
Now you have a file called certreq.csr that you can submit to the
Certificate Authority (look at the documentation of the Certificate
Authority website on how to do this). In return you get a Certificate.
11) Importing the Certificate
Now that you have your Certificate you can import it into you local
keystore. First of all you have to import a so called Chain Certificate or
Root Certificate into your keystore. After that you can proceed with
importing your Certificate.
* Download a Chain Certificate from the Certificate Authority you obtained
the Certificate from.
For Verisign.com commercial certificates go to:
http://www.verisign.com/support/install/intermediate.html
For Verisign.com trial certificates go to:
http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html
For Trustcenter.de go to:
http://www.trustcenter.de/certservices/cacerts/en/en.htm#server
For Thawte.com go to: http://www.thawte.com/certs/trustmap.html
* Import the Chain Certificate into your keystore
* keytool -import -alias root -keystore 
-trustcacerts -file 
* And finally import your new Certificate
* keytool -import -alias tomcat -keystore 
-file 

Restart Tomcat and run a test case.

12) References

Applied Cryptography (Second Edition) Bruce Schneier 1996
Old but still a great book for learning the details of cryptography. Long
at 758 pages

A Layman's Guide to a Subset of ASN.1, BER, and DER  Burton S. Kaliski Jr.
Revised November 1, 1993 http://luca.ntop.org/Teaching/Appunti/asn1.html
A layman's introduction to a subset of OSI's Abstract Syntax Notation One
(ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER).

Festy Duck OpenSSL Cookbook by Ivan Risti?
https://www.feistyduck.com/library/openssl-cookbook/
Free download of a detailed description of all aspects of OpenSSL









On Sun, Dec 3, 2017 at 9:13 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Don Flinn [mailto:fl...@alum.mit.edu]
> > Subject: Re: Trying to understand How Tomcat uses Keystore for SSL
>
> > Attached is a first cut at setting up SSL for Tomcat.  It is in MicroSoft
> Word.
>
> Most attachments are automatically stripped by the mailing list server.
> You
> can either send it in plain text or post it somewhere publicly accessible.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
>

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

Chris,

Attached is a first cut at setting up SSL for Tomcat.  It is in MicroSoft
Word. Hopefully people have that. If not I'll send it in another format
that is acceptable.

I tried to achieve a balance between completeness and brevity by only going
deep enough to give the reader enough information to understand what is
needed to use SSL/TLS with Tomcat.  When it got down to keystore I
effectively just repeated what was on the Tomcat SSL website.  A weak point
in the writeup (among many others) is getting Tomcat to listen on port 80
for letsencrpy.

If this might be useful please comment and correct.

Don

On Fri, Dec 1, 2017 at 11:32 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Don,
>
> On 12/1/17 3:14 AM, Don Flinn wrote:
> > I'll be happy to accept your challenge to try to write some
> > documentation for the site from a newbee's point of view.  It will
> > be on the slow side as my 'day job' will interfere somewhat.  It
> > also will require some correction of errors.
>
> No problem at all. Just reach-out to the group if you need any
> hand-holding.
>
> - -chris
> > On Wed, Nov 29, 2017 at 9:37 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Don,
> >
> > On 11/28/17 4:55 PM, Don Flinn wrote:
> >>>>>> In fact, I think you are using PEM-encoded DER files and
> >>>>>> not a packaged keystore, even though your
> >>>>>> SSLHostConfig's keystoreType is set to "PKCS12".
> >>>>
> >>>> Yes, I am using PEM files.  Got to read more on DER files.
> >
> > PEM is an encoding, while DER is really the file format. It's like
> > saying "is this file text/plain or UTF-8?"
> >
> > This is a great read for almost anyone who cares about x509
> > certificates :
> >
> > https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-
> ce
> >
> >
> r-vs-pem-certificates-and-how-to-convert-them
> >
> >>>> So do I just drop the keystoreType="PKCS12"  from the
> >>>> connector?
> > Theoretically, yes. The keystoreType is only used when there is a
> > keystore and not "certificate files", etc.
> >
> >>>>> If there's anything inaccurate on the Tomcat site
> >>>>
> >>>> No, I was talking about other sites, not the Tomcat site.
> >>>> I've been reading all over the internet for that which seems
> >>>> related. My statement was a caution to not believe everything
> >>>> you read. 'Trust but verify'
> >
> > Mark has given a number of presentations on TLS and they are very
> > accessible. Have a look at the slides (and some audio/video) on
> > the "presentations" page on the Tomcat site. Each of them has a
> > varying level of "introductoryness", but I think the more recent
> > ones like "Introduction to Tomcat and TLS" from TomcatCon in Miami
> > are probably the best ones to see for beginners.
> >
> >>>> Your e-mail has been very helpful, not only to me, but I
> >>>> believe to others.  With respect to the Tomcat site, I think
> >>>> a lot of what you wrote would be very helpful there.  For
> >>>> example, the Tomcat write up on SSL describes how to do self
> >>>> signed certificates and fleetingly mentions that if you have
> >>>> a certificate from a CA that you could use e.g. openssl and
> >>>> then refers the reader to their java documentation and
> >>>> openssl documentation.  Not too helpful to the
> >>>> security/Tomcat novice.
> >
> > Agreed. Would you care to write some new documentation and/or
> > prepare a patch for the site? IT's usually best when beginners
> > write for their own audience. I, for example, understand it
> > backwards and forwards so when I write I have a skewed perspective.
> > Writing as a beginner can re-focus the narrative for a different
> > audience.
> >
> > If you need any help grabbing the site from svn, etc. please just
> > ask.
> >
> >>>> Thanks for your patience and help.
> >
> > You are more important than the software. No, really:
> > https://blogs.apache.org/foundation/entry/asf_15_community_over_code
> >
> >  -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

Chris

I'll be happy to accept your challenge to try to write some documentation
for the site from a newbee's point of view.  It will be on the slow side as
my 'day job' will interfere somewhat.  It also will require some correction
of errors.

Don

On Wed, Nov 29, 2017 at 9:37 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Don,
>
> On 11/28/17 4:55 PM, Don Flinn wrote:
> >>> In fact, I think you are using PEM-encoded DER files and not a
> >>> packaged keystore, even though your SSLHostConfig's
> >>> keystoreType is set to "PKCS12".
> >
> > Yes, I am using PEM files.  Got to read more on DER files.
>
> PEM is an encoding, while DER is really the file format. It's like
> saying "is this file text/plain or UTF-8?"
>
> This is a great read for almost anyone who cares about x509 certificates
> :
>
> https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-ce
> r-vs-pem-certificates-and-how-to-convert-them
>
> > So do I just drop the keystoreType="PKCS12"  from the connector?
> Theoretically, yes. The keystoreType is only used when there is a
> keystore and not "certificate files", etc.
>
> >> If there's anything inaccurate on the Tomcat site
> >
> > No, I was talking about other sites, not the Tomcat site.  I've
> > been reading all over the internet for that which seems related.
> > My statement was a caution to not believe everything you read.
> > 'Trust but verify'
>
> Mark has given a number of presentations on TLS and they are very
> accessible. Have a look at the slides (and some audio/video) on the
> "presentations" page on the Tomcat site. Each of them has a varying
> level of "introductoryness", but I think the more recent ones like
> "Introduction to Tomcat and TLS" from TomcatCon in Miami are probably
> the best ones to see for beginners.
>
> > Your e-mail has been very helpful, not only to me, but I believe
> > to others.  With respect to the Tomcat site, I think a lot of what
> > you wrote would be very helpful there.  For example, the Tomcat
> > write up on SSL describes how to do self signed certificates and
> > fleetingly mentions that if you have a certificate from a CA that
> > you could use e.g. openssl and then refers the reader to their java
> > documentation and openssl documentation.  Not too helpful to the
> > security/Tomcat novice.
>
> Agreed. Would you care to write some new documentation and/or prepare
> a patch for the site? IT's usually best when beginners write for their
> own audience. I, for example, understand it backwards and forwards so
> when I write I have a skewed perspective. Writing as a beginner can
> re-focus the narrative for a different audience.
>
> If you need any help grabbing the site from svn, etc. please just ask.
>
> > Thanks for your patience and help.
>
> You are more important than the software. No, really:
> https://blogs.apache.org/foundation/entry/asf_15_community_over_code
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloexiYdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiY1Q//SLRGAzEuc2QzyvK9
> svCG+s0HKA1QY+ubtdmoy+czFtm1b857uQ6L0Zo8KCp+edzYvTyd7iupGjPngEqr
> 5B9qRV3bcu3jsvMUcXEFe779MjjKsSX+m0jF8/9A1RtOvtEqqemlC6Q5AVuSZZUf
> usSrTjXV2XyVlEtv0J5Rw+hMtLUpRwppg1LKAX5ZflHdhA1Zdq+TH6NSbLQlPr1z
> WRzpLuOfSpt6Cnx2Kfqcwgop0EqCyPFcIqC3o2V+ONDQh4Z7FOdUNn70O03ympDg
> fRMZbo8o0mX6RyjSk0nDFEfXLv2lafPoOrE5OUMvnuN4bZ472Jpq3nDtl0ZwYSIy
> IcjXnfw+NUNTcIkJVz0K009/K/U8U4O4NBm5IBW4uFa2yapx717pB8H/Fmr6LvEr
> FuIZG6wODc7YtN3kqbHR8J/3N1n3q6SM3CXyyjfazN0Kur0e4FOIE5WagzZTwQSm
> K7LJsuIu84sVEShPcTB2CvTsaawJQj7clCM+eZngejuvuxSiwiC0u0zWKfoPDD8Z
> bbXY69RJ0F1iKw7rgj+tr1KOxoNaDyHV8ys7CKinuG32hb37qzntygLrGZ0ZPOQZ
> pUTuSsm1Zn/Zd/3oLWIhXJ9UZA5OfwhYYt6YwaTo4JYLhB1IsiVl9qqdzo2CQLIY
> UHuG7kdiTBEig/ej+/RBOLZSI0k=
> =6iU6
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

Chris,

Thanks for the corrections.

>>In fact, I think you are using PEM-encoded DER files and not a
>>packaged keystore, even though your SSLHostConfig's keystoreType is
>>set to "PKCS12".

Yes, I am using PEM files.  Got to read more on DER files.  So do I just
drop the keystoreType="PKCS12"  from the connector?

>I'll have to triple-check, but I believe you can put all certificates
>into a single file like you can do with httpd. Just make sure that
>your server's certificate (leaf) is listed first, then the
>intermediate certificate(s), then the root certificate. Usually you do
>not need to supply the root certificate since most clients should have
>the root certificates available already.

I'll give that a try.

>Use SSL Labs' SSLTest[1] to help make sure you don't have too little
>or too much in your certificate. Too little and your clients will get
>trust errors. Too much and you'll be wasting bandwidth

Will do

>If there's anything inaccurate on the Tomcat site

No, I was talking about other sites, not the Tomcat site.  I've been
reading all over the internet for that which seems related.  My statement
was a caution to not believe everything you read.  'Trust but verify'

Your e-mail has been very helpful, not only to me, but I believe to
others.  With respect to the Tomcat site, I think a
lot of what you wrote would be very helpful there.  For example, the Tomcat
write up on SSL describes how to do self signed certificates and
fleetingly mentions
that if you have a certificate from a CA that you could use e.g. openssl
and then refers the reader to their java documentation and openssl
documentation.  Not too helpful to the security/Tomcat novice.

Thanks for your patience and help.
Don


On Tue, Nov 28, 2017 at 12:59 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Don,
>
> On 11/27/17 10:47 AM, Don Flinn wrote:
> > My previous mail was cryptic.  Below is a fuller explanation of
> > what I did to get things running.
> >
> > First, I'm using Tomcat 9 and the protocol for the Tomcat 8.5 and
> > up has been expanded.  Chris suggested that I use PKCS12 rather
> > than JDK keystore, which I have done.
>
> Actually, at this point, I'd be using the PEM-encoded DER files (just
> like httpd does) instead of a packaged cert/key bundle, just because I
> find those easier to deal with.
>
> > I'm also using the APR configuration.  So redirected connector that
> > I'm using looks like:
> >
> >  > port="8443" maxThreads="150" SSLEnabled="true">
> >
> >  keystoreType="PKCS12"  > certificateKeyFile="C:/users/don/Security/domain.key"
> > certificateFile="C:/users/don/Security/domain-chain.crt"
> > certificateChainFile="C:/users/don/Security/ICDTrustRoot.crt"
> > type="RSA" /> 
> >
> > 
>
> In fact, I think you are using PEM-encoded DER files and not a
> packaged keystore, even though your SSLHostConfig's keystoreType is
> set to "PKCS12".
>
> > The domain key is the private key I used when getting the
> > certificates from letsencrypt.  The certificate I got from
> > letsencrypt I called domain-chain.crt. Lastly I downloaded the
> > ICDTrustRoot.crt from the letsencrypt at
> > https://letsencrypt.org/certificates.
>
> If you use a tool like certbot-auto (which may or may not be available
> for Windows), all of this is done automatically for you.
>
> > You will notice that I'm using Window's syntax, which is just for
> > the pathname where the certificates live.  You would use a Linux
> > path syntax if you are running Linux.  You need three certificates
> > for letsencrypt; a cert for your domain, one for the intermediate
> > and finally the root certificate.
>
> +1
>
> > What I call domain-chain.crt holds two certificates; my domain
> > certificate and the intermediate.  In order to see what these were
> > I separated them in a text editor and called them domaincert1.crt
> > and the second domaincert2.crt Then I used openssl to see what was
> > in them.  For example:
> >
> > openssl x509 -noout -subject -issuer -in domaincert1.crt this
> > printed out subject= /CN=info.finwoks.com issuer= /C=US/O=Let's
> > Encrypt/CN=Let's Encrypt Authority X3
> >
> > So that one was my domain cert issued by the letsencrypt
> > intermediate
> >
> > The second one certificate gave subject= /C=US/O=Let's
> > Encrypt/CN=Let's Encrypt Authority X3 issuer= /O=Digital Signature
> > Trust Co./CN=DST Root CA X3
> >
> > which is the intermediate.
>
> I'l

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

Hi Joleen,

My previous mail was cryptic.  Below is a fuller explanation of what I did
to get things running.

First, I'm using Tomcat 9 and the protocol for the Tomcat 8.5 and up has
been expanded.  Chris suggested that I use PKCS12 rather than JDK keystore,
which I have done. I'm also using the APR configuration.  So redirected
connector that I'm using looks like:




 keystoreType="PKCS12"





The domain key is the private key I used when getting the certificates from
letsencrypt.  The certificate I got from letsencrypt I called
domain-chain.crt. Lastly I downloaded the ICDTrustRoot.crt from the
letsencrypt at https://letsencrypt.org/certificates.  You will notice that
I'm using Window's syntax, which is just for the pathname where the
certificates live.  You would use a Linux path syntax if you are running
Linux.  You need three certificates for letsencrypt; a cert for your
domain, one for the intermediate and finally the root certificate.

What I call domain-chain.crt holds two certificates; my domain certificate
and the intermediate.  In order to see what these were I separated them in
a text editor and called them domaincert1.crt and the second domaincert2.crt
Then I used openssl to see what was in them.  For example:

openssl x509 -noout -subject -issuer -in domaincert1.crt
this printed out
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

So that one was my domain cert issued by the letsencrypt intermediate

The second one certificate gave
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

which is the intermediate.

I downloaded the certificates using the java program mentioned in my
previous e-mail. Depending on your particular setup, you can get the four
items using different methods.  I would suggest that you check what the
various certificates contain by using the ssl commands. I've also read that
the order of the certificates should be

Your domain
Intermediate
Known Root

So that's the order I used.  A caution, in my reading I have found some
directions not to be accurate.

If what I have written is not clear, please let me know and I'll try to
clear it up.

Don




On Mon, Nov 27, 2017 at 5:52 AM, Joleen Barker <oldenuf2no...@gmail.com>
wrote:

> Hello Don,
>
> I'm trying to understand these as well. I had a question regarding the data
> and commands you used to display the certificate information. You wrote
> that you used the following command to create a pkcs12 store:
>
> openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key" -certfile
> "ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout "pass:changeit"
>
> To display the 2 certs you show one example command to see the first one
> as:
>
> openssl x509 -noout -subject -issuer -in domaincert1.crt subject= /CN=
> info.finwoks.com issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority
> X3
>
> Where did the "domaincert1.crt" come from? I did not see anything in the
> first command reference this and I was not sure how someone would know this
> name and the second one called domaincert2.crt.
>
> Thank you,
>
> Joleen
>
> On Sun, Nov 26, 2017 at 10:35 PM, Don Flinn <fl...@alum.mit.edu> wrote:
>
> > IT WORKS
> >
> > My next question is whether the Tomcat team would want this Java program
> > that does the heavy lifting for letsencrypt, which I would be happy to
> > clean up and make available as open source.  The guts of the program
> comes
> > from -  http://acme4j.shredzone.org, which is under the Apache license.
> >
> > I've made a number of enhancements, e;g. a GUI front end; the ability to
> do
> > the letsencrypt authorization without any user intervention; the ability
> to
> > sit on an admin node retrieve and install the retrieved letsencrypt SSL
> > certificates on a remote tomcat node.
> >
> > If the answer is yes, let me know the procedure to make it available as
> > open sourcce.
> >
> > Don
> >
> > On Sun, Nov 26, 2017 at 4:54 PM, Don Flinn <fl...@alum.mit.edu> wrote:
> >
> > > Didn't read closely enough.  The protocol that I used is no longer
> > > applicable for Tomcat 9.
> > >
> > > Don
> > >
> > > On Sun, Nov 26, 2017 at 3:15 PM, Don Flinn <fl...@alum.mit.edu> wrote:
> > >
> > >> Chris
> > >>
> > >> Thank you for your excellent reply and references.
> > >>
> > >> I've been doing a lot of reading on SSL, certificates, keys,
> algorithms,
> > >> etc. Woo!  However I still don't have it correct.
> > >>
> > >> I've retrieved certificates 

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

IT WORKS

My next question is whether the Tomcat team would want this Java program
that does the heavy lifting for letsencrypt, which I would be happy to
clean up and make available as open source.  The guts of the program comes
from -  http://acme4j.shredzone.org, which is under the Apache license.

I've made a number of enhancements, e;g. a GUI front end; the ability to do
the letsencrypt authorization without any user intervention; the ability to
sit on an admin node retrieve and install the retrieved letsencrypt SSL
certificates on a remote tomcat node.

If the answer is yes, let me know the procedure to make it available as
open sourcce.

Don

On Sun, Nov 26, 2017 at 4:54 PM, Don Flinn <fl...@alum.mit.edu> wrote:

> Didn't read closely enough.  The protocol that I used is no longer
> applicable for Tomcat 9.
>
> Don
>
> On Sun, Nov 26, 2017 at 3:15 PM, Don Flinn <fl...@alum.mit.edu> wrote:
>
>> Chris
>>
>> Thank you for your excellent reply and references.
>>
>> I've been doing a lot of reading on SSL, certificates, keys, algorithms,
>> etc. Woo!  However I still don't have it correct.
>>
>> I've retrieved certificates from letsencrypt and following your
>> suggestions did the following.
>>
>> Created a pkcs12 store using the following command line.
>> openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key"
>> -certfile "ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout
>> "pass:changeit"
>>
>> where the domain-chain.crt contains two certificates  and ICDTrustRoot
>> contains one as shown below -
>> PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
>> -in domaincert1.crt   (the first cert in domain-chain.crt)
>> subject= /CN=info.finwoks.com
>> issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>>
>> PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
>> -in domaincert2.crt (the second cert in domain-chain.crt)
>> subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>> issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
>>
>> PS C:\users\don\security\letsenc4> openssl x509 -noout -subject -issuer
>> -in ICDTrustRoot.crt
>> subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
>> issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
>> so I have the three certificates and the private key which is shared with
>> letsencrypt called domain.key
>> My server.xml contains:
>> >sslImplementationName="org.apache.tomcat.util.net.openssl.O
>> penSSLImplementation"
>>port="8443"  maxThreads="200"
>>scheme="https" secure="true" SSLEnabled="true" keystoreType="PKCS12"
>>keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
>>   clientAuth="false" sslProtocol="TLS"
>>/>
>>
>> However when I restart Tomcat is get the following error in the Tomcat
>> error log and of course it fails in the handshake with the browser
>>
>> org.apache.catalina.core.StandardService.initInternal Failed to
>> initialize connector [Connector[HTTP/1.1-8443]]
>>  org.apache.catalina.LifecycleException: Failed to initialize component
>> [Connector[HTTP/1.1-8443]]
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>> at org.apache.catalina.core.StandardService.initInternal(Standa
>> rdService.java:549)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at org.apache.catalina.core.StandardServer.initInternal(Standar
>> dServer.java:873)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.Pool.cre
>> ate(J)J
>> at org.apache.tomcat.jni.Pool.create(Native Method)
>> at org.apache.tomcat.util.net.openssl.OpenSSLEngine.(Op
>> enSSLEngine.java:75)
>> at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImpl

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

Didn't read closely enough.  The protocol that I used is no longer
applicable for Tomcat 9.

Don

On Sun, Nov 26, 2017 at 3:15 PM, Don Flinn <fl...@alum.mit.edu> wrote:

> Chris
>
> Thank you for your excellent reply and references.
>
> I've been doing a lot of reading on SSL, certificates, keys, algorithms,
> etc. Woo!  However I still don't have it correct.
>
> I've retrieved certificates from letsencrypt and following your
> suggestions did the following.
>
> Created a pkcs12 store using the following command line.
> openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key"
> -certfile "ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout
> "pass:changeit"
>
> where the domain-chain.crt contains two certificates  and ICDTrustRoot
> contains one as shown below -
> PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
> -in domaincert1.crt   (the first cert in domain-chain.crt)
> subject= /CN=info.finwoks.com
> issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>
> PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
> -in domaincert2.crt (the second cert in domain-chain.crt)
> subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
> issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
>
> PS C:\users\don\security\letsenc4> openssl x509 -noout -subject -issuer
> -in ICDTrustRoot.crt
> subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
> issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
> so I have the three certificates and the private key which is shared with
> letsencrypt called domain.key
> My server.xml contains:
> sslImplementationName="org.apache.tomcat.util.net.openssl.
> OpenSSLImplementation"
>port="8443"  maxThreads="200"
>scheme="https" secure="true" SSLEnabled="true" keystoreType="PKCS12"
>keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
>   clientAuth="false" sslProtocol="TLS"
>/>
>
> However when I restart Tomcat is get the following error in the Tomcat
> error log and of course it fails in the handshake with the browser
>
> org.apache.catalina.core.StandardService.initInternal Failed to
> initialize connector [Connector[HTTP/1.1-8443]]
>  org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> at org.apache.catalina.core.StandardService.initInternal(Standa
> rdService.java:549)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.core.StandardServer.initInternal(Standar
> dServer.java:873)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> Caused by: java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.Pool.cre
> ate(J)J
> at org.apache.tomcat.jni.Pool.create(Native Method)
> at org.apache.tomcat.util.net.openssl.OpenSSLEngine.(
> OpenSSLEngine.java:75)
> at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplemente
> dProtocols(OpenSSLUtil.java:61)
> at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:46)
> at org.apache.tomcat.util.net.openssl.OpenSSLUtil.(OpenSS
> LUtil.java:41)
> at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.get
> SSLUtil(OpenSSLImplementation.java:36)
> at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSs
> l(AbstractJsseEndpoint.java:82)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:261)
> at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEnd
> point.java:798)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
> at org.apache.coyote.http11.AbstractHttp11Protocol.init(Abstrac
> tHttp11Protocol.java:66)
> at org.apache.catalina.connector.Connector.initInternal(Connect
> or.java:1010)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> ... 12 more
>
> I'm running Tomcat 9 in Amazon Web services using Windows Server.  I don't
> know what I'm doing wrong.  F

Re: Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

Chris

Thank you for your excellent reply and references.

I've been doing a lot of reading on SSL, certificates, keys, algorithms,
etc. Woo!  However I still don't have it correct.

I've retrieved certificates from letsencrypt and following your suggestions
did the following.

Created a pkcs12 store using the following command line.
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key" -certfile
"ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout "pass:changeit"

where the domain-chain.crt contains two certificates  and ICDTrustRoot
contains one as shown below -
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer -in
domaincert1.crt   (the first cert in domain-chain.crt)
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer -in
domaincert2.crt (the second cert in domain-chain.crt)
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

PS C:\users\don\security\letsenc4> openssl x509 -noout -subject -issuer -in
ICDTrustRoot.crt
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
so I have the three certificates and the private key which is shared with
letsencrypt called domain.key
My server.xml contains:


However when I restart Tomcat is get the following error in the Tomcat
error log and of course it fails in the handshake with the browser

org.apache.catalina.core.StandardService.initInternal Failed to initialize
connector [Connector[HTTP/1.1-8443]]
 org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at org.apache.catalina.core.StandardService.initInternal(
StandardService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(
StandardServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.Pool.
create(J)J
at org.apache.tomcat.jni.Pool.create(Native Method)
at org.apache.tomcat.util.net.openssl.OpenSSLEngine.
(OpenSSLEngine.java:75)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplementedProtocols(
OpenSSLUtil.java:61)
at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:46)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.(
OpenSSLUtil.java:41)
at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.getSSLUtil(
OpenSSLImplementation.java:36)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(
AbstractJsseEndpoint.java:82)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:261)
at org.apache.tomcat.util.net.AbstractEndpoint.init(
AbstractEndpoint.java:798)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(
AbstractHttp11Protocol.java:66)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more

I'm running Tomcat 9 in Amazon Web services using Windows Server.  I don't
know what I'm doing wrong.  Further help will be appreciated. It appears I
have the pkcs12 wrong.

Don

On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Don,
>
> On 11/14/17 1:57 AM, Don Flinn wrote:
> > I've done some reading on SSL and understand the protocol is as
> > follows; Client/Browser sends ClientHello and server Tomcat replies
> > with ServerHello.  This establishes the protocol they will use. The
> > server then sends the certificate and the public key - in the
> > clear The browser encrypts a message containing the servers domain,
> > all encrypted with the server's public key to the CA which the
> > browser trusts.  The public key is in the certificate. The CA
> > de-crypts the message with the server's private key.  So the
> > server's name/ domain must be not encrypted. If the server can
> > decrypt the message it knows the server and it then sends a ack
> > message back to the browser encryp

Trying to understand How Tomcat uses Keystore for SSL

[Don Flinn]

I've done some reading on SSL and understand the protocol is as follows;
Client/Browser sends ClientHello and server Tomcat replies with
ServerHello.  This establishes the protocol they will use.
The server then sends the certificate and the public key - in the clear
The browser encrypts a message containing the servers domain, all encrypted
with the server's public key to the CA which the browser trusts.  The
public key is in the certificate.
The CA de-crypts the message with the server's private key.  So the
server's name/ domain must be not encrypted. If the server can decrypt the
message it knows the server and it then sends a ack message back to the
browser encrypted with the client's private key.
The browser and Tomcat then establish a secret key to send messages back
and forth.

If I have the above correct, I must have keystore set up incorrectly, since
running my scenario I get an error in the Chrome debugger,which says

This page is not secure
"Valid certificate
The connection to this site is using a valid, trusted server certificate
issued by unknown name.
Secure resources
All resources on this page are served securely. "

Note the 'the certificate is valid and it is issued by unknown name"  Why
is the issuer unknown, since the issuer's name is in the certificate?

letsencrypt has an online web site from which one can download a ca_bundle,
a private key and a certificate for your domain
Oracle has an article on keytool which says that keytool  can not create a
pkcs12 keystore but can read it and to use openssl, which I did following
their instructions.  Concatenate the CA cert, the private key and the user
cert then put these in keystore. The result is shown below.  Tomcat isn't
able to use this keystore to communicate with the browser for some reason.
Why? What's missing or incorrect?

C:\Users\don\Security\letsenc>%keytool% -list -keystore MMcert.p12 -v
-storetype pkcs12
Enter keystore password:

Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: tomcat
Creation date: Nov 13, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=info.finwoks.com
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Serial number: 415913da3a6a956ef3efef2fb2eb4baff17
Valid from: Sat Nov 11 16:05:35 EST 2017 until: Fri Feb 09 16:05:35 EST 2018
Certificate fingerprints:
 MD5:  F5:FD:4F:8B:9A:A0:38:D1:B7:78:B6:36:38:AB:42:31
 SHA1: 7C:AB:5C:D3:A9:95:01:FD:43:CC:F5:D5:1D:24:64:1A:BF:4C:AE:66
 SHA256:
A9:85:5C:34:3D:DA:65:64:2F:C7:45:57:52:3F:EE:0F:D6:70:50:DE:AA:5C:2A:D1:16:F3:29:B9:CB:F3:B2:36
 Signature algorithm name: SHA256withRSA
 Version: 3

Extensions:

#1: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: ocsp
   accessLocation: URIName: http://ocsp.int-x3.letsencrypt.org
,
   accessMethod: caIssuers
   accessLocation: URIName: http://cert.int-x3.letsencrypt.org/
]
]

#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
: A8 4A 6A 63 04 7D DD BA   E6 D1 39 B7 A6 45 65 EF  .Jjc..9..Ee.
0010: F3 A8 EC A1
]
]

#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
]

#4: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
  [CertificatePolicyId: [2.23.140.1.2.1]
[]  ]
  [CertificatePolicyId: [1.3.6.1.4.1.44947.1.1.1]
[PolicyQualifierInfo: [
  qualifierID: 1.3.6.1.5.5.7.2.1
  qualifier: : 16 1A 68 74 74 70 3A 2F   2F 63 70 73 2E 6C 65 74  ..
http://cps.let
0010: 73 65 6E 63 72 79 70 74   2E 6F 72 67  sencrypt.org

], PolicyQualifierInfo: [
  qualifierID: 1.3.6.1.5.5.7.2.2
  qualifier: : 30 81 9E 0C 81 9B 54 68   69 73 20 43 65 72 74 69
0.This Certi
0010: 66 69 63 61 74 65 20 6D   61 79 20 6F 6E 6C 79 20  ficate may only
0020: 62 65 20 72 65 6C 69 65   64 20 75 70 6F 6E 20 62  be relied upon b
0030: 79 20 52 65 6C 79 69 6E   67 20 50 61 72 74 69 65  y Relying Partie
0040: 73 20 61 6E 64 20 6F 6E   6C 79 20 69 6E 20 61 63  s and only in ac
0050: 63 6F 72 64 61 6E 63 65   20 77 69 74 68 20 74 68  cordance with th
0060: 65 20 43 65 72 74 69 66   69 63 61 74 65 20 50 6F  e Certificate Po
0070: 6C 69 63 79 20 66 6F 75   6E 64 20 61 74 20 68 74  licy found at ht
0080: 74 70 73 3A 2F 2F 6C 65   74 73 65 6E 63 72 79 70  tps://letsencryp
0090: 74 2E 6F 72 67 2F 72 65   70 6F 73 69 74 6F 72 79  t.org/repository
00A0: 2F /

]]  ]
]

#5: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
  clientAuth
]

#6: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]

#7: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: info.finwoks.com
]

#8: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 04 6B 27 5C F4 5E 85 21   24 38 A7 44 2D 7E 69 CA  .k'\.^.!$8.D-.i.
0010: CF 

Re: Am I reinventing the wheel to get letsencrypt certs for Tomcat

[Don Flinn]

Hi Johan,

Thank you for the information.  A few things, I'm running Tomcat on a
Windows machine as a windows server.  I'm not running as root, I was
talking about the ROOT directory under Tomcat's webapps directory.  So that
when letsencrpt logs into my domain/.well-known/acme-challenge, which is
where they are looking for the authentication token. they just retrieve the
authentication file.  I'll look at your approach using Windows.

Don

On Fri, Oct 27, 2017 at 10:37 AM, Johan Compagner <jcompag...@servoy.com>
wrote:

> On 27 October 2017 at 15:05, Don Flinn <fl...@alum.mit.edu> wrote:
>
> > Hi Andre,
> >
> > I have looked and it may be my ignorance but I didn't find any that
> seemed
> > to fit.  I'll look more closely at the available letsencrypt clients.
> >
> > With letsencrypt you first have to authenticate, i.e. show you own the
> > site, by letsencrypt logging into your site, e.g. Tomcat and checking a
> > token.  Then the Java program can get the letsencrypt certificate.  There
> > are two different addresses Tomcat on AWS and the node, which is running
> > the Java program.
> >
> > I've set Tomcat to listen on port 80 and put the directory structure they
> > want in Tomcat ROOT.  The Java program, running on my node, gets the
> > letsencrypt authentication token and ftp's it to Tomcat
> > ROOT/.well-known/acme-challenge, which is the directory structure they
> > expect. letsencryt then authenticates the token which is in Tomcat, by
> > retrieving it . The program lets letsencrypt know when the ftp is done
> The
> > Java program then retrieves the certificate from letsencrypt, puts it in
> a
> > keystore, ftp's the keystore to AWS in the directory in which I've set
> > Tomcat to look for the keystore.  It's all done from the one Java
> program,
> > which I can run from my node.  I have yet to incorporate programically
> > inserting the certificate into the keystore.  All the other steps are
> > working.  It needs testing and doing the update of the certificate, which
> > is pretty much the same steps as already programmed.
> >
> > Don
> >
>
>
>
> i just set this up a few day ago
>
> But all the current scripts out there are working for the most part
> Also running tomcat at root is not a good idea you can just use ip tables
> for that:
>
> sudo iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port
> 8080
> sudo iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-port
> 8443
>
> so when tomcat is running on port 8080 and 8440 with iptables you route
> those port also to 80/443
>
> so no need to change anything in tomcat
>
> besides that i just use certbot-auto
>
> wget https://dl.eff.org/certbot-auto
> sudo chmod a+x certbot-auto
>
> sudo ./certbot-auto --debug -v --server
> https://acme-v01.api.letsencrypt.org/directory certonly -d your.domain.com
>
>
> you have to have a ROOT webapp in tomcat for this and with certbot you just
> point to that tomcat/webapps/ROOT dir
>
> and the certificates are there.
>
>
> then the only thing todo left is to convert it and place it in the right
> folder (and i guess the first time you have to change also the owner/group
> because that file will be root:root)
>
>
> sudo openssl pkcs12 -export -out tomcat/conf/bundle.pfx -inkey
> /etc/letsencrypt/live/your.domain.com/privkey.pem
> <http://build.servoy.com/privkey.pem> -in /etc/letsencrypt/live/
> your.domain.com/cert.pem <http://build.servoy.com/cert.pem> -certfile
> /etc/letsencrypt/live/your.domain.com/chain.pem
> <http://build.servoy.com/chain.pem> -password pass:apassword
>
>
> and you have your first certificate in a format tomcat/java understand
>
>
> then only a crontab under root:
>
>
> #!/bin/sh
> /home/ec2-user/certbot-auto renew
> openssl pkcs12 -export -out /tomcat/conf/bundle.pfx -inkey
> /etc/letsencrypt/live/your.domain.com/privkey.pem
> <http://build.servoy.com/privkey.pem> -in /etc/letsencrypt/live/
> your.domain.com/cert.pem <http://build.servoy.com/cert.pem> -certfile
> /etc/letsencrypt/live//your.domain.com/chain.pem
> <http://build.servoy.com/chain.pem> -password pass:apassword
>
>
> and you are done
>
>
> The only thing that i need to investigate is to only call the openssl in
> the cron tab when the certbot did renew and then also restart tomcat (as
> long as tomcat doesn't auto pick it up)
>

Re: Am I reinventing the wheel to get letsencrypt certs for Tomcat

[Don Flinn]

Hi Markus

I'm not familiar with the inner workings of Tomcat, but  I just looked at
the source code distro and it seems to contain java programs.  So maybe my
little effort may be of use.

Don

On Fri, Oct 27, 2017 at 10:11 AM, i...@flyingfischer.ch <
i...@flyingfischer.ch> wrote:

> Am 27.10.2017 um 15:29 schrieb André Warnier (tomcat):
> > On 27.10.2017 15:05, Don Flinn wrote:
> >> Hi Andre,
> >>
> >> I have looked and it may be my ignorance but I didn't find any that
> >> seemed
> >> to fit.  I'll look more closely at the available letsencrypt clients.
> >
> > It is certainly more my own ignorance, rather than yours. I was only
> > pointing out the obvious, since a fair number of people who post
> > questions here seem to not bother doing their own homework first, and
> > neglect obvious sources of information such as the WWW or the Tomcat FAQ.
> >
> > Your proposal solution below sounds very nice, and would certainly be
> > of immense help to SSL/HTTPS dummies such as myself.
> > I'm out of my depth already, but on this forum, Christopher may be the
> > person most able to provide thoughtful and competent comments
> > regarding such matters.
> > I guess he'll be in shortly, being on the same oceanic side as you are
> > (or seem to be; one never really knows these days).
>
> Let's Encrypt will roll out an ACME module for Apache httpd called mod_md:
>
> https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html
>
> It would be most interesting to have a similar functionality directly
> built into Tomcat, taking care of LE certs and their wildcard certs
> coming next year.
>
> Best regards
> Markus
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Am I reinventing the wheel to get letsencrypt certs for Tomcat

[Don Flinn]

Hi Andre,

I have looked and it may be my ignorance but I didn't find any that seemed
to fit.  I'll look more closely at the available letsencrypt clients.

With letsencrypt you first have to authenticate, i.e. show you own the
site, by letsencrypt logging into your site, e.g. Tomcat and checking a
token.  Then the Java program can get the letsencrypt certificate.  There
are two different addresses Tomcat on AWS and the node, which is running
the Java program.

I've set Tomcat to listen on port 80 and put the directory structure they
want in Tomcat ROOT.  The Java program, running on my node, gets the
letsencrypt authentication token and ftp's it to Tomcat
ROOT/.well-known/acme-challenge, which is the directory structure they
expect. letsencryt then authenticates the token which is in Tomcat, by
retrieving it . The program lets letsencrypt know when the ftp is done  The
Java program then retrieves the certificate from letsencrypt, puts it in a
keystore, ftp's the keystore to AWS in the directory in which I've set
Tomcat to look for the keystore.  It's all done from the one Java program,
which I can run from my node.  I have yet to incorporate programically
inserting the certificate into the keystore.  All the other steps are
working.  It needs testing and doing the update of the certificate, which
is pretty much the same steps as already programmed.

Don

On Fri, Oct 27, 2017 at 7:26 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 27.10.2017 13:22, Don Flinn wrote:
>
>> I am writing a Java program to get a certificate from letsencrypt put it
>> in
>> a keystore and ftp it to my Tomcat 9 or any version running on Amazon Web
>> Services or any place you can fip to.  I intended to contribute it to
>> Tomcat users.  It's about 80% done. I am able to get the letsencrypt
>> certificate and do the ftping.   Recent mail indicates that this has
>> already been done.  If so how can I get the existing code?  No sense
>> duplicating existing work.
>>
>> Indeed.
> Searching Google for "tomcat letsencrypt" seems to get a number of hits.
> Did you look at them ?
> (I haven't)
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Am I reinventing the wheel to get letsencrypt certs for Tomcat

[Don Flinn]

I am writing a Java program to get a certificate from letsencrypt put it in
a keystore and ftp it to my Tomcat 9 or any version running on Amazon Web
Services or any place you can fip to.  I intended to contribute it to
Tomcat users.  It's about 80% done. I am able to get the letsencrypt
certificate and do the ftping.   Recent mail indicates that this has
already been done.  If so how can I get the existing code?  No sense
duplicating existing work.

Don

Re: Trouble using SSL with Tomcat 9

[Don Flinn]

Thanks Chuck,

As is obvious, I'm not an experienced admin, but a developer.  I picked
another unused port, 447, and tried again.  I'm not running Tomcat as
root.  I want to get the self signed cert working before purchasing an SSL
certificate.

This WORKED.  Thanks for all the help.  Note that I just picked an unused
port at random, not knowing any better.  I'm sure that there is a more
sophisticated way to pick a port to use.  I'm guessing that if I have
Tomcat grab that port it will keep it while it is running.  But for now I'm
over-joyed,

Don

On Wed, Sep 27, 2017 at 1:24 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Don Flinn [mailto:fl...@alum.mit.edu]
> > Subject: Re: Trouble using SSL with Tomcat 9
>
> > I installed a new download of tomcat 9, established one application with
> > php/java bridge (need php and java access). Set the SSL port to an unused
> > port, 443, and ran my app who's only out put is an H1 message.  This time
> I
> > get the expected error from Chrome with the red warning about bad
> > certificate.  However, the redirect went to https://localhost/Financial/
> > index.php - i.e. NO port number and of course drilling down couldn't find
> > my app which is at port 443, I believe.
>
> Port 443 is the standard HTTPS port, so it won't show up in the https: URL
> since it's the default.
>
> Unless you're running Tomcat as root (a very, very bad idea), you'll need
> to
> use iptables or equivalent to let Tomcat listen on port 443.
> https://wiki.apache.org/tomcat/HowTo#How_to_run_
> Tomcat_without_root_privileg
> es.3F
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>

Re: Trouble using SSL with Tomcat 9

[Don Flinn]

Hi Andre

I installed a new download of tomcat 9, established one application with
php/java bridge (need php and java access). Set the SSL port to an unused
port, 443, and ran my app who's only out put is an H1 message.  This time I
get the expected error from Chrome with the red warning about bad
certificate.  However, the redirect went to https://localhost/Financial/
index.php - i.e. NO port number and of course drilling down couldn't find
my app which is at port 443, I believe.

Progress, but still no cigar.

The tomcat logs only showed  a 302. -  0:0:0:0:0:0:0:1 - -
[27/Sep/2017:05:08:12 -0400] "GET
/Financials/index.php?XDEBUG_SESSION_START=netbeans-xdebug
HTTP/1.1" 302 -

Don't know what my next step should be - any suggestions.  Your help to
this point has been great.  I greatly appreciate the help you are giving me.

Also, I'm sure you have seen, another user, John Ellis, is having somewhat
similar problems.


Don

On Mon, Sep 25, 2017 at 10:26 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 25.09.2017 15:57, Don Flinn wrote:
>
>> Andre,
>>
>> I've attached the output from netstat -a.  I see 8080 listening, but not
>> 8443.  I've also
>> attached the screen shot of the result of running my "protected"
>> application in Tomcat.
>>
>
> This list removes most attachments, so we did not get the screenshot.
> You have ti post it to dropbox or so, for us to have a look.
>
> But you should definitely look in the tomcat logfiles (in the subdirectory
> inventively named "logs"), to see why it did not open port 8443 when
> supposedly told to do so.
>
> As I mentioned, when I have Norton Security and it shuts down Windows
>> firewall and runs
>> its own firewall.
>>
>
> Yes, but if port 8443 is not open and listening, that's a secondary
> consideration now. The first is why tomcat does not open that port.
>
> P.S. There are additional options to netstat, which will also print the
> name of the process which "owns" that port. Makes it easier to scan the
> list, because it will say
> "tomcat" next to the ones opened by tomcat.
>
>
>> Don
>>
>> On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) <a...@ice-sa.com
>> <mailto:a...@ice-sa.com>> wrote:
>>
>> On 24.09.2017 16 <tel:24.09.2017%2016>:08, Don Flinn wrote:
>>
>> Andre,
>>
>> I apologize for not giving all my information. As you perceived,
>> I'm
>> running Windows. Other info, Windows 10, Tomcat 9, java
>> 1.8.0_144.  As you
>> suggested, using netstat and telnet I found that port 8443 is not
>> open.
>> Looking further Windows firewall is controlled by Norton
>> security.  I am
>> now trying to find out how to open ports in Norton security using
>> the
>> Norton blog.
>>
>> Thank you for your help.  As is obvious, I'm a newbee in low
>> level admin
>> work.  I'm hoping that when I get port 8443 open things will
>> work.  I'll
>> let you know.
>>
>> Maybe wait just a second more, before you go digging in the firewall.
>> You say that you found out that "the port is not open".
>> That is not the same thing as
>> - the port /is/ open
>> - but it cannot be connected to
>> If netstat shows the port open and listening, but you cannot connect
>> to it with
>> telnet, it is probably a firewall issue.
>> But if the port is not open, then it is a tomcat issue.
>> Provided that you configured tomcat properly, the port should be
>> open, firewall or no
>> firewall. (A firewall can only block access by a client, to a server
>> port that is
>> open. It cannot prevent a server process to open that port for
>> listening.)
>> If it isn't open, the tomcat logs should tell you why.
>>
>>
>>
>>
>>
>> Don
>>
>>
>>
>> On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) <
>> a...@ice-sa.com
>> <mailto:a...@ice-sa.com>>
>> wrote:
>>
>> On 24.09.2017 02 <tel:24.09.2017%2002>:36, Don Flinn wrote:
>>
>> I'm trying to use a self signed certificate generated in
>> keytool.  When I
>> run the application Chrome, Firefox and internet Explorer
>> using
>> localhost:8080/ all the browsers do a redirect to
>> localhost:8443
>> and
>> then return This site can’t be reachedL*ocalhost* refused
>&g

Re: Trouble using SSL with Tomcat 9

[Don Flinn]

I've put the log files, the jpg of the chrome page and the netstat -a -b in
Google Drive and sent you a link.

My application is somewhat complex and hopefully not the cause of the
problem.  It is composed of a large number of php and  javascript files in
the Financials application, which includes the php/java bridge, which calls
into a java application called JFin in a number of places, which also has a
large number of java files,  The JFin jar is placed in the
webapps/Financials/WEB-INFO/lib directory along with a large number of
other jars, which are includes in the java files.  All this runs fine under
Tomcat on port 8080.  The log files ect. that I sent are when I run
localhost:8080/Financials.  The log files capture the restart of Tomcat and
the run of the Financials application. I also have run it under debug in
NetBeans 8.2. and it never gets to the first line in Financials/index.php.

The logs capture Tomcat startup, then run as
localhost:8080/Financials.index.php
in chrome and then at 12:49 I ran it in netbeans debug.  The logs look ok
in the first two cases, but when run under netbeans the tomcat stderr gave
an error -
25-Sep-2017 12:56:18.251 INFO [http-nio-8080-exec-1]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header
 Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in method
name. HTTP method names must be tokens
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
Http11InputBuffer.java:406)

I don't know what this means.  Is it a clue or is it an artifact of
NetBeans debug?  It didn't show up in the run directly from chrome.  I ran
it again at about 1:30pm directly from chrome and the error again didn't
show up.



So the

On Mon, Sep 25, 2017 at 10:26 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 25.09.2017 15:57, Don Flinn wrote:
>
>> Andre,
>>
>> I've attached the output from netstat -a.  I see 8080 listening, but not
>> 8443.  I've also
>> attached the screen shot of the result of running my "protected"
>> application in Tomcat.
>>
>
> This list removes most attachments, so we did not get the screenshot.
> You have ti post it to dropbox or so, for us to have a look.
>
> But you should definitely look in the tomcat logfiles (in the subdirectory
> inventively named "logs"), to see why it did not open port 8443 when
> supposedly told to do so.
>
> As I mentioned, when I have Norton Security and it shuts down Windows
>> firewall and runs
>> its own firewall.
>>
>
> Yes, but if port 8443 is not open and listening, that's a secondary
> consideration now. The first is why tomcat does not open that port.
>
> P.S. There are additional options to netstat, which will also print the
> name of the process which "owns" that port. Makes it easier to scan the
> list, because it will say
> "tomcat" next to the ones opened by tomcat.
>
>
>> Don
>>
>> On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) <a...@ice-sa.com
>> <mailto:a...@ice-sa.com>> wrote:
>>
>> On 24.09.2017 16 <tel:24.09.2017%2016>:08, Don Flinn wrote:
>>
>> Andre,
>>
>> I apologize for not giving all my information. As you perceived,
>> I'm
>> running Windows. Other info, Windows 10, Tomcat 9, java
>> 1.8.0_144.  As you
>> suggested, using netstat and telnet I found that port 8443 is not
>> open.
>> Looking further Windows firewall is controlled by Norton
>> security.  I am
>> now trying to find out how to open ports in Norton security using
>> the
>> Norton blog.
>>
>> Thank you for your help.  As is obvious, I'm a newbee in low
>> level admin
>> work.  I'm hoping that when I get port 8443 open things will
>> work.  I'll
>> let you know.
>>
>> Maybe wait just a second more, before you go digging in the firewall.
>> You say that you found out that "the port is not open".
>> That is not the same thing as
>> - the port /is/ open
>> - but it cannot be connected to
>> If netstat shows the port open and listening, but you cannot connect
>> to it with
>> telnet, it is probably a firewall issue.
>> But if the port is not open, then it is a tomcat issue.
>> Provided that you configured tomcat properly, the port should be
>> open, firewall or no
>> firewall. (A firewall can only block access by a client, to a server
>> port that is
>> open. It cannot prevent a server process to open that port for
>> listening.)
>>  

Re: Trouble using SSL with Tomcat 9

[Don Flinn]

Andre,

I've attached the output from netstat -a.  I see 8080 listening, but not
8443.  I've also attached the screen shot of the result of running my
"protected" application in Tomcat.  As I mentioned, when I have Norton
Security and it shuts down Windows firewall and runs its own firewall.

Don

On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 24.09.2017 16:08, Don Flinn wrote:
>
>> Andre,
>>
>> I apologize for not giving all my information. As you perceived, I'm
>> running Windows. Other info, Windows 10, Tomcat 9, java 1.8.0_144.  As you
>> suggested, using netstat and telnet I found that port 8443 is not open.
>> Looking further Windows firewall is controlled by Norton security.  I am
>> now trying to find out how to open ports in Norton security using the
>> Norton blog.
>>
>> Thank you for your help.  As is obvious, I'm a newbee in low level admin
>> work.  I'm hoping that when I get port 8443 open things will work.  I'll
>> let you know.
>>
>> Maybe wait just a second more, before you go digging in the firewall.
> You say that you found out that "the port is not open".
> That is not the same thing as
> - the port /is/ open
> - but it cannot be connected to
> If netstat shows the port open and listening, but you cannot connect to it
> with telnet, it is probably a firewall issue.
> But if the port is not open, then it is a tomcat issue.
> Provided that you configured tomcat properly, the port should be open,
> firewall or no firewall. (A firewall can only block access by a client, to
> a server port that is open. It cannot prevent a server process to open that
> port for listening.)
> If it isn't open, the tomcat logs should tell you why.
>
>
>
>
>
> Don
>>
>>
>>
>> On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) <a...@ice-sa.com>
>> wrote:
>>
>> On 24.09.2017 02:36, Don Flinn wrote:
>>>
>>> I'm trying to use a self signed certificate generated in keytool.  When I
>>>> run the application Chrome, Firefox and internet Explorer using
>>>> localhost:8080/ all the browsers do a redirect to localhost:8443
>>>> and
>>>> then return This site can’t be reachedL*ocalhost* refused to connect.
>>>> There is no red lined out protocol in any of the browsers.  All the
>>>> Tomcat
>>>> logs show no errors or warnings.  I can access applications that are not
>>>> protected and tomcat itself.
>>>>
>>>>
>>> I would suggest that you first re-read what you wrote above, line by
>>> line,
>>> and reflect quietly on what each line is telling you.
>>>
>>> 1) you say "localhost". That means that you are using a browser as
>>> client,
>>> on the same machine as the one which is running the server.
>>> 2) you also say that one of the browsers is IE.
>>> 3) (1) and (2) together imply that the host in a Windows server (and the
>>> client also of course).
>>> 4) you are not saying which version of Tomcat you are using, neither
>>> which
>>> version of Java, neither which version of Windows.  That makes helping
>>> you
>>> more complicated and time-consuming, and delays any help, because now we
>>> have to ask you, and you have to respond.
>>> 5) "refused to connect" : before any kind of SSL dialog can even take
>>> place, the browser must be able to establish a TCP connection to the
>>> host:port in question.
>>> "refused to connect" seens to indicate that this is not the case.
>>> 6) the logs do not show anything : that would seem to corroborate (5) :
>>> tomcat does not even see this connection. iow, there is no connection.
>>>
>>> There are several possible reasons for this.
>>> a) Tomcat never opens the port 8443 for listening on it.
>>> That can be checked, with tomcat running, with the "netstat" utility
>>> program, included in Windows. With the proper arguments (which I will
>>> leave
>>> to you as an exercise)(but "netstat -h" will help), netstat will show you
>>> on which ports tomcat is listening locally.  If this does not include a
>>> ":8443" port, then it is not listening on that port, and certainly the
>>> logs
>>> of tomcat will tell you why.
>>> b) tomcat does listen on port 8443, but something else is blocking access
>>> to that port.
>>> Then you probably have to check your local firewall settings (or whatever
>>> else in what

Re: Trouble using SSL with Tomcat 9

[Don Flinn]

Andre,

I apologize for not giving all my information. As you perceived, I'm
running Windows. Other info, Windows 10, Tomcat 9, java 1.8.0_144.  As you
suggested, using netstat and telnet I found that port 8443 is not open.
Looking further Windows firewall is controlled by Norton security.  I am
now trying to find out how to open ports in Norton security using the
Norton blog.

Thank you for your help.  As is obvious, I'm a newbee in low level admin
work.  I'm hoping that when I get port 8443 open things will work.  I'll
let you know.

Don



On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 24.09.2017 02:36, Don Flinn wrote:
>
>> I'm trying to use a self signed certificate generated in keytool.  When I
>> run the application Chrome, Firefox and internet Explorer using
>> localhost:8080/ all the browsers do a redirect to localhost:8443
>> and
>> then return This site can’t be reachedL*ocalhost* refused to connect.
>> There is no red lined out protocol in any of the browsers.  All the Tomcat
>> logs show no errors or warnings.  I can access applications that are not
>> protected and tomcat itself.
>>
>
> I would suggest that you first re-read what you wrote above, line by line,
> and reflect quietly on what each line is telling you.
>
> 1) you say "localhost". That means that you are using a browser as client,
> on the same machine as the one which is running the server.
> 2) you also say that one of the browsers is IE.
> 3) (1) and (2) together imply that the host in a Windows server (and the
> client also of course).
> 4) you are not saying which version of Tomcat you are using, neither which
> version of Java, neither which version of Windows.  That makes helping you
> more complicated and time-consuming, and delays any help, because now we
> have to ask you, and you have to respond.
> 5) "refused to connect" : before any kind of SSL dialog can even take
> place, the browser must be able to establish a TCP connection to the
> host:port in question.
> "refused to connect" seens to indicate that this is not the case.
> 6) the logs do not show anything : that would seem to corroborate (5) :
> tomcat does not even see this connection. iow, there is no connection.
>
> There are several possible reasons for this.
> a) Tomcat never opens the port 8443 for listening on it.
> That can be checked, with tomcat running, with the "netstat" utility
> program, included in Windows. With the proper arguments (which I will leave
> to you as an exercise)(but "netstat -h" will help), netstat will show you
> on which ports tomcat is listening locally.  If this does not include a
> ":8443" port, then it is not listening on that port, and certainly the logs
> of tomcat will tell you why.
> b) tomcat does listen on port 8443, but something else is blocking access
> to that port.
> Then you probably have to check your local firewall settings (or whatever
> else in whatever version of Windows may be blocking connections to a port).
>
> Another quick way to check if tomcat (or anything) is listening on port
> 8443 (and/or something is blocking it) would be, in a command window, to
> run the following command :
> telnet localhost 8443
> (also with tomcat running)
> If it also tells you "no connection", then (a) or (b) above would be
> confirmed.
> If it connects, then you may get another message, due to the fact that it
> expects an SSL connection. (If it did not expect an SSL connection, you'd
> just get a blank page until you type something else).
> Obviously, access to tomcat's port 8080 is fine, so you can compare the
> responses above with what happens when you substitute 8080 for 8443.
>
> Once the above is really cleared up, then it may be worth looking at the
> rest of the information which you sent below.
>
>  If I set 
>
>> CONFIDENTIAL to NONE everything works with
>> localhost:8080.
>>
>> My SSL files in tomcat -
>>
>> *server.xml -*
>>
>> Connector
>> protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEI
>> mplementation"
>> SSLEnabled="true" acceptCount="100" clientAuth="false"
>> disableUploadTimeout="true" enableLookups="false" maxThreads="25"
>> port="8443" keystoreFile="c:/temp/mkeystore2.jks" keystorePass="foobar"
>> secure="true" sslProtocol="TLS" clientAuth="false" />
>>
>> *web.xml -*
>>
>> 
>>  
>>  Financials
>>   

Trouble using SSL with Tomcat 9

[Don Flinn]

I'm trying to use a self signed certificate generated in keytool.  When I
run the application Chrome, Firefox and internet Explorer using
localhost:8080/ all the browsers do a redirect to localhost:8443 and
then return This site can’t be reachedL*ocalhost* refused to connect.
There is no red lined out protocol in any of the browsers.  All the Tomcat
logs show no errors or warnings.  I can access applications that are not
protected and tomcat itself. If I set 
CONFIDENTIAL to NONE everything works with
localhost:8080.

My SSL files in tomcat -

*server.xml -*

Connector
protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
SSLEnabled="true" acceptCount="100" clientAuth="false"
disableUploadTimeout="true" enableLookups="false" maxThreads="25"
port="8443" keystoreFile="c:/temp/mkeystore2.jks" keystorePass="foobar"
secure="true" sslProtocol="TLS" clientAuth="false" />

*web.xml -*



Financials
/*


CONFIDENTIAL



*the output from my keystore  list -*

C:\Users\don\Documents\Mansurus\Security> "%java_home%/bin/keytool.exe"
-list  -v -keystore c:/temp/mkeystore2.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: tomcat
Creation date: Sep 23, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Issuer: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Serial number: 6b5fe428
Valid from: Sat Sep 23 12:57:19 EDT 2017 until: Sun Sep 23 12:57:19 EDT 2018
Certificate fingerprints:
 MD5:  11:9D:2C:50:4A:09:9D:17:2F:46:3C:AF:AF:E5:59:EE
 SHA1: 63:EF:21:21:3C:22:82:46:21:84:9C:81:C6:B0:C1:EC:0F:1C:87:31
 SHA256:
4E:75:D6:6A:6C:23:84:E0:36:AF:CF:1E:56:7D:18:6E:A1:BE:E5:EE:0B:E5:7B:2A:01:96:DF:49:CA:F1:50:C7
 Signature algorithm name: SHA256withRSA
 Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 46 C9 48 D4 54 2A 54 CE   24 1F 22 ED 1D FC 6E 14  F.H.T*T.$."...n.
0010: BE 6F 4A 49.oJI
]
]

What am I doing wrong?  I want to get a self-signed keystore working before
I purchase a commercial certificate.

Don