Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status update? #1

Open
lukehutch opened this issue Oct 3, 2018 · 8 comments
Open

Status update? #1

lukehutch opened this issue Oct 3, 2018 · 8 comments

Comments

@lukehutch
Copy link

This project is marked deprecated -- is that because it is no longer maintained, or because SNI-01 validation was shut down, or because there's a new, better way to do ACME validation for Vert.x?

@xkr47
Copy link
Owner

xkr47 commented Oct 9, 2018

Hi,

Thanks for your interest. It was marked deprecated when SNI-01 was shut down. I have not had time to reimplement it to use SNI-02 although that would probably be great. So my home servers are without https at the moment :/ I will however update the README to reflect this now.

I do not foresee myself having time to implement SNI-02 in 2018, but you never know.

The AcmeManager code is ugly because it was at the same time an academic effort to write everything in async :-) Java does not bend..

@lukehutch
Copy link
Author

Thanks for the update. Exactly because of "nested callback hell" I have been looking for ways to use Vert.x that do not involve callbacks, and I came up with the combination of the following two projects -- an async/await implementation for Java based on CompletableFutures / promises, and a CompletableFuture API for Vert.x. I have yet to test if this combination works, but it looks promising, no pun intended:

This may make the SNI-02 rewrite a lot more palatable.

@xkr47
Copy link
Owner

xkr47 commented Oct 10, 2018

Thanks for the tips!

@lukehutch
Copy link
Author

Actually this might be even better...

https://vertx.io/docs/vertx-sync/java/

@lukehutch
Copy link
Author

lukehutch commented Mar 7, 2019

@xkr47 I started looking into this again, and I thought of a simpler way to add ACME support to a Vertx project. Would it be possible to simply set up certbot as a cron job, and then use a cutdown version of vertx-acme4j that only consists of something like DynamicCertManager to watch for certificate changes? I don't know much about certificate management, but it seems like this should work.

(Instead, if you do still want to implement the full SNI-02 without all the callbacks, you could also try writing it in Kotlin, with vertx-kotlin-coroutines.)

@xkr47
Copy link
Owner

xkr47 commented Mar 11, 2019

Yeah you totally can use just the DynamicCertManager to (re)import certificates on-the-fly. It was even part of the plan. For people wanting to do non-SNI handshakes it is the way to go. For SNI it made sense (to me) to build a "all-in-one" solution. Also, it was a bit of a academic approach :)

I'll try to add some docs on how to use DynamicCertManager standalone. Also, feel free to request anything more you need. :)

@xkr47
Copy link
Owner

xkr47 commented Mar 11, 2019

Ok done, lmk if you need code examples.. You can look in AcmeManager.java and search for dynamicCertManager.

@lukehutch
Copy link
Author

Thanks. I think you should seriously consider upstreaming your dynamic certificate reloading code into Vertx:

eclipse-vertx/vert.x#2870

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants