On 10/5/2020 2:42 PM, Christopher Schultz wrote:
…
Sure, it can contain S3 credentials and you can pick-up your key and
certificate (or, better yet, the whole keystore) there, but at that
point you have "moved" the problem outside of Tomcat, right?
No, not at all. The major problems are:
1. Generating the certificate automatically.
2. Feeding the certificate to Tomcat automatically.
If the "extra" thing I have to do is specify an environment variable
with the name of the S3 bucket to use as a certificate state, then that
is a teeny, tiny problem. That is not really even a problem.
Can you imagine if in my spring boot application I could run it using
"java -jar my-app.jar --cert-work-bucket my-bucket" and it would just go
get a certificate automatically?
You can have a "certificate renewal service" that writes to S3.
I want it built into my application as a module. You just include the
module, specify the domain name (and maybe a couple of other details
needed by RFC 8555, such as a contact email), and boom, it all happens
automatically.
Why does it have to be more difficult than that? It shouldn't be.
I suppose you could put that directly into Tomcat, but Tomcat is not
likely to ship with an Amazon-specific feature built-into it.
Read my original email. I never intended to put this directly into
standalone Tomcat (although if you want to put it into Tomcat you're
welcome to). I want to use this with an application running on embedded
Tomcat. Spring Boot is a prime example. I'll just extend the Spring Boot
embedded Tomcat module and extend/modify that as needed. If that
requires modifying Tomcat code, fine.
Another idea would be to use embedded Tomcat (or, at your suggestion,
Spring Boot) and fetch the keystore from some "standard" location of
your choosing. Again, that would be (appropriately, IMO) outside Tomcat
code.
That was always the intention. In my introduction to my original email I
explained that the modern approach is moving away from something like
standalone Tomcat to self-contained executables that run their own
servers, whether embedded Tomcat or whatever. (I was late to the party,
and even two years ago I wasn't getting it.)
1. Does acme4j allow me to verify my certificate behind another port?
(e.g. ElasticBeanstalk deploys a JAR behind NGINX port 5000 by
default. I'm still reading RFC 8555 to find out if the ACME server
has to connect back on a certain port for verification.)
2. Once I have the Let's Encrypt certificate, can I convert to PKCS12
for Tomcat completely in the application without shelling out to
openssl or keytool? I'm hoping Bouncy Castle and/or acme4j-util will
allow me to do that.
This can be done, but it's non-trivial. For example, Tomcat contains
code to package PEM-encoded DER files (good old OpenSSL-style =====BEGIN
CERTIFICATE===== things) into an in-memory keystore to configure JSSE.
It seems like it would be straightforward, but it turns out not to be in
all cases. YMMV.
Non-trivial as it may be, it /only needs to be done once/. If I have a
converter, then I can use it a thousand times. A million times. And
suddenly the deployment becomes a piece of cake.
In reality, today's style of handling SSL is what matches your
description of "It seems like it would be straightforward, but it turns
out not to be …". So why do we keep doing all this difficult, manual,
tedious, not-trivial stuff to deploy certificates the hard way, when we
could put our efforts into a single no-trivial task of making a
converter so that Tomcat can use the Let's Encrypt certificates
directly? We do it once. It's hard, but then everything else is easy. I
don't get why we want to spend another decade doing it the hard way when
we can spend one year on a different hard task and then do SSL the easy
way for the other nine.
(The frustration isn't directed at you. It's just in general in software
development I see the industry—why does the most basic of things have to
be so difficult?)
3. Once I have the PKCS12, how do I feed it to the embedded Tomcat?
If it's a file on the disk, it's easy: just use the path.
Can I pass it in memory? If not, why not? How is memory less accessible
than a file?
Chris, where can I get more information on the latter questions about
getting this certificate to Tomcat once I have it?
This mailing list is a good place to start (and likely finish).
Of course I really super-appreciate the help on this mailing list, and
I'll be asking lots more questions. But I also don't want to ask things
you've already answered elsewhere. I thought sure in one of your
ApacheCon 2019 presentations you mentioned you had made more progress
than the ApacheCon 2018 slides, such as auto-reloading or something. If
there is further documentation let me know.
…
Go back to my presentation on Let's Encrypt and you'll see how to use
openssl to convert to a keystore if that's what you want.
I want to make any conversions completely in the application without
depending on some utility installed in the OS. So no making a shell call
to openssl. If OpenSSL can do something, why can't Java?
Or, better
yet, skip that step entirely and use the PEM-encoded DER files that
Let's Encrypt already provides to you.
I have no idea what a PEM-encoded DER file is, but I'll certainly learn.
And if it means that Tomcat can directly use something provided by Let's
Encrypt with no conversion required, than that's awesome!
So what's the problem? One piece of code talks to Let's Encrypt and
stores this DER file thing on S3. Another piece of code pulls the DER
file from S3 and starts up an embedded Tomcat with it. (All in same app,
as needed.) Seems straightforward to me.
You just have to work-out
file-permissions issues.
I still don't get why files have to be involved. I pulled a DER file
from S3. I have it in memory. Embedded Tomcat is running in memory. They
are in the same JVM. Why do I have to put something in a file?
…
What you have to remember is that AWS is often MORE EXPENSIVE than
running your own stuff.
It shouldn't be, in general. Part of the whole cloud value proposition
is that you only pay for what you use.
The problem here is that this big SSL antipattern hurdle is making me
need to use things I don't need for a tiny app. I'm wanting to remove
that hurdle.
…
I hear that. I still don't understand how you are supposed to get OS
updates working for an application deployed into Elastic Beanstalk.
See
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html
.
But I don't want to over-focus on Elastic Beanstalk.
The issue here is that I want a standalone app with embedded Tomcat that
automatically 100% configures SSL. For now Elastic Beanstalk is just one
vehicle to run that app. In the future we may have platforms (if we
don't already) that completely hide the OS, and the JAR is just running
as a service.
We have the same sort of thing with static sites on AWS. Remember that
static site generator, Guise Mummy, I showed off at ApacheCon 2019? I
finished it, and all my sites are now using it. Guise Mummy generates
and deploys a static site to S3, but then configures CloudFront to cache
and serve it with edge access around the world, with HTTPS. (See
https://www.globalmentor.com/ as an example.) What web server is serving
those files? What OS is hosting the web server? I have no idea. It's
irrelevant. How do I update the OS? I don't need to. For all practical
purposes there is no OS. My site consists of static files, and AWS is
hosting them.
Eventually the same should go for my JAR file. I give AWS my JAR file.
AWS starts up my JAR file. It has HTTPS automatically. I shouldn't have
to do a single thing.
We are almost there, except for this huge SSL problem where I have to do
basically what I did in 2000 to get SSL turned on. (Maybe it's a little
easier. Not much.)
Really, I'm speaking from a
position of profound ignorance on this point. I really have no idea how
this stuff is supposed to work and I haven't put any time into
discovering the real answers.
Chris, I'm learning all this stuff too. I had to get over a bunch of
gotchas to get this S3->CloudFront with automatic SSL stuff working for
a static site. And you can see from my Stack Overflow question
https://stackoverflow.com/q/63650514 that I naively approached Elastic
Beanstalk from the same view, thinking it would transparently handle
everything for me. It doesn't. But that's where we want to go eventually.
So I have a lot to learn. One of the first things I'm learning is that
SSL is a problem Everywhere. All the gazillions of cute demos don't
include SSL. If you do set up SSL, you have to jump through all these
hoops, or pay lots extra to have a load balancer. Really, there isn't an
easy SSL solution for anything in the cloud that I can find that isn't a
static site. If you know of something, then please go answer my Server
Fault question: https://serverfault.com/q/1036276 .
If nobody else will do this, I will do this. It needs to be done,
because I don't enjoy playing sysadmin just to set up SSL when I'd
rather be writing applications and deploying them.
Garret
