Hello,
I need to obtain certificates with HTTP-01 challenge with an ACME client in .NET.
I understand how to obtain certificates with HTTP-01 challenges, but I couldn't find any information regarding the renewal of these.
Should I simply request a new certificate for a domain after a certain period of time? If this isn't the correct method, then what is the proper way of renewing certificates obtained with HTTP-01 challenges?
Each ACME Client should describe the renewal process it uses. There is no one specific method.
Which one are you using?
I was looking at Certes, it's one of the clients listed on the official Let's Encrypt website, but probably renewal is not possible with it
Technically, renewal is just a brand new certificate with the same hostnames as a previous cert. If that client doesn't support a renewal option, you probably are meant to simply issue the same cert again. Although most clients do have some renew option, because most clients also store the clients and manage that storage et cetera.
Please note that Let's Encrypt recommends to renew when the certificate has 30 days validity left (i.e. 60 days from the initial issuance). As your client doesn't have any renewal option, it's your job to make sure you don't "renew" too early or too late.
Just adding onto Osiris comment ... Certes is just an API so you must manage the certs and their renewal. You need to manage the certs and renewal.
There are other ACME Clients designed for Windows that handle automated renewal (and more). Certify the Web is easiest to use and has a gui. Certify is probably the most popular choice on Windows. win-acme also has renewal built-in. See the Windows section of that same page for links to these.
If you want to do all the extra coding that's fine. If you just want the easier way to get and manage your certs look at these other options.
Thank you both for the clarification. I am doing the renewals via code, since I need to automate the process. I was confused, because I couldn't find renewal related info.
Since it's alright to issue a new certificate for the same hostname after 60 days, then this approach totally works for me.
Both Windows ACME Clients I mentioned have automated renewals included.
In general, many ACME Clients have that. It is not common for people to code their own.
I am on Linux, and the app is running in docker. Are you saying I shouldn't use the open source .NET ACME client?
Since you're using Linux and Docker, can you not use more established methods of obtaining certificates rather than trying to implement something from scratch? For example the most go-to client Certbot has an official Docker container, which may or may not be easier to integrate into whatever you're currently hosting.
Apart from the Certbot Docker container, there are many good ACME clients for Linux. You could probably more easily obtain and manage your certs in your Linux "host" and just share the cert files with your container.
But, no, if you must develop your own code for this app then Certes is fine. It is just this is often more complicated than people think. Not only is it harder, custom code requires ongoing maintenance. A full-featured ACME Client and cert manager is easier.
Valid points. I see that Certbot is really powerful, but I am not sure if I can use it. I should issue certificates for any domain CNAMEd to the domain where the server is running. I should be also able to move certificates between instances, so those certificates would be available on all running machines.
Correct me if I am wrong, but what happens if I get a certificate with Certbot on one instance, could I move the private key and the certificate to another instance and tell the other Certbot running there to use the existing certificate? If this is possible, then I am all for it.
Are these just for a small number or are you developing a service with outside customers?
You would usually only have Certbot running in one place. One example is to use the --webroot method which has Certbot placing a file in the "Document Root" of the server. This would be a "volume" (directory) shared with your server container. Certbot would place the certs in its /etc/letsencrypt/live folder so also share that with your containers.
Certbot's "renew" command reviews all the certs you have gotten and renews each one as it is needed. You periodically need to reload your containers so they pickup any fresh cert.
It is easy enough to copy private keys and cert file(s) between servers or containers. But, copying between multiple Certbot instances won't work well. Certbot has a specific directory structure that must be maintained (symlinks, archive, accounts, ...). It also uses renewal profiles. It is not appropriate to inject files into Certbot folders. Sometimes people run several virtual machines and have a Certbot in each. You just don't copy between them and let each manage itself. In this case you must be aware of Let's Encrypt Rate Limits.
Many domains can be CNAMEd to the main one, there is no limit. A certificate is required for each one.
Let's say 2 instances are running the same service and on each there's a Certbot. What happens is, one instance issues a certificate for a domain, but the other one not. A request can go to the instance which doesn't have the certificate.
I think the most straightforward solution would be to have a Certbot sitting where the web server is (e.g. Nginx) and let it issue certificates. If it's possible to issue a certificate for an incoming CNAMEd domain on the fly then it's great, but it would require to restart the web server.
Sounds like a load balancer is involved. Yes? If so then wouldn't you terminate HTTPS at the load balancer and then just use HTTP from that to each instance?
Yes, but wouldn't that mean short downtimes in the system? Let's say request comes from a CNAMEd domain, it has no certificate, so one is issued with Certbot. Wouldn't that mean a restart is necessary for the certificate to be loaded?
To be honest I am not quite sure how this works, but it looks doable. Though it would be great if restarts would not be necessary...
Yeah, there will always be possibility of downtime if you don't get certs in advance. Let's Encrypt may be down for example. Or there might be a backbone comms problem. When you setup the CNAME you could explicitly request a cert so it is available before the first "real" request.
You might want to look at something like Caddy which handles the certs and proxying. https://caddyserver.com/
Your design is starting to sound something like that.
I have no words, this is most likely what I need! Thank you so much.
You are very welcome. Yes, we came a long way from ... 
Hope Caddy works out for you.