cavecafe
commented
1 month ago Hi @adrielairaldo, Thanks for your interest. I'm currently using this project outcome with my Kubernetes Cluster. I think, you can do the similar ways.
Just one note, let's say your project use port 5500 your own propose. For ACME, you can use any other ports such as 5443, 5080 in your container. As you know single server can serve with multiple ports, incoming ACME validation can be mapped (forwarded) 443->5443, 80->5080 in your Azure environment yet, your port 5500 still can be served with the same SSL certificate.
Cheers! Thomas
Hey Tomas! This is great!
Now, if I'm understanding correctly the idea of the project is to run this application persistently to generate the certificates automatically.
Let'sEncrypt ends its challenge on port 80, so your domain should always be available on port 80 for the challenge path, correct?
Right now I am thinking about how to develop an add-on for my .Net services, in which I can have running in an automated way a service for the generation/renewal of certificates at the same time of the service in which they are. This way, everything can run in a single container, occupying a minimum weight.
Let's take an example: I have a Web API, and I want to deploy that API in Azure Container Apps (for example). When deploying this container, I would automatically run the certificate generation/renewal service (in a Hosted Service, for example), and its implementation would be simply to provide the domain details and so on.
I think something could be achieved by simply injecting the corresponding service, and having the settings in appsettings.json (or inject them in pipeline, or read them from secrets or KeyVault, or similar). This would avoid manipulating the Builder, it would be limited to just adding the dependency in Nuget and injecting the service.
How do you see it?