I’m seeking clarification about domain validation. I am looking at the possibility of using Let’s Encrypt with Octopus Deploy (OD) to have regular certificates rolled out to the server itself and ideally use the same certificate for the RDP access to that server.
I have created steps to execute with OD that assist with domain validation via DNS. The reason for going for DNS DV is because the OD server is hosted at the https address. OD runs its own NancyFx http server. I don’t control how OD responds to https requests therefore I can’t do DV via http.
I can do DNS validation, however our DNS provider does not support any automation via an API. I don’t control the corp DNS so a change away from this provider is unlikely.
From what I can understand, DV needs to occur reasonably regularly, something like every 90-100 days. If I can’t automate http nor DNS DV, am I right in assuming that there is no other way to completely automate rolling out certificates to the OD server?
I’m not familiar with Octopus Deploy. Broadly speaking, what does it do? Does the NancyFx server listen on both 443 and 80?
Hi @roryprimrose, related to @jsha’s question, can you control how OD/NancyFx responds to (specific) HTTP requests?
How much influence over the DNS do you have? Can you get some CNAME records set up once, and delegate a subdomain to different DNS servers?
You could, for example, delegate
acme.example.com. to a different provider that can be managed programatically, and have your DNS team set up records like
_acme-challenge.www.example.com. CNAME www.acme.example.com. to use it.
You could use pretty much anything for it. BIND and
nsupdate on one of your servers, acme-dns, Amazon Route 53…
I work for Octopus Deploy, and thank you for our UV suggestion (https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/17858140-add-let-s-encrypt-automation-to-od-server for future people with the same query). LetsEncrypt support is something on our minds since we’ve added the certificate management feature. However until we do, perhaps there is a workaround.
I am not super familiar with the ins and outs of letsencrypt, but I do note that in the documentation for the manual method mentions that only port 80 is needed. If you have Octopus running on HTTPS (443), there should be no conflict. To answer @jsha’s question, we allow the user to configure the ports and paths.
Another option, if letsencrypt supports it is to run the DV server in a sub folder (eg http://example.com/letencrypt) and Octopus on http://example.com. Or perhaps the reverse. We cooperate with Windows HTTPSYS to allow multiple processes to listen on the same port.
If there is something simple we could do (eg forward a particular path to another process), please let us know on our UV ticker.
Thanks for the update @droyad! I can confirm that, from Let’s Encrypt’s perspective, you only need to be able to listen on port 80, or serve the sub folder
Awesome feedback guys. Thank you. I’ll have a think about the best path forward.
Unfortunately this is a showstopper for one client because their OD server is on an internal network rather than a DMZ exposed to the internet and their DNS provider does not support automation.
I think there is a good path forward however for other OD servers that are exposed to the internet. Running IIS over http with a mime type mapping of . = text/plain looks like it will work nicely.
I will be able to adjust my OD steps to request a new DV via http, write the DV challenge to a location exposed by IIS over http, then continue with the installation on the OD server.
Thanks for the pointers everyone.
2 posts were merged into an existing topic: Can I`Use This Let’s Encrypt
FYI, I’ve posted the individual steps I put together for doing DNS domain validation via Octopus Deploy steps. See http://www.neovolve.com/2017/02/01/octopus-deploy-lets-encrypt-dns/
I like that article and the way you worked through the problem!
Thanks for posting
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.