LetsEncrypt setup in a dockerized and automated infrastructure #43418
Replies: 4 comments 13 replies
-
|
Uploading acquired certificates over a secure management port connection, with the authentication constraint, can make sense. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, there are 3rd party solutions, most of the time I use cloudflare proxy which provides tunnel, cdn and certificate for free, you just need a domain. Then why bother to add letsencrypt support at all? |
Beta Was this translation helpful? Give feedback.
-
You will receive both the certificate and private key. So, someone who can use this endpoint can forge a certificate and "apply" it. The DNS protection you mention is not enabled for every protocol (it is highly recommended for HTTPS but can be disabled). Not every protocol over TCP applies the same check. In this context, someone can upload you a new certificate (potentially invalid), or forge a certificate and then build something using the same certificate that will look legit. Sure, it won't happen for HTTP (because of the hostname verification), but that's not the only protocol using TLS.
The Elyton ACME client library with its dependencies would be about ~500K (a rough estimation based on the size of the artifacts)—not big, but not small either. Also, it does not use the HTTP client we would need to use in Quarkus. Basically, we would have to re-implement something from scratch instead of reusing something battle-tested.
Because there are cases where you do not want or cannot use these, typically, I've several applications running on EC2, and I want to terminate the TLS connection in my app. I'm not using any CDN or Clouflare. If you use them, you do not need to use the Quarkus let's encrypt support. It's for all the cases where you cannot. Also, there is nothing preventing an extension or even an application from implementing its own Acme support. The TLS registry API allows you to do that. We came up with what we have seen to be the most common approach, but sure, there are others. There are other challenges, too (not only HTTP_01). Recently, I reviewed the ALPN one, which has the advantage of not requiring any plain HTTP connection at all (but it's slightly more complicated to handle). By the way, on Kubernetes or OpenShift, the TLS connection is generally terminated at the ingress level. You can also terminate the TLS connection in your application (in this case, you will have to mount the cert and private key on a volume). Finally, for internal TLS communication (between 2 apps from the same cluster), Kubernetes Cert-Manager provides a good solution. |
Beta Was this translation helpful? Give feedback.
-
|
We also would like to support simple web site providers who do not deal with Docker, AWS, cloud or kuberenetes in general, possibly running on bare metal, etc |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, over time, we can make it very easy to plug in custom ACME client implementations |
Beta Was this translation helpful? Give feedback.
-
That's nonsense. There's no need to transfer private key. It can be generated once and packaged with the application. Storing it in the ordinary directory is simply not secure.
Then that's the epic failure, because you need to install java, maven, quarkus cli and a lot of maven dependencies in order it to work on a bare metal. Plus it does not manage renewals automatically. Thus it simply cannot be served as a certbot replacement. Compare that to e.g. certbot which can be easily installed from a snap by one command on a lot of linux distributions and installs systemd timer to automatically renew your certs. Plus it uses proper file permissions to prevent private key from being stolen. |
Beta Was this translation helpful? Give feedback.
-
Let's avoid all these dismissive arguments, some of which are not relevant to the issue of the automatic certificate renewal.
It is totally not relevant and in fact straightforward to complete. In any case, we are not talking about pros and cons of doing bare metal. So let's stay focused.
How is this argument relevant to the statement that we want to help bare metal users, it is either automatically renewed or not with Let's Encrypt irrespective of the deployment environment ? We don't want the renewal going automatically by default right now, we'd like users, developers, be in |
Beta Was this translation helpful? Give feedback.
-
In fact, packaging it with the application does not look secure to me and it fails when the user wants to get a new key pair for the account. Either way, we appreciate the feedback, I suggest that you look closer at the code and do enhancement requests, PRs |
Beta Was this translation helpful? Give feedback.
-
|
@pragmasoft-ua We have opened an enhancement request at #43461, following this discussion, thanks for initiating it. It is obvious you have a lot of experience in the related area so your input to #43461 will be appreciated. Please look at the code and work with us on making Quarkus Let's Encrypt feature stand out, thanks ! |
Beta Was this translation helpful? Give feedback.
-
|
@sberyozkin great news, but I'm hopefully on vacations since tomorrow, till the mid of October. In general, I'm thinking wouldn't it be easiest to write a 3rd party certbot plugin for Quarkus, similar to the one it has for apache and nginx? |
Beta Was this translation helpful? Give feedback.
-
Np at all, enjoy, this issue does not have any specific timelines, and I imagine it may take us awhile there to finalize it, we can gather ideas there for some time.
It can probably be an interesting idea for a Quarkiverse extension. Quarkus CLI ACME client is important because it will let Quarkus users work with Quarkus tools only in some deployments. But I believe the Quarkus TLS registry Let's Encrypt ACME challenge handler can work with any ACME client tool, though it might need some extra optional configuration for it to be able to get the data produced by certbot. If you'd like, please explore if using the certbot client is feasible with Quarkus in the next couple of months. |
Beta Was this translation helpful? Give feedback.
-
I have a question about the recently added LetsEncrypt certificate management https://quarkus.io/guides/tls-registry-reference#lets-encrypt
From the documentation it looks like the quarkus application should be launched from the project directory (containing quarkus cli and tls plugin) and at the same time served from the externally accessible dns name.
Though in real life it is seldom a case - public server application is running from the binary distribution which does not contain quarkus cli, or often from a container, whereas project directory with quarkus cli is only available on the dev machine without even public ip. The only real possibility of running this setup is with ngrok, but free version of ngrok does not allow to configure the domain name yet.
The question is actually how it is supposed to work with a dockerized application or public server? Should we mount .letsencrypt folder as a volume on a public server and run quarkus tls extension on the development machine, accessing public server's management interface?
From the documentation it looks like quarkus tls extension only stores letsencrypt certificates locally and doesn't transfer them via the management interface. This then requires to somehow manually copy certificates to the .letsencrypt folder of the public server, which is rather bad DX in my opinion. Alternatively, you need to rebuild the image with the new certs and do this every time you renew certificates, which is even worse DX, as letsencrypt certs are short lived, not even close to the advertised automatic certificate management.
Another question is how all this is supposed to be deployed in an automated deployment environment.
Beta Was this translation helpful? Give feedback.
All reactions