Garret, On 10/5/20 12:21, Garret Wilson wrote: > Thank you so much for replying, Chris. Responses below. > > On 10/5/2020 8:53 AM, Christopher Schultz wrote: >> Microservices won't work the way you want with Let's Encrypt. You have >> two options: >> >> 1. Hit Let's Encrypt every time you launch a new instance of the >> microservice to deploy a new certificate >> >> 2. Handle the certificate provisioning elsewhere (e.g. ELB) >> >> #1 just won't work. LE won't re-issue a certificate more frequently than >> every 6 weeks or something like that. So that really leaves you with #2. > > It's good to know about the six-week limit, but you discarded #1 too > quickly. Can't the microservice simply store the credentials in S3 or > one of a hundred other data stores? (Note that I care less about > "microservices" as such at the moment. I just want a turnkey deployment > of a single application for now. But the idea is the same.)
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? You can have a "certificate renewal service" that writes to S3. I suppose you could put that directly into Tomcat, but Tomcat is not likely to ship with an Amazon-specific feature built-into it. I could imagine a LifecycleListener which has been written with this kind of thing in mind. (I'm not sure that a LifecycleListener would be able to intervene early enough in the process of a non-embedded Tomcat startup to do this, btw; just an idea.) 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. >> What you really want is for the orchestrator to provide the certificate >> and key to the nodes as they come on-line. > > Look these "orchestrators" are a configuration nightmare at the moment. > They end up being worse than my just configuring a CentOS machine from > scratch. Plus I have to pay for all those extra services. Read > https://leebriggs.co.uk/blog/2019/04/13/the-fargate-illusion.html and > try not to shudder. > >> So instead of trying to get LE to work with Tomcat (which does work, but >> requires some care and feeding), maybe we should try to get Tomcat to >> load its crypto material from other places. > > There is already a Java library (https://github.com/shred/acme4j) for > talking to Let's Encrypt. It sounds like it does everything I need. I'll > need to investigate more, but here are my initial doubts: > > 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. > 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. > 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). >> One way to do that would be with e.g. Amazon's key storage service. I'm >> not familiar with that. I know it can store various types of keys; not >> sure about certificates and if we can pull a private key out of it. > > I think your idea of storing this stuff elsewhere is a good first > stepping stone to get to where I want to go. > > Just to get the ball rolling, I could manually run some Let's Encrypt > client, and then store the certificate in S3. Then the first component I > would write would be steps #2 and #3 above. I am already familiar with > the AWS Java library, so I could quickly figure out how to pull the > certificates off S3. But I need your help in finding out how to convert > them to PKCS12 (or whatever; this is new territory for me) on the fly > and feed them to the embedded Tomcat. 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. Or, better yet, skip that step entirely and use the PEM-encoded DER files that Let's Encrypt already provides to you. You just have to work-out file-permissions issues. >> Honestly, your best bet would probably be to use ELB and just pay for >> it. You only pay for data-transfer, so a dormant ELB costs you virtually >> nothing. > > Last month I deployed a test application on Elastic Beanstalk on a > domain nobody knows about just to see how it worked. The ELB cost me $16 > in a month with basically nobody using it! That adds up quickly. I have > several little apps I want to toss up. See also my question > https://serverfault.com/q/1036276 . Oh, I forgot that you have to pay for lb-hours as well as transfer. Sorry about that. Yeah, they don't keep services up and running for free. :) What you have to remember is that AWS is often MORE EXPENSIVE than running your own stuff. It's just WAY more flexible and "responsive". If I want to get a new server installed by my infra provider into a DC, ?I usually have to call them, tell them what I want, get some quotes for specific hardware, ask them to order it, install it, but an OS on it, etc. and maybe that takes 3 total weeks. With AWS, I can do it in 5 minutes. Auto-scale with a traditional co-located deployment strategy? Not possible. >> Instead of spinning-up an EC2 instance for your service, maybe you >> should be looking at Lambda instead. You can probably get your costs >> down more that way than trying to eliminate the ELB. > > I want to drop either a self-contained JAR file or a Docker image > somewhere, and have it immediately start running with SSL support, > without my configuring a VM or running scripts. When I have a new > version, I want to drop a new JAR or Docker image and have it > automatically replace the other one. I don't want to maintain a VM. I hear that. I still don't understand how you are supposed to get OS updates working for an application deployed into Elastic Beanstalk. You immediately get a bunch of EC2 instances. Do I have to watch them for OS updates? Do I have to apply them? OR does AWS just wave their hands and say "they'll be fine" and auto-update and auto-re-build them whenever they want. I have regulatory requirements that say that I need to document my patch cycles. What do I say for this stuff? "Amazon says I don't need to worry my pretty little head?" 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. For my AWS deployments, I treat them all just like I do with regular DC deployments where I instrument and maintain each and ever service. I'd love to be free of that burden. > I have a target price of let's say $5/month for everything (although > $3 would be better). Does AWS Lambda give me that? If so, please > point me to the guides. I think you always need the lb, and if the lb prices are too high for you, then you need to look for other solutions. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
