Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Jooby and Let's Encrypt#2606

Closed
imeszaros started this conversation inIdeas
Discussion options

Until now I only used Jooby at work, creating internal projects for my company which has its on CA, generacting certificates was straightforward.

Now I wan't to create a personal public website with Jooby, SSL enabled. I would like to use Let's Encrypt to obtain free certificates. I never used it acutally, so I've just found how it works. Skip the next paragraph if you already familiar with it..

Let's Encrypt provides certs with short expiration periods (60-90 days), and on each renewal the CA needs to verify that you actually own the domain you want to encrypt. This is done by various challenges, e.g. a file with a special content has to be served via an HTTP request or a special DNS entry has to be made. If the verification succeeds, the cert can be downloaded. For this whole procedure Let's Encrypt uses the Automatic Certificate Management Environment (ACME) protocol, and has a client application which can be integrated with many popular web servers to manage certificate renewal automatically and transparently.

I had a look on how it should be done with java servers, and some suggested one should wrap the service with a proxy e.g. nginx which can be in turn integrated with Let's Encrypt. Is this the commonly used way or best practice?

If nothing against it, I already have thoughts how Let's Encrypt support could be integrated to Jooby via a module (only had a look on Netty as of now):

  • server modules should accept a factory for SSL context
  • there would be background service that keeps certs up to date usingacme4j, able to perform http challenges without user intervention (this would work for non-wildcard domain certs)
  • an SSL context factory would make sure that an always up-to-date (and cached) context is handed over to the server implementation

I would spend time on this if it makes any sense.

You must be logged in to vote

Replies: 2 comments

Comment options

This came up couple of times... but long time ago when acme4j was starting. There was pros and cons (which I don;t remember 😄 )

Go for it, the hard part (not impossible) will be to make it work across servers.

You must be logged in to vote
0 replies
Comment options

@imeszaros FWIW we terminate the SSL at the load balancer (nginx or google cloud). I recommend doing that as the tools (acme) for doing that with things like nginx or k8s are more mature. There is also a bunch of other nice things about having an external load balancer like bot and denial of service protection.

The only time I could see a use for doing it at the jooby level for microservices going across clusters. Usually self signing happens for that. However again most people put something in front like an API Gateway or another load balancer.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Ideas
Labels
3 participants
@imeszaros@agentgt@jknack

[8]ページ先頭

©2009-2026 Movatter.jp