Re: Let's Encrypt with Tomcat?

[Igal Sapir]

James,

On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:

> We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
> currently using a Java Keystore for the SSL support.
>
> We would like to be able to use Let's Encrypt, but I've learned that
> Let's Encrypt and Tomcat don't get along all that well together. The
> best I've found so far are article at:
>
> <
> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
> >
>
> and this thread in the Let's Encrypt community forum:
>
> <
> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423
> >
>
> Does anybody here have any experience with situations like this? Does
> anybody here have any suggestions? Or, as another alternative, does
> anybody here know of some Amazon AWS product that could front-end a
> single-box, non-load-balanced Tomcat server, and use Amazon's free
> "Public Certificates"? (I've already posted that last to the relevant
> Amazon forum.)
>

You should check out Chris' presentations on the topic.  He outlines a very
efficient process.  There is probably more materials out there, but a quick
search brings up the video [1] and slides [2] from his presentation at
ApacheCon earlier this year, as well as his shell script for automating the
process.

Igal

[1] https://www.youtube.com/watch?v=BWUjvmJgSeE
[2]

https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt%20Apache%20Tomcat.pdf
[3]
https://people.apache.org/~schultz/ApacheCon%20NA%202019/lets-encrypt-renew.sh






>
> James H. H. Lampert
> Touchtone Corporation
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Let's Encrypt with Tomcat?

[Andrew Stanton]

You could use their public certificate with their lb and redirect 443 to
port 80 in the lb I was using jboss server running on port 80 in the ec2
instances that were running behind the lb.  when I did that all requests
hitting the lb were secured.  Jboss is another container like tomcat.

Hope that helps

On Thu, Dec 26, 2019 at 4:49 PM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:

> We have a Tomcat (8.5.40) server running on an Amazon EC2 instance,
> currently using a Java Keystore for the SSL support.
>
> We would like to be able to use Let's Encrypt, but I've learned that
> Let's Encrypt and Tomcat don't get along all that well together. The
> best I've found so far are article at:
>
> <
> https://medium.com/@raupach/how-to-install-lets-encrypt-with-tomcat-3db8a469e3d2
> >
>
> and this thread in the Let's Encrypt community forum:
>
>
> <
> https://community.letsencrypt.org/t/how-can-i-automate-renewals-with-tomcat/81423
> >
>
> Does anybody here have any experience with situations like this? Does
> anybody here have any suggestions? Or, as another alternative, does
> anybody here know of some Amazon AWS product that could front-end a
> single-box, non-load-balanced Tomcat server, and use Amazon's free
> "Public Certificates"? (I've already posted that last to the relevant
> Amazon forum.)
>
> James H. H. Lampert
> Touchtone Corporation
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
Andrew G. Stanton

CEO/Founder/Principal Engineer, Stanton Web Applications, Inc.
Founder, GetMorty.io and UniversalWallet.io


email: andrewgstan...@gmail.com
also: a...@stantonweb.com

web: www.stantonweb.com
*mobile: 415-793-4072*
tel/fax: 415-738-8501
linkedin: https://www.linkedin.com/in/andrew-g-stanton/
twitter: https://twitter.com/andrewgstanton

This message and any attachments are solely for the individual(s) named
above and others who have been specifically authorized to receive such and
may contain information which is confidential, privileged or exempt from
disclosure under applicable law. If you are not the intended recipient, any
disclosure, copying, use or distribution of the information included in
this message and any attachments is strictly prohibited. If you have
received this communication in error, please notify us by reply e-mail and
immediately and permanently delete this message and any attachments.  Thank
you.

Re: HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7

[Pattavee Sanchol]

Dear Olaf

Thank you so much for your reply.


*problem: You're trying to deliver the HSTS header for some, but not allof
the requests coming in(?) (Otherwise, please correct) *

- > No. I want to respond HSTS header in all request but after I follow
configuration below it not response HSTS header on some request
such as  http://192.168.1.1/%20 or http://192.168.1.1/%3e  I think url
pattern /* is not apply to request with special characters on path.



httpHeaderSecurity

/*

REQUEST



Regards.


*ปฐวี สรรค์ชลPattavee SANCHOL*


*    *

*Thai Digital ID CO.,LTD. *

319, 25th Floor, Room 10-11, Chamchuri Square Building,
Phayathai Road, Phathum Wan, Bangkok
Thailand 10330
Tel : +66-029-0290 ext. 3317

E-mail : pattavee@thaidigitalid.com


On Thu, Dec 26, 2019 at 6:11 PM Olaf Kock  wrote:

>
> On 26.12.19 11:22, Pattavee Sanchol wrote:
> > Dear support team
> >
> > I config tomcat server to enabled HSTS some request URI path not
> > response with Secure heading
> >
> > ...
> >
> >
> > I some request URI such as http://192.168.1.1/%20 is not response with
> > security hedering
> >
> >
> > this is working
> >
> >
> > image.png
> > this not working
> > image.png
> >
> Note: Images are stripped from the list, but I hope that I get the
> problem: You're trying to deliver the HSTS header for some, but not all
> of the requests coming in(?) (Otherwise, please correct)
>
> I believe that this is chasing a ghost: It's a lot of work to make it
> happen, but doesn't have any meaningful advantage: If *any* request
> states that the server *only* wants to see HTTPS traffic, it doesn't
> matter if *more* requests also state the same: The server will need to
> provide proper answers to any HTTPS connection. You're basically asking
> everybody who ever saw the HSTS header during the last 31536000 seconds
> (your configuration) to rewrite a http-URL to a https-URL.
>
> Thus, I'd recommend to just not worry about any specific conditions to
> apply for those headers. Just send them - they don't harm, or make any
> difference. Or give us some more specific reasons that I might have missed.
>
> Olaf
>
>

-- 
 

Let's Encrypt with Tomcat?

[James H. H. Lampert]

We have a Tomcat (8.5.40) server running on an Amazon EC2 instance, 
currently using a Java Keystore for the SSL support.


We would like to be able to use Let's Encrypt, but I've learned that 
Let's Encrypt and Tomcat don't get along all that well together. The 
best I've found so far are article at:




and this thread in the Let's Encrypt community forum:




Does anybody here have any experience with situations like this? Does 
anybody here have any suggestions? Or, as another alternative, does 
anybody here know of some Amazon AWS product that could front-end a 
single-box, non-load-balanced Tomcat server, and use Amazon's free 
"Public Certificates"? (I've already posted that last to the relevant 
Amazon forum.)


James H. H. Lampert
Touchtone Corporation

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

ECDSA Private Keys

[logo]

Hi Mark,

I just recently tested Step CA (smallstep.com) as an internal CA that provides 
an internal ACME service.

After I deployed the created cert to my Tomcat (8.5.50 with adoptopenjdk 11) I 
noticed that while the openssl connector immediately started, the JSSE 
connector with the same cert would fail with a 
"java.security.KeyStoreException: Cannot store non-PrivateKeys“
I use the openssl XML certificate config also for JSSE.

It took me quite a while to figure this one out - as the message usually 
indicates a public key as cert. I noticed that Step Ca is creating ECDSA certs 
by default. The Openssl Connector delivers the new ECDSA cert just fine.

While Java (afaik) seems to be able to handle ECDSA, tomcat will fall through a 
case statement in org.apache.tomcat.util.net.jsse.PEMFile

When loading the PEM file parts it will skip all cases in

for (Part part : parts) {
switch (part.type) {
case "PRIVATE KEY":
privateKey = part.toPrivateKey(null, keyAlgorithm, 
Format.PKCS8);
break;
case "ENCRYPTED PRIVATE KEY":
privateKey = part.toPrivateKey(password, keyAlgorithm, 
Format.PKCS8);
break;
case "RSA PRIVATE KEY":
privateKey = part.toPrivateKey(null, keyAlgorithm, 
Format.PKCS1);
break;
case "CERTIFICATE":
case "X509 CERTIFICATE":
certificates.add(part.toCertificate());
break;
}
}

as an EC certificate will start with EC PRIVATE KEY.

Is this something that is expected? ECDSA unsupported? Or just an incomplete 
implementation, edge case or a bug?

Best regards

Peter




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7

[Olaf Kock]

On 26.12.19 11:22, Pattavee Sanchol wrote:
> Dear support team
>
> I config tomcat server to enabled HSTS some request URI path not
> response with Secure heading
>
> ...
>
>
> I some request URI such as http://192.168.1.1/%20 is not response with
> security hedering
>
>
> this is working
>
>
> image.png
> this not working
> image.png
>
Note: Images are stripped from the list, but I hope that I get the
problem: You're trying to deliver the HSTS header for some, but not all
of the requests coming in(?) (Otherwise, please correct)

I believe that this is chasing a ghost: It's a lot of work to make it
happen, but doesn't have any meaningful advantage: If *any* request
states that the server *only* wants to see HTTPS traffic, it doesn't
matter if *more* requests also state the same: The server will need to
provide proper answers to any HTTPS connection. You're basically asking
everybody who ever saw the HSTS header during the last 31536000 seconds
(your configuration) to rewrite a http-URL to a https-URL.

Thus, I'd recommend to just not worry about any specific conditions to
apply for those headers. Just send them - they don't harm, or make any
difference. Or give us some more specific reasons that I might have missed.

Olaf

HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7

[Pattavee Sanchol]

Dear support team

I config tomcat server to enabled HSTS some request URI path not response
with Secure heading

The configuration illustrated below

   

httpHeaderSecurity


org.apache.catalina.filters.HttpHeaderSecurityFilter

true



  hstsEnabled

  true





   hstsIncludeSubDomains

   true

   



 hstsMaxAgeSeconds

 31536000

  



  antiClickJackingEnabled

  true





  antiClickJackingOption

  SAMEORIGIN



  


  

httpHeaderSecurity

/*

REQUEST

  


I some request URI such as http://192.168.1.1/%20 is not response with
security hedering


this is working


[image: image.png]
this not working
[image: image.png]
Please suggest me to solve this problem.
Thank you.

Regards.


*ปฐวี สรรค์ชลPattavee SANCHOL*


*    *

*Thai Digital ID CO.,LTD. *

319, 25th Floor, Room 10-11, Chamchuri Square Building,
Phayathai Road, Phathum Wan, Bangkok
Thailand 10330
Tel : +66-029-0290 ext. 3317

E-mail : pattavee@thaidigitalid.com

--